02-17-2012 02:16 PM
I have PCI-6509 and PCI-DIO-96 digital i/o cards used on DAQmx 9.4 via the C API. Typically, I only need to write a single sample to various lines to control a test panel. Until now, it's been easy enough to create a task for each channel with each channel created addressing a single line. From there, I'd write a 1 or 0 to control the line. No problem. Okay, today I need to be able to change the state of several lines at the same time so I've created channels with multiple lines on them. There are some channels with 1 line, some with multiple lines but all on the same port, and some lines on multiple ports. My tasks and channels are created without errors and writing via DAQmxWriteDigitalU32 doesn't error. The problem is that the mapping of the lines to the bits in the write array is baffling to me. I opened up the VC_WriteDigPort example and made the following changes.
data = 0xFFC07FF8;
in DAQmxCreateDOChan -> "Dev1/port0/line0:2,Dev1/port1/line7,Dev1/Port5/line0:5"
First off, the panel is active low so everywhere data is a 1 is off and 0 is on. Irrelevant but I thought I'd explain the value. I'd expect the first 10 bits of data to represent the lines in the channel but that's not the case.
port0/line0:2 is controlled by bits 0-2 of data
port1/line7 is controlled by bit 15 of data
port5/line0:5 is controlled by bits 16-21
I then started to think that since each port/line combination is the same a line number ( port1/line7 is the same as line15 ) and that's why bits 3-14 weren't used. But, that doesn't explain 16-21 as they'd map to line 40-45 which exceeds our available bit count. Then I thought maybe if you use any line on a port then 8 bit blocks represent a port thus 0-7 would be port 0, 8-15 represent port 1, and 16-23 represent port 5. A plausible conclusion at this point so it must be tested. I then changed the program with the following:
data = 0xC07E7FF8;
in DAQmxCreateDOChan -> "Dev1/port0/line0:2,Dev1/port1/line7,Dev1/port2/line0:2,Dev1/Port5/line0:5"
The data value changes represent what's need to have the same state for the common lines ( port0, port1, and port5's lines from the previous text ).
Now,
port0/line0:2 is controlled by bits 0-2 of data
port1/line7 is controlled by bit 15 of data
port2/line0:2 is controlled by bits 16-18 of data
port5/line0:5 is controlled by bits 23-28
In this case, a byte doesn't represent a port as part of port 5's line bits encroach on port 2's byte ( bit 23 ). Okay, so a port per byte is out.
For giggles, I then added Dev1/port4/line6:7 which resulted in a -200566 error because I exceeded 32 bits. I was trying to control a mere 15 lines but due to the mapping scheme I used too many bits.
So how in the heck does the write array map to the lines specified for a channel? And, why does it not seem to matter the order of the text? ( if you swap port 1 with 0 in my examples the same bits represent the values so if you create your channel list on the fly you can't assume the write array will map to it even in that unknown order )
Thanks!
02-21-2012 01:40 PM
Hello,
Can you try writing to the channel using single channel --> single sample --> 1D array of boolean values instead of a hex value? You should be able to whatever lines you want using that method.