SubVI doesn't return the desired data continuously

[RavensFan]

I'm glad to hear you figured it out.

I don't understand the comment " I replaced the case structure with a flat sequence".  Case structures and flat sequences are two completely different structures with different purposes.  You probably don't actually need a flat sequence structure anywhere.

[DC20]

Yes, and I put a flat seq to be sure that the events will execute in the right order...maybe it works without it, but it looked easier to me than to work with case structure

[RavensFan]

The wires will guarantee the order that things execute.

You may want to look at action engines.

Action Engine Nugget

You are repeatedly initializing, executing, and closing every time that subVI runs.  An action engine contains a single while loop with a true constant wired to its stop terminal.  You can call the VI once before your main VI loop starts sending it an enum that runs the initialized case.  Andy data that needs to persist such as the references of your devices get wired into an uninitialized shift register.  In your main VI while loop, you call the subVI with a "GetData" enum wired in.  It runs the case where you get the data.  The references in the shift register get used.

When your main VI loop ends, you call the subVI with the Close enum.  It will run the close case and clear out the references.

Now you have a single VI that encapsulates all the details of communication, but you can call it when you need to just using an enum input as the command.

[Gregory]

---

@RavensFan wrote:

An action engine contains a single while loop with a true constant wired to its stop terminal. 

---

Did For loops not always support shift registers? A single iteration For loop just seems like less of a hack than a while loop with True wired to its stop.

[RavensFan]

As far as I can remember.  1 iteration For Loop should work just as well.

I have just always seen action engines created as while loops.  Don't think it is a hack compared to a For Loop.  For one you need to wire a True constant to a stop terminal.  For the other, you need to wire a 1 constant to the N terminal.  Same amount of work either way.

There may be a slight advantage to the For Loop because you can keep the 1 close to the N whenever you expand the loop down or to the right.  With the normal position of the stop terminal being to the lower right and not really stuck to the loop, you might need to move it around when you expand the loop, (unless you expand it up or to the left.)

[crossrulz]

Who even needs a loop?  Use Globally Initialized Feedback Nodes!

Spoiler

Let the flame war begin...

[Gregory]

---

@RavensFan wrote:

I have just always seen action engines created as while loops.  Don't think it is a hack compared to a For Loop.  For one you need to wire a True constant to a stop terminal.  For the other, you need to wire a 1 constant to the N terminal.  Same amount of work either way.

---

Fair enough 🙂 

I saw the For loop on Mike Porter's blog one day and then I wondered why that wasn't the norm. I also used feedback nodes for some AE's, but I like the loops better for the shallow reason of thinking that it looks "nicer".

[RavensFan]

---

@crossrulz wrote:

Who even needs a loop?  Use Globally Initialized Feedback Nodes!

Spoiler

Let the flame war begin...

---

Another good option.

I generally won't use them because I would still wind up with a loop of wire that takes the feedback node back around to itself  that could be long depending on how large the action engine cases may be.  I like the left to righ flow that shift registers maintain.

[tst]

---

@Gregory wrote:

Did For loops not always support shift registers? A single iteration For loop just seems like less of a hack than a while loop with True wired to its stop.

---

In earlier versions of LV while loops were actually "while" loops (meaning the terminal would continue if true), as opposed to the "until" loops which they are now by default (and which I agree this is a better design). You also didn't have to wire the terminal. This meant it was easier to use a while loop.

Personally, my preference is also for feedback nodes (a decent option since ~LV 8.5), and this is probably a relevant point to plug this unpopular idea - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-the-ability-to-split-feedback-nodes/idi-p/3109053

[Gregory]

---

@tst wrote:

Personally, my preference is also for feedback nodes (a decent option since ~LV 8.5), and this is probably a relevant point to plug this unpopular idea - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-the-ability-to-split-feedback-nodes/idi-p/3109053

---

I never thought to use local variables on the left side in place of the shift register / feedback node. I actually like how it carries the name of the indicator because I usually end up making free labels next to the shift registers to remind me what data is inside them.