How to pause a vi programmatically (with many loops and cases)

[ASH2020]

Hi all,

I would like to be able to pause the operation of a vi at any point and resume where it left off.

I have looked at the examples in the forum and cannot find anything that I can use. The vi is an event driven case structure with various different sampling loops and I have tried all manner of things without any success, The problem seems to be that the data collection loop needs to finish before it will respond to the button, even if there is an event for that button press. In the case of something looping for maybe an hour, that clearly isn't viable.

Strangely, the pause button on the menu bar works perfectly, all I need is to use that programmatically, without adding extra loops etc. Is there a simple way?

I have attached the code but it won't mean much and won't run without hardware.

Thanks for any help.

Andrew

[jwscs]

hi ash,

attached is your code with some comments.

plz clean up your code before asking ppl to have a look

not everyone has an 8K monitor laying around,

also it doesn't help yourself debugging.

follow the DRY (don't repeat yourself) paradigm in coding.

most definately don't use the STOP before your have executed your teardown code.

regarding the pause. i think you should consider another approach,

like keeping a record of the state and load it next time you run your vi

regards

[ASH2020]

Thanks for that. It's clearly work in progress and the reason the code is spread out is that I don't have all the specification yet, I am modifying things as I get more information, not the best way to work. The stuff off to the side of the front panel display is of no interest to anyone. Likewise, there are redundant bits on the block diagram which I may or may not need, so I don't want to delete them.

Thanks for the bit about labelling wires, that is very useful.

The reason for needing a pause is that it is a patient applied medical sensor. If the patient moves, the operator might want to pause temporarily and then resume when the patient is settled.

Reflex 1 and Reflex 2 might or might not be the same, according to which tests are being done.

As and when the system is working correctly, (hardware and software) then I will consolidate the whole thing and break down into sub vis and loops. I understand that, in an ideal world, you should never have more code than will fit on a standard monitor before breaking down into subs, but I'm afraid this whole project is neither bottom up or top down, but a sort of side to side and back to front!

Cheers

[jwscs]

i'm not quite sure, but i think what you want is to pause the measurements.

just do exactly that, let the program run its loop, have a button/state that decides wether your data acquisiton is running or not.

have a look at producer-consumer design pattern

[GerdW]

State machines might help too!

[ASH2020]

---

@jwscs wrote:

i'm not quite sure, but i think what you want is to pause the measurements.

just do exactly that, let the program run its loop, have a button/state that decides wether your data acquisiton is running or not.

have a look at producer-consumer design pattern

---

Thanks. there is already a queue in there. Is that what you mean by producer-consumer?

The way the system works is that the GUI (my Labview end) sends a request for data to the other microprocessor in the system, (running a Forth core) which then sends 2 packets of 50 data points back, which I then stitch together and plot as 100 points. It then loops, doing the same thing for about 4 minutes. 

The problem I have, so far is that once the loop is running the pause button doesn't even work, i.e. you click on it and it doesn't go in. When the loop ends, you see the button go in and then things happen. I thought the whole point of an event case was that it responded from wherever you were.

Do I have to continually poll the pause button to see if it has changed state? That seems to contradict the idea of event driven processes. Also, does the button have to be inside the loop? I really want it outside all the loops.

[GerdW]

Hi Ash,

I thought the whole point of an event case was that it responded from wherever you were.

THINK DATAFLOW is the main order you have to obey!

Dataflow: a node will be executed when all it's inputs are ready for execution…

Do I have to continually poll the pause button to see if it has changed state? That seems to contradict the idea of event driven processes.

No, use the event structure to wait until someone presses the button…

Also, does the button have to be inside the loop? I really want it outside all the loops.

The button itself doesn't has to be in the loop. (It is still recommended to put it in a loop, especially for the latching ones!)

BUT: the event structure has to be in a loop. And the event structure has to be able to react immediatly on events: THINK DATAFLOW!

On your VI:

- Are you sure you want to react on "MouseUp"? Really? Most often a "ValueChange" event is needed!

- Calling a STOP function inside a VI is plain wrong. Especially when there is code for cleanup later on…

- having event cases running for "long" time is usually bad program design! Example: the "Priming" case runs a FOR loop 4 times. Inside the loop there are several waits of 0.2s and 4s, so the loop runs atleast for 16s…

[jwscs]

take what GerdW said to heart

and a queue and an event structure don't make it a producer-consumer-design-pattern, although it uses both of them.

you also have to decouple your measurements from your presentation

[cbutcher]

Some quick comments along the lines of those already posted:

• You can use SubVIs even if you don't know if they're finished/going to be changed. You can always delete them later. If you really want, you can right click on a SubVI and choose to "Replace with SubVI Contents", which will basically copy-paste it out for you (this is almost the inverse of Create SubVI on the Edit menu).
• Reflex 1 and 2 are almost but not quite the same case. It seems to me that you're changing only the stimulus choice between two different wires. You can make one Event Structure case handle both by going to the edit window for the structure, choosing to Add Event, and selecting the second. Then you can use a Select node with the two inputs, and compare the CtrlRef available on the left edge of the Event Structure to get a boolean allowing you to choose between the two at the Select node (compare equality to a reference for one of the buttons).
• Here is the link for the Producer/Consumer design. This might be useful, but maybe you already read it.
• Here is the link for the State Machine tutorial. This might require too much overhauling to be the best way forward at present, I'd say once you modularise with some SubVIs it will be easier to see what you want to do.

[ASH2020]

---

@GerdW wrote:

Hi Ash,

I thought the whole point of an event case was that it responded from wherever you were.

THINK DATAFLOW is the main order you have to obey!

Dataflow: a node will be executed when all it's inputs are ready for execution…

Do I have to continually poll the pause button to see if it has changed state? That seems to contradict the idea of event driven processes.

No, use the event structure to wait until someone presses the button…

Also, does the button have to be inside the loop? I really want it outside all the loops.

The button itself doesn't has to be in the loop. (It is still recommended to put it in a loop, especially for the latching ones!)

BUT: the event structure has to be in a loop. And the event structure has to be able to react immediatly on events: THINK DATAFLOW!

On your VI:

- Are you sure you want to react on "MouseUp"? Really? Most often a "ValueChange" event is needed!

- Calling a STOP function inside a VI is plain wrong. Especially when there is code for cleanup later on…

- having event cases running for "long" time is usually bad program design! Example: the "Priming" case runs a FOR loop 4 times. Inside the loop there are several waits of 0.2s and 4s, so the loop runs atleast for 16s…

---

Thanks GerdW

I will have a go at cleaning up today, and trying to shorten the time inside a loop. Although, in the case of the Priming loop, it must happen 4 times with exactly 4 seconds between iterations. the 200ms wait is because if I do a serial write and immediately serial read, it crashes. 100ms is the absolute minimum between write and read. However, I believe the 200ms and the 4sec are not additive.