Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

cDAQ: automatic module detection

Hi, I am using a cDAQ 9188 chassis with 4 modules (2x NI 9401, 1x NI 9263, 1x NI 9225). I searched for them in MAX and did a selftest of the cDAQ. Afterwards, all 4 modules are listed. I then created DAQmx tasks and can finally use this tasks inside my LV project. So far, so good. I can even restart my cDAQ and still use the tasks. However, if I restart my computer, only the cDAQ is automatically redetected, but the 4 modules are not (4 white/red X inside MAX). If I start my LV project and run it using the DAQmx tasks, I will get the "Error -201003" which tells me, that the device cannot be accessed. I've found 2 work-arounds which are both not very pleasing and I am wondering if I am doing something wrong. 1.) Open MAX after restart of the computer and perform a manual selftest of the cDAQ chassis 9188. It then "re-detects" the 4 modules and everything is fine. This is of course not satisfying as it is manual. 2.) Run the selftest programmatically inside my project and then wait for a arbitrary time period of let's say 5 seconds as the self test VI returns immediately and does not wait until the selftests are finished. This is also only partly satisfying due to the arbitrary delay. So, my question: Is there a better way to do this?? Optimally, LV should auto-detect all 4 modules inside my cDAQ after reboot. Best regards, Henning
0 Kudos
Message 1 of 16
(7,341 Views)
Mmh, I don't know why all my formatting got lost after pressing the "Post" button. I am sorry for this. I hope it is still readable.
0 Kudos
Message 2 of 16
(7,339 Views)

HI Henning,

 

thank you for your inquiry. In order to help you out, could you please provide some more informaiton for me?

 

- What operating system do you use?

- Which version of the  DAQmx-diver is installed?

- Which Firmware is you cDAQ 9188 on?

- Has this behavior always been this way?

- How do you connect the chassis to your Computer?

 

Kind regards

 

Martin

0 Kudos
Message 3 of 16
(7,284 Views)

Hi Martin,

 

thanks for your reply.

 

- What operating system do you use?

Windows 7 professional, 64-bit, SP1

 

- Which version of the  DAQmx-diver is installed?

NI-DAQmx 14.2.0

In this case/project, however, I am using LV2012 not 2014.

 

- Which Firmware is you cDAQ 9188 on?

 1.1.0f0

 

- Has this behavior always been this way?

It's a new cDAQ chassis and I didn't notice any other behavior before.

 

- How do you connect the chassis to your Computer?

LAN via Switch

The chassis is automatically detected. However, not the modules (after reboot of the computer that is).

 

Best,

Henning

 

0 Kudos
Message 4 of 16
(7,275 Views)

Hi Henning,

 

thank you for providing the information. There are several starting points for fixing your issue.

At first, please update your Firmware to the latest edition, you can find it uder the link below:

 

NI cDAQ-9188 Firmware 1.5.1 - National Instruments
http://www.ni.com/download/ni-cdaq-9188-firmware-1.5.1/4302/en/

 

If this does not fix your issue, we should take a look at your connection. E. g. does your switch provide a DHCP-server? Are there any firewalls configured on your computer?

 

Regards

 

Martin

National Instruments

0 Kudos
Message 5 of 16
(7,263 Views)

Hi Martin,

 

the firmware update unfortunately did not help. Still, only the cDAQ is detected automatically and not the modules.

 

However, I must admit that I doubt that LAN/Firewall settings are the problem as the cDAQ is detected via LAN and I can access the cDAQ selftest even programmatically. Only the modules cannot be accessed without cDAQ self-test and there is no LAN connection between modules and cDAQ.

 

I will try it on another computer to see if it is computer dependent. Any other ideas?

 

Regards,

Henning

0 Kudos
Message 6 of 16
(7,249 Views)

Hi Henning,

 

that is a great idea in order to minimize the influence of the usage environment. I agree with you that it does not seem logical that the connection might be the issue since a communication between the device and your computer seems to be working. I have had cases though where the simple communication of finding the device in MAX worked out but more complex communication failed to work. Please let me know, if trying a different Computer shows the same behavior. If it doesn't, in rare occasions the NI-MAX database might become corrupted. You can reset it by following this guide, but be aware that all your settings regarding the NI MAX will be erased, so you could consider it ultima ratio.

 

What is the Process For Resetting the MAX Database? - National Instruments
http://digital.ni.com/public.nsf/allkb/2C7480E856987FFF862573AE005AB0D9

 

Best,

 

Martin

0 Kudos
Message 7 of 16
(7,236 Views)

Hi Henning,

 

Did you solve the problem?

 

I'm observing the same behaviour. I've got a cDAQ-9188 chassis with 6 modules. Sometimes when the computer is powered up, the LabVIEW application reports error -201003. If I open the MAX I see thet the chassis is detected, but the modules have red cross.

 

cDAQ-9188 Error 201003.jpg

Manually reserving the chassis in MAX usualy solves the problem, but I need a programatic solution.

 

Regards, Bogomir

0 Kudos
Message 8 of 16
(7,029 Views)

Hi Bogomir,

 

yes, this is exactly the same error. Sometimes, the modules are detected and sometimes not (even if they were properly reserved). Some of my colleagues told me about similar behavior (at least when using cDAQ chassis with ethernet connection, not USB).

Unfortunately, I did not satisfyingly solve the problem, even though I tested it on a completely new hardware with the newest LabVIEW version, it still happened. So, if Martin still reads this: could you please further investigate the issue?

 

Regarding your question, Bogomir: There is a programmatical solution which might be okay for you. You can call the "self-test" VI from the DAQmx palette with the chassis as device input ("cDAQ9188-19C5F18"). It has some drawbacks, however: The VI will not wait until the self-test is completed (even though this would be much better in my opinion). So, you either have to wait some arbitrary time or after the self-test has started you have continuously poll your modules/tasks until the error is "gone".

 

I use this work-around, but I don't like it very much. The main reason is (apart from the arbitrary delay) that you have to know the cDAQ chassis to do this. My program only knows about the DAQmx task and actually doesn't care about the underlying hardware. So, there is no proper hardware abstraction.

 

Best regards,

Henning

 

0 Kudos
Message 9 of 16
(7,012 Views)

Hi Henning,

 

thank you for the response. I'll try the "self-test" work-around.

 

Regards, Bogomir

0 Kudos
Message 10 of 16
(7,004 Views)