07-29-2021 09:15 AM
Hello everyone,
After doing a bit of research I've dig up this thread about interruptions using queues and sub-VIs : https://forums.ni.com/t5/LabVIEW/Interrupt-a-an-unfinished-state-in-a-QSM/td-p/2817784?profile.langu...
JÞB analogy is quite good and represents well my problem : I have a few short actions and then one that is longer (5s to 1 min). The problem is that even if it's long, it needs to be well precisely timed. That's why I am currently using a timed loop.
But if I use a timed loop, I won't get out of it until the action is over, so i can't interrupt it by sending a priority message because i can't send the action back to itself through queue.
My idea would be to get rid of the timed queue, send the action back to itself and measure time since last execution and then execute it again when it's time to, but i'm not sure about it.
It would look like this :
Do action -> Measure end time -> Send message in the queue "do action" -> Measure start time -> wait for time to pass -> When enough time has passed, do action.... This can be interrupted with a priority message.
But keeping the timed loop would ease things a lot. Any ideas ?
Thanks,
Marl
Solved! Go to Solution.
07-29-2021 09:26 AM
I would use a state machine to do this. It can be implemented using a queue or an event structure with user events. In my state machines I also have timers that I can start/stop that will fire off an event message back to the state machine. The timers auto adjust to account for clock drift so they work nicely over extended periods of time. They can also be synchronized to seconds, minutes or hours. They have proven to be as accurate as the clock on the PC. In terms of the state machine, it it is doing other tasks your timing could be affected but if it is dedicated it should be pretty good. In a dedicated state machine the timer could be part of the state machine itself much in the way you describe. My timer class uses the event structure and the timeout case as the basis for the timer. From my testing I have found that it is never more than a few milliseconds off which is to be expected on a PC. If you are using a RT target, than the timed loop may be more accurate. Even there, I think the timer on the event structure would be fairly accurate.
07-30-2021 01:11 AM
Thanks for this clear and detailed answer ! I will dig into this.