Hi I am looking for an easy way to get the elapsed time since the last front panel action was performed by the user. This should be a security check as after two hours the system should stopped. Formally I have checked this by comparing a the absolute clock value read before the appropriate loop to the actual time. But as I now have two loops in parallel this might not work and anyhow I hope there should be a nicer solution.
Solved! Go to Solution.
There is a function in the Dialog & User Interface Palette called Wait for Front Panel Activity.
I would use that in its own loop to update a functional global variable (even a local variable or global variable could work). Everytime it executes, it puts the current time into the variable.
Use another loop to monitor that variable. If the current time is equal to or greater than 2 hours plus the time stored by that Wait for FPA function, then execute your shutdown strategy.
It sounds like you are describing something similar. If what you are doing now is not working for you, post your VI so we can comment in it an suggest improvements.
Another way is to use the event structure (if you use a producer /consumer design pattern) to reset a "shutdown counter" when there is a front panel action. See attached.
Ravens, next one is 10K, congratulation!
Hi 'Ravens Fan' and 'Ben64',
thanks both for your fast and very helpful reply.
The reason why I have chosen Ravens solution is that I am not really familiar with these event structures (I know its really a shame). But I still think that your solution Ben64 would have been much more complicated to implement, as I have two independent while loops (except that the stopping is controlled by the same button) with a stacked frame before and afterwards for initialization and stopping communication, respectively.
With the extra while-loop it finally worked. But I had put the 'wait for user action' within a case structure (false case) which is wired to the read local variable of the stop button. Otherwise the whole VI did only stop after pushing the stop button and doing an additional action. What I am still wondering is that it seems that a single action (like changing a value) is recognized as at least two actions.
I think the event structure method would have been problematic because you would essentially need to create events for just about every UI interaction possible. And even then, I think there are some things you couldn't code. For instance, I don't know if there is any event for just doing a mouse wiggle on the screen. But that seems like something you would want to capture as well and reset the clock. The Wait for Front Panel Activity function would detect that wiggle.
I think the issue that caused you to add code to handle the stop button is almost like a race condition between the front panel activity and the button action. Once you hit the stop button, the activity the front panel activity has already occurred by the time the stop button value is read to stop your while loop. Now in all likelihood, if you hit your stop button, you are probably not goint to stop the mouse instantly after actuating the button but the mouse will move some more which would generate additional front panel activity.
One other alternative you could use is to use the function Generate Front Panel Activity. That is a way to programmatically trigger the Wait function to stop waiting.
I'm glad you got things working.
Well, I think it depend on what you define as front panel action in this specific case. If you define it as anything from button pressed to mouse move then you don't have the choice to use the Wait for Front Panel Activity VI. But if your front panel actions are limited to some commands sent or settings change you're probably better with the event structure if you don't want a mouse movement to reset the counter.
Thanks again to both of you. It is really helpful to get not only an answer how the solution is but also some more information on the pro and cons.