sequence structures

[Dave Neumann]

I have a vi that consists of a sequence structure with 4 frames. Frame 3
contains most of the working code. If I want the program to reset (back
to frame 0) when a certain condition occurs in frame 3 (skip frame 4 and
go to frame 0), is there a way to do it?

I guess I'm asking if there's anything like a 'goto' command so I can select
frames in a sequence.

Thank you for your help.

Dave Neumann

[Kevin_work]

Dave Neumann wrote:

> I have a vi that consists of a sequence structure with 4 frames. Frame 3
> contains most of the working code. If I want the program to reset (back
> to frame 0) when a certain condition occurs in frame 3 (skip frame 4 and
> go to frame 0), is there a way to do it?
>
> I guess I'm asking if there's anything like a 'goto' command so I can select
> frames in a sequence.
>
> Thank you for your help.
>
> Dave Neumann

Dave,
This can not be done in the way that you wish. That said there are a couple of
things
you can do. In the 3rd frame set a boolean and pass it to the 4th frame. Put a
case around
the code in 4th frame and either skip or execute based on the boolean from the
3rd frame.

You can not go back to the 1st (zeroth) frame unless the
whole sequence is in a
loop.

Another structure that does what you want is called a state machine.
This is a while loop with a case inside of it. Each case will set the selector
of the next case to execute. This is one of the reasons to use local variables.

Each case can write to the variable and on the next iteration of the loop the
case will execute that selection.

I can send you a small example if you want.

Kevin Kent

[Johannes Niess]

"Kevin B. Kent" writes:

[...]

> You can not go back to the 1st (zeroth) frame unless the whole
> sequence is in a loop.
>
> Another structure that does what you want is called a state machine.
> This is a while loop with a case inside of it. Each case will set the
> selector of the next case to execute. This is one of the reasons to
> use local variables.
>
> Each case can write to the variable and on the next iteration of the
> loop the case will execute that selection.

Kevin,

For simple cases even the local variable isn't needed. My measurement
and control programm just sets the enumerated type in the case
frame. A strict type definition is quite usefull here.

I've a seperate vi with a boolean case (Button "Execute next
mode")
which passes input to output in false and a ring with all the states
in the true case. It gives me 1 choice of state change per (main)
while loop, which is enough for me.

Johannes Nieß

[ej]

In this instance using a shift register is a better solution than using
a local variable.

In article <399060D8.B7B3D39D@usa.alcatel.com>,
"Kevin B. Kent" wrote:
> This is a multi-part message in MIME format.
> --------------CE14DC6F79D751324A4F112C
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> Dave Neumann wrote:
>
> > I have a vi that consists of a sequence structure with 4 frames.
Frame 3
> > contains most of the working code. If I want the program to reset
(back
> > to frame 0) when a certain condition occurs in frame 3 (skip frame
4 and
> > go to frame 0), is there a way to do it?
> >
> > I guess I'm asking if there's anything like a 'goto' command so I
can select
> > frames in a sequence.
> >
> > Thank you for your help.
> >
> > Dave Neumann
>
> Dave,
> This can not be done in the way that you wish. That said there are a
couple of
> things
> you can do. In the 3rd frame set a boolean and pass it to the 4th
frame. Put a
> case around
> the code in 4th frame and either skip or execute based on the boolean
from the
> 3rd frame.
>
> You can not go back to the 1st (zeroth) frame unless the whole
sequence is in a
> loop.
>
> Another structure that does what you want is called a state machine.
> This is a while loop with a case inside of it. Each case will set the
selector
> of the next case to execute. This is one of the reasons to use local
variables.
>
> Each case can write to the variable and on the next iteration of the
loop the
> case will execute that selection.
>
> I can send you a small example if you want.
>
> Kevin Kent
>
> --------------CE14DC6F79D751324A4F112C
> Content-Type: text/x-vcard; charset=us-ascii;
> name="Kevin.Kent.vcf"
> Content-Transfer-Encoding: 7bit
> Content-Description: Card for Kevin B. Kent
> Content-Disposition: attachment;
> filename="Kevin.Kent.vcf"
>
> begin:vcard
> n:Kent;Kevin
> tel;work:972-477-4468
> x-mozilla-html:TRUE
> url:http://www.usa.alcatel.com
> org:Alcatel USA;WDCS Hardware Development
> adr:;;;;;;
> version:2.1
> email;internet:Kevin.Kent@usa.alcatel.com
> title:Engineering Technician
> x-mozilla-cpt:;-26944
> fn:Kevin Kent
> end:vcard
>
> --------------CE14DC6F79D751324A4F112C--
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.

[Kevin_work]

ej wrote:

> In this instance using a shift register is a better solution than using
> a local variable.
>
>

Well, certainly a shift will work, but I would not go so far as to say it is
better.
To use a shift I must pass data out of EVERY case. I find the local to
be a much cleaner setup, especially when printed. If I add a case
I immediately
have a broken VI (this may actually be helpful since I now have to set the
next state).
This also gives me more control over the operation of the state machine.

I have seen many talk about locals, globals, sequences, etc as being "Bad
Things"
This is, in my opinion, hogwash. There is no such thing as bad constructs
only Bad Code.

Of course this is all just opinion.
Kevin Kent

[ej]

Kevin,

Maybe it doesn't matter so much now that memory is cheap, but when I
started LabVIEW anything that you could do to save the amount of wasted
memory the better, especially in large applications.

Here is why I still think that using shift regs are better that using
locals:

To avoid having those broken wires from a case statement that would
generally go out to a shift register, you would have to create a new
local for every case. Also if you don't need to have a control or
indicator on the front panel, you must create a control or indicator
just to be able to use your locals. You still wouldn't have much
control over operation of the state machine without putting in special
cases to eliminate race conditions.

I also can't see how creating several local variables is neater than
creating one complete wire path to a shift register which does the same
thing (especially since you need more comments to help others to follow
your data flow). For me it is less taxing to follow one complete wire
path to a shift register than to try to find out where all of the read
locals and write locals are located.

Wow! This seems to be a touchy subject for me. 🙂 I suppose I'm just
in favor of optimization, no matter how much memory you have to spare.

ej

In article <3991FC7C.C7F88AA@usa.alcatel.com>,
"Kevin B. Kent" wrote:
> ej wrote:
>
> > In this instance using a shift register is a better solution than
using
> > a local variable.
> >
> >
>
> Well, certainly a shift will work, but I would not go so far as to
say it is
> better.
> To use a shift I must pass data out of EVERY case. I find the local to
> be a much cleaner setup, especially when printed. If I add a case
> I immediately
> have a broken VI (this may actually be helpful since I now have to
set the
> next state).
> This also gives me more control over the operation of the state
machine.
>
> I have seen many talk about locals, globals, sequences, etc as
being "Bad
> Things"
> This is, in my opinion, hogwash. There is no such thing as bad
constructs
> only Bad Code.
>
> Of course this is all just opinion.
> Kevin Kent
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.

[Kevin_work]

OK, I must apologize a bit here and say I may be a bit touchy on this
subject as well.
I should preface all this by saying that my intention was to point out that
this
is one of the FEW times that a local is handy, and less dangerous.
I implemented
my code this way and liked it. I should have been more clear in the original
reply.


ej wrote:


> Kevin,
>
> Maybe it doesn't matter so much now that memory is cheap, but when I
> started LabVIEW anything that you could do to save the amount of wasted
> memory the better, especially in large applications.
>

Indeed the shift will use less memory (2 identical vis the local is 16k,
shift is 13k)

>
> Here is why I still think that using shift regs are better that using
> locals:
>
> To avoid having those broken wires from a case statement that would
> generally go out to a shift register, you would have to create a new
> local for every case.

This is a bit confusing, If I DONT use shift at all, I won't have any wires
out of the case.
I dont really have to create a local for every case (though that could be a
"Bad Thing")
Never tried this but it might be interesting.

> Also if you don't need to have a control or
> indicator on the front panel, you must create a control or indicator
> just to be able to use your locals. You still wouldn't have much

I'll agree with this .

>
> control over operation of the state machine without putting in special
> cases to eliminate race conditions.

Not so sure about this, granted there can be race conditions, but if I set a
local
inside a case there won't be a problem, since no one will read it till the
case
exits.

>
> I also can't see how creating several local variables is neater than
> creating one complete wire path to a shift register which does the same
> thing (especially since you need more comments to help others to follow
> your data flow).

Well, maybe it is just preference for me. When I print and / or document the

VIs it is much easier to have a local in each case, especially if there is
more
than one case structure. I can look at the disembodied cases and see that
all locals named "StateM_1" go together. Much easier than a wire to nowhere.

> For me it is less taxing to follow one complete wire
> path to a shift register than to try to find out where all of the read
> locals and write locals are located.
>

Yep again just preferences.

>
> Wow! This seems to be a touchy subject for me. 🙂 I suppose I'm just
> in favor of optimization, no matter how much memory you have to spare.
>
> ej

Yes I typically try to get the smallest, fastest, bestest I can but there
are other
considerations. Since I work with several different coders, and have strict
documentation
guidelines, I have to pick what is best overall.
This is like any other kind of programming. There are many ways to skin the
cat.
My general philosophy is : If it works, is bug free, and you (or I) can
figure it out in 6 months,
then it is perfectly fine with me.
Kevin Kent

[ej]

I agree with you on all points, especially on the "if it works" part.

As a summary to the original poster. Try using the fore mentioned
state machine. This is probably the best (only?) solution for
a "selectable sequence". The value used to select the next state (for
the next iteration of your loop) may be passed by either a local
variable or a shift register.

eric

In article <39935F80.6A9D879B@usa.alcatel.com>,
"Kevin B. Kent" wrote:
> OK, I must apologize a bit here and say I may be a bit touchy on this
> subject as well.
> I should preface all this by saying that my intention was to point
out that
> this
> is one of the FEW times that a local is handy, and less dangerous.
> I implemented
> my code this way and liked it. I should have been more clear in the
original
> reply.
>
> ej wrote:
>
> > Kevin,
> >
> > Maybe it doesn't matter so much now that memory is cheap, but when I
> > started LabVIEW anything that you could do to save the amount of
wasted
> > memory the better, especially in large applications.
> >
>
> Indeed the shift will use less memory (2 identical vis the local is
16k,
> shift is 13k)
>
> >
> > Here is why I still think that using shift regs are better that
using
> > locals:
> >
> > To avoid having those broken wires from a case statement that would
> > generally go out to a shift register, you would have to create a new
> > local for every case.
>
> This is a bit confusing, If I DONT use shift at all, I won't have any
wires
> out of the case.
> I dont really have to create a local for every case (though that
could be a
> "Bad Thing")
> Never tried this but it might be interesting.
>
> > Also if you don't need to have a control or
> > indicator on the front panel, you must create a control or indicator
> > just to be able to use your locals. You still wouldn't have much
>
> I'll agree with this .
>
> >
> > control over operation of the state machine without putting in
special
> > cases to eliminate race conditions.
>
> Not so sure about this, granted there can be race conditions, but if
I set a
> local
> inside a case there won't be a problem, since no one will read it
till the
> case
> exits.
>
> >
> > I also can't see how creating several local variables is neater than
> > creating one complete wire path to a shift register which does the
same
> > thing (especially since you need more comments to help others to
follow
> > your data flow).
>
> Well, maybe it is just preference for me. When I print and / or
document the
>
> VIs it is much easier to have a local in each case, especially if
there is
> more
> than one case structure. I can look at the disembodied cases and see
that
> all locals named "StateM_1" go together. Much easier than a wire to
nowhere.
>
> > For me it is less taxing to follow one complete wire
> > path to a shift register than to try to find out where all of the
read
> > locals and write locals are located.
> >
>
> Yep again just preferences.
>
> >
> > Wow! This seems to be a touchy subject for me. 🙂 I suppose I'm
just
> > in favor of optimization, no matter how much memory you have to
spare.
> >
> > ej
>
> Yes I typically try to get the smallest, fastest, bestest I can but
there
> are other
> considerations. Since I work with several different coders, and have
strict
> documentation
> guidelines, I have to pick what is best overall.
> This is like any other kind of programming. There are many ways to
skin the
> cat.
> My general philosophy is : If it works, is bug free, and you (or I)
can
> figure it out in 6 months,
> then it is perfectly fine with me.
> Kevin Kent
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.