02-21-2013 12:34 AM
I have a VI in which there are two independent while loops,
I am using 2 booleans namely functioning as,
1. Close – Will be true when user will press exit from the front panel.
2. Error – TRUE when there are 3 successive failures in serial communication.
In both the while loops above two booleans are ORed & used as termination condition. The problem is when there is failure of serial communication and after 2 (Say) second user presses the exit button from front panel the program is not terminating as reason is error boolean is not executed still and OR node wont be executed until both the inputs are ready. But I want to terminate the VI as soon as user presses exit from front panel after 2 (Say) sec by terminating both the while loops but this is not happening. I know this approach is wrong.
What are the approaches to deal with it ?
Thanks
02-21-2013 02:39 AM
You should post a little example. I am not sure how pass the values of the terminals into both concurrently running loops. Are you using variables?
I think you should look into the producer/consumer or master/slave pattern for some interesting approaches to manage concurrently running loops.
Norbert
02-21-2013 02:55 AM
I am using local variable..This is just an example for reference only. Please focus on right corner of the VI only.
02-21-2013 03:02 AM
Your block diagram is way too big. Make it smaller.
Additionally, the second loop hogs a complete core to 100% load since you don't have wait times included.
IYour second loop most likely starts running before you reset the variables (left of the first, big loop). So this is a race condition.
Because you work with variables, the boolean buttons must not be "latching". You chose to configure (at least the button "Close") to switch until release.
I think that your first loop is too slow to see a short pressing of the Close button. So it will keep reading "false".
You should switch to a proper architecture as already recommended.
Norbert
02-21-2013 03:29 AM
The block inside first while loop can't be small,
It doesn't matter for me if second loop most likely starts running before you reset the variables as both are false.
I just want to know how to terminate the VI. What architecture i can use for that
02-21-2013 03:38 AM
@Ranjeet_Singh wrote:
The block inside first while loop can't be small,
[...]
There are many ways to reduce the size of the code on the block diagram.
The most obvious being removal of redundant code by proper usage of subVIs......
As i alread wrote, you should look into producer/consumer and/or master/slave.
Norbert
02-21-2013 03:55 AM
Lets not go for reduction of code inside first while loop,i tried already.
See there are serial communication involved so queue cant be helpful, Still working on which is better & how to use that in my application.
Thanks
02-21-2013 05:00 AM - edited 02-21-2013 05:01 AM
Hi Ranjeet,
you provide a lot of help in other threads, but when good tipps are given to you you resist to follow them?
You already got a honorable mention in the Rube-Goldberg thread for providing code like that:
On the upper side you see equivalent code.
Most of your VI is doing all the work in an overly complex manner. Please remove RubeGoldberg code and PLEASE put a wait in your second loop...
02-21-2013 05:33 AM - edited 02-21-2013 05:37 AM
@Ranjeet_Singh wrote:
Lets not go for reduction of code inside first while loop,i tried already.
Seriously? That's your attempt at reduced code? First of all, you way over abuse the Type Case function. Secondly, you can reduce your code A LOT by simply using the Index Array and expanding it down. Here's some more reduced code for you to look at.
On a serious note: What is the second loop supposed to be doing? The way I see it, you already have all the information you need in the first loop. I don't see a point in your second loop.
02-21-2013 05:58 AM
@crossrulz wrote:
[...]
On a serious note: What is the second loop supposed to be doing? The way I see it, you already have all the information you need in the first loop. I don't see a point in your second loop.
Nice remarks on the oversized block diagram, Gerd and crossrulz.
I am guessing on the quoted: He wants to add some concurrent functionality and the posted VI is simply some kind of "proof of concept". So i hope that a simple "hogger loop" is not the task! 😉
Norbert