Data Acquisition Idea Exchange

When a cDAQ (I'm using both a 9184 and 9188) chassis is energized (or the host computer is rebooted) it is programmatically read as reserved (by either MAX or LAbVIEW program). To gain control of the chassis, one has to either use MAX (MAX deosn't save or remember the previous reservation) and reserve it or programmatically force the reservation in the LabView code. In addition, if a chassis is reserved by a different host, another host can force the reservation by itself programmatically. Both of these can be accomplished by using the reserve chassis function with the 'Override Reservation' input set to True. This really is not a good method - it's effectively a hostile-takeover of the hardware (I've tried this and I can literally reserve hardware that is actively being used by another host).

I would recommend the following firmware/driver/software updates/corrections:

1. When a chassis is power-up it should be in an ‘unassigned’ state. Basically it will be in 'standing-by' waiting for a job/task.
2. When a host interrogates the chassis it should only be able to ‘reserve’ it if it is in the ‘unassigned’ state. Once the chassis is reserved by a host it is locked to it until it is either unreserved by the host or power is cycled to the chassis and it reboots, returning it to the unassigned state.
3. When interrogated, a ‘reserved’ chassis should provide the identification of what host has reserved it. This would allow redundant or multi-host configurations to find each other and do things like handing-over a chassis between hosts. This is useful if a host error is detected (redundant host system) or a host needs to be taken offline for service and the process can’t tolerate extended interruption (and it's useful to do this programmatically).
4. The chassis firmware and functions in DAQmx should be updated or augmented consistently to support 1,2, and 3.
5. There should be example code showing how to implement these features

It would be nice to have the ability to spawn a “Child” Task based upon a “Parent” Task local virtual channels. Today, this can be accomplished with global virtual channels, but not easily with local virtual channels within the Task. Today, we dynamically generate Tasks based upon the physical channels and save it to an external file.  There are many variations of this, but all require a decent amount of programming for complete automation. The external calibration interface in MAX has greatly improved over the years and now it is easy to calibrate multiple sensors at the same time. Not only that, but it is nice to have device setup and calibration information in one location.

Currently we are using LabWindows/CVI with a 96 bit DIO card (PXI-6509).

What we have found and NI support confirmed is that with the following the software needs to be aware of the bit offset during a write to one or more lines on a port.

Virtual Channel                    Physical Channel

dataEnable                          dev1/port0/line 2

Our assumption was that writing to 'dataEnable' a value of 1 using DAQmxWriteDigitalU8() would write to the virtual channel 'dataEnable'.  What we found is that is not the case.  We need to write a value of 0x04.  But that the bits that are set to zero in this value written to 'dataEnable' have no affect on other lines on the port that are already set.  This gives us the impression that the driver has knowledge of what bit position we are trying to write too.

So based on this why is it not possible that when I call from LabWindows/CVI to do a write to a virtual channel I cannot just do something like this:

Virtual Channel                    Physical Channel

dataEnable_Clk                   dev1/port0/line2:3

Line 2 = dataEnable

Line 3 = dataClk

write( dataEnable_Clk, 1)               // to set enable line high

write( dataEnable_Clk, 3)               // to keep enable line high and raise clk line

write( dataEnable_Clk, 1)               // keep enable line high and lower clk line

write( dataEnable_Clk, 0)               // lower enable line

** assumption is that seperate lines on another port are used to present the data to the external hardware and are not shown here.  The data would have bee setup before the sequence above and then change data and repeat sequence as needed.

Here I don't have to keep in mind that Enable is on line 2 and Clk is on line 3 or have to setup values of 0x04 for hte Enable and 0x08 for the Clk.  If I have to do this I would rather have direct access to each port to just write the values directly.  i know there is the register level I can use but doing this at a higher level is better.

In our code when a internal function is called to write data we would like to just write a value out to the virtual channel and not have to figure out the bit alignment to shift over the value to use one of the current functions.

Let me know your thoughts.

Bob Delsescaux