Community Nugget 2-19-2007 "Stacked Sequence Exterminator"

[shoneill]

I have also thought of a feature like this before, mainly in connection with state machines....

I think the "shift registers" would have to differentiate themselves visually from proper shift registers.  Proper shift registers work differently, and I think we're looking at a whole new feature here.

On a side note, regarding "...full of wires that have no meaning ..." why not simply build a cluster in a state machine with all values which need to be preserved and then use unbundle by name to access them?  I used to think this was horrible inefficient due to memory access when changing a small part of the cluster, but then I was informed that clusters are stored in fragmented memory space, meaning that updating one part has no (or little) need for copying of other parts.  When converting to string, clusters are expensive because all "parts" must be accessed at different addresses.....  Then it's only "...full of a wire that has no meaning..."

Just my 2c

Shane.

Message Edited by shoneill on 02-21-2007 01:58 PM

[Ben]

Shane wrote;

" ... why not simply build a cluster in a state machine with all values which need to be preserved and then use unbundle by name to access them? "

AS long as the elements of the cluster are small and the preformance req are low, then OK.

When ever the data elements become large, then explicit storage is called for. What I have in mind when I speak of "large" I am thinking a arrays that are over 10K (approx).

From what I have observed of buffer usage and performance, sticking a large array inside a cluster in a SR casuses beffer copies. If the large arrays are broken out and stored in distinct SR's the buffer can be re-used when an element of the arry is replaced.

I have been toying with "showing my hand" when it comes to the "Data Analysis" phase of application design and trying to put it in a Nugget (or two, or three?) but I have not been able to formalize what exactly "Data Analysis" is! For the time being let me describe it as "an additinal step I insert after the "fuzzy cloud" step and before the "State Diagram" step that defines my data structures and identifies performance risks."

Anyone else do something similar?

Care to team up on a Nugget?

If so e-mail me at

bar@dsautomation.com

Ben

[Kevin_Price]

---

Tomi M wrote:

I personally hate it when my event structures are full of wires that have no meaning in that particular event. Hence the idea of allowing unwired shift registers, to make diagrams clearer and allow users to better use the space of the diagram (no need to reserve space for wires without meaning).

---

One of the things I dread most is when I have a state machine with 15+ states, and decide that I need to add a shift register or two to the loop. 

Click to next case.  Wire from RH SR to case. Wire from case to LH SR.  Wire from other RH SR to case.  Wire from case to LH SR.  Repeat.  20 times or so.  Arrrrgggghhh!

It'd be really great to have an SR option for "retain prior value if unwired" which would grey out the SR icon in a manner analogous to "use default if unwired" tunnels.  The option would have to be non-default to avoid breaking existing code.

-Kevin P.

[Ben]

Tomi,

Here is a SIMPLE example of how I handle errors.

Kevin,

I have a Nugget to handle the SR issue. Stay tuned!

Ben

Message Edited by Ben on 02-21-2007 08:02 AM

[tst]

---

@Ben wrote:

Kevin,

I have a Nugget to handle the SR issue. Stay tuned!

---

Ben, allow me to make your life harder - Kevin, in the LAVA forums you can find the tunnel wiring wizard, written by David Boyd. 
It uses scripting to allow you to select any two tunnels and it will automatically connect them in all the cases where the output tunnel is not wired.

[Ben]

tst wrote "...Ben, allow me to make your life harder ..."

Trying to cut off my Nuggets eh?

Sorry did not work. that was only the foot note.

Ben

[altenbach]

---

Kevin Price wrote:
It'd be really great to have an SR option for "retain prior value if unwired" which would grey out the SR icon in a manner analogous to "use default if unwired" tunnels.  The option would have to be non-default to avoid breaking existing code.

---

Kevin,

Mnay years ago (fall 2002) we had a discussion on info-labVIEW about very similar issues. I made a suggestion to add a special "case" to explicitely define the default behavior of unwired tunnels in event and case structures. I still think that would be a very useful addition. 🙂

The full story has been recorded in the LAVA forum

Here's what I wrote back then:

---

I would prefer a even more flexible solution: Make a special, usually hidden case with a name such as "_default outputs_". For example, you would right-click on the case and select "define default outputs". Now you see a case that has a different color. Here you can wire away and define what the output terminals should receive in all the "regular" cases *if* they are not wired. Only outputs you don't wire here would receive the default for the data type as we have now. By default, this case is empty, duplicating the current behavior for unwired outputs.

In your very special case, you would connect the desired input and output tunnels across, but now the possibilities are truly endless. Now you also have the opportunity to do math, e.g. insert a [+1], [-1], etc as often needed. One output tunnel could receive a special wired constant (1, -100, Inf, NaN, etc.) that would be more suitable for the particular situation than the default for the data type we have now. One output tunnel could receive a mathematical result of multiple input tunnels.

Just some ideas ... (We can dream) Christian Altenbach

---

Only cases that need a special treatment for an output need to be wired. For example if one case does not need the "+1" we have defined, you would wire across to override the default behavior in that single case only.

In your case you would wire all tunnels accross in the "_default outputs_" case and from now on you only need to wire to the output tunnels in the rare cases where you actually modify the tunnel data. 🙂

[shoneill]

Ben,

regarding : "sticking a large array inside a cluster in a SR casuses beffer copies"

I just read this.  Your example assumes that because overwriting a larger array with itself causes more overhead that the arays are not stored as pointers within a cluster.  I'm not so sure.  I thought I'd do some benchmarking of my own. 

The attached VI has two clusters, each with two arrays.

In the first cluster, the second array has 5000000 elements in it, whereas the first is empty.
The second has 5 elements in the second array, whereas the first is empty.

In the code, I increment the empty array 10,000 times (Read/Write/Append).

I find the work on the first array to be independent of the second array's size.  This would mean that both arrays within a given cluster must occupy seperate memory spaces, no?

Please have a look and comment (VI is LV 8.20),

Shane.

[Ben]

Hi Shane,

Please take a look at the attached.

I get a factor of 10 difference in performance when I use distinct SR instead of using the cluster.

How does this run on your machine?

Ben

[altenbach]

Did Hell just freeze over or is Shane actually using LabVIEW 8.2??!? 😮

Shane, you should make current values to the defaults before saving and posting. All your controls are empty in the posted example.