Fix the type definition cluster movement bug

[Bob_Schor · Accepted solution]

I do something similar, but I make a sub-VI out of it and "hide the Messy Details".  Here's my Send Message sub-VI:

 You see that this takes both the State (which is an Enum and has a TypeDef to define it) and the (optional) Data (which I have as a Variant to allow full flexibility).  Inside this VI, I combine these using a Bundle by Name (to make sure I wire things to the right place), use the Type Def just to get me the names of the components, and stick it on the Queue.  

"But where's the Queue?", you ask  That little Blue sub-VI is my "Invisi-Q" (I'm sure others have invented this, also).

This function creates the Queue, and provides the "Queue Wire" whenever you need it (so you don't need to "run Queue wires backwards" to link parallel Queue-enabled patterns like the Queued State Machine or Producer/Consumer Design, resulting in "neater" Block Diagrams).  The first time you call this, it creates the Queue (here I specified a size of 200) -- the False case (when it's not the first Call) just uses the Queue reference saved on the Shift Register.

So your example, for me, would be something like this:

Since I'm not using the "Data" part of the Cluster, only the State, I don't wire it into the Queue (I let it take the default value), and there's no problem with the Cluster "edges" clipping (or leaving gaps) with the size of the particular Enum instance.  And do notice the use of the Error Line to "serialize" the order of things being put on the Queue.  The Error Line is Your Friend -- Use It Almost Always.

Bob Schor

[strait]

Hi Bob_Schor,

I really appreciate the detailed response. This looks way better than how I've done it (I like the Variant flexibility, too! Hadn't thought of that). I'll have to try this because it elegantly solves my problem.

I hope NI can improve the type def cluster aesthetics, but I'm accepting your answer because once I implement this I suppose I won't care anymore.

[wiebe@CARYA]

Note that this used to be the #1 cause for the infamous "insane objects".

That would corrupt the VIs with the type def, and you needed the heap peak to fix it.

At least that got fixed.