"grey" wrote in message
news:50650000000500000096850000-1023576873000@exchange.ni.com...
> So I ask the experts here...what is a good way to ensure dataflow?
> Using the error in/out wont work for many VI's. I tied some case/loops
> together just passing useless data...it worked but that cant be a good
> way.
Why not to use sequences? One big reason, efficiency, and one little reason,
readability.
The sequence removes possible parallelism from your computation enforcing a
"join" once all work is completed before moving on. Rarely is the sequence
necessary, so performance will suffer. There is simply no reason to do A+B=C
followed by D+E=F because they are independant and LV likely could have
scheduled them more efficiently on its own! You're enforcing an artificial
dependancy with that sequence structure.
Also a big sequence results in lots of local variables, inputs, and outputs
being generated in different frames. It turns into an unreadable mess. It's
almost certain that you can wire a neater, more readable data-flow dependant
diagram.
What to do instead: an item on the block diagram will not start executing
until all its inputs are ready. All your diagrams should already be
conforming to the LV standards guides with error-in/error-out to handle
error conditions right? In that case the error flow will enforce ordering
because your VI will not execute until (or unless!) the preceeding VIs have
succeeded. If NI forgot the error terminals then create your own SubVI which
runs the functions only when there is no error condition; easy fix and
handles the error. Why take the measurement if there was a previous error?
More likely you want to do a different function.
As another poster suggested, some VIs come without error-in/error-out
terimals. However since mathematical, boolean, and string functions are
NEVER order dependant then who cares. When would you want sequences? When
there is a dependancy that cannot be detected by pure dataflow; when you're
using local variables, global variables, initializing property nodes, or
some physical systems. For example, "set the properties for all frontpanel
controls, THEN start executing".
In the specific case mentioned, do the digital I/O, wire along error
cluster, and then if the digital I/O succeeded the analog portion will
start. You can exploit some parallelism by allowing each to setup in
parallel, starting the digital-read if both setups succeeded, then starting
the analog-read, then executing the rest of the program. Right?
Good luck!
-joey
