LabVIEW
Conditional parallelism on LabVIEW
I am writing an application to update the numeric value given user's input value and depending on the user's input value the program checks if it is greater than 10 if it is greater than 10 then the program waits for 1 second and then will have a popup message says "true".
My intention was to call the conditional check, printing true every one second if the user's input value is greater than 10; in other words, the case structure was to be called regardless of the event structure in the same loop infinitely.
But it doesn't seem to work the way I expected. Unless there is user's new input value, getting into the event structure, the program doesn't get to the case structure even though the case structure is in a loop.
Is there any way to call the case structure not dependent to the event structure but I want to use a shift register for the numerical value and also having an event structure and a case structure in parallel.
It would be easier if you attached a copy of your vi so that we could run it to see what's going on. What you are doing should work, though there are a few things that you should do differently. First, you should initialize the shift register. Otherwise you may get an unintended data point on the first run. Next, there is no need to write the value back to the control. You are reading the value from the control. Also, are you doing something in the timeout state? Is there a reason that you're using the previous value of your numeric for your timeout? What is happening in your False case?
- last edited on by
Content Cleaner
The loop doesn't iterate because it's waiting for all things inside of it to run - when there are no events, the event structure waits forever (unless you connect the timeout).
However, it looks like you must have a timeout case (you wired the timeout) and I'm guessing from the icon on the Event Structure tunnel that it doesn't contain any code (including wires).
If this isn't doing what you're describing at least once, then I think it must be due to a race condition (although I'm surprised).
The reason it only prints once (if that's what you're observing) is that the timeout case is outputting the default (0) value, which then doesn't satisfy the condition.
The normal way to do this would probably be to handle the input inside the Event Structure. If you don't want to do that (because this is a simplified example, and your real code takes a long time to process etc) then you can consider something like a Queued Message Handler. You can make one essentially by combining Producer/Consumer with State Machine, where the Producer is your loop with Event Structure, and your Consumer contains your message handler (State Machine etc).
As a side note, you should probably place your stop button inside the Event Structure and give it its own case - otherwise it won't stop in quite the way you expect (although with the short timeouts you might not have noticed).
I recreated the code as shown (assuming the timeout event is empty and the False case is empty) with only the change that I did not write the value back to the control since it was already there. The program worked as I believe that the OP wanted. I suspect that the OP has much more complicated code that he is trying to run in parallel and likely should consider other design patterns (QMH, for example) which move the parallel operations into a separate loop.
It is muy importante to remember this little phrase:
"Remember that a node executes only when data is available at all of its input terminals and supplies data to the output terminals only when the node finishes execution."
Taken literally, you can see that the input to the shift register - considered to be an input terminal - will not have data supplied to it until the event structure produces an output. Your loop cannot iterate until the shift register gets some data out of the event loop.
I would as was suggested and convert this into a QMH design pattern, or something closely related.
@billko wrote:
It is muy importante to remember this little phrase:
"Remember that a node executes only when data is available at all of its input terminals and supplies data to the output terminals only when the node finishes execution."
Taken literally, you can see that the input to the shift register - considered to be an input terminal - will not have data supplied to it until the event structure produces an output. Your loop cannot iterate until the shift register gets some data out of the event loop.
I would as was suggested and convert this into a QMH design pattern, or something closely related.
Not sure why the loop wouldn't be able to execute - uninitialized shift registers are used all the time in FGVs. The code will run just fine, but the initial value is unpredictable on the first run of the program. I still recommend something like a QMH because I suspect that the actual application is much more complicated.
@johntrich1971 wrote:
@billko wrote:
It is muy importante to remember this little phrase:
"Remember that a node executes only when data is available at all of its input terminals and supplies data to the output terminals only when the node finishes execution."
Taken literally, you can see that the input to the shift register - considered to be an input terminal - will not have data supplied to it until the event structure produces an output. Your loop cannot iterate until the shift register gets some data out of the event loop.
I would as was suggested and convert this into a QMH design pattern, or something closely related.
Not sure why the loop wouldn't be able to execute - uninitialized shift registers are used all the time in FGVs. The code will run just fine, but the initial value is unpredictable on the first run of the program. I still recommend something like a QMH because I suspect that the actual application is much more complicated.
Billko is referring to the dataflow concept - the inner edge of the right side shift register is waiting for data.
@cbutcher wrote:
@johntrich1971 wrote:
@billko wrote:
It is muy importante to remember this little phrase:
"Remember that a node executes only when data is available at all of its input terminals and supplies data to the output terminals only when the node finishes execution."
Taken literally, you can see that the input to the shift register - considered to be an input terminal - will not have data supplied to it until the event structure produces an output. Your loop cannot iterate until the shift register gets some data out of the event loop.
I would as was suggested and convert this into a QMH design pattern, or something closely related.
Not sure why the loop wouldn't be able to execute - uninitialized shift registers are used all the time in FGVs. The code will run just fine, but the initial value is unpredictable on the first run of the program. I still recommend something like a QMH because I suspect that the actual application is much more complicated.
Billko is referring to the dataflow concept - the inner edge of the right side shift register is waiting for data.
Correct. It will get data when either of two events occur - the value changed event is registered or the timeout occurs. Granted in this case the timeout is unpredictable on first run.
