Help understanding what is stopping flat sequence in first frame

[sbernie2]

I'm having trouble understanding what triggers a flat sequence to move from one frame to the next.

Specifically, I have a setup that sends data collected inside an instrument with cryogenic capabilities to a multimeter. A VI (credit to Tektronics, NI, QD Instruments, and V. Morano for original code) reads the data leaving the multimeter while controlling both instruments. The issue is that the cryogenic machine (PPMS) is either controlled on its own computer or on the one that is running LabView, and throws a fit if its control software (MultiVu) is open in both locations.

So to control for this issue I implemented a piece of code which 1) checks if the PPMS is set to be remotely controlled, 2) checks if MultiVu is running, and 3) starts/stops local MultiVu if needed. I put this into the second frame of a flat sequence structure, which I'd like to keep so the other users of this VI can better follow my changes.

In the second frame (top picture), the starting/stopping is incredibly slow - like 2-3 min between user action and VI response. I think this is because of the other highly complex loops in that frame.

I managed to speed this process up by moving this bit of code into the first frame. Now the open/close is super fast! ...but the VI will NOT proceed to the next frame. I've tried moving controls in and out of loops and frames, no luck.

I can do without this code if necessary, but I'm now confused as to what exactly triggers the progression through flat sequences, and it ma come up later.

So, what is not happening to progress to the next frame in the bottom photo? You can change the "PpmsMvu.exe" to "notepad.exe" to run on your own PC. Cleanup suggestions are okay, but I really only care about the frame issue ATM.

old and slow

fast but stops

[altenbach]

(Oh boy!)

In code #1 Your first frame uses 100% CPU doing nothing but polling the controls. (greedy loop)

The loop in the second frame (or code #2) can only spin whenever an event occurs. How often does that happen?

You have event structures scattered across the entire diagram, buried deep inside loops inside case structures. Very Bad!!! 

Overall, big sequence structures are a hallmark of bad beginner code. Learn about state machines instead.

Do you really need to poll the emergency stop button as fast as the computer allows, also burning 100% of a CPU core that could be used more efficiently elsewhere?

[sbernie2]

I'm aware of its many issues with loops/case structures, just trying to make minimal changes to preexisting code. I'll go back and streamline after I jump this one hurdle.

Events occur whenever a button is toggled, so theoretically as quick as a human clicks? In the old version there's about a 2 min wait after any click before the action is performed, no matter how rapidly/frequently one clicks.

Are you implying that the old code is slow because the PC is wasting resources on other things? I had already guessed that. Can you help me figure out why the newer version won't execute past the first frame?

[StevenD]

To exit the first sequence you have to exit the loop. To exit the loop you must meet two conditions: first "Save/VISA Set" must be true, and secondly the event structure has to execute at least once. I would at minimum add the "Save/VISA Set" button to the event structure. 

As altenbach has mentioned there are a lot of architecture problems with this VI however (greedy loops, multiple event structures, data duplication).

Anyway, as a starting point here is a picture of what I recommend.

[RavensFan · Accepted solution]

---

@StevenD wrote:

To exit the first sequence you have to exit the loop. To exit the loop you must meet two conditions: first "Save/VISA Set" must be true, and secondly the event structure has to execute at least once. I would at minimum add the "Save/VISA Set" button to the event structure. 

As altenbach has mentioned there are a lot of architecture problems with this VI however (greedy loops, multiple event structures, data duplication).

Anyway, as a starting point here is a picture of what I recommend.

---

That's not good.  The resource name, file path, and remote control boolean will all be read immediately upon entering the loop.  The loop will wait at the event structure until the Save/VISA set boolean is pressed and read as True.

However if the user changes any of those controls prior to pressing the Save button, they will not be read since they have already been read when the loop started.  You should move all of those controls inside the event case!

[Bob_Schor]

---

@sbernie2 wrote:

I'm having trouble understanding what triggers a flat sequence to move from one frame to the next.

Have you heard about the Principle of Data Flow, the central idea that governs "order of execution" in LabVIEW?  It involves Structures, Inputs, Output, and Data flowing in Wires.

• Structures include Frames (including individual Frames in a Frame Sequence), Loops, Event Structures, things found on the Event Palette, LabVIEW Functions, and sub-VIs that you write.
• Inputs are carried into Structures on Wires.
• Outputs are carried out of Structures on Wires.
• Data flows between/among Structures in Wires connected to the Structure's Inputs and Outputs.

The "Principle of Data Flow" says the following:

• The code inside a Structure does not begin to execute until all of the Structure's Inputs have data present on their connected Wires.
• The Structure cannot exit until all of the code inside the Structure has executed.
• The Outputs of a Structure do not have data present until the Structure exits.

Note that the above points imply that all the outputs of a Structure get data at the same time (when the Structure ends), even though some of the wires providing the data to the "out-going" edge may have data present at various times as the code inside the Structure executes.

So -- what triggers a flat sequence to move from one frame to the next?  Every code element inside the previous Frame has run, and all wires going out of the previous Frame and into the current Frame have data on them.  If the previous Frame contained a Structure within it (such as a While Loop), then the Loop has to execute and finish executing (meaning it has to exit).

Bob Schor

[sbernie2]

OK, so clearly this event structure within the flat sequence is a failure. I tried moving the Save button within the event structure - this allows the flat sequence to proceed BUT it only proceeds if Save has been pressed and then a change is made to the Start/Stop MultiVu button. Not exactly what I want but I understand mostly why it does what it does.

It sounds like State Machines are a viable alternative, and this VI already uses some so I should be good there. However, I'm concerned about nested loops. Are they going to be efficient time-wise? Resource-wise?

Say I have one jumbo loop containing a case structure that is controlled by the Save button - i.e. save pressed/unpressed. Within it, I'm going to place two other State Machines, one for the PPMS controls and one for the electrometer controls. Each set of controls require loops/state machines inside them, as already present in the original VIs. Is this a worthwhile plan? { [ A(x,x,x) B(y,y,y) ] }

[crossrulz]

---

@sbernie2 wrote:

Say I have one jumbo loop containing a case structure that is controlled by the Save button - i.e. save pressed/unpressed. Within it, I'm going to place two other State Machines, one for the PPMS controls and one for the electrometer controls. Each set of controls require loops/state machines inside them, as already present in the original VIs. Is this a worthwhile plan? { [ A(x,x,x) B(y,y,y) ] }

---

State Machines inside of State Machines is a BAD idea.  You should look into having your state machines run completely in parallel and use User Events or Queues to communicate between them.

[sbernie2]

Thanks for the input. New plan: Either 1) something like this example where a queue is used to control a state machine running in parallel to a loop that will stop things or 2) notifiers/semaphore are used to synch data leaving my initial Save loop and going into more parallel loops.

Do we like either plan? Is one preferable?

Are parallel loops a good plan in general? @altenbach earlier seemed to suggest that loops by themselves are wasting processor power. Should I be working to minimize the number of parallel loops? How do we feel about nested loops?

Thanks again, All, for helping me make this code more efficient.

[Yamaeda]

---

@crossrulz wrote:

---

State Machines inside of State Machines is a BAD idea.  You should look into having your state machines run completely in parallel and use User Events or Queues to communicate between them.

---

Yes and no. In general i agree with you and as a simple rule of thumb, yes. However, i'd say it's not uncommon to e.g. implement sub-vi's as state machines, resulting in SMs within SMs. 🙂 

In this case it do sound like separate processes and as such they should run separately.

/Y