200587 Conflicts

[krenik22]

Just a heads up I am a labview Novice

I am working with a legacy 6024e PCI DAQ. We are currently using it to activate a motor (digitial I/O) and control a magnetic particle brake (analog out), and read a torque meter (analog in).

We are running all this hardware communication in parallel loops and using closed feedback to run a dynometer program. I have made a small protoboard that is going to utilize free digital I/O ports on the DAQ to control voltages going to our device under test.

So obviously my first instinct was to the the easy-to-use DAQ assistant, which of course didn't exists +15 years ago when the orginal hardware interface software was made. I used the DAQ assistant and get a conflict error with 200587...

I look at the older code and I have no idea how to determine "Task IDS, groups, ETC" control and choose physical I/O's from the DAQ. The task ID's are very confusing because I don't know how they are generated, but I can only assume each I/O on the DAQ board has a specific ID? It appears I need to use "Digital single write" but the definition/creation of the inputs for it have me at a loss. I try to follow the current code that controls the present hardware but I have no idea where these addresses come from. It's like these task ID's are generated automatically and I have no idea how to determine how the code knows what specific channels to operate on the DAQ board.

Any help? I'm sure there are lots of posts or tutorials for this, but I am getting very frustrated. 

Attached is current DAQ channel setup for the present hardware.  

Mainly I would like to have definitions of the digital output control using this method.

[Mcdan]

kernik22,

If you are running code in Traditional DAQ, then DAQmx you do need to call a Traditional DAQ Device Reset before the device will be accessible in DAQmx (read the device can be used in Traditional DAQ or DAQmx, but not both at the same time).

In general, the task in DAQmx represents a collection of channels (I/O) with common timing and triggering attributes.  I think Traditional DAQ is similar in this respect.  The taskID that the driver returns just simply lets the driver know which group of channels and timing info to act upon.  In your Traditional DAQ example, the taskID would represent the channels represented by your 'ChannelList' for the top task.  Again, I suspect that the root cause of the error you are seeing is that you are trying to use both DAQmx and Traditional DAQ at the same time, and that it's not a 'per-task' resource conflict.

Hope that helps,

Dan

[krenik22]

I read about this method but I think it could possibly cause issues as I am reading/writing legacy DAQ commands, completely killing/resetting legacy, starting the Current DAQ comm, resetting/killing, etc (starting all over).

The timing interval that I read/write via traditional and legacy will not always be in a specific sequence.  The communication for each hardware I/O are all running in parallel while loops.  So if I shutdown legacy comm when i need to write via traditional won't my legacy comm loops error-out because they are shutdown?

I just wanted to clarify that, maybe my assumption that the reset method won't work is incorrect?

[Mcdan]

Yes, calling Traditional DAQ device reset would cause all subsequent operations to fail.  If you need these to be on-going, then you'll want to use Traditional DAQ  to program the unused ports you are going to use for your proto board.

The root issue here is that there is no mechanism by which Traditional DAQ and DAQmx can communicate about which specific resources either driver is using.  Because of this, we all only one driver to access the device at a time.  If Traditional DAQ is accessing a device, it will take ownership of that device until a Traditional DAQ device reset is issued.  Until this happens, all attempts to access this device by DAQmx should result in the -200587 error you were seeing.

Hope that helps,
Dan

[krenik22]

I agree, I need to use the legacy DAQ comm. 

The only problem is I am getting stuck on how to assign the digital ports (via Task ID's?, etc).  That's where I'm at.  The attached code on the original message shows how they currently set-up the channels (analog/digital).   I can't determine any rhyme or reason about how you select the specific channels/ports of the DAQ using these VI blocks.  Bottom line I need to determine the command blocks necessary to send high/low commands to 3 digital output terminals.  Right now I still don't know. 

[Mcdan]

Unfortunately I do not currently have a system with Traditional DAQ installed.  However, there should be some examples which get installed with Traditional DAQ which might be able to get you headed in the right direction.  If memory serves me right, they can be found in the 'Program Files/National Instruments/LabVIEW Version/examples/daq directory.  They should be categorized by function (ie analog_io, digital, etc).  I believe there are some simple Digital Read and Digital Write examples which you can build on.

Hope that helps,

Dan

[Kevin_Price]

I don't have a traditional NI-DAQ setup at hand either, but one thing I recall about DIO is that you need

to know whether your daq board has separate ports for input and output so you know which lines

are available for software control.  Some (many?) boards would allow you to mix input and output within

a given port, but then you would need to define a bit pattern at task config time to specify which lines are

which.  Later, when doing the write, you might need to use a "line mask" to help prevent an inadvertant

attempt to write to an input line.

Sorry I don't recall all the specifics -- it's been quite a few years since I did DIO with traditional NI-DAQ.

-Kevin P