LabVIEW
While loop delay
Padmavathi.B wrote:
I have purposefully placed two buttons in single event i.e start, stop.I have clearly ensured that the delay is not with these two buttons in the event structure.
I agree with Ray that you should probably do a few tutorials and learn about dataflow. This code is a mess.
- Why would you read the table control via value properties and have the terminal disconnected sitting around. Just wire from the table control and eliminate the value properties.
- That small sequence frame in the middle has no purpose at all. Dataflow already ensures the same execution order.
- Your use stacks and stacks of while loops with mind boggling boolean logic. All you probably need is a single outer while loop and a state-machine design. Keep it simple!
- You could convert the three element array to number with a single primitive and index later. Less code!
- You read the table elements outside the loop, but the size of it inside the loop. If the operator changes things during run, you get inconsistent behavior.
- If the table can change during the run, the terminal belongs in the innermost loop.
- Can you explain the purpose of the "error-in" control???
- Setting controls programmatically should be done via local variables. Value properties are orders of magnitude less efficient.
- And NO, as Ray said, you don't want an event for the stop, because you are polling it inside anyway. The only thing your stop event does, if firing another event executing the empty case for nothing.
Sorry, I don't understand. What application? Why Air conditioning?
Padmavathi.B wrote:
But i have written the code a/c to my application
Your query.vi is of no help to us, because we cannot run it without your DAQ hardware setup. All we can do is inspect the code to see if there are any weird constructs, and the start/stop event is one of them. If you don't understand our arguments with this issue, you should really start out with some simpler problems than an advanced DAQ application.
Code can only be debugged efficiently if it is programmed with some logic and reason. Your three stacked loops don't really lend themselves to be debugged by just looking at them.
So... do you only get a delay between the first and second row or between all rows, all the time? Apparently you already made up your mind blaming the "clear task" function. Can you enlighten us what made you come to that conclusion?
As I pointed out in my list above, the start/stop event issue is really only the tip of the iceberg.
You should also describe the problem a bit better. You haven't even really told us what kind of "delay" you are experiencing. Is is a few milliseconds or a couple of weeks? What kind of dealy would be acceptable?
JoeLabView wrote:
Padmavathi.B wrote:
Start and Stop buttons in a single event structure will run with out any problem.
Glad to read that... surprised... (no... astonished)
Of course it will run fine on the surface, but it is simply running the event once more with an empty case whenever stop is pressed. The stop button is polled inside the innermost loop, so pressing stop will do two things.
- Cause the inner loops to terminate (without the need of any events!)
- Cause the queing up of the stop event in the event structure.
- Once all loops have stopped and the current (start) event can finally finish, the stop event will fire, running the same event once more, but now with the code of the empty case.
What happens in (3) is completely unecessary, and if you would just remove the stop trigger from the event case, you could also remove the case structure, because it is no longer needed. Only (1) is useful coding! The example displays a fundamental misunderstanding of the event structure.
What we have here is a NOOP that qualifies as pure Rube Goldberg code.
The code is so full of weed that ist is difficult to tell the necessary stuff from all the fluff, making debugging (such as solving your problem) nearly impossible.
