Must wire shift register through event structure

[Steve Parus]

For shift registers whose value is not accessed or changed within a
given event of an event structure, it seems that the shift registers
must be wired through the event otherwise their values are not
retained. So when a new event is added to the event structure, all
unmodified shift registers must be wired through. Is there any sort
of "retain existing values of unaccessed or unmodified shift
registers" configuration setting ?

Steve

[Mads]

Don't think so (the same as with cases. In 6.1(?) you got the option to choose use default, but that just means false for a boolean, blank for a string etc..it does not use the previous value as the new (would have been nice though)).

The easiest solution besides wiring it through is probably to not use a shift register in the event loop but a "functional global/LV 2 style global"...that way you can read/write to it only in those events that requires access to it, and still really be using a shift register with the benefits that gives...

[Randy_H]

Steve,

Another option is to use the Duplicate Event Case option when you right-click on the Event Structure. This will copy all of the code and the event registration. You can then edit the events for this case and all of the wiring for the shift registers is done for you.

Randy Hoskin
Applications Engineer
National Instruments
http://www.ni.com/ask

[wiebe@CARYA]

Hi,

Afterwards, there is not much you can do about this.

You can make a LV2 global (gli), and use it as a buffer. This way there is
no need for the shift register at all. Some data is more suitable for this
then other.

Another option to prevent this in the future, is to use a cluster in the
shift register. By adding a constant to the cluster, the data is available
for every state. It does add some extra code to the cases (the unbundle and
bundle functions), and results in 'ugly' code easilly.

I have been experimenting with the use of front panel objects (indicators)
to store data. A state can read and write the data through a local. The main
thing against using locals is the code is not flow driven. But if the local
is used in a state machine, this is not
a valid argument. I've build some
programs with this method. If applied properly, you can build fast, flexible
and easy readable code. It's a fast way to develop, and it's easy to debug
and document. Just don't use this for intensive UI objects, such as 2d
boolean arrays. Also, you will get lots of critique from other
programmers...

Regards,

Wiebe.


"Steve Parus" wrote in message
news:dkm88vg6gcpa9p925a27ta9p2vjlgkisc7@4ax.com...
> For shift registers whose value is not accessed or changed within a
> given event of an event structure, it seems that the shift registers
> must be wired through the event otherwise their values are not
> retained. So when a new event is added to the event structure, all
> unmodified shift registers must be wired through. Is there any sort
> of "retain existing values of unaccessed or unmodified shift
> registers" configuration setting ?
>
> Steve
>

[Stanislav Rumega]

Lets resume:
Passing individual data between cases of a state machine via shift
registers is the official recommended way. I had points removed on my
LabVIEW certification exam for using local variables for this purpose!
However, even if the data item is used only in a couple of cases you
still have to wire it through all the cases. Which sucks when you have
several data like that!
So, the only three alternatives we have are:
1. Bundling data into one or several clusters to reduce the number of
shift registers and wires, resulting in unbundling or bundling the
needed item every time it's accessed.
2. Using subVIs with unwired shift registers (LV2 style globals)
3. Using local variables/controls/indicators.

I guess using globals is out of question
.

Can anybody really rate these methods with respect to speed of
execution? Is, say, writing to a local in one case and then reading
from it in another REALLY slower than bundling into the shift register
and then unbundling, or passing data to a subVI and then calling it
again to retrieve it?

Stan

[mikeporter]

Option 1 is good, for all the reasons mentioned earlier. However, if one finds that they are having to add a lot of additional shift registers, perhaps they should have given a bit more thought to the problem before starting...

Option 2 and 3 are equally nasty. Remember: LV is a dataflow programming environment. Make use of that feature and you life will be easier, your hair will be shiny and dandruff free, and your kids will all grow up to be above average (ok, ok, I'm kidding about the hair).

Mike...

[Greg_McKaskle2]

> So, the only three alternatives we have are:
> 1. Bundling data into one or several clusters to reduce the number of
> shift registers and wires, resulting in unbundling or bundling the
> needed item every time it's accessed.
> 2. Using subVIs with unwired shift registers (LV2 style globals)
> 3. Using local variables/controls/indicators.
>
> I guess using globals is out of question.
>
> Can anybody really rate these methods with respect to speed of
> execution? Is, say, writing to a local in one case and then reading
> from it in another REALLY slower than bundling into the shift register
> and then unbundling, or passing data to a subVI and then calling it
> again to retrieve it?

I can rate them based upon what I know of LV, but I'd enc
ourage you to
make your own timing tests. Nothing teaches quite like practice.

1. Shift registers that flow throu without being modified are free. The
data on the wire between shift registers is pretty much a pointer. If
some cases modify the data, they are just writing it to the pointed
buffer, and reading reads from the pointer. This is the fastest.

2. Each time you read from a LV2 style global, you copy the data from
the subVI registers into the top diagram wire. Writing copies the other
way. With the right set of operations on the LV2 style global, you have
the most efficient global access possible, but not as good as the shift
register in #1.

3. Locals, globals, property nodes values, all behave similar to the LV2
style global. With simple data they will be faster as they don't have
the subVI overhead. With complex data or large arrays, the LV2 global
will win out since it hopefully doesn't need to access most of the data.
Since I have no idea what your da
ta types are, I'd put this one as a
tie with #2.

Greg McKaskle

[wiebe@CARYA]

Hi,

It all depends on the application. While a shiftregister is just a pointer,
it is passed every case that is executed. A lv2 global will only use
execution time in the states it is called in. Lv2 globals have an advantage
over shiftregisters/clusters, because they can be called anywhere in the
program. And you can build in nice tricks, like auto average, min max, fifo
buffers, circular buffers, etc.

Anyway, in my experience, using locals did not cause any timing problems.
Then again, some applications require max 1 Hz logging...

I'm not saying using locals is the way, I just tried it and did not find any
reason not to use it. I use lv2 globals for some data, data indicators for
other data. I also have some really bad experiences with programs using
locals.

My main reason to try the data indicator method was this. I build a template
state machine, and did like the idea that the programmer (me, and some
colleages), did not need to modify anything that was not in a case. (And I
don't like to work with clusters, it feels to me there are too much mouse
movements involved, but that is personal, and I could be wrong about it.)
Another reason was that if I could find a convenient way to document the
user indicators and controls, I could use this method for the data
indicators, one on one.

Some methods not mentioned jet;

+ Using reference files. These files are loded once, and remain in memory.
Tried it, and also has cons and pros. It is in fact an advanced lv2 global.

+ OOP-ish style. Also in fact a lv2 global. Program clearity and reuse of
code might justify any time penalty caused by lv2 global contruction used. I
don't know if this method could replace all data in a main state machine
(the top level UI). I might try it some day.

Regards,

Wiebe.


"Greg McKaskle" wrote in message
news:3E8BBA02.7050701@austin.rr.com...
> > So, the only three alternatives we have are:
> > 1. Bundling data into one or several clusters to reduce the number of
> > shift registers and wires, resulting in unbundling or bundling the
> > needed item every time it's accessed.
> > 2. Using subVIs with unwired shift registers (LV2 style globals)
> > 3. Using local variables/controls/indicators.
> >
> > I guess using globals is out of question.
> >
> > Can anybody really rate these methods with respect to speed of
> > execution? Is, say, writing to a local in one case and then reading
> > from it in another REALLY slower than bundling into the shift register
> > and then unbundling, or passing data to a subVI and then calling it
> > again to retrieve it?
>
> I can rate them based upon what I know of LV, but I'd encourage you to
> make your own timing tests. Nothing teaches quite like practice.
>
> 1. Shift registers that flow throu without being modified are free. The
> data on the wire between shift registers is pretty much a pointer. If
> some cases modify the data, they are just writing it to the pointed
> buffer, and reading reads from the pointer. This is the fastest.
>
> 2. Each time you read from a LV2 style global, you copy the data from
> the subVI registers into the top diagram wire. Writing copies the other
> way. With the right set of operations on the LV2 style global, you have
> the most efficient global access possible, but not as good as the shift
> register in #1.
>
> 3. Locals, globals, property nodes values, all behave similar to the LV2
> style global. With simple data they will be faster as they don't have
> the subVI overhead. With complex data or large arrays, the LV2 global
> will win out since it hopefully doesn't need to access most of the data.
> Since I have no idea what your data types are, I'd put this one as a
> tie with #2.
>
> Greg McKaskle
>

[wiebe@CARYA]

Well, I don't have to worry about any kids.

I'll consider not using Option 2 or Option 3 when I do...

Wiebe.


"mikeporter" wrote in message
news:506500000005000000B2E20000-1042324653000@exchange.ni.com...
> Option 1 is good, for all the reasons mentioned earlier. However, if
> one finds that they are having to add a lot of additional shift
> registers, perhaps they should have given a bit more thought to the
> problem before starting...
>
> Option 2 and 3 are equally nasty. Remember: LV is a dataflow
> programming environment. Make use of that feature and you life will be
> easier, your hair will be shiny and dandruff free, and your kids will
> all grow up to be above average (ok, ok, I'm kidding about the hair).
>
> M
ike...

[Greg_McKaskle2]

The question was to compare execution times. My suggestions were based
on timings I've made before, and on my knowledge of how LV executes
code. But not all decisions should be made on performance. If your
datatype is simple enough and you don't run the diagram that often,
simplify the diagram however you like.

I'll try to explain a bit more about the performance differences below,
but again, this doesn't mean that the other techniques don't have their
place.

> It all depends on the application. While a shiftregister is just a pointer,
> it is passed every case that is executed. A lv2 global will only use
> execution time in the states it is called in. Lv2 globals have an advantage
> over shiftregisters/clusters, b
ecause they can be called anywhere in the
> program. And you can build in nice tricks, like auto average, min max, fifo
> buffers, circular buffers, etc.

The pointer isn't actually passed. What happens is that each case that
needs access to the data has generated code that uses the pointer. If
the wire runs straight across, no code is generated, the pointer isn't
used, and it costs nothing in terms of performance.

The LV2 style global is only executed in the cases that need the data,
much like the code that uses the shift register pointer. And if the
shift register code is put into a subVI that takes data in and returns
it, the averaging code can also be shared just like the LV2 style global
except the storage pointer will be handed to it, rather than the data
being in the subVI's diagram. Another difference is that the LV2 global
will always call a subVI, adding some overhead. The code dealing with
the shift register can be either in a subVI or inline.

Greg McKaskle