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

[Tomi_Maila]

You are kind of right Ben... However state diagrams toolkit is not part of LabVIEW language but an add on that most users don't have access to. So I don't think it solves a general problem of error handling that should be accessible to everyone. Currently there is no good diagram that suits well to error handling. I think error handling is such an important

I'd like to have a single diagram for error handling, that would function in similar (but more advanced) way as three nested diagrams below. It would combine functionality of while loop (allow stopping, shift registers), sequence (limited number of frames in certain order, no going back) and case structure (maching errors against prototypes).
- Handle errors that occur before the diagram in one or more cases
    - Even though errors have occurred before the diagram, allow executing rest of the diagram in special cases defined by "continue" node
- Execute the primary code in one single case
- Handle errors that occurred after the diagram in error handler cases
- Allow stopping the sequence in any of the frames
- Allow leaving right hand side shift registers unwired, the previous wired value is used in these cases
- Add a new left hand side "pattern matching" dual connector terminal similar to "?" terminal but this terminal would take error cluster and an array of anything as input. The error in error-in is matched against this array of anything. There would be one error handling case for each item in the array of anything. (If you didn't understand this, never mind)

Tomi

Message Edited by Tomi M on 02-20-2007 01:29 PM

Message Edited by Tomi M on 02-20-2007 01:30 PM

[Ben]

Hi Tomi,

If a developer has access to the VIA they probably have access to the SDE.

Even without the SDE, State Diagrams (as illustrated in the LV 6.X code shown in reply #8) are still available.

Everything that you proposed can be done in a state diagram.

Maybe when I learn to think "LVOOP-ishly" I may see the benefit of your suggestion.

Please be patient with me! I'm still learning.

Ben

[Tomi_Maila]

Ben, I just think language should guide or sometimes even force users to good programming conventions. How many of you use state diagrams in every single of your VIs to handle errors? How about using them in any VIs to handle errors? I can guess the answers. Unless there is a structure that guides users to good programming conventions then most of the developers will be too lazy to implement them. 

Second issue is of course matching patterns that cannot currently be implemented in an elegant way. The idea of pattern mathing is: Test if my error cluster contains a flattened string of LabVIEW type [A,B,C]. If so, then execute case [CaseA, CaseB, CaseC] respectively. [] denotes an array. Only one of the cases is executed, the one which matches first. Otherwise execute case default. The same concept of pattern matching can also be applied to LVClasses, LabVIEW references, flattened strings and variants in addition to error clusters. Test if my variant is of type [A,B,C]. If so, then execute case [CaseA, CaseB, CaseC] respectively. Or Test if my LabVIEW object is of type [A,B,C]. If so, then execute case [CaseA, CaseB, CaseC] respectively. The necessary requirement for pattern matching is that test amd case wires can carry multiple type of data and we have many such wires in LabVIEW.

Was I clear enough?

Tomi

Message Edited by Tomi M on 02-20-2007 08:47 PM

[Jarrod_S.]

I really like this idea of having shift registers on a sequence structure! This would not only simplify reading stacked sequence structures, but it would allow us to rethink the LV2 style global. We could do away with the overhead of having to run a loop once just to take advantage of uninitialized shift registers! Now you could just have a single-frame sequence structure to store your data.

Heck, why stop there... Why not add shift registers to any structure in LV? Maybe that's a little too revelutionary, but as I see it, it would bind data storage closer to the nodes that access them, enhance inplaceness, etc.

I wonder if it would more or less helpful to allow right-hand shift registers to not be wired in stacked sequence structures, though. That's personally my main gripe with sequence locals is that they only project forwards in the sequence, and you can't write to it more than once. So it's a little confusing to see the node there in all cases, but only use it once. The advantage of allowing unwired shift registers would be that you wouldn't have to wire the data through when unused just to maintain it. Diagrams would be a little cleaner, but perhaps more complicated in nature.

[Tomi_Maila]

---

I wonder if it would more or less helpful to allow right-hand shift registers to not be wired in stacked sequence structures, though.

---

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).

Tomi

[Ben]

"...full of wires that have no meaning ..."

Oh but the do! They say in a very explicit manner that the data associated with those shift register will not be modified by this case (event).

Ben

[Tomi_Maila]

---

Oh but the do! They say in a very explicit manner that the data associated with those shift register will not be modified by this case (event).

---

Well, an unwired shift register could have exactly the same meaning but it would be easier to read as the information is concentrated on a single point, namely the right hand side shift register. Only the wires having other than default action would be required.

[JDave]

---

Well, an unwired shift register could have exactly the same meaning but it would be easier to read as the information is concentrated on a single point, namely the right hand side shift register. Only the wires having other than default action would be required.

---

However, the difference between a purposefully unwired input and a neglectfully unwired input is huge, while at the same time hard to detect.  An unwired input also has the connotation of "Use Default in Unwired".  It would be confusing to add this meaning in as well.  If nothing else it should have a different appearance.

[Tomi_Maila]

---

@JDave wrote:

---

Well, an unwired shift register could have exactly the same meaning but it would be easier to read as the information is concentrated on a single point, namely the right hand side shift register. Only the wires having other than default action would be required.

---

However, the difference between a purposefully unwired input and a neglectfully unwired input is huge, while at the same time hard to detect.  An unwired input also has the connotation of "Use Default in Unwired".  It would be confusing to add this meaning in as well.  If nothing else it should have a different appearance.

---

Very good point! How about the following. By default you must wire the the right side shift regsiter. However there is a context menu option "use previous value". Thid option must be set for each frame separately. This guarantees that at least the developer of the structure must explicitly define each shift register in each frame to use previous value. Perhaps such shift register should look a little different. I think this is sufficient to avoid most errors and makes the structure clearer.

How at NI R&D owns the stacked sequence and similar structures?

Tomi

[Tomi_Maila]

Double posting, ignore this.

Message Edited by Tomi M on 02-21-2007 12:07 PM