AnsweredAssumed Answered

vrf Propagation Puzzle

Question asked by VRFuser on Jun 16, 2003

Like • Show 0 Likes0
Comment • 16

> add of a dummy *junction* before
> pinging the *next* object

Pierre, that is amazing! I'm happily wrong and thanks for the tip.
-SHAWN-

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".

No one else has this question

Outcomes

16 Replies

VRFuser Jun 11, 2003 7:51 PM
Mark Correct
Correct Answer

     Unless I am missing something the original Vee program with the message box
     next, continue and break works correctly. The next meaning is to continue within the loop
     of the Until Break, the continue pin hangs and is not handled which means continue
     within the loop of the Until Break and the break goes the bottom sequence
     pin of the Until Break box and then stops. In a loop or outside a loop you need to handle
     all the sequence pins or the understanding of your program may present problems.

Harry Walker

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Like • Show 0 Likes0
Actions
bill.ossmann Jun 11, 2003 8:31 PM
Mark Correct
Correct Answer
This does seem peculiar. I note that the behavior is the same if you replace the dialog box with either a pair of "OK" buttons or an If/Then/Else.

In any of these cases, if you watch the propagation flow you see that after the "Next" operates, the UntilBreak does NOT fire again as I would expect. I've had this sort of problem before, and been frustrated by it, but I never reduced it to a simple
enough example like this to see that it wasn't just a simple misconception of the way Next works.

--
Bill Ossmann
Philips Ultrasound
e-mail: bill.ossmann@philips.com

                                                   To:   "VEE vrf" <vrf@it.lists.it.agilent.com>
                                                   cc:   (bcc: Bill Ossmann/ANR/MS/PHILIPS)
                                                   Subject:    [vrf] Propagation Puzzle

               Peter_M_Fender@raytheon.            Classification:                               Unclassified
               com

               06/12/2003 11:39
               Please respond to
               Peter_M_Fender

The enclosed program does not flow the way I would expect it to.
Continue and Break work as I would expect, but the Next seems to not know
it's in a loop, and flows the same as Continue.
The key elements seem to be a Junction followed by a Message Box.
(It took awhile to boil this down from a larger program.)
It works the same on VEE 5.01 and VEE Pro 6.1.
Is this a bug, or a feature?

(See attached file: Flow Test3.vee)

Peter Fender
Raytheon Network Centric Systems
St. Petersburg, FL

---
You are currently subscribed to vrf as: bill.ossmann@philips.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".

[attachment "Flow Test3.vee" deleted by Bill Ossmann/ANR/MS/PHILIPS]

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Like • Show 0 Likes0
Actions
peter_m_fender Jun 11, 2003 8:39 PM
Mark Correct
Correct Answer
Like • Show 0 Likes0
Actions
michael.asbery Jun 11, 2003 9:45 PM
Mark Correct
Correct Answer
> PS: I bet you Scott is going to tell somebody to join ADN and
> submit a bug report, even though by reading this thread he
> has already received it including the VEE example he needs. )

:-)

Regards,

Scott Bayes
Software Technical Support

Agilent Technologies, Inc.
815 14th Street S.W.
Loveland, CO, U.S.A. 80537

970 679 3799 Tel
970 635 6867 Fax

> -----Original Message-----
> From: Gerard Geurts [mailto:gerard.geurts@connectix.co.uk]
> Sent: Thursday, June 12, 2003 10:50 AM
> To: VEE vrf
> Subject: [vrf] Re: Propagation Puzzle
>
>
> I had another look at it, and do agree now there is something
> strange happening. A look in the help file (VEE 5) reveals:
>
> Execution of the subthread hosted by the Until Break output
> continues until one of the following occurs:
>
> *     All objects that can, have operated; the subthread is
> deactivated. The subthread is reactivated by refiring the
> Until Break output until a Break object is encountered.
> *     A Break object operates . The subthread is deactivated
> and the sequence output pin is activated.
> *     A Next object operates. The subthread is deactivated
> then reactivated by refiring the Until Break output until a
> Break object is encountered.
>
> When the 'continue' button is pressed the first option should
> happen, since not all objects that can be activated have done
> so yet. This works fine. When the 'next' button is pressed
> and the next object operates then the third option should
> happen, but it doesn't. Somehow VEE gets confused with the
> multiple inputs into the junction object, and picks up
> execution where it left of.
>
> Observation: take the message box away and connect the next
> object directly to the data flow pin on the alphanumeric
> display. Only zeros are displayed. It appears that inserting
> the messagebox causes the strange behaviour.
>
> Gerard
>
> PS: I bet you Scott is going to tell somebody to join ADN and
> submit a bug report, even though by reading this thread he
> has already received it including the VEE example he needs. )
>
>
>
>
> -----Original Message-----
> From: bill.ossmann@philips.com [mailto:bill.ossmann@philips.com]
> Sent: Thursday, 12 June 2003 17:32
> To: VEE vrf
> Subject: [vrf] Re: Propagation Puzzle
>
>
> This does seem peculiar. I note that the behavior is the same
> if you replace the dialog box with either a pair of "OK"
> buttons or an If/Then/Else.
>
> In any of these cases, if you watch the propagation flow you
> see that after the "Next" operates, the UntilBreak does NOT
> fire again as I would expect. I've had this sort of problem
> before, and been frustrated by it, but I never reduced it to a simple
> enough example like this to see that it wasn't just a simple
> misconception of the way Next works.
>
> --
> Bill Ossmann
> Philips Ultrasound
> e-mail: bill.ossmann@philips.com
>
>
>
> Peter Fender
> Raytheon Network Centric Systems
> St. Petersburg, FL
>
>
>
> ---
> You are currently subscribed to vrf as: bill.ossmann@philips.com
> To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
> To unsubscribe send a blank email to
> "leave-vrf@it.lists.it.agilent.com".
> To send messages to this mailing list, email
> "vrf@it.lists.it.agilent.com".
> If you need help with the mailing list send a message to
> "owner-vrf@it.lists.it.agilent.com".
>
>
> [attachment "Flow Test3.vee" deleted by Bill Ossmann/ANR/MS/PHILIPS]
>
>
>
>
>
>
> ---
> You are currently subscribed to vrf as: gerard.geurts@connectix.co.uk
> To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
> To unsubscribe send a blank email to
> "leave-vrf@it.lists.it.agilent.com".
> To send messages to this mailing list, email
> "vrf@it.lists.it.agilent.com".
> If you need help with the mailing list send a message to
> "owner-vrf@it.lists.it.agilent.com".
>
> ---
> You are currently subscribed to vrf as: scott_bayes@agilent.com
> To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
> To unsubscribe send a blank email to
> "leave-vrf@it.lists.it.agilent.com".
> To send messages to this mailing list, email
> "vrf@it.lists.it.agilent.com".
> If you need help with the mailing list send a message to
> "owner-vrf@it.lists.it.agilent.com".
>

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Like • Show 0 Likes0
Actions
VRFuser Jun 11, 2003 10:16 PM
Mark Correct
Correct Answer
> PS: I bet you Scott is going to tell somebody to join ADN and
> submit a bug report, even though by reading this thread he
> has already received it including the VEE example he needs. )

:-)

Regards,

Scott Bayes
Software Technical Support

Agilent Technologies, Inc.
815 14th Street S.W.
Loveland, CO, U.S.A. 80537

970 679 3799 Tel
970 635 6867 Fax

> -----Original Message-----
> From: Gerard Geurts [mailto:gerard.geurts@connectix.co.uk]
> Sent: Thursday, June 12, 2003 10:50 AM
> To: VEE vrf
> Subject: [vrf] Re: Propagation Puzzle
>
>
> I had another look at it, and do agree now there is something
> strange happening. A look in the help file (VEE 5) reveals:
>
> Execution of the subthread hosted by the Until Break output
> continues until one of the following occurs:
>
> *     All objects that can, have operated; the subthread is
> deactivated. The subthread is reactivated by refiring the
> Until Break output until a Break object is encountered.
> *     A Break object operates . The subthread is deactivated
> and the sequence output pin is activated.
> *     A Next object operates. The subthread is deactivated
> then reactivated by refiring the Until Break output until a
> Break object is encountered.
>
> When the 'continue' button is pressed the first option should
> happen, since not all objects that can be activated have done
> so yet. This works fine. When the 'next' button is pressed
> and the next object operates then the third option should
> happen, but it doesn't. Somehow VEE gets confused with the
> multiple inputs into the junction object, and picks up
> execution where it left of.
>
> Observation: take the message box away and connect the next
> object directly to the data flow pin on the alphanumeric
> display. Only zeros are displayed. It appears that inserting
> the messagebox causes the strange behaviour.
>
> Gerard
>
> PS: I bet you Scott is going to tell somebody to join ADN and
> submit a bug report, even though by reading this thread he
> has already received it including the VEE example he needs. )
>
>
>
>
> -----Original Message-----
> From: bill.ossmann@philips.com [mailto:bill.ossmann@philips.com]
> Sent: Thursday, 12 June 2003 17:32
> To: VEE vrf
> Subject: [vrf] Re: Propagation Puzzle
>
>
> This does seem peculiar. I note that the behavior is the same
> if you replace the dialog box with either a pair of "OK"
> buttons or an If/Then/Else.
>
> In any of these cases, if you watch the propagation flow you
> see that after the "Next" operates, the UntilBreak does NOT
> fire again as I would expect. I've had this sort of problem
> before, and been frustrated by it, but I never reduced it to a simple
> enough example like this to see that it wasn't just a simple
> misconception of the way Next works.
>
> --
> Bill Ossmann
> Philips Ultrasound
> e-mail: bill.ossmann@philips.com
>
>
>
> Peter Fender
> Raytheon Network Centric Systems
> St. Petersburg, FL
>
>
>
> ---
> You are currently subscribed to vrf as: bill.ossmann@philips.com
> To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
> To unsubscribe send a blank email to
> "leave-vrf@it.lists.it.agilent.com".
> To send messages to this mailing list, email
> "vrf@it.lists.it.agilent.com".
> If you need help with the mailing list send a message to
> "owner-vrf@it.lists.it.agilent.com".
>
>
> [attachment "Flow Test3.vee" deleted by Bill Ossmann/ANR/MS/PHILIPS]
>
>
>
>
>
>
> ---
> You are currently subscribed to vrf as: gerard.geurts@connectix.co.uk
> To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
> To unsubscribe send a blank email to
> "leave-vrf@it.lists.it.agilent.com".
> To send messages to this mailing list, email
> "vrf@it.lists.it.agilent.com".
> If you need help with the mailing list send a message to
> "owner-vrf@it.lists.it.agilent.com".
>
> ---
> You are currently subscribed to vrf as: scott_bayes@agilent.com
> To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
> To unsubscribe send a blank email to
> "leave-vrf@it.lists.it.agilent.com".
> To send messages to this mailing list, email
> "vrf@it.lists.it.agilent.com".
> If you need help with the mailing list send a message to
> "owner-vrf@it.lists.it.agilent.com".
>

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Like • Show 0 Likes0
Actions
VRFuser Jun 12, 2003 12:22 AM
Mark Correct
Correct Answer
Peter,

Not having a 'break' is the same as having a 'next' in this case. I'd say the behaviour is as should be expected, with the next and continue options on your dialog box giving exactly the same response.

Switch on execution and data flow and monitor what happens when you press various buttons, and you should see what is going on. Maybe the dialog box is connected to the rest of the program in the wrong place to get the behaviour you want?

Regards

Gerard Geurts
Connectix Ltd

-----Original Message-----
From: Peter_M_Fender@raytheon.com [mailto:Peter_M_Fender@raytheon.com]
Sent: Thursday, 12 June 2003 16:40
To: VEE vrf
Subject: [vrf] Propagation Puzzle

The enclosed program does not flow the way I would expect it to.
Continue and Break work as I would expect, but the Next seems to not know
it's in a loop, and flows the same as Continue.
The key elements seem to be a Junction followed by a Message Box.
(It took awhile to boil this down from a larger program.)
It works the same on VEE 5.01 and VEE Pro 6.1.
Is this a bug, or a feature?

(See attached file: Flow Test3.vee)

Peter Fender
Raytheon Network Centric Systems
St. Petersburg, FL

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Like • Show 0 Likes0
Actions
VRFuser Jun 12, 2003 1:57 AM
Mark Correct
Correct Answer
Peter,

Not having a 'break' is the same as having a 'next' in this case. I'd say the behaviour is as should be expected, with the next and continue options on your dialog box giving exactly the same response.

Switch on execution and data flow and monitor what happens when you press various buttons, and you should see what is going on. Maybe the dialog box is connected to the rest of the program in the wrong place to get the behaviour you want?

Regards

Gerard Geurts
Connectix Ltd

-----Original Message-----
From: Peter_M_Fender@raytheon.com [mailto:Peter_M_Fender@raytheon.com]
Sent: Thursday, 12 June 2003 16:40
To: VEE vrf
Subject: [vrf] Propagation Puzzle

The enclosed program does not flow the way I would expect it to.
Continue and Break work as I would expect, but the Next seems to not know
it's in a loop, and flows the same as Continue.
The key elements seem to be a Junction followed by a Message Box.
(It took awhile to boil this down from a larger program.)
It works the same on VEE 5.01 and VEE Pro 6.1.
Is this a bug, or a feature?

(See attached file: Flow Test3.vee)

Peter Fender
Raytheon Network Centric Systems
St. Petersburg, FL

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Like • Show 0 Likes0
Actions
VRFuser Jun 12, 2003 2:49 AM
Mark Correct
Correct Answer
Hi Gonzalo,

> I had a situation in which I grouped a bunch of VEE objects
> that were inside
> a nested until break/for loop, these objects repeated
> themselves several

[deleted]

In my discussion with R&D today, the grouping of objects inside a loop did come up. It's an area where VEE is known to have some problems. It's likely that the compiler is involved in these problems, because creating a compiler for a language like VEE is immensely difficult and requires some bleeding-edge software technology. You could see whether setting Execution Mode 3 (i.e. non-compiled) helps, though the odds are that modern VEE applications use features not found in VEE 3, so this would not be a very practical idea except as an experiment.

> One final thing that I noticed is that when a function is
> executed, VEE
> continues the execution/flow of the program by flowing data from the
> uppermost pin to the lower most output pin of the
> function/object. I didnot

I think you're talking about "sequence pins", on the top and bottom. These are not really "data" pins, they are meant to control flow of execution when execution control is necessary, and the contents of the data sent on them is irrelevant. The pins on the sides of the object (mostly) send and receive the actual data such as text or numbers, etc, though there can be Error and Control and XEQ pins on the sides as well.

To learn about this stuff, you'll want to read Chapter 1 of the VEE User's Guide, especially the part that covers "Understanding Pins and Terminals", and later in the chapter, "How Agilent VEE Programs Work". Chapter 2 is also very important for understanding how VEE programming works.

(Sorry Gerard If you want to make the enhancement suggestion about rearranging pins, you should go to the ADN and submit it as a defect. We'll understand that it's actually an enhancement request and will put it in the correct form for R&D to consider.

Regards,

Scott Bayes
Software Technical Support

Agilent Technologies, Inc.
815 14th Street S.W.
Loveland, CO, U.S.A. 80537

970 679 3799 Tel
970 635 6867 Fax

> -----Original Message-----
> From: Gonzalo Urday [mailto:gurday@negenex.com]
> Sent: Thursday, June 12, 2003 4:48 PM
> To: 'BAYES,SCOTT (A-Loveland,ex1)'; 'VEE vrf'
> Cc: 'Gerard Geurts'
> Subject: RE: [vrf] Re: Propagation Puzzle
>
>
> Hello VEErs:
>
> I had a situation in which I grouped a bunch of VEE objects
> that were inside
> a nested until break/for loop, these objects repeated
> themselves several
> times in my program so I created a function to replaced
> them....in the first
> case the flow would continue to other objects normally and at
> the end VEE
> would return to the for count object as expected, but when I
> replaced the
> grouped objects with the function the flow of the program
> would stop after
> the function executed and then returned to the for count
> object, cutting
> short the execution of the program. I did many, many things
> to try to fix
> this situation, but given that I am new with VEE I thought
> that I was doing
> something wrong and when back to the "known working evil"
> ... but looking
> at it now, it may be a similar situation as the one now we
> are discussing,
> fyi my program does have multiple JCTs.....I'll see if I can shrink my
> program and make sure that the problem continues and email to
> the group.
>
> One final thing that I noticed is that when a function is
> executed, VEE
> continues the execution/flow of the program by flowing data from the
> uppermost pin to the lower most output pin of the
> function/object. I didnot
> know that, until my program flowed in a way that I was not
> expecting (the
> end result was the same, but it was more difficult to
> follow), JUST as a
> suggestion to the R&D team, it would be nice if one could
> just drag and
> drop, (ie move around) the input/output pins of objects and
> functions rather
> than delete them and placing them again in the order that one
> wants to have
> them.
>
> Hope I have contributed to this discussion
>
> Rgds
>
> Gonzalo
>
> -----Original Message-----
> From: BAYES,SCOTT (A-Loveland,ex1) [mailto:scott_bayes@agilent.com]
> Sent: Thursday, June 12, 2003 5:23 PM
> To: VEE vrf
> Cc: 'Gerard Geurts'
> Subject: [vrf] Re: Propagation Puzzle
>
>
> OK, Gerard shamed me into investigating in more detail
> (Support has been
> hectic today and for the last few weeks, so I couldn't get to it right
> away).
>
> I wrote an even smaller program that I've attached that shows
> the topology
> that appears to be critical for this problem, with some interesting
> variations. The key factor appears to be that the Until Break
> is on one side
> of a junction and the Next (or Break) is on the other. I
> talked with R&D and
> this is a known problem, probably extremely difficult to
> solve. May already
> be in the defect database, I haven't had a chance to look yet.
>
> The probable cause is that the Next (or Break) can't
> communicate back to its
> repeat object (whether that's an Until Break, For, or maybe
> On Cycle) across
> the junction (JCT). In a way it makes sense: a JCT's job is
> to pass anything
> it sees on its inputs to its output without regard for the
> flow control rule
> that says that all inputs must be satisfied before it will
> fire the output.
> As long as it gets at least one container input, it fires,
> and consequently
> apparently loses track of where the container originated, so
> can't inform
> the Until Break that it should send out a new container immediately.
>
> There are probably other problems involved with flow across a
> JCT, or other
> symptoms of the same problem. Scotts.Toy.vee (attached)
> demonstrates my
> little investigation.
>
> When you load Scotts.Toy.vee, turn on "Show Data Flow"
> debugging before you
> run it, so you can watch the data flow. There are four
> separate threads, all
> similar, but different in what the JCT outputs to.
>
> You'll see that if there's a Next or a Break on the output of
> the JCT, then
> Until Break doesn't even fire (nor does its sequence pin) or
> may only fire
> once, whether you use Run or press one of the Start buttons.
> These threads
> operate incorrectly and demonstrate the defect.
>
> But if there's nothing connected, or a non-flow object like
> an Alphanumeric
> instead, then Until Break cycles as expected. And if you put a Break
> somewhere on the left side of the JCT, then Until Break's
> sequence pin fires
> after the Break is seen by it, as expected. These two threads operate
> correctly.
>
> Bill Ossmann has kindly submitted a defect that simplifies
> the original
> demonstration program, and I will submit it together with
> Scotts.Toy to the
> defect database.
>
> One advantage of submitting defects via ADN is that
> evaluating and inputting
> defect submissions is part of my job, but reading the vrf is not.
>
> However, reading the vrf is a lot more fun!
>
>
>
> Regards to all,
>
>
> Scott Bayes
> Software Technical Support
>
> Agilent Technologies, Inc.
> 815 14th Street S.W.
> Loveland, CO, U.S.A. 80537
>
> 970 679 3799 Tel
> 970 635 6867 Fax
>
> > -----Original Message-----
> > From: Gerard Geurts [mailto:gerard.geurts@connectix.co.uk]
> > Sent: Thursday, June 12, 2003 10:50 AM
> > To: VEE vrf
> > Subject: [vrf] Re: Propagation Puzzle
> >
> >
> > I had another look at it, and do agree now there is something
> > strange happening. A look in the help file (VEE 5) reveals:
> >
> > Execution of the subthread hosted by the Until Break output
> > continues until one of the following occurs:
> >
> > *     All objects that can, have operated; the subthread is
> > deactivated. The subthread is reactivated by refiring the
> > Until Break output until a Break object is encountered.
> > *     A Break object operates . The subthread is deactivated
> > and the sequence output pin is activated.
> > *     A Next object operates. The subthread is deactivated
> > then reactivated by refiring the Until Break output until a
> > Break object is encountered.
> >
> > When the 'continue' button is pressed the first option should
> > happen, since not all objects that can be activated have done
> > so yet. This works fine. When the 'next' button is pressed
> > and the next object operates then the third option should
> > happen, but it doesn't. Somehow VEE gets confused with the
> > multiple inputs into the junction object, and picks up
> > execution where it left of.
> >
> > Observation: take the message box away and connect the next
> > object directly to the data flow pin on the alphanumeric
> > display. Only zeros are displayed. It appears that inserting
> > the messagebox causes the strange behaviour.
> >
> > Gerard
> >
> > PS: I bet you Scott is going to tell somebody to join ADN and
> > submit a bug report, even though by reading this thread he
> > has already received it including the VEE example he needs. )
> >
> >
> >
> >
> > -----Original Message-----
> > From: bill.ossmann@philips.com [mailto:bill.ossmann@philips.com]
> > Sent: Thursday, 12 June 2003 17:32
> > To: VEE vrf
> > Subject: [vrf] Re: Propagation Puzzle
> >
> >
> > This does seem peculiar. I note that the behavior is the same
> > if you replace the dialog box with either a pair of "OK"
> > buttons or an If/Then/Else.
> >
> > In any of these cases, if you watch the propagation flow you
> > see that after the "Next" operates, the UntilBreak does NOT
> > fire again as I would expect. I've had this sort of problem
> > before, and been frustrated by it, but I never reduced it
> to a simple
> > enough example like this to see that it wasn't just a simple
> > misconception of the way Next works.
> >
> > --
> > Bill Ossmann
> > Philips Ultrasound
> > e-mail: bill.ossmann@philips.com
> >
> >
> >
> > Peter Fender
> > Raytheon Network Centric Systems
> > St. Petersburg, FL
> >
> >
> >
> > ---
> > You are currently subscribed to vrf as: bill.ossmann@philips.com
> > To subscribe send a blank email to
> "join-vrf@it.lists.it.agilent.com".
> > To unsubscribe send a blank email to
> > "leave-vrf@it.lists.it.agilent.com".
> > To send messages to this mailing list, email
> > "vrf@it.lists.it.agilent.com".
> > If you need help with the mailing list send a message to
> > "owner-vrf@it.lists.it.agilent.com".
> >
> >
> > [attachment "Flow Test3.vee" deleted by Bill Ossmann/ANR/MS/PHILIPS]
> >
> >
> >
> >
> >
> >
> > ---
> > You are currently subscribed to vrf as:
> gerard.geurts@connectix.co.uk
> > To subscribe send a blank email to
> "join-vrf@it.lists.it.agilent.com".
> > To unsubscribe send a blank email to
> > "leave-vrf@it.lists.it.agilent.com".
> > To send messages to this mailing list, email
> > "vrf@it.lists.it.agilent.com".
> > If you need help with the mailing list send a message to
> > "owner-vrf@it.lists.it.agilent.com".
> >
> > ---
> > You are currently subscribed to vrf as: scott_bayes@agilent.com
> > To subscribe send a blank email to
> "join-vrf@it.lists.it.agilent.com".
> > To unsubscribe send a blank email to
> > "leave-vrf@it.lists.it.agilent.com".
> > To send messages to this mailing list, email
> > "vrf@it.lists.it.agilent.com".
> > If you need help with the mailing list send a message to
> > "owner-vrf@it.lists.it.agilent.com".
> >
>
>

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Like • Show 0 Likes0
Actions
VRFuser Jun 12, 2003 2:49 AM
Mark Correct
Correct Answer
I had another look at it, and do agree now there is something strange happening. A look in the help file (VEE 5) reveals:

Execution of the subthread hosted by the Until Break output continues until one of the following occurs:

*     All objects that can, have operated; the subthread is deactivated. The subthread is reactivated by refiring the Until Break output until a Break object is encountered.
*     A Break object operates . The subthread is deactivated and the sequence output pin is activated.
*     A Next object operates. The subthread is deactivated then reactivated by refiring the Until Break output until a Break object is encountered.

When the 'continue' button is pressed the first option should happen, since not all objects that can be activated have done so yet. This works fine. When the 'next' button is pressed and the next object operates then the third option should happen, but it doesn't. Somehow VEE gets confused with the multiple inputs into the junction object, and picks up execution where it left of.

Observation: take the message box away and connect the next object directly to the data flow pin on the alphanumeric display. Only zeros are displayed. It appears that inserting the messagebox causes the strange behaviour.

Gerard

PS: I bet you Scott is going to tell somebody to join ADN and submit a bug report, even though by reading this thread he has already received it including the VEE example he needs. )

-----Original Message-----
From: bill.ossmann@philips.com [mailto:bill.ossmann@philips.com]
Sent: Thursday, 12 June 2003 17:32
To: VEE vrf
Subject: [vrf] Re: Propagation Puzzle

This does seem peculiar. I note that the behavior is the same if you replace the dialog box with either a pair of "OK" buttons or an If/Then/Else.

In any of these cases, if you watch the propagation flow you see that after the "Next" operates, the UntilBreak does NOT fire again as I would expect. I've had this sort of problem before, and been frustrated by it, but I never reduced it to a simple
enough example like this to see that it wasn't just a simple misconception of the way Next works.

--
Bill Ossmann
Philips Ultrasound
e-mail: bill.ossmann@philips.com

Peter Fender
Raytheon Network Centric Systems
St. Petersburg, FL

---
You are currently subscribed to vrf as: bill.ossmann@philips.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".

[attachment "Flow Test3.vee" deleted by Bill Ossmann/ANR/MS/PHILIPS]

---
You are currently subscribed to vrf as: gerard.geurts@connectix.co.uk
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Like • Show 0 Likes0
Actions
jcmartin Jun 12, 2003 3:10 AM
Mark Correct
Correct Answer
Hello VEErs:

I had a situation in which I grouped a bunch of VEE objects that were inside
a nested until break/for loop, these objects repeated themselves several
times in my program so I created a function to replaced them....in the first
case the flow would continue to other objects normally and at the end VEE
would return to the for count object as expected, but when I replaced the
grouped objects with the function the flow of the program would stop after
the function executed and then returned to the for count object, cutting
short the execution of the program. I did many, many things to try to fix
this situation, but given that I am new with VEE I thought that I was doing
something wrong and when back to the "known working evil" ... but looking
at it now, it may be a similar situation as the one now we are discussing,
fyi my program does have multiple JCTs.....I'll see if I can shrink my
program and make sure that the problem continues and email to the group.

One final thing that I noticed is that when a function is executed, VEE
continues the execution/flow of the program by flowing data from the
uppermost pin to the lower most output pin of the function/object. I didnot
know that, until my program flowed in a way that I was not expecting (the
end result was the same, but it was more difficult to follow), JUST as a
suggestion to the R&D team, it would be nice if one could just drag and
drop, (ie move around) the input/output pins of objects and functions rather
than delete them and placing them again in the order that one wants to have
them.

Hope I have contributed to this discussion

Rgds

Gonzalo

-----Original Message-----
From: BAYES,SCOTT (A-Loveland,ex1) [mailto:scott_bayes@agilent.com]
Sent: Thursday, June 12, 2003 5:23 PM
To: VEE vrf
Cc: 'Gerard Geurts'
Subject: [vrf] Re: Propagation Puzzle

OK, Gerard shamed me into investigating in more detail (Support has been
hectic today and for the last few weeks, so I couldn't get to it right
away).

I wrote an even smaller program that I've attached that shows the topology
that appears to be critical for this problem, with some interesting
variations. The key factor appears to be that the Until Break is on one side
of a junction and the Next (or Break) is on the other. I talked with R&D and
this is a known problem, probably extremely difficult to solve. May already
be in the defect database, I haven't had a chance to look yet.

The probable cause is that the Next (or Break) can't communicate back to its
repeat object (whether that's an Until Break, For, or maybe On Cycle) across
the junction (JCT). In a way it makes sense: a JCT's job is to pass anything
it sees on its inputs to its output without regard for the flow control rule
that says that all inputs must be satisfied before it will fire the output.
As long as it gets at least one container input, it fires, and consequently
apparently loses track of where the container originated, so can't inform
the Until Break that it should send out a new container immediately.

There are probably other problems involved with flow across a JCT, or other
symptoms of the same problem. Scotts.Toy.vee (attached) demonstrates my
little investigation.

When you load Scotts.Toy.vee, turn on "Show Data Flow" debugging before you
run it, so you can watch the data flow. There are four separate threads, all
similar, but different in what the JCT outputs to.

You'll see that if there's a Next or a Break on the output of the JCT, then
Until Break doesn't even fire (nor does its sequence pin) or may only fire
once, whether you use Run or press one of the Start buttons. These threads
operate incorrectly and demonstrate the defect.

But if there's nothing connected, or a non-flow object like an Alphanumeric
instead, then Until Break cycles as expected. And if you put a Break
somewhere on the left side of the JCT, then Until Break's sequence pin fires
after the Break is seen by it, as expected. These two threads operate
correctly.

Bill Ossmann has kindly submitted a defect that simplifies the original
demonstration program, and I will submit it together with Scotts.Toy to the
defect database.

One advantage of submitting defects via ADN is that evaluating and inputting
defect submissions is part of my job, but reading the vrf is not.

However, reading the vrf is a lot more fun!

:-)

Regards to all,

Scott Bayes
Software Technical Support

Agilent Technologies, Inc.
815 14th Street S.W.
Loveland, CO, U.S.A. 80537

970 679 3799 Tel
970 635 6867 Fax

> -----Original Message-----
> From: Gerard Geurts [mailto:gerard.geurts@connectix.co.uk]
> Sent: Thursday, June 12, 2003 10:50 AM
> To: VEE vrf
> Subject: [vrf] Re: Propagation Puzzle
>
>
> I had another look at it, and do agree now there is something
> strange happening. A look in the help file (VEE 5) reveals:
>
> Execution of the subthread hosted by the Until Break output
> continues until one of the following occurs:
>
> *     All objects that can, have operated; the subthread is
> deactivated. The subthread is reactivated by refiring the
> Until Break output until a Break object is encountered.
> *     A Break object operates . The subthread is deactivated
> and the sequence output pin is activated.
> *     A Next object operates. The subthread is deactivated
> then reactivated by refiring the Until Break output until a
> Break object is encountered.
>
> When the 'continue' button is pressed the first option should
> happen, since not all objects that can be activated have done
> so yet. This works fine. When the 'next' button is pressed
> and the next object operates then the third option should
> happen, but it doesn't. Somehow VEE gets confused with the
> multiple inputs into the junction object, and picks up
> execution where it left of.
>
> Observation: take the message box away and connect the next
> object directly to the data flow pin on the alphanumeric
> display. Only zeros are displayed. It appears that inserting
> the messagebox causes the strange behaviour.
>
> Gerard
>
> PS: I bet you Scott is going to tell somebody to join ADN and
> submit a bug report, even though by reading this thread he
> has already received it including the VEE example he needs. )
>
>
>
>
> -----Original Message-----
> From: bill.ossmann@philips.com [mailto:bill.ossmann@philips.com]
> Sent: Thursday, 12 June 2003 17:32
> To: VEE vrf
> Subject: [vrf] Re: Propagation Puzzle
>
>
> This does seem peculiar. I note that the behavior is the same
> if you replace the dialog box with either a pair of "OK"
> buttons or an If/Then/Else.
>
> In any of these cases, if you watch the propagation flow you
> see that after the "Next" operates, the UntilBreak does NOT
> fire again as I would expect. I've had this sort of problem
> before, and been frustrated by it, but I never reduced it to a simple
> enough example like this to see that it wasn't just a simple
> misconception of the way Next works.
>
> --
> Bill Ossmann
> Philips Ultrasound
> e-mail: bill.ossmann@philips.com
>
>
>
> Peter Fender
> Raytheon Network Centric Systems
> St. Petersburg, FL
>
>
>
> ---
> You are currently subscribed to vrf as: bill.ossmann@philips.com
> To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
> To unsubscribe send a blank email to
> "leave-vrf@it.lists.it.agilent.com".
> To send messages to this mailing list, email
> "vrf@it.lists.it.agilent.com".
> If you need help with the mailing list send a message to
> "owner-vrf@it.lists.it.agilent.com".
>
>
> [attachment "Flow Test3.vee" deleted by Bill Ossmann/ANR/MS/PHILIPS]
>
>
>
>
>
>
> ---
> You are currently subscribed to vrf as: gerard.geurts@connectix.co.uk
> To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
> To unsubscribe send a blank email to
> "leave-vrf@it.lists.it.agilent.com".
> To send messages to this mailing list, email
> "vrf@it.lists.it.agilent.com".
> If you need help with the mailing list send a message to
> "owner-vrf@it.lists.it.agilent.com".
>
> ---
> You are currently subscribed to vrf as: scott_bayes@agilent.com
> To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
> To unsubscribe send a blank email to
> "leave-vrf@it.lists.it.agilent.com".
> To send messages to this mailing list, email
> "vrf@it.lists.it.agilent.com".
> If you need help with the mailing list send a message to
> "owner-vrf@it.lists.it.agilent.com".
>

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Like • Show 0 Likes0
Actions
gurday Jun 12, 2003 3:48 AM
Mark Correct
Correct Answer
Hello VEErs:

I had a situation in which I grouped a bunch of VEE objects that were inside
a nested until break/for loop, these objects repeated themselves several
times in my program so I created a function to replaced them....in the first
case the flow would continue to other objects normally and at the end VEE
would return to the for count object as expected, but when I replaced the
grouped objects with the function the flow of the program would stop after
the function executed and then returned to the for count object, cutting
short the execution of the program. I did many, many things to try to fix
this situation, but given that I am new with VEE I thought that I was doing
something wrong and when back to the "known working evil" ... but looking
at it now, it may be a similar situation as the one now we are discussing,
fyi my program does have multiple JCTs.....I'll see if I can shrink my
program and make sure that the problem continues and email to the group.

One final thing that I noticed is that when a function is executed, VEE
continues the execution/flow of the program by flowing data from the
uppermost pin to the lower most output pin of the function/object. I didnot
know that, until my program flowed in a way that I was not expecting (the
end result was the same, but it was more difficult to follow), JUST as a
suggestion to the R&D team, it would be nice if one could just drag and
drop, (ie move around) the input/output pins of objects and functions rather
than delete them and placing them again in the order that one wants to have
them.

Hope I have contributed to this discussion

Rgds

Gonzalo

-----Original Message-----
From: BAYES,SCOTT (A-Loveland,ex1) [mailto:scott_bayes@agilent.com]
Sent: Thursday, June 12, 2003 5:23 PM
To: VEE vrf
Cc: 'Gerard Geurts'
Subject: [vrf] Re: Propagation Puzzle

OK, Gerard shamed me into investigating in more detail (Support has been
hectic today and for the last few weeks, so I couldn't get to it right
away).

I wrote an even smaller program that I've attached that shows the topology
that appears to be critical for this problem, with some interesting
variations. The key factor appears to be that the Until Break is on one side
of a junction and the Next (or Break) is on the other. I talked with R&D and
this is a known problem, probably extremely difficult to solve. May already
be in the defect database, I haven't had a chance to look yet.

The probable cause is that the Next (or Break) can't communicate back to its
repeat object (whether that's an Until Break, For, or maybe On Cycle) across
the junction (JCT). In a way it makes sense: a JCT's job is to pass anything
it sees on its inputs to its output without regard for the flow control rule
that says that all inputs must be satisfied before it will fire the output.
As long as it gets at least one container input, it fires, and consequently
apparently loses track of where the container originated, so can't inform
the Until Break that it should send out a new container immediately.

There are probably other problems involved with flow across a JCT, or other
symptoms of the same problem. Scotts.Toy.vee (attached) demonstrates my
little investigation.

When you load Scotts.Toy.vee, turn on "Show Data Flow" debugging before you
run it, so you can watch the data flow. There are four separate threads, all
similar, but different in what the JCT outputs to.

You'll see that if there's a Next or a Break on the output of the JCT, then
Until Break doesn't even fire (nor does its sequence pin) or may only fire
once, whether you use Run or press one of the Start buttons. These threads
operate incorrectly and demonstrate the defect.

But if there's nothing connected, or a non-flow object like an Alphanumeric
instead, then Until Break cycles as expected. And if you put a Break
somewhere on the left side of the JCT, then Until Break's sequence pin fires
after the Break is seen by it, as expected. These two threads operate
correctly.

Bill Ossmann has kindly submitted a defect that simplifies the original
demonstration program, and I will submit it together with Scotts.Toy to the
defect database.

One advantage of submitting defects via ADN is that evaluating and inputting
defect submissions is part of my job, but reading the vrf is not.

However, reading the vrf is a lot more fun!

:-)

Regards to all,

Scott Bayes
Software Technical Support

Agilent Technologies, Inc.
815 14th Street S.W.
Loveland, CO, U.S.A. 80537

970 679 3799 Tel
970 635 6867 Fax

> -----Original Message-----
> From: Gerard Geurts [mailto:gerard.geurts@connectix.co.uk]
> Sent: Thursday, June 12, 2003 10:50 AM
> To: VEE vrf
> Subject: [vrf] Re: Propagation Puzzle
>
>
> I had another look at it, and do agree now there is something
> strange happening. A look in the help file (VEE 5) reveals:
>
> Execution of the subthread hosted by the Until Break output
> continues until one of the following occurs:
>
> *     All objects that can, have operated; the subthread is
> deactivated. The subthread is reactivated by refiring the
> Until Break output until a Break object is encountered.
> *     A Break object operates . The subthread is deactivated
> and the sequence output pin is activated.
> *     A Next object operates. The subthread is deactivated
> then reactivated by refiring the Until Break output until a
> Break object is encountered.
>
> When the 'continue' button is pressed the first option should
> happen, since not all objects that can be activated have done
> so yet. This works fine. When the 'next' button is pressed
> and the next object operates then the third option should
> happen, but it doesn't. Somehow VEE gets confused with the
> multiple inputs into the junction object, and picks up
> execution where it left of.
>
> Observation: take the message box away and connect the next
> object directly to the data flow pin on the alphanumeric
> display. Only zeros are displayed. It appears that inserting
> the messagebox causes the strange behaviour.
>
> Gerard
>
> PS: I bet you Scott is going to tell somebody to join ADN and
> submit a bug report, even though by reading this thread he
> has already received it including the VEE example he needs. )
>
>
>
>
> -----Original Message-----
> From: bill.ossmann@philips.com [mailto:bill.ossmann@philips.com]
> Sent: Thursday, 12 June 2003 17:32
> To: VEE vrf
> Subject: [vrf] Re: Propagation Puzzle
>
>
> This does seem peculiar. I note that the behavior is the same
> if you replace the dialog box with either a pair of "OK"
> buttons or an If/Then/Else.
>
> In any of these cases, if you watch the propagation flow you
> see that after the "Next" operates, the UntilBreak does NOT
> fire again as I would expect. I've had this sort of problem
> before, and been frustrated by it, but I never reduced it to a simple
> enough example like this to see that it wasn't just a simple
> misconception of the way Next works.
>
> --
> Bill Ossmann
> Philips Ultrasound
> e-mail: bill.ossmann@philips.com
>
>
>
> Peter Fender
> Raytheon Network Centric Systems
> St. Petersburg, FL
>
>
>
> ---
> You are currently subscribed to vrf as: bill.ossmann@philips.com
> To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
> To unsubscribe send a blank email to
> "leave-vrf@it.lists.it.agilent.com".
> To send messages to this mailing list, email
> "vrf@it.lists.it.agilent.com".
> If you need help with the mailing list send a message to
> "owner-vrf@it.lists.it.agilent.com".
>
>
> [attachment "Flow Test3.vee" deleted by Bill Ossmann/ANR/MS/PHILIPS]
>
>
>
>
>
>
> ---
> You are currently subscribed to vrf as: gerard.geurts@connectix.co.uk
> To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
> To unsubscribe send a blank email to
> "leave-vrf@it.lists.it.agilent.com".
> To send messages to this mailing list, email
> "vrf@it.lists.it.agilent.com".
> If you need help with the mailing list send a message to
> "owner-vrf@it.lists.it.agilent.com".
>
> ---
> You are currently subscribed to vrf as: scott_bayes@agilent.com
> To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
> To unsubscribe send a blank email to
> "leave-vrf@it.lists.it.agilent.com".
> To send messages to this mailing list, email
> "vrf@it.lists.it.agilent.com".
> If you need help with the mailing list send a message to
> "owner-vrf@it.lists.it.agilent.com".
>

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Like • Show 0 Likes0
Actions
VRFuser Jun 12, 2003 8:45 AM
Mark Correct
Correct Answer
Scott,

> It's likely that the compiler is involved
> in these problems, because creating a
> compiler for a language like VEE is immensely
> difficult and requires some bleeding-edge
> software technology.

That's interesting - I had pretty much chalked it up to an ambiguous problem
specification (program) rather than any bug. I can't do a serious BN
analysis, but it seems to me that the problem needs to be stated differently
in order to be solved correctly.

My pseudo-BN shows that one could consider the junction the "problem" as
there are conflicting flow directives on either side of it - so I guess this
is really a converse ambiguity. Is there such a thing? It not that there's
not enough information, there's too much

FWIW I don't think any visual language has solved this particular problem.
You just have to think differently to draw up the problem specification.
Say, where can I get my hands on this compiler... j/k take care
-SHAWN-

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Like • Show 0 Likes0
Actions
ramarquardt Jun 12, 2003 6:02 PM
Mark Correct
Correct Answer

The constructs that do NOT work would not work [in a predictable manner]
in any programming language. I doubt any compiler could catch one.
LINT might flag it if working with C or one of it's children.
To have a compiler catch this would require the compiler to analyze the
entire program flow which would be both slow and costly.
A run time error could be generated much more easily but would
have to be done in a special debug mode or interpreter mode
since the overhead to constantly monitor for this situation would
be a waste of resources.
Isn't it nice to know that us humans are still occasionally needed

Logical Problems:
Breaking before Entering the loop
Continuing before Entering the loop

Branching into loops from the outside
has always been a programming NO NO!

.....Rob

"BAYES,SCOTT (A-Loveland,ex1)" <scott_bayes@agilent.com> on 06/12/2003
04:22:38 PM

Please respond to "BAYES,SCOTT (A-Loveland,ex1)" <scott_bayes@agilent.com>

To:    "VEE vrf" <vrf@it.lists.it.agilent.com>
cc:    "'Gerard Geurts'" <gerard.geurts@connectix.co.uk>

Subject:    [vrf] Re: Propagation Puzzle

OK, Gerard shamed me into investigating in more detail (Support has been
hectic today and for the last few weeks, so I couldn't get to it right
away).

I wrote an even smaller program that I've attached that shows the topology
that appears to be critical for this problem, with some interesting
variations. The key factor appears to be that the Until Break is on one
side of a junction and the Next (or Break) is on the other. I talked with
R&D and this is a known problem, probably extremely difficult to solve. May
already be in the defect database, I haven't had a chance to look yet.

The probable cause is that the Next (or Break) can't communicate back to
its repeat object (whether that's an Until Break, For, or maybe On Cycle)
across the junction (JCT). In a way it makes sense: a JCT's job is to pass
anything it sees on its inputs to its output without regard for the flow
control rule that says that all inputs must be satisfied before it will
fire the output. As long as it gets at least one container input, it fires,
and consequently apparently loses track of where the container originated,
so can't inform the Until Break that it should send out a new container
immediately.

There are probably other problems involved with flow across a JCT, or other
symptoms of the same problem. Scotts.Toy.vee (attached) demonstrates my
little investigation.

When you load Scotts.Toy.vee, turn on "Show Data Flow" debugging before you
run it, so you can watch the data flow. There are four separate threads,
all similar, but different in what the JCT outputs to.

You'll see that if there's a Next or a Break on the output of the JCT, then
Until Break doesn't even fire (nor does its sequence pin) or may only fire
once, whether you use Run or press one of the Start buttons. These threads
operate incorrectly and demonstrate the defect.

But if there's nothing connected, or a non-flow object like an Alphanumeric
instead, then Until Break cycles as expected. And if you put a Break
somewhere on the left side of the JCT, then Until Break's sequence pin
fires after the Break is seen by it, as expected. These two threads operate
correctly.

Bill Ossmann has kindly submitted a defect that simplifies the original
demonstration program, and I will submit it together with Scotts.Toy to the
defect database.

One advantage of submitting defects via ADN is that evaluating and
inputting defect submissions is part of my job, but reading the vrf is not.

However, reading the vrf is a lot more fun!

:-)

Regards to all,

Scott Bayes
Software Technical Support

Agilent Technologies, Inc.
815 14th Street S.W.
Loveland, CO, U.S.A. 80537

970 679 3799 Tel
970 635 6867 Fax

> -----Original Message-----
> From: Gerard Geurts [mailto:gerard.geurts@connectix.co.uk]
> Sent: Thursday, June 12, 2003 10:50 AM
> To: VEE vrf
> Subject: [vrf] Re: Propagation Puzzle
>
>
> I had another look at it, and do agree now there is something
> strange happening. A look in the help file (VEE 5) reveals:
>
> Execution of the subthread hosted by the Until Break output
> continues until one of the following occurs:
>
> *   All objects that can, have operated; the subthread is
> deactivated. The subthread is reactivated by refiring the
> Until Break output until a Break object is encountered.
> *   A Break object operates . The subthread is deactivated
> and the sequence output pin is activated.
> *   A Next object operates. The subthread is deactivated
> then reactivated by refiring the Until Break output until a
> Break object is encountered.
>
> When the 'continue' button is pressed the first option should
> happen, since not all objects that can be activated have done
> so yet. This works fine. When the 'next' button is pressed
> and the next object operates then the third option should
> happen, but it doesn't. Somehow VEE gets confused with the
> multiple inputs into the junction object, and picks up
> execution where it left of.
>
> Observation: take the message box away and connect the next
> object directly to the data flow pin on the alphanumeric
> display. Only zeros are displayed. It appears that inserting
> the messagebox causes the strange behaviour.
>
> Gerard
>
> PS: I bet you Scott is going to tell somebody to join ADN and
> submit a bug report, even though by reading this thread he
> has already received it including the VEE example he needs. )
>
>
>
>
> -----Original Message-----
> From: bill.ossmann@philips.com [mailto:bill.ossmann@philips.com]
> Sent: Thursday, 12 June 2003 17:32
> To: VEE vrf
> Subject: [vrf] Re: Propagation Puzzle
>
>
> This does seem peculiar. I note that the behavior is the same
> if you replace the dialog box with either a pair of "OK"
> buttons or an If/Then/Else.
>
> In any of these cases, if you watch the propagation flow you
> see that after the "Next" operates, the UntilBreak does NOT
> fire again as I would expect. I've had this sort of problem
> before, and been frustrated by it, but I never reduced it to a simple
> enough example like this to see that it wasn't just a simple
> misconception of the way Next works.
>
> --
> Bill Ossmann
> Philips Ultrasound
> e-mail: bill.ossmann@philips.com
>
>
>
> Peter Fender
> Raytheon Network Centric Systems
> St. Petersburg, FL
>
>
>
> ---
> You are currently subscribed to vrf as: bill.ossmann@philips.com
> To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
> To unsubscribe send a blank email to
> "leave-vrf@it.lists.it.agilent.com".
> To send messages to this mailing list, email
> "vrf@it.lists.it.agilent.com".
> If you need help with the mailing list send a message to
> "owner-vrf@it.lists.it.agilent.com".
>
>
> [attachment "Flow Test3.vee" deleted by Bill Ossmann/ANR/MS/PHILIPS]
>
>
>
>
>
>
> ---
> You are currently subscribed to vrf as: gerard.geurts@connectix.co.uk
> To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
> To unsubscribe send a blank email to
> "leave-vrf@it.lists.it.agilent.com".
> To send messages to this mailing list, email
> "vrf@it.lists.it.agilent.com".
> If you need help with the mailing list send a message to
> "owner-vrf@it.lists.it.agilent.com".
>
> ---
> You are currently subscribed to vrf as: scott_bayes@agilent.com
> To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
> To unsubscribe send a blank email to
> "leave-vrf@it.lists.it.agilent.com".
> To send messages to this mailing list, email
> "vrf@it.lists.it.agilent.com".
> If you need help with the mailing list send a message to
> "owner-vrf@it.lists.it.agilent.com".
>

---
You are currently subscribed to vrf as: ramarquardt@ra.rockwell.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email
"vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to
"owner-vrf@it.lists.it.agilent.com".

<< Attachment clipped: Scotts.Toy.vee (13362 bytes ) >>

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Like • Show 0 Likes0
Actions
VRFuser Jun 12, 2003 10:53 PM
Mark Correct
Correct Answer
Hi Gonzalo,

Thanks for the clarification on your comment.

You can't and shouldn't depend on that flow pattern (output pins firing from top to bottom in sequence). Even if it's fully reliable right now (which I doubt), Agilent may need to fix a defect or add a feature in the future, and in the process change the order of propagation. Your program could stop working correctly when that happens.

It is true that all the subthreads of all the output pins have to complete before the sequence out will fire.

By the way, if you have more than one thread, you may find that another thread executes partially or fully before the one you're looking at completes. So execution of the subthread of one of the output pins could be paused while another pin's subthread executes before the previous one completes.

If you turn on Show Data Flow debugging and hit run (not the Start objects) on Scotts.Toy, you'll see two of the threads interleaving operation in an unpredictable way.

It's really dangerous to depend on undocumented behaviour.

I think the ability to reposition output pins would be nice even without depending on firing order; it might make the program easier to understand because the wires would route better.

Best Regards,

Scott Bayes
Software Technical Support

Agilent Technologies, Inc.
815 14th Street S.W.
Loveland, CO, U.S.A. 80537

970 679 3799 Tel
970 635 6867 Fax

> -----Original Message-----
> From: Gonzalo Urday [mailto:gurday@negenex.com]
> Sent: Friday, January 01, 1999 4:40 PM
> To: scott_bayes@agilent.com
> Cc: vrf@it.lists.it.agilent.com
> Subject: RE: [vrf] Re: Propagation Puzzle
>
>
> Hello Scott:
>
> Thanks a lot for the email...just one thing...my comment
> related to flowing
> data from upper to lower most output pins is basically
> related to when a
> function or object finishes to execute, the data placed on
> its output pins
> flow to other objects starting from the uppermost pin until
> that data flow
> as far right as it can,continuing in the same fashion until
> the lower most
> pin is reached then the sequence pin is activated and then the program
> continues. That's why it would be nice to be able to move
> around the output
> pins...
>
> Thanks and regards
>
> Gonzalo
>
> -----Original Message-----
> From: scott_bayes@agilent.com [mailto:scott_bayes@agilent.com]
> Sent: Thursday, June 12, 2003 7:50 PM
> To: gurday@negenex.com
> Cc: gerard.geurts@connectix.co.uk; vrf@it.lists.it.agilent.com
> Subject: RE: [vrf] Re: Propagation Puzzle
>
>
> Hi Gonzalo,
>
> > I had a situation in which I grouped a bunch of VEE objects
> > that were inside
> > a nested until break/for loop, these objects repeated
> > themselves several
>
> [deleted]
>
> In my discussion with R&D today, the grouping of objects
> inside a loop did
> come up. It's an area where VEE is known to have some
> problems. It's likely
> that the compiler is involved in these problems, because
> creating a compiler
> for a language like VEE is immensely difficult and requires some
> bleeding-edge software technology. You could see whether
> setting Execution
> Mode 3 (i.e. non-compiled) helps, though the odds are that modern VEE
> applications use features not found in VEE 3, so this would
> not be a very
> practical idea except as an experiment.
>
> > One final thing that I noticed is that when a function is
> > executed, VEE
> > continues the execution/flow of the program by flowing data from the
> > uppermost pin to the lower most output pin of the
> > function/object. I didnot
>
> I think you're talking about "sequence pins", on the top and
> bottom. These
> are not really "data" pins, they are meant to control flow of
> execution when
> execution control is necessary, and the contents of the data
> sent on them is
> irrelevant. The pins on the sides of the object (mostly) send
> and receive
> the actual data such as text or numbers, etc, though there
> can be Error and
> Control and XEQ pins on the sides as well.
>
> To learn about this stuff, you'll want to read Chapter 1 of
> the VEE User's
> Guide, especially the part that covers "Understanding Pins
> and Terminals",
> and later in the chapter, "How Agilent VEE Programs Work".
> Chapter 2 is also
> very important for understanding how VEE programming works.
>
> (Sorry Gerard If you want to make the enhancement suggestion about
> rearranging pins, you should go to the ADN and submit it as a
> defect. We'll
> understand that it's actually an enhancement request and will
> put it in the
> correct form for R&D to consider.
>
> Regards,
>
>
> Scott Bayes
> Software Technical Support
>
> Agilent Technologies, Inc.
> 815 14th Street S.W.
> Loveland, CO, U.S.A. 80537
>
> 970 679 3799 Tel
> 970 635 6867 Fax
>
> > -----Original Message-----
> > From: Gonzalo Urday [mailto:gurday@negenex.com]
> > Sent: Thursday, June 12, 2003 4:48 PM
> > To: 'BAYES,SCOTT (A-Loveland,ex1)'; 'VEE vrf'
> > Cc: 'Gerard Geurts'
> > Subject: RE: [vrf] Re: Propagation Puzzle
> >
> >
> > Hello VEErs:
> >
> > I had a situation in which I grouped a bunch of VEE objects
> > that were inside
> > a nested until break/for loop, these objects repeated
> > themselves several
> > times in my program so I created a function to replaced
> > them....in the first
> > case the flow would continue to other objects normally and at
> > the end VEE
> > would return to the for count object as expected, but when I
> > replaced the
> > grouped objects with the function the flow of the program
> > would stop after
> > the function executed and then returned to the for count
> > object, cutting
> > short the execution of the program. I did many, many things
> > to try to fix
> > this situation, but given that I am new with VEE I thought
> > that I was doing
> > something wrong and when back to the "known working evil"
> > ... but looking
> > at it now, it may be a similar situation as the one now we
> > are discussing,
> > fyi my program does have multiple JCTs.....I'll see if I
> can shrink my
> > program and make sure that the problem continues and email to
> > the group.
> >
> > One final thing that I noticed is that when a function is
> > executed, VEE
> > continues the execution/flow of the program by flowing data from the
> > uppermost pin to the lower most output pin of the
> > function/object. I didnot
> > know that, until my program flowed in a way that I was not
> > expecting (the
> > end result was the same, but it was more difficult to
> > follow), JUST as a
> > suggestion to the R&D team, it would be nice if one could
> > just drag and
> > drop, (ie move around) the input/output pins of objects and
> > functions rather
> > than delete them and placing them again in the order that one
> > wants to have
> > them.
> >
> > Hope I have contributed to this discussion
> >
> > Rgds
> >
> > Gonzalo
> >
> > -----Original Message-----
> > From: BAYES,SCOTT (A-Loveland,ex1) [mailto:scott_bayes@agilent.com]
> > Sent: Thursday, June 12, 2003 5:23 PM
> > To: VEE vrf
> > Cc: 'Gerard Geurts'
> > Subject: [vrf] Re: Propagation Puzzle
> >
> >
> > OK, Gerard shamed me into investigating in more detail
> > (Support has been
> > hectic today and for the last few weeks, so I couldn't get
> to it right
> > away).
> >
> > I wrote an even smaller program that I've attached that shows
> > the topology
> > that appears to be critical for this problem, with some interesting
> > variations. The key factor appears to be that the Until Break
> > is on one side
> > of a junction and the Next (or Break) is on the other. I
> > talked with R&D and
> > this is a known problem, probably extremely difficult to
> > solve. May already
> > be in the defect database, I haven't had a chance to look yet.
> >
> > The probable cause is that the Next (or Break) can't
> > communicate back to its
> > repeat object (whether that's an Until Break, For, or maybe
> > On Cycle) across
> > the junction (JCT). In a way it makes sense: a JCT's job is
> > to pass anything
> > it sees on its inputs to its output without regard for the
> > flow control rule
> > that says that all inputs must be satisfied before it will
> > fire the output.
> > As long as it gets at least one container input, it fires,
> > and consequently
> > apparently loses track of where the container originated, so
> > can't inform
> > the Until Break that it should send out a new container immediately.
> >
> > There are probably other problems involved with flow across a
> > JCT, or other
> > symptoms of the same problem. Scotts.Toy.vee (attached)
> > demonstrates my
> > little investigation.
> >
> > When you load Scotts.Toy.vee, turn on "Show Data Flow"
> > debugging before you
> > run it, so you can watch the data flow. There are four
> > separate threads, all
> > similar, but different in what the JCT outputs to.
> >
> > You'll see that if there's a Next or a Break on the output of
> > the JCT, then
> > Until Break doesn't even fire (nor does its sequence pin) or
> > may only fire
> > once, whether you use Run or press one of the Start buttons.
> > These threads
> > operate incorrectly and demonstrate the defect.
> >
> > But if there's nothing connected, or a non-flow object like
> > an Alphanumeric
> > instead, then Until Break cycles as expected. And if you put a Break
> > somewhere on the left side of the JCT, then Until Break's
> > sequence pin fires
> > after the Break is seen by it, as expected. These two
> threads operate
> > correctly.
> >
> > Bill Ossmann has kindly submitted a defect that simplifies
> > the original
> > demonstration program, and I will submit it together with
> > Scotts.Toy to the
> > defect database.
> >
> > One advantage of submitting defects via ADN is that
> > evaluating and inputting
> > defect submissions is part of my job, but reading the vrf is not.
> >
> > However, reading the vrf is a lot more fun!
> >
> >
> >
> > Regards to all,
> >
> >
> > Scott Bayes
> > Software Technical Support
> >
> > Agilent Technologies, Inc.
> > 815 14th Street S.W.
> > Loveland, CO, U.S.A. 80537
> >
> > 970 679 3799 Tel
> > 970 635 6867 Fax
> >
> > > -----Original Message-----
> > > From: Gerard Geurts [mailto:gerard.geurts@connectix.co.uk]
> > > Sent: Thursday, June 12, 2003 10:50 AM
> > > To: VEE vrf
> > > Subject: [vrf] Re: Propagation Puzzle
> > >
> > >
> > > I had another look at it, and do agree now there is something
> > > strange happening. A look in the help file (VEE 5) reveals:
> > >
> > > Execution of the subthread hosted by the Until Break output
> > > continues until one of the following occurs:
> > >
> > > *     All objects that can, have operated; the subthread is
> > > deactivated. The subthread is reactivated by refiring the
> > > Until Break output until a Break object is encountered.
> > > *     A Break object operates . The subthread is deactivated
> > > and the sequence output pin is activated.
> > > *     A Next object operates. The subthread is deactivated
> > > then reactivated by refiring the Until Break output until a
> > > Break object is encountered.
> > >
> > > When the 'continue' button is pressed the first option should
> > > happen, since not all objects that can be activated have done
> > > so yet. This works fine. When the 'next' button is pressed
> > > and the next object operates then the third option should
> > > happen, but it doesn't. Somehow VEE gets confused with the
> > > multiple inputs into the junction object, and picks up
> > > execution where it left of.
> > >
> > > Observation: take the message box away and connect the next
> > > object directly to the data flow pin on the alphanumeric
> > > display. Only zeros are displayed. It appears that inserting
> > > the messagebox causes the strange behaviour.
> > >
> > > Gerard
> > >
> > > PS: I bet you Scott is going to tell somebody to join ADN and
> > > submit a bug report, even though by reading this thread he
> > > has already received it including the VEE example he needs. )
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: bill.ossmann@philips.com [mailto:bill.ossmann@philips.com]
> > > Sent: Thursday, 12 June 2003 17:32
> > > To: VEE vrf
> > > Subject: [vrf] Re: Propagation Puzzle
> > >
> > >
> > > This does seem peculiar. I note that the behavior is the same
> > > if you replace the dialog box with either a pair of "OK"
> > > buttons or an If/Then/Else.
> > >
> > > In any of these cases, if you watch the propagation flow you
> > > see that after the "Next" operates, the UntilBreak does NOT
> > > fire again as I would expect. I've had this sort of problem
> > > before, and been frustrated by it, but I never reduced it
> > to a simple
> > > enough example like this to see that it wasn't just a simple
> > > misconception of the way Next works.
> > >
> > > --
> > > Bill Ossmann
> > > Philips Ultrasound
> > > e-mail: bill.ossmann@philips.com
> > >
> > >
> > >
> > > Peter Fender
> > > Raytheon Network Centric Systems
> > > St. Petersburg, FL
> > >
> > >
> > >
> > > ---
> > > You are currently subscribed to vrf as: bill.ossmann@philips.com
> > > To subscribe send a blank email to
> > "join-vrf@it.lists.it.agilent.com".
> > > To unsubscribe send a blank email to
> > > "leave-vrf@it.lists.it.agilent.com".
> > > To send messages to this mailing list, email
> > > "vrf@it.lists.it.agilent.com".
> > > If you need help with the mailing list send a message to
> > > "owner-vrf@it.lists.it.agilent.com".
> > >
> > >
> > > [attachment "Flow Test3.vee" deleted by Bill
> Ossmann/ANR/MS/PHILIPS]
> > >
> > >
> > >
> > >
> > >
> > >
> > > ---
> > > You are currently subscribed to vrf as:
> > gerard.geurts@connectix.co.uk
> > > To subscribe send a blank email to
> > "join-vrf@it.lists.it.agilent.com".
> > > To unsubscribe send a blank email to
> > > "leave-vrf@it.lists.it.agilent.com".
> > > To send messages to this mailing list, email
> > > "vrf@it.lists.it.agilent.com".
> > > If you need help with the mailing list send a message to
> > > "owner-vrf@it.lists.it.agilent.com".
> > >
> > > ---
> > > You are currently subscribed to vrf as: scott_bayes@agilent.com
> > > To subscribe send a blank email to
> > "join-vrf@it.lists.it.agilent.com".
> > > To unsubscribe send a blank email to
> > > "leave-vrf@it.lists.it.agilent.com".
> > > To send messages to this mailing list, email
> > > "vrf@it.lists.it.agilent.com".
> > > If you need help with the mailing list send a message to
> > > "owner-vrf@it.lists.it.agilent.com".
> > >
> >
> >
>

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Like • Show 0 Likes0
Actions
VRFuser Jun 15, 2003 8:50 PM
Mark Correct
Correct Answer
This is slick. I wish I would have seen this a long time ago. I wonder if it
causes any problems down the road ?

Jeff Davis
CDI Engineering Solutions Aerospace Technologies
Embedded Systems and Electronics
3137 E Elwood # 160
Phoenix, Arizona 85034
Phone: (602)431-4497 (x226)
Cell: (480)330-1431
Fax: (602)431-4435

> -----Original Message-----
> From: Pierre Mousseau [mailto:Pierre.Mousseau@mont.mitectelecom.com]
> Sent: Monday, June 16, 2003 08:42
> To: VEE vrf
> Subject: [vrf] Re: Propagation Puzzle
>
>
> Hi Peter,
>
> I faced the same problem in the past. Attached, you will find a tiny
> modification to your program (add of a dummy *junction* before pinging
> the *next* object). That way, it behaves like you expect!
> The problem
> is... I cannot explain why... I found this work-around a
> long time ago
> and it still works for me. The drawback is that I am probably taking
> advantage of a side-effect that might disappear one day. However,
> eventhough the side-effect is removed, my programs should *logicaly*
> behave the same.
>
> But for now, that could fix your propagation issue without having to
> modify your code too much.
>
> Regards,
>
> Pierre Mousseau
> Mitec Telecom
> Montreal, Canada
>
> >>> <Peter_M_Fender@raytheon.com> 06/12/03 11:39AM >>>
> The enclosed program does not flow the way I would expect it to.
> Continue and Break work as I would expect, but the Next seems to not
> know
> it's in a loop, and flows the same as Continue.
> The key elements seem to be a Junction followed by a Message Box.
> (It took awhile to boil this down from a larger program.)
> It works the same on VEE 5.01 and VEE Pro 6.1.
> Is this a bug, or a feature?
>
>
> (See attached file: Flow Test3.vee)
>
>
> Peter Fender
> Raytheon Network Centric Systems
> St. Petersburg, FL
>
>
>
> ______________________________________________________________
> __________
> This email has been scanned for all viruses by the MessageLabs Email
> Security System. For more information on a proactive email security
> service working around the clock, around the globe, visit
> http://www.messagelabs.com
> ______________________________________________________________
> __________
>

________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
________________________________________________________________________

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Like • Show 0 Likes0
Actions
pierre.mousseau Jun 16, 2003 1:42 AM
Mark Correct
Correct Answer
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"><META content="MSHTML 5.00.2919.6307" name=GENERATOR></HEAD><BODY style="COLOR: #0000ff; FONT-FAMILY: Tahoma"><DIV><SPAN class=118332700-05072003>ALL,</SPAN><SPANclass=118332700-05072003></SPAN></DIV><DIV><SPAN class=118332700-05072003> Does anyone know how toget VEE to eliminate unwanted numbers after a decimal point. I am capturingdata from an instrument and only want to display the first decimalpoint. The round(x) function will return only whole numbers which areuseless for me. </SPAN></DIV><DIV><SPAN class=118332700-05072003></SPAN> </DIV><DIV><SPAN class=118332700-05072003> For example, Iam pinging a current reading from a power supply that reads 6.7863 and only wantto display 6.7 on my VEE front panel. </SPAN></DIV><P><FONT color=#800040><STRONG>David S. Wilson <BR>Environmental Test Manager<BR>Paradigm Wireless Systems, Inc. <BR>(949) 260-1840 #142 </STRONG></FONT></P><DIV> </DIV>---<BR>You are currently subscribed to vrf as: rsb@soco.agilent.com<BR>To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".<BR>To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".<BR>To send messages to this mailing list, email "vrf@it.lists.it.agilent.com". <BR>If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".</BODY></HTML>
Like • Show 0 Likes0
Actions

vrf Propagation Puzzle

Outcomes

Related Content

Recommended Content