Shift Registers and Property Nodes

[brindlaj13]

I am working on an application using LabVIEW.  I got my CLD a few years ago, but for the last 6 years I have mostly made small VIs and compiled test sequences in TestStand.  I am a little rusty with writing a complete application in LabVIEW.  As I am creating this code, I have a ton of shift registers to pass data through the state machine.  I am trying to keep my application to fit on one monitor, I am trying to maintain readability, and follow other style standards to the code.  If I need to pass more data between states, which of the following do you recommend:

• Squeeze the new shift registers in the space I have available, even if it makes the code more difficult to read.
• Ignore the limit to a single screen, expand my outer while loop, and keep adding shift registers so it is readable.
• Replace some shift registers with property nodes --> only the cases where it is just a single read in one other state.

I am also open to any other suggestions you may have.

Here is a screenshot of my current application. I have created the property nodes for the three new items, just to test it out - this is option 3. 

[BertMcMahan · Accepted solution]

None of the above 🙂 I'd recommend going with a single shift register that has a cluster which contains ALL of your relevant variables. You can bundle and unbundle as needed, which will dramatically clean up your code. If you have a couple different "groups" of data you need to use, you can group them by making sub-clusters within your main cluster.

Also, if I remember right, using Property nodes to query values is slower than using a Local variable. I'd recommend not using either of them, but at least LV's are a bit faster (but don't quote me on this).

[Alexander_Sobolev · Accepted solution]

If it is single read, you can put a control where you need it, like Paused button is not wired to anything and you are checking its value with a property node.

Small enhancement is supercluster - bundle experiment parameters, single shift register.

Then group similar parameters into sub clusters and use classes where reasonable.

May be use Producer-consumer to separate acquisition and user loops.

[brindlaj13]

Thanks Burt!

Your suggestions make perfect sense.  I don't know why I got stuck on property nodes vs local variables, so I will definitely keep that in mind going forward.  Sometimes I miss the complete obvious when I am in too deep!