LabVIEW
Wait on Front Panel Activity crashes labview?
Solved!
Do you have all of your front panel activity captured in an event structure elsewhere in your code? Does this event structure have a timeout? Perhaps it would be more practical to implement code that only ran if the timeout ran x times consecutively. This would be as simple as initializing a shift register to 0. In timeout case if it is less than X then increment - otherwise run your code to turn background scanning back on. In all other cases reset the value to 0. You could add logic in the timeout case to track whether it's on or not, and do nothing if it's already on.
I can't really see why the Wait For Front Panel Activity funtcion would be affecting your application in this way. I do know that you are using a VI that was created what, twenty, maybe twenty-five years ago to solve a problem that was solved a few years later.
Maybe, as others have mentioned, you might re-architect the code to use a different approach - if nothing else, at least as a troubleshooting step. All you need to do if it doesn't solve it is revert to the current version in the repository. (You have one, right?)
@msoflaherty wrote:
It feels a bit like we're backtracking here, this has all been covered, chaps.
@johntrich1971 wrote:
Do you have all of your front panel activity captured in an event structure elsewhere in your code? Does this event structure have a timeout? Perhaps it would be more practical to implement code that only ran if the timeout ran x times consecutively. This would be as simple as initializing a shift register to 0. In timeout case if it is less than X then increment - otherwise run your code to turn background scanning back on. In all other cases reset the value to 0. You could add logic in the timeout case to track whether it's on or not, and do nothing if it's already on.
This is exactly the solution Altenbach suggested in the first reply to this topic. As I said in my reply, alongside the 'Wait on FP' there is an event structure that handles UI interaction, and triggers background reads on timeout.
The issue, as per the linked reply, is that
" ... the timeout case triggers other cases (via signalling property node writes), and those would be indistinguishable from user triggers (unless in every case I added code to check the event source, which would be a fair bit of work). So it's not as easy as counting how many consecutive timeouts occurred."
And yes, I shot myself in the foot by not decoupling UI interaction from code execution - I've admitted that already, but i'll say it again. At this point, though, I'm just not up for restructuring the code.
Since this thread doesn't seem to be going anywhere at this point, I guess I'll put you all off by scaring you with the real code: I uploaded it to github - don't expect to be able to run it without any hardware or dependencies, but at least you can see what i'm working with here.
@billko wrote:
I do know that you are using a VI that was created what, twenty, maybe twenty-five years ago to solve a problem that was solved a few years later.
I really don't see why the age of the function is in any way relevant. If it works, it works. If it's broken, it should be fixed or removed.
As some excuse for my unwillingness to put in the time and effort of a rewrite, I'm currently working a 9-5 writing firmware, writing up my PhD thesis in the evenings, and preparing for a post-doc interview next week. So to say I've got a bit much on my plate I feel is justified. 😫
Sorry for the backtracking. For some reason I had forgotten that you were using value signalling in your timeout - I thought that you were using User Events in which case you could easily decouple anything that was still coupled.
I get 404 error when I click on your github link. Is it possible that you could zip the files and upload them here? I think that seeing your code would give better clarity.
Good luck on the PhD thesis and the interview!
OK, it's been nearly a week, I'm going to mark that as the solution.
This is the new code:
case [0] is shown
case [1] stops on stop.
case [2] stops on stop. (those 2 cases need to be separate as only this one seems to catch the new value of the stop button).
This still feels like a bit of a 'hack' to me - using an event structure with events registered to 'key down + mouse down panel 1 + mouse down panel 2 + ...' seems like an inelegant way to reproduce exactly what 'wait on FP activity' does natively. But, it works, so good enough for me.
Thanks to altenbach, john, bert, ben and bilko for all the suggestions and support. 😁 You guys make these some of the best forums around.
