LabVIEW
Message box stops VI running in Background
I see a lot of very questionable code (deeply stacked structures, too many local variables, serious race conditions, greedy loops, unneeded sequences etc*), but I don't see the code for any message box. Can you point us to it? (Or are you talking about error popups generated inside the system VIs?).
Popups are typically modal, so you simply need to ensure that they are called in parallel (or complete immediately while leaving the panel open, for example) so the code can continue. Maybe an informational string indicator on the main panel is preferrable over a popup?
@Rashkrash wrote:
2. I wish that the process start from starting and so many time how much number i put?
Sorry, I don't understand your second question at all. Can you explain. Everything typically starts from starting, whatever that means. Where do you put a number?
* examples of code problems:
- "Dritte": If you would eliminate the delta_P_Q_i local and would wire from the indicator wire nearby, you could eliminate the sequence structure because execution order will be determined by dataflow
- "Dritte": Race onditions with stoppp2: most likely the one guiding the state selection in the right will be read before the inner FOR loop event starts, so if the code is stopped while the inner code is executing, you'll go to the wrong state afterwards. same problem in "Erste" and "zweite". Delete the outer local and wire from the one inside the loop to enforce proper order.
- The lone outside sequence at the bottom makes no sense.
- The inner loop in "zweite" uses 100% CPU doing nothing relly useful. Slow it down!
- Why is "i 6" double instead of I32?
- ...
Are you talking about "Warten_VI_Neu.vi"? You did not include that so we don't know if it is a popup or not or what it does. Maybe you could simply place the contents of that case structure outside the inner while loop so both can run in parallel. It still guarantees that the main code cannot proceed to "zweite" before both the inner while loop and the popup have finished.
We need to see the code of the subVI to decide. Why are you calling it multiple times, once per iteration of the inner loop (or as long as "start Ventil" is true). Since the "erste" state cannot be reached unless "start ventil" is true, and your switch has "switch until released" boolean actiion, the outcome is very unpredictable. When "Erste" is reached, it could (1) already be FALSE the first time the local variable is read or (2) it could be TRUE for a few iterations, making the code very unpredictable. Of course if there is a popup, the user needs to release the boolean, but it all seems very fragile. "Switch until released" is very rarely the right choice, so don't use that!
Yes, the function of "I 6" is clear, it is just not clear why it is not an integer.
You still need to address all other serious code flaws as already explained.
The way I understood it, the popup should just run in parallel to the code if the currest state. The next state requires the output of the subVI, so a completely asynchronous call would be problematic. I think it is sufficient to place the popup outside the inner while loop of that state.
(Sorry, currently don't have access to LabVIEW, so I cannot look at your suggestion).
- You still have tons of serious race conditions.
- Why are you now using value property nodes everywhere?
- You have event structures inside case structures, so they are not guaranteed to be reachable by dataflow to service the event, yet they lock the front panel until the event completes. That's not good!
- You still have serious architectural problems with loops inside cases, inside loops, etc. ad infinitum.
