Array of (static) subVI references

[Ben]

THis seems like a lot of work to avoid having to lok in the states to see what is next. I will include a diagram as part of the code to make it easy to see the flow.

I also feel moved to warn you about the data structure you keep your states in. LV wants all multi-dimentional arrays to rectangular (all rows must have same number of collumns).

There is also a Tool kit to allow you develop State Diagrams  so you may want to look for that.

LVOOP may also be of assistance since I believe I saw an example of a "worker pool" design patern.

THe other gotcha is that the actual transfer of data into out of a Call By Ref node requires the UI thread to move the data effectively eliminating all of the other cores on your machine.

Been there, done that, and suprised I am still employed after doing so!

Ben

[nathand]

---

@alexwk wrote:

One of my motivations is precisely to avoid the case structure, and just use a combination of current state and event enumerated indices to determine the next state and corresponding action.  In my thinking, the next state table uniquely documents the top view of a state transition diagram, whereas a case structure requires to look into each case to see how the next state is determined, adding one level of depth to trace code execution.

---

Consider the version I posted.  It does have a case structure, but the case structure does not determine the next state - in fact, the state wire does not even pass through the case structure.  I think this meets your goal of not needing to look in each case to follow the state transitions.  It has a number of advantages over calling by reference.  You can easily put a breakpoint in a specific state.  It is not necessary for each state to be a separate subVI (simple code can be placed directly in the case structure).  State VIs do not need matched connector panes and inputs.  The same case can handle multiple states.  It's more efficient to call subVIs directly than by reference.  No risk of a mismatch between array indices and states.  Perhaps the biggest advantage is in readability.  When you want to know what happens in State 3, you just open that case in the case structure.  No need to figure out what the enumeration value is, find the build array, and trace the wire back to the reference to find the subVI.

Personally, if I were implementing this in C, I would do it using a switch statement instead of function pointers.  Again, as in LabVIEW, the switch statement doesn't need to determine the next state, but it certainly makes it easier to follow the code and see what happens in each state.  A function pointer jumps off to some unknown destination; it might be theoretically elegant, but difficult to debug in practice.

The easiest way to put code into this forum is to select the code and then go to "Edit -> Create VI Snippet from Selection."  This generates a PNG that you can upload as an image in the forum (Flash is required to insert images).  These snippets are also neat because they are not just an image, they are actual code that you can drag onto a block diagram.

[MarcoMauri]

I don't know it this can be useful, but it's possibile to create your array of references from an array of paths,

Marco

[alexwk]

Thank you MarcoMauri, as well as to nathand, for the two suggested mechanisms that I was looking for, on how to create an array of VI ref's, and to all others for all your feedback.  I've attached my latest solution, which captures various lessons that I have picked from this discussion.  It is a simple demo of a state machine, for my own learning purposes, which captures some of the lessons that I've picked up.  Referring to "good LabVIEW style and practices", such as with standard state machine templates using case structures, as I have often seen, I can only confess to my present fixation on my C background, and my preferred inclination to the next-state transition table combined with a matching array of VI ref's; it seems to me that it reduces the complexity at the level of the state machine iteration loop, and minimizes coupling between the state subVIs.  I have added a simple example of a cluster of various dummy data to represent variables which would be involved in the operation of the state machine, and which is passed by reference to each state subVI, to minimize parameter passing overhead.  The more I read about LabVIEW, the more I see how much more I have to learn, and how, umm, interesting and challenging, and fun, of course, is this LabVIEW learning curve!!  So, please do offer any feedback re. performance, what I may have missed, what needs to be anticipated, etc.  I will appreciate it, and look forward to "breaking free" from any former C notions and practices incompatible with accepted LabVIEW wisdom 😉

[Ben]

---

@alexwk wrote:

...

 and which is passed by reference to each state subVI, to minimize parameter passing overhead.  ...

---

Can you plese post an image of how you are passing by reference?

(I don't have a modern version of LV on this machine and can only view images).

Ben

[alexwk]

Well, I'm more ignorant than I had thought ! I can grab a piece off the front panel or code diagram, with CTRL-C, and then paste with CTRL-V in MS Word, and vice-versa, but I don't know how to paste into this here correspondence.  What am I missing??  Some features in MS Word?  Some other feature/tool to transfer between LabVIEW and clipboard and here ?  Please explain.  So instead, I have copied and pasted the pertinent bits into the attached MS Word file.

[nathand]

Did you read what I wrote above about snippets? That's the best way to get your code into an image. Please don't use Word. If you want to copy/paste somewhere, paste into mspaint and save as a png. You can also paste a screen shot (in Windows, Alt-PrintScreen copies the active window into the clipboard).

[Ben]

i have to echo nathand's remarks about posting word docs since they are a vector for contamination.

jpgs are fine. Use the litle Tree button to include your image while posting.

I am going to put on the "been there done that hat" in an attempt to help you avoid possible disaster. Putting it more candidly...

YOU are asking for trouble!

History in short...

I started out as a VAX Macro programmer that taught himself C from Kernigham and Ritchie before C++ was invented. I dipped my toe into C++ but abandoned C in favor of C.

When making the switch between C and LV I made many mistakes. Some of those mistakes are evident in your posts so I WANT TO HELP you avoid some of those mistakes.

1) LV is a data flow language. The WIRES ARE THE DATA. Although "Locals", "Globals" and "references" are shared terms between G and C, they are different animals. Failure to recognize this will led to frustration with poorly performing applications.

2) LV is multithreaded by default. LV will decide where an when multiple threads can be used and will utilizie all of the available cores... if you let it.

Now to some details to illustrate some issues.

Control refs:

You should look at control references as if they are file references. The are handles that let you interact with a shared resource. In LV as it is with C we have to be carefully about accessing shared resources to enusre our data is intact and self consistant. In C we could reach for a some syncronization schemes like semaphores to control access to the sahred resource. When accessing the values stored in the buffer the LV environment uses to store data for display (i.e property node >>> Value) LV submits the operation to the User Interface Thread which is single threaded. This prevents simultaneous access to the buffer but is iteslf a bottle-neck. When you try to scale up the app you are pondering, you will find that one of your cores will be maxed out and all other cores will be left idle.

Summary:

Using control references to share data between states will seriously limit your aplications performance.

Control refs are I/O refs that should only be used when you want to send an output (up date an indicator) or get an input (get a control state).

So how should you share data between fucntions in LV?

Knowlege of the various sharing methods is covered in the tutorials and NI traing stuff. Understanding them and knowing when to use one version vs another is what is required for properly designing an architecture in LV.

I invite you to investigate them yourself but for this post let me mention three of the more flexible options.

Action Engines - Action engines are LV version of a subroutine with a static local in C. The static local can be acted on by any code calling that subroutine. I wrote a Nugget on Action Engines where I introduce them and explain how they work. You can find that Nugget here. Prior to the introduction of polymorphic queues in LV 6i, AE where the fastest way of sharing data between threads. If you learn no other data sharing methods, learn AEs first.

Queues - Allow moving data "in-place" from multiple sources to a single sink. Note: Search on "in-place" to learn how LV decides if the data buffer holding the data in a wire needs to be duplicated. All operations that can completed "in-place" are faster than operations that require duplicating the data.

DVR - A recent addition to the LV tool-box is very close to what C developers think of as "Pass by reference". Look into these to find out how to use them.

Threading:

Read about the threading and scheduling here. THere ae many things we can do to prevent teh power of G from performing as well as possible. One of the worst "sins" we can commit is to write application that can only run in the UI thread. "Property node >>> value is one of them. Call by Reference is yet another. You can read about the issues with using the Call by reference node in this thread. Warning: wrap your hed in Duct tape before attempting to rad that thread. YOu can see from the lack of constructive replies that it contains more information than most of the experienced contributors could handle and still think straight.

I have already spent too much time writting up this reply so I'll attempt to close by saying as a forrmer C programmer tha has "seen the light" DO NOT TRY TO USE G to write a C program! It at best will be an exercise in futility.

Learn you use the LV State Machines.

Listen to what the others on this forum offer as suggestions. Every contributor that has yellow/gold bars under their avatars are voluteers that are trying to help you.

Paaphrasing a message that was over the doors of the DEC training facility back in the 70's.

"Through these forums past some of the greatest engineers and scientist in the world!"

Spoiler

Myself excluded

Listen to them.

Ben

[alexwk]

Finally !!  I had been able to produce a code snippet and save it to a PNG file, as well as clip a part of the front panel or code diagram and save to disk, but I thought I could just copy with Ctrl-C and paste with Ctrl-V into here, but that wasn't working, which left me puzzled as to what I was doing wrong.  I just now realized there is a special button to insert an image.  I obviously missed that before.  My apologies, and thanks for the help and patience.  Just to prove my newly acquired skill:

trying

[tst]

You can also use the Code Capture Tool, which is specifically designed to capture and share LV code images.