I'm using an NI 9401 for digital i/o as part of a cDAQ-9178. I have a normally-closed relay attached to one of the lines, so I need to constantly send it a signal to keep it open. I also have several other devices attached to this same card, and I'm running the whole system using Labview 2015.
When I start my program, I use DAQmx Write to send a True to that channel, and the relay turns on and stays on. However, as soon as I run DAQmx Read on another channel on that same 9401, the relay turns off. There is only one input channel on that card, and the rest are all outputs or unused.
Does anyone know what might be causing it, or is there some way of preventing it?
Normally I would put this on a relay card but I am all out of slots in the chassis and the other relay cards.
Has this program worked before? Are you sure you have all the connection wired correctly? How complex is your program? Can you attach your VI so others can take a look at it as long as it's not a complex one?
Everything is wired correctly. If I just run a VI whose sole purpose is to set that DIO channel to True, then the relay turns on and stays on. I stepped through my code and isolated the problem to the DAQmx Read call. The relay stays on until I call DAQmx Read, and then it turns off. I'm just mystified as to why that would happen.
The program is very complex so I can't really show it all. As of right now I have a temporary fix where I just send DAQmx Write True to the channel for the relay right after the Read call, but I'm not satisfied with that as I'm worried it's power cycling the relay, althoughthe device attached to the relay seems to be working fine.
Can you at least show how you have your DAQmx task programmed from open to close function? When you say you have a read and write in the same task do you have a producer/consumer loop set up?
This is the sub VI in question. The main VI operates as a Queued Message Handler with various state controls to handle various message queues.
You will need to create two tasks to do this. Although, the DAQmx API can perform channel expansion it allows one DAQmx task to simultaneously allow read or write. Even though this is one device you will need to perform two tasks so you can perform a read AND a write simultaneously. Please take a look at the forum below:
Also, here is a knowledgebase on channel expansion:
I suspect that it's a side effect of making a single DAQmx function call with a global channel. Some extra stuff is being done implicitly behind the scenes to configure and start your digital tasks.
I propose you make this explicit and control it. In the message case where you do initializations, chain together a call to DAQmx Create Task and DAQmx Start Task for both your input and output tasks. Store the 'task out' refnum outputs locally. Then in the message case where you do your read and write, wire in these task refnums as inputs to DAQmx Read and DAQmx Write. (You'll also want to call DAQmx Clear on these tasks in the message case that does your cleanup before exiting the message loop.)
By taking explicit control over the tasks, I'll venture that the Read will no longer have an effect on your digital outputs.
Is the input on a separate nibble from the output lines? From the NI 9401 Getting Started Guide:
The DIO channels are grouped in two ports, one containing channels 0, 1, 2, and 3, and one containing channels 4, 5, 6, and 7. You can independently configure each digital port in software for input or output. Note that all four channels in the port must share the same line direction.
So, if your input line and any of your output lines are configured on the same port, the direction of that port is being reconfigured each time you run the read task and the write task.
With the 9401, we also need to consider line reservations, if there are ever multiple tasks running simultaneously on the device. That doesn't appear to be the case, based on your screenshot -- just mentioning as a note.
Without being able to see how the tasks are configured, we're missing a lot of information. A key takeaway from Kevin's comments is that the tasks need to be cleared when acquisition or output is complete. I'd be surprised if your error out indicator didn't show at least a warning after you stop your loop, since you repeatedly apply a new task to hardware that is already reserved by an existing task.
Thanks for your reply. That was the problem -- we had mixed inputs and outputs in each of the nibbles. We re-wired and this solved the problem.