So here is a rundown of what is happening:
All the action is in frame 2 of the large stacked sequence.
There are 5 parallel while loops
Starting from top to bottom:
The
first loop captures user input onto the GUI, mostly, changes to
hardware configuration that occur only during thstartup phase of the
software, or ar irregular, non-critical times throughout. I am not
worried about the impact here, because while I am trying to drive my
system at high speeds, this loop is basically hitting the time out even
over and over. It is possible fo the user to change a control that
would fire an event (events 5, 6, 7, and 9) in this loop that would
impact the lower loops. In these events, the use is requesting a
change in at least one of the eight members of a boolean array to be
written to the NI9472. This generates a notifier, which brings us to
the second loop.
The second loop waits for notification
that something needs to change in the output array, and then sends the
new array to the 9472 (!Valveit!_MC.vi). With the exception of
initialization (in frame 2) and shutdown (in frame 4), this is the only
place that I actually send signals to the 9472.
The third
and fourth loop have the same function (as each other). When
triggered, (P1on = T for loop 3, or P2on = T for loop 4), the loop
advances through a pattern of values for three of the elements of the
control array. Each step is timed using the Labview's "wait"
function. Each change generates a notifier, which triggeres action in
loop 2. These are separated into distinct loops so that the two sets
of three valves can actuate as independent units.
The
final loop is camera control. This loop is truely parallel, which no
communication with the other loops. This loop controls a firewire
camera (previously initialized). It allows for live imaging
("CLive"=T", images captured and displayed on the front panel, but not
stored in memory) or for the recording of images to disk (direct
streaming to hard disk as a binary). In the live mode the loop
continuously uses "GetSingleRBGIMage_2_CCpAP.vi" to acquire an image
from the camera which is then displayed on the front panel.
In
the live mode, there is jitter in the display on the front panel, but
there does not appear to be jitter in the actual actuation of the
valves. In the data streaming mode, there is some jitter in both. In
the recording mode, the same sub-vi ("GetSingleRBGIMage_2_CCpAP.vi") is
again used to snap a sinlge image, but rahter than outputing the image,
it outputs three structures (one for each color channel of the image)
which consist of a 1D array of pixel values, and an average value over
a region of interest. Each 1D array is streamed to a binary on hard
disk.
Since my initial post, I modified the
'!ValveIt!_MC.vi' to output a tick count every time it executes, and
see that it is executing at the correct rate, except for at either the
start or finish of an image capture (probably the finish). (Remeber,
theoutput to the 9472 is changing many times during a single image
acquisition). And at that point, there is one cycle that takes longer
than it shouldfollowed by a cycle that is much shorter than it should
be. So it catches up.
Hope that clears it up, and allows you to make any suggestions you think would be helpful.
M
