06-18-2015 08:10 AM
06-18-2015 08:12 AM
06-23-2015 01:46 AM
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
06-23-2015 03:04 AM
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
06-23-2015 10:46 AM
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
06-24-2015 06:40 PM
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
06-25-2015 10:54 AM
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
08-20-2015 01:38 AM
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.
Manually reserving the chassis in MAX usualy solves the problem, but I need a programatic solution.
Regards, Bogomir
08-20-2015 03:25 AM
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
08-20-2015 03:38 AM
Hi Henning,
thank you for the response. I'll try the "self-test" work-around.
Regards, Bogomir