Ok, so you mean, the Data Acquisition VI's output will not trigger another actions, so nothing/nobody is waiting for it to finish, yes?
Hmm, interesting. This means, I start a Datasocket VI and it will work and simultaneously the other loops will begin to work as well. Ok, I understood now. I thought it's in front of the other operation in the data flow. I know that the position on block diagram doesn't matter for execution flow, but I thought it's wired to someone's input.
So this is equal to some independent loop in the same vi. right? Good design to keep the code managable.
OK, in my case, I think I should have this loop in the same VI, because the data from datasocket will start some actions which would reflect on the front panel. so I think it should be in the same VI, for the sake of simplicity.
Yes, I do understand your point. Actually if you see the previously posted designs that I made, it shows the same thing (many loops in parallel), but I was just afraid to load so many loops in parallel. All this discussion was my attempt to understand if you're doing that in the same way or have a better way with reduced CPU expenses.
And, as a matter of fact, even after creating several Event Structures, I am still going to load those loops, and things would be redundant. Although, I would manage different states with different event structures successfully, because at each state the user sees only a certain set of controls, there would be redundancy in datasocket loop (that also has to be in all the states where i create event structure), apart from the bad design (multiple event structure).
So, yesterday I took a brave step, and considered your suggestion (I got convinced that there is no harm) and changed everything into what I had planned to do earlier and what you and Norbert have been suggesting me to do.
Now, I have a big loop, with a state machine, and there are just 3 states - Initialize, MainUIEvents, End.
That MainUIEvents has now events which were earlier handled in StartUIEvents, LoginUIEvents etc. (I think the names suggest what they did).
So everything like DS operations, Event structures and other loops for Video etc. happen here and the outgoing state is "End".
After highlighting execution, I saw that this case ends only after all the loops are ended, so there is no harm in directly putting End as the outgoing state without any conditions. I was afraid, that the outer loop executes all the times and in each cycle it would recheck the value and execute internal loop's next cycle. But in fact it's not the case. so I could boldly wire the End without any conditions.
I was afraid of loading the system with so many loops, but there is no other better way and I hope the user's system would support so many threads.
For now, I have avoided using PC in my program, because of comlexity in Queues closing. I am just going with the standard Event structure loops along with DataSocket's timed loops (because the Timed loop allows me to select a separate processor for that thread, apart from giving some rest of 200 ms to the system. I haven't connected any processor to that input node, since i donno abt the user's system, so it would automatically find the available processor. and I guess this is a benefit over the while loop with Wait function which would not select other processor, I guess.).
Any thing that raises eyebrows?
Message Edited by Vaibhav on 09-10-2009 04:18 PM
Vaibhav
