Stopping Parallel Loops...

[krwlz101]

Thanks for all the help.  I have it down to two loops now using the example vi provided by mtat.  I actually used a generate user event to trigger the screen update every interval, so I was able to move that into the event loop, rather than the DAQ loop.

One issue I am running into however, is that with the actual updating of settings taking place in the event loop, (rather than a state in a state machine) I am having a hard time triggering that event as part of an itialization.

On another note, is there any benefit to using the "New Value" terminal in the event loop as opposed to just wiring the a actual control?

[krwlz101]

Nevermind on the initialize part.  Was way over thinking it.

[krwlz101]

One additional question.

By moving many of the "processing" tasks right into the event structure, is it not possible that I will end up with a very laggy FP?  That was my motivation for adding a loop that dealt with the actual reading and writing tasks, leaving the event structure to just queue up tasks, which obviously occurs quickly.

That said, looking at the tasks I am actually completely, nothing seems terribly lengthy, so it is probably fine in the event structure?

[johnsold]

You are right that you should not put any code in an event structure which takes much time to execute.  I usually use a few tens of milliseconds as the maximum.  Actually I usually do not put anything but an enqueue function in most event cases.

Lynn

[krwlz101]

I suppose that in this case, it really ends up being a matter of style.  I think that I will revert to queueing up tasks in the event structure.  It just seems like if I make this standard practice, that I should avoid certain issues.

That said, is there any reason to avoid extra loops?  Outside of actual code clarity?

[johnsold]

I am not sure what you mean by "extra loops." Many fairly complicated programs can be written in a two loop architecture like the Producer/Consumer or Master/Slave.  Sometimes additional loops performing a specific task (such as DAQ or communications) make sense.  Add loops if there is a good reason why the task cannot be performed in the existing loop(s). Clarity certainly could be a factor in the decision, but probably not the only one.

Lynn