If you are sophisticated and adventurous enough to use Producer-Consumer, you are ready to use "real DAQmx" explained here in excellent White Paper and to banish Dynamic Data.
Producer should consist of DAQ acquisition of data. Consumer should "consume" the data. This includes writing data to disk and potentially other things.
Where should you be controlling the valves, making decisions based on the data? Probably as part of the Consumer (unless you need really tight timing requirements, in which case you may want to make some decisions in the Producer). Especially if the decisions involve multiple data points, the Consumer seems the better place.
Within the Consumer, you can do several things in parallel, such as logging, computing slopes, triggering valves, etc. Think about the logic of what you want to happen, and the conditions that would lead you to do something or not.
Strive to keep your wires running straight and parallel. If a function has an Error terminal, you should put it on the Error line (and use that as part of the sequencing process). Consider "hiding" some of the messier features (like fitting lines and determining slopes) to sub-VIs, which will allow you to dramatically shrink the size of your Block Diagram (all diagrams should fit on a single modest-sized screen).
Note that if the Producer is always "producing", the Consumer doesn't necessarily have to Consume -- it could "Discard", instead, if the "Consume" button is not pressed ...
Bob Schor
