LabVIEW
Automating Button Clicks
@jackson040 wrote:
I've attempted to implement a third event structure inside another while loop, but the program won't return a reading from the device. I believe this has to do with how I added the new loop
Well, I'm sorry to say it, but you're right!
So, my suggestion was to add those changes to the existing Event Structure. Generally, having more than one Event Structure can lead to unexpected behaviour, particularly when you're new to LabVIEW. (Of course, I don't mean that the behaviour changes when you've used LabVIEW for longer... just maybe you're more likely to expect it!)
The suggestions that involved adding another loop (from johntrich, essentially) should instead have looked like this:
Here, there is no timeout case (in any loop) and there is a separate While loop which contains a Wait function (1000 ms) and then unconditionally enqueues the Read command.
The Read Event case remains in the original Event Structure, so that you can trigger extra reads by clicking the button, if you want.
Yamaeda's solution was more like mine, but would help to reduce the chance of long delays between reads by changing the checking interval to a lower value. It's a bit more complicated (because it requires time checking e.g. with Elapsed Time or similar) and so I haven't created an image here.
Edit: (and important) - I forgot to mention, but in the image above you'll see I added another Stop button. Of course there are other ways to stop multiple loops with only a single button, but you cannot do it in the way that you attempted, because of the principle of dataflow.
The idea here is essentially that a loop (or any other node, structure, subVI (that's a node, but for emphasis...)) will not start until all of its inputs are available. None of the outputs will become available until the loop (node, structure, etc) finishes running/executing.
In your case, the top-most loop had as an external input the boolean control from the middle loop. It was an output of the middle loop. So the top loop couldn't start until after the middle loop finished.
At that point, the value that was output, then an input, would be True. So the top loop would run exactly once. This is marginally better than another common problem, which looks like the following (DO NOT DO THIS!!):
In this case, the loops will read the value of the Stop control before starting to run, and then every loop iteration, they will use the same value (they will never check the control again, because the control is not inside the loop...). As a result, the initial condition is either true (they run one iteration each, and stop) or false (they never stop, until you abort). In either case, the stop button won't make any difference, no matter how much you click it...
No, do NOT put another event structure. You should only need one event structure in a program. If you want to put another loop then just use a loop with a timer. You can use a notifier to stop the loop. You would then want to put a case in the Read case of the bottom loop that only runs it if the communication has been opened.
Edited to add:
cbutcher's reply overlapped mine. He did a good job in explaining, and his example showed what I was suggesting.
So, the top loop looks fine now. It's good that you named your buttons appropriately to give the user (perhaps you) a clue as to what each one stops!
Regarding the error, I have the same question as yesterday (sorry it perhaps got lost in the several posts about different solutions to the timeout/queue entry problem).
What is the actual error code?
I don't have the driver you're using (MB something something, I guess it's one of the MODBUS libraries) so I can't check the contents of the subVI, but if you can give the error information rather than the call chain, the reason might become clear(er...) 🙂
I would suggest adding an error indicator here (arrow):
Of course, yours probably has real icons instead of question marks... If any information appears in the circled "error out", that would also be a possible source of information.
Having looked at this a little closer and realised that both of these VIs are the same (and are reading from some resource) I wonder if they are having some conflict with one another.
You might have some success by taking the error output from where the arrow is pointing, and connecting it to the input of the second subVI (with Set Point 1 Setting as the output). This will require disconnecting the current input where it branches. The result would be something like:
This may (may, no promises!) solve your problem.
