synchronize digital output and input

[Phil R]

I have an application that needs to continually monitor the state of 18 hardware LEDs . It uses a PCI-6071E. It does this by sending a bit pattern on digital lines 0-5 and reading the result on line 6. I used DAQmx to create an output task using lines 0-5 and a corresponding input task using line 6. I created a test application and this works fine if i just write one pattern and read the reply. If I put the write / read into a loop thru all the LEDS than at some point every one starts to return high, whether or not that is true. I'm guessing this is a timing issue, or maybe a buffer clearing issue, but I can't seem to get anywhere.
I checked through the message boards and can't seem to find anything relevant. Can someone point me to some sample code? Note that I don't have labview - I'm strictly C / C++. I'm also a software developer rather than an engineer so be gentle with me 🙂
Thanks

[Tom_W_[DE]]

Hi Phil- 

It sounds like you're running into some issues with programming for DIO on your board.  I'm not sure what would cause you to read all "high" values after a time, but you are probably correct that it is a timing issue.

Your E Series card does not feature correlated (i.e. hardware-timed) DIO like M Series cards do, so exact synchronization will not be possible.  The best method to make sure you are reading the ports in order is to combine programming as illustrated in the NI-DAQmx Examples in the "C:\Program Files\National Instruments\NI-DAQ\Examples\DAQmx ANSI C\Digital" directory of your hard drive.

If you look at the "Generate Values" and "Read Values" folders you will find "Write Dig Chan" and "Read Dig Chan" examples, respectively.  By combining the programming flows of these examples you should be able to achieve the results you describe.  The program flow should be as follows:

1. Create task 1 for digital output
2. Create task 2 for digital input
3. Create DO channel in task 1
4. Create DI channel in task 2
5. Start both tasks
6. In a loop, write to DO channel and then read from DI channel
7. After loop is broken, stop both tasks

Keep in mind that when creating channels that do not comprise complete ports you will need to specify the channel names as "Dev1/port0/lines0:5" and "Dev1/port0/line6" for the two tasks.

You should be able to see better results with this setup.  Please let us know if you need more suggestions.

I hope this helps-

[Phil R]

Tom,

Thanks for the reply. This is exactly what I have been doing, although I was using the newer DAQmx  classes - CNiDAQmxTask etc. I looked at the samples you mentioned and they all use the Ansi C calls. I went ahead and changed my app to use those calls instead and I get the same results. I'm about to update my NIDAQ drivers to 7.4 in case its that. Another point of interest - while my app is running and getting back incorrect values I can go into the test panels of MAX and use the digital IO panel to send and receive the correct data. From that i would seem to be the implementation of the DAQmx functions / classes that would seem to be in error - of course I don't know what the test panel uses - it may even be labview I guess.

Phil

[Chris_W1]

Both the C and C++ APIs are actively maintained in NI-DAQmx; C++ is not replacing C. NI-DAQmx provides APIs in LabVIEW, C, C++, and .NET that are identical in functionality; the choice between the APIs in entirely a matter of which programming language you feel most comfortable in.

One thing that is unique about the C++ API is that it requires Measurement Studio; the C API does not. Since you have been using the C++ API previously, you must already have Measurement Studio. If you are using other Measurement Studio components in your program (like the user interface, instrumentation, or Data Socket components), then the DAQmx C++ API will be much easier to integrate into your program than the C API will. Also, depending on which edition (e.g. Standard, Professional, Enterprise) of Measurement Studio you have, you may have support for DAQmx code generation using the C++ API from Visual Studio (DAQ Assistant)--you can compare Measurement Studio editions using this webpage. While LabWindows/CVI supports DAQmx C code generation, Visual Studio does not, so this may be another factor in your decision between the C++ and C APIs.

There are C++ versions of the examples you're looking at in the following location:
C:\Program Files\National Instruments\MeasurementStudioVS2003\VCNET\Examples\DAQmx\Digital

The documentation for the C++ DAQmx API, along with the documentation for Measurement Studio in general, is integrated into the Visual Studio help.

Good Luck,
-- Chris

[Tom_W_[DE]]

Hi Phil-

It sounds like you are actually running into a programming problem.  My reason for saying this is that if a task is running on the card you will not be able to monitor the lines in MAX test panels- an error will be thrown by the test panel that amounts to a "resource is reserved" error.  This is the text I got when running my application during an attempt to view the test panels:

---

Error -200587 occurred at Test Panel

Possible Reason(s):

Requested operation could not be performed, because the specified digital lines are either reserved or the device is not present in NI-DAQmx. It is possible that these lines are reserved by another task, the device is being used through the Traditional NI-DAQ interface, or the device is being reset.

If you are using these lines with another task, wait for the task to complete.  If you are using the device through the Traditional NI-DAQ interface, and you want to use it with NI-DAQmx, reset (initialize) the device using the Traditional NI-DAQ interface. If you are resetting the device, wait for the reset to finish.

Device:  Dev1

---

So it is beginning to sound like your application is terminating the DAQmx task earlier than expected for an unknown reason.  This also explains why the values would update for a while (during the task actually running) and then stop updating.  Please take another look at your code or post a small portion of it that is easy to understand and that illustrates the problem.

I hope this helps-

[Phil R]

Everyone - thanks for your input. It turns out that my problem was actually a hardware issue. I needed to send down a reset type command at certain points - something my hardware guy neglected to mention. I want to thank you guys for pointing to the sample code though, I hadn't been aware of its existance and its very useful, especially the newer stuff.