Abort Execution button no longer interrupts "wait (ms)" is that normal?

[SenCore]

This is probably something obvious.  However I just upgraded to LabVIEW 8.5.1 and I THINK its behaving different than before and I think its incorrectly.

I've attached a sample piece of code.  All it does is to have a counter count seconds.  It also checks a button to see run a 20 second delay.  The counter should keep counting during this, and it does.

Now... if you run the code on a cRIO and DON'T press the "Run 20sec WAIT" button... and then press the "Abort Execution" button in the menu bar it will terminate immediately... if you press "Run 20sec WAIT" and THEN press the "Abort Execution" button quickly... it seems like you have to wait until the "wait (ms)" finishes execution before the VI will terminate.

I don't remember this being the behavior before.... and it seems like its incorrect.  What happens if someone coded a wait (ms) that was for 1,000,000,000 ms?  They have to wait hours for the Abort to take?

[LaurenLL]

Hi SenCore,

I have been investigating this behavior, and you are correct in saying that the abort button is waiting for the wait function to complete.  I also tested it out on LabVIEW 8.5, and saw the same behavior, so I do not think this is new with your latest upgrade.  Either way, this behavior is unexpected, so I have filed a Corrective Action Request, #117894, to investigate this for upcoming releases.

In the meantime, you may want to try to avoid using wait functions within timing structures.  The general purpose of timed structures is to handle the software timing of loops without requiring additional waits.

Thank you for your feedback.  It is through feedback such as this that we are able to improve our products.

Regards,

Lauren

[StevenA]

Is this issue you are working on in LV RT only?

[SenCore]

It is in LV RT only as far as I can tell.

As for avoiding its use in timed structures....  How do I create a sequence to turn a pump on, turn a valve on...wait 30 seconds turn the valve off, turn another valve on for 5 seconds, turn that valve off, turn off my pump... and have it all controlled by a button on the front panel?

I've used a timed loop to poll the button and then inside of that I have a sequence with wait commands in the appropriate places.... can timed sequences have different delays for each frame?  How?

[SenCore]

Answered my own question... yes they can...   New question  How much overhead is there in a timed loop?  If I follow this suggestion (which I agree might be the correct thing to do) I'll be putting timed loops in all over the place to poll things like buttons where the timing isn't that important, however I don't wan't the processor to be loaded down with watching the button.  I've been using a 10ms delay in those loops... is that the wrong thing?

I know in normal labview you can use front panel events, but I don't think those are available in LabVIEW RT accessed remotely.

[StevenA]

It sounds like you are running your RT application from the development environment and using the front panel of the RT VI as a user interface.  Generally this is not a good idea.  It's fine for development and debug, but a better practice is to create a separate vi that will run on your windows host that is used for your GUI.  You will communicate all of your user interface over ethernet to the RT vi.  Use an event structure in your windows vi to capture a button press, then send that "command" to the RT.

Good Real Time architecture it a little different than standard labview.  Good practice is to at least create two "loops".  One that deals with communication from the Host, and one that does your control.  I put loops in "" because these loops could really consist of multiple loops in some cases.  The idea is that the loop that does your  communication is set at a lower priority (and loop speed) and your control loop or loops set at higer priority.   RT FIFO Shared variables are a good mechanism to do the communication between your communication loop and your control loop.  Network shared variables are good mechanism to use between the Host (windows) vi and the RT vi.  I also really like to use the Simple TCP Messaging Protocol.  For info on that look here. It is a very good communication tool and is very worth while to learn.  This mechanism gives you a command based mechanism that you don't have to poll. 

One more comment about your wait question.  Typically you want your high priority control loop to run at a constant rate.  This will give your RT application more stability and less timing jitter.  RT is built for constant loop times.  If you need to create a delay in the control, keep your loop iterating, but use a state machine to set your value, then move to a state where nothing happens until X number of loops have passed.  X number of loops times your loop time is your delay. 

[SenCore]

Great advice...  I hadn't thought of it in that way.  LabVIEW RT is new for me and I'll keep it in mind for future applications.

One difference in THIS case is that the final application I'd like to be able for the user to control from the Web, so I'd rather not have a Host VI in windows for this application.  I don't want the user to have to install anything to use my equipement.  With a Web interface, I'm kinda stuck with what I'm doing I think unless I'm missing something.

The good news is that my timing is a bit more lax than RT.  For the most part if things slip a little in their timing its okay.  The things that require more determinism I have run without any interface on a thread at high priority, and if they are a few (ms) off no real harm will be done.  I'm using a cRIO and the things that require absolute timing precision I've implemented on the FPGA.

[StevenA]

Even though you are going to use the web server (remote panels) then you may still consider making a single vi that has all your user interface on it that sends data to the control loop vi (the vi that interfaces with the FPGA code).  That way you could have a single loop that polls all the front panel controls and then passes that data to the control loop vi.  This may not be needed depending on the complexity of the vi and your RT cpu usage.  For each loop you run, it will cause some overhead.  Is there a reason you would need to create a new loop for each control you want to poll?  Can you not put all the controls in the same loop and poll then all at the same time?

[SenCore]

Actually, I've already thought of that for the most part and many of my front panel controls are actually polled in one loop,

A second loop is state machine controlling the rest of the system and mechanics (valves, pumps, etc)... that loop polls a control or two to change states.  Its not too much of a problem because once the control is polled and the state switches then that state has to complete before any of the controls in the state machine loop are needed.  I did it under the belief that while a state was being "executed" the other controls in the state machine loop aren't necessary and polling them during that time seems to be useless.... so I put the state machine in a timed loop... poll the commands that change states and then execute the state.... I configured the outer timed loop for the state machine to discard missed iterations.

Perhaps I should rethink that and move those controls to the main polling loop and then pass the data for those few controls...  whats the advantage?

Sorry if I'm taking alot of your time with this but I'm learning quite a bit.

[StevenA]

It soulds like what you are doing with your controls is ok.  One more question, are you placing a timed loop inside another timed loop?   Is it possible for you to post your code or take a screen shot of your diagram for us to look at?  I