LabVIEW
How to time and relay commands and value-signaling to sub-VI
Hi MaWi,
@MaWi711 wrote:
I've been teaching myself, mostly, so I've probably done some stuff you will tell me to 'NEVER do that' - please be kind, tell me why and I'll try to improve 🙂 VIs are attached but as I said fairly complex, so I added annotations in the top left corner of while loops to explain which is which. If someone is willing to help I am happy to go more into detail.
Please do some of those Training resources at the top of the LabVIEW board (again)!
Especially look at:
- avoiding local variables, especially when the terminals of frontpanel elements are unused in the block diagram!
- avoiding local variables by using shift registers!
- learning about "best practices" for using event structures! Most of your loops can be simplified into just one loop, with one event structure with more event cases. Most often you don't need a case structure next to the event structure as you can execute to code in those cases directly in the event cases!
As the code is right now I wouldn't try to implement even more functionality. I recommend to step back and start over with some more thoughts about the algorithms and programming schemes you want to implement…
I can't open your vis because I'm still on LabVIEW 2019 but I wanted to respond to a couple of your comments.
@MaWi711 wrote:
Can "hiding" front panel elements in nested loops cause problems? If they need to be read from multiple loops, in which should I put the element itself (and local variables for the rest)?
When I started this project I also didn't know about shift registers but I can see now how some local variables and even front panel elements could be replaced by them. Thanks for the hint. Apart from needing memory, is there a reason not to use local variables? In some cases, like the stop button, I can't avoid it because every loop also needs to stop executing when stop is pressed.
I would not "hide" front panel elements in nested loops. It sounds like you really don't have an architecture. When you have multiple loops it is generally a good idea to have one loop that handles all of the UI interaction and some type of approach to send the information in an organized way to the other loops. I generally use queues. Others utilize channel wires. Local variables can be used, but you need to keep in mind that race conditions may occur. You might, for instance, get one more loop on some loops than on others if you use a local variable for your stop button because of when the local variable is read. While there are some instances where Local Variables are OK I recommend that you take great measures to avoid them when you're new to LabVIEW. You'll soon find that you rarely, if ever, really need them.
@MaWi711 wrote:
When I first started, I was taught that event structures should only be used to output numbers which are then handled by case structures, i.e. "never put any more complex functionality in there". You're now saying the opposite. So how can I tell if it is ok to put something in the event structure directly?
It is generally not a good idea to put code inside your event structure that is going to take a long time to execute. That's probably what was meant by "never put any more complex functionality in there". My recommendation or long actions is to react to the UI interaction and send the appropriate information to the loop(s) that need it. This leaves your UI open for more interaction while your process is running. You don't, for instance, want to put the code to wait for 2 hours inside your event loop, essentially locking your front panel for two hours.
I would recommend looking up queued message handler (QMH) on this board (include DQMH and even as a variation CMH) for ideas on how you might communicate between the loops. Once you've got that figured out putting the code into subvis that communicate with the main vi is a piece of cake!
