LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Array of (static) subVI references

References are not pointers.  Front panel references are the least efficient way to move data through a LabVIEW program.  The most efficient way to move data is on a wire.  Here's a quick attempt at reworking (most of) your program:

undefined

This is more efficient, easier to read and faster to debug, than your original version:

undefined

0 Kudos
Message 21 of 24
(788 Views)

Thanks a million !  I just tried it out, and it's quite neat; for example:   

undefined

0 Kudos
Message 22 of 24
(769 Views)

Alex,

 

Thats one of the oddest code constructs I've ever seen.   I can understand an array of enums to document the transitions for a given "Event."  (Lets rename that to "Condition", Event is something different in LabVIEW, treat it like a keyword) but for several reasons I would argue for using a Queued state machine:

 

  1. Your approach requires the same number of states for any condition (2d arrays will be rectangular as Ben noted)
  2. A change in condition will have different effects depending on the entry point
  3. A duplicated state breaks the machine.  (Worse, some possible entry points will break the machine! e.g if a condition change yields next state equal to current state you get a "locked" condition where you can't break out of looping on a single state)
  4. I can't think of a reason to not complete or abort a "cycle"  I hope there is no "Clean-up" required.  I've rarely seen a state machine where all states have no prerequisites and any is perfectly ligitmate to execute at any time.  You may have such an animal! But then, this approach would only be applicable to that corner case.
  5. The UI thread is required for switching.  thats been drilled home to you before as well.

Passing 1D arrays of enums via queue will meet your "Self-documentating" transition map and the case frames of the state machine decouple the "Working code" (I still fail to see where requireing a prototype con pane does not add unnecessary coupling between the sub-vis)  This design pattern is known as a Queue Driven State Machine and one of the real workhorse design patterns because it leverages a lot of what LabVIEW developers have learned over 25 years of programming in LabVIEW.

 

Those VI server refs are very powerful tools but this is not a good way to use them.

 

Now, Sometimes we DO want to extend the QDSM by making it less specific of the actions the states take.  This is not only possible to do in LabVIEW but an entire Framework has been developed that does this effectivly and whithout requireing the UI thread.  Take a look at the Actor Framework here  It depends on LVOOP to accomplish what I think you originally had in mind and approached from a slippery angle because of your background in languages that have native "by-reference" conventions.   

 


"Should be" isn't "Is" -Jay
Message 23 of 24
(741 Views)

Mega-kudos Jeff!

 

As a an ex-C developer let me please try to make the important point that you seem to be missing.

 

You would be better served to learn how to work with LV than these attempts to turn LV into C.

 

I believe the origin of the following quote is Mark Twain

 

"When all you have is a hammer, everything looks like a nail."

 

So learn to use the LV screwdriver for a different twist.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 24 of 24
(738 Views)