Conflict between PCI-6024E and PCI-6221

[PetraB]

Hi all,

I have a problem which might originate from a conflict between PCI-6024E and PCI-6221. I have developed an application on a computer using PCI-6024E and DAQmx 7.5. LV 7.1. The application works fine on this computer both in developer mode and as a stand alone application. When i install the application on another computer using PCI-6221 I repeatedly get Error 50103 at DAQmx Control Task.vi. As I have understood this error occurs when two tasks are trying to read to or from the DAQ-card at the same time. This is taken care of in the application by checking if the DAQ is available before reading or writing. Is there any incompatiblity between the two versions of DAQ-card that could cause this problem?

Thanks

Petra (Uppsala, Sweden)

[devchander]

Hi,

Does MAX recognise these devices after you put this PCI 6024 card in system with PCI 6221 ?

Are they passing self test on MAX??

[Jimmie_A.]

Hello!

Just to verify that I understood everything correctly:

You have developed an application with DAQmx 7.5 and LV 7.1 and in the past you have used a 6024 data acquisition board. Now you want to use the very same application together with a 6221 data acquisition board instead in another computer so I assume you have a built application (read executable). Is that correct? In other words you don’t have the data acquisition boards in the same computer.

If this is the case and the 6221 passes all tests in Measurement & Explorer and that you can run the test panels without any issues indicates that the board and driver is installed correctly which is good.

You haven’t hard-coded any device names and such?

Also look at this KB:

Causes of NI-DAQmx Error 50103 "The Specified Resource is Reserved"

http://digital.ni.com/public.nsf/websearch/04BEDD9E9E91ED3486256D180048116D?OpenDocument

[sirnell]

Hi!

Yes Jimmie, you understood it correctly! The DAQ-cards are in different computers and we are using a built application. The device names are read from an .ini file and used in the start of the program for creating and verifying the DAQ-task - so I dont believe that is a problem.

We have seen the KB document you refer to and deemed it not relevant to our application. We use a reserve/unreserve scheme to check DAQ-card availability before attempting to take any samples (done in every interation). This scheme workes well using the old DAQ-card, and has been in use for several months. Could this work differently with the new card? (we were told by NI at the time of purchase that the new card should work the same)

Do we for some reason need to recompile the application on a computer with the new hardware?

The first computer has LabVIEW Development system installed (this is were we built the application). It is the built application we have been running there too though. But could having it installed make the application behave differently?

/Michael, Uppsala, Sweden

I worked on the application and the first setup earlier and I am trying to help Petra out now with the new setup.

[Jimmie_A.]

Hello!

You mentioned that you use ini-files in order to verify the devices and such. So you have verified that the device names are correct in other words that the M-Series DAQCard has the same name as the E-Series DAQCard? Programming an M-series compared to E-series should pretty much the same just minor things to consider when it comes to internal clocks and when synchronizing. What would happen if you tested the M-series board on your development machine? Would the same issue occur? What happen if you reset the device before creating the task? Please let me know how things proceed!

[sirnell]

Hi again!

Holidays and other projects has delayed my answers to your questions.

• Yes, we have verified that the devicenames and channels are correct.
• We have performed a daqtest on the M-series board using: http://digital.ni.com/softlib.nsf/websearch/FEA4D55E1B3DA33A86257076006AA260?opendocument&node=13206...
  The new board passed all tests. It was reset and calibrated during the test as well. Still does not work the way we want/expect.
• We hope to, in the new computer, try replacing the new card with the old one this week. We figured that would cause less compatibility issues with drivers and software than the other way around. Should we be able to have both cards on the same machine simultaneously without conflict? (given that the devicenames in the application point to the correct card)

Regards, Michael

[Jimmie_A.]

Hello!

I am unsure what might go wrong here, I am afraid. You can have both boards installed in the same machine without any issues (that is if you have enough resources like DMA, IRQ and such).

[sirnell]

Thanks for your answer!

Petra has now tried switching the daq-hardware between the setups with the following result:

• E-series card, new computer (labview runtime only): does not work. same problem as with M-series on this computer.
• M-series card, old computer (labview development system installed, but running the .exe application): works fine!

New questions:

• does having development system installed change the way applications are run? does it change daq in any way?
• could it be a daq-driver issue? how do we get that confirmed? where can we see what drivers are installed on each machine (we believe we are using the daq-drivers v7.5 on both)?

(By the way, to be safe, we have not tried having both cards on the same machine at the same time.)

Regards, Michael

[Jimmie_A.]

Hello!

1) No change in the way NI-DAQ executes.

2) You can find driver versions in MAX under Software.

[Jimmie_A.]

Hello!

I believe that you have talked to our FSE/DSM as well and he told me more about your application. I would recommend you to do all analog in operations within the same task that is if you have the same timing parameters (sample rate). If not you cannot perform the tasks simultaneously and you have to make sure that the resources in this case the ai subsystem is free. Another benefit if you do everything in one task is that the code will be cleaner and not that big compared to having three similar code snippets in the program you most likely have now.