How to perform an action after a delay, based on a software trigger

[Rickmmmmm]

My application logs and displays data correctly for 3 analog signals. I have tried to add the capability to do a value comparison based on a time delay after a certain value on one data point has been reached. In other words, once Speed reaches 50, delay for 1.2s and then determine if pressure is within a certain range of values. In general this works, but without using the time delay. It does the comparison and shows the results but the comparison is made as soon as the logic is true after speed reaches 50 and not after the delay.

The code that is performing the delay is in the lower left hand side of my app. and 3 signals are being used with 3 seperate time delays.

[Shea C]

Hello Rickmmmmm,

Thank you for your inquiry regarding time delays in LabVIEW. It sounds like your application is making calculations immediately after the speed reaches 50. I am having a hard time deciphering your code without taking a lot of time to understand it. Could you supply a simpler example that demonstrates the same issue? One possible solution is to use a sequence structure with the delay placed in the first frame and the data to be processed wired through that case to the next case where the calculations are done.

Other responses can be found on the ni.com website by clicking the support tab at the top of the home page. Then search for �YOUR TOPIC� from Technical Resources at the top of the page or topics similar to yours. I hope these resources hel
p. Let me know if I can further assist you.

Shea C.
Applications Engineering

[Rickmmmmm]

Shea,

Thank you for you response.

This code is running on a customer's machine and it is difficult for me to get time on it for troubleshooting. I believe the problem I am having is with the millisecond timer specifically. I will give a detailed description of what is happeneing in the logic and maybe that will make it easier to decipher.

The code in question is in the long skinny case structure in the lower left of the application. This case structure is true when data is being logged.

Since this application is a repeating cycle, the data is logged while position is greater than a setpoint, then logging is stopped when position is less than the setpoint.

When the outer case structure (the long skinny one) is true (during logging) it looks for a speed value of 50 then enables the large inner case structure. This value of 50 is the trigger to begin the time delays. While speed is less than 50 it stores the millisecond timer in "Speed Init Value". When speed is greater than 50, the "Speed Init Value" is stored and used as the start time.

The 3 small case structures are all the same logic for 3 different signals. They have 4 states; 0-3.

State 0 is the initial state and it determines if the millisecond timer will roll over during timing or not. If it will roll over then it goes to case 2, if it will not roll over then it goes to case 1. The math is different based on whether it rolls over or not.

It stays in case 1 or 2 until the millisecond timer, minus the "Speed Init Value" is greater than the delay setpoint. Then it enables the "Check Range" logic, and it changes to state 3. State 3 disables the "Check Range" logic.

All of this seems to work ok except for the comparison of the millisecond timer minus the "Speed Init Value" being greater than the delay setpoint. The application has a 200ms scan rate and the "Check Range" logic seems to be taking place 3 scans after the speed reaches 50. This is what I would expect if the delay setpoint was set to 0. But it happens regardless of the value in the delay setpoint.

Can you look at the section where I am using the millisecond timer in the long skinny case structure in the lower left of the application and tell me if there is anything fundamentally wrong with the way I am using it? I will also try to duplicate the problem in small application as well.

Thanks for your help,
Rick

[Shea C]

Rick,

I am starting to be a little more familiar with your code. However it would take me many hours to completely understand code which may have taken hundreds of hours to develop. Two things do come to mind without seeing a simpler VI. It is possible that the Timer has already passed the Speed Int Value and is immediately moving on to the third state. You also have to be careful when using the Timer VI because the value of the millisecond timer wraps from (2�32)�1 to 0. It is clearly a timing problem and you may want to try running the code in Highlight Execution mode and probing certain areas to clearly understand how your code is executing. I hope these things help!


Shea C.
Applications Engineering