08-21-2015 02:36 AM
Hi Henning,
Hi Bogomir,
I've looked into this issue and found a possibility to solve it. As you already mentioned, reserving the device programmatically should solve issues of addressing the modules. ou can find an example here:
Community: Reserve an Ethernet Chassis Programmatically - National Instruments
https://decibel.ni.com/content/docs/DOC-37398
If your VI does not know about the specific cDAQ-device there is a way to address it using the system configuration palette. This is a modified example based on the given link and the 'Show All Hardware.vi' example from the LabVIEW example library. Of course your program still needs at least some indication for your hardware in order to narrow down the selection.
Cheers
Martin
08-24-2015 03:27 AM
Hi Martin,
thank you for the link. Reserving the chassis programmatically (even though it is already reserved) is at least a step in the right direction, as this VI unlike the self-test VI stops execution until chassis reservation and module detection has finished. So, the arbirtrary delay is "gone" which helps me and simplifies code. Overall, this work-around is okay for me.
From a hardware abstraction layer point of view, though, it is still not too satisfying. Before running DAQmx tasks, I now have to always reserve and self-test the chassis referenced by its _name_ (or IP or whatever). So, I have to know which cDAQ chassis exactly is associated with the respective DAQmx tasks. So, if I changed the DAQmx tasks inside NI MAX, I'd also have to make changes inside the code.
(and I still do not fully understand why sometimes the modules are detected after restart and sometimes not, even though in both cases the chassis is still reserved).
Best,
Henning
08-26-2015 06:36 AM
If I understand you correctly, the hardware device is being selected in the task which is configured using NI MAX. In this case, assuming only one device is involved, you can enhance the block diagram as shown in the attached snippet. (you can directly drop it on your block diagram)
08-26-2015 07:38 AM
12-06-2021 11:29 PM
did anynew solution about C-DAQ needs to be detected again in NI -MAX after reboot PC, or data acquising , i met the same error and could not find a solution
12-09-2021 10:15 AM
To re-establish connection with an Ethernet cDAQ chassis after a host PC reboot, polls until a self test on the cDAQ chassis succeeds (that will trigger a reconnection) and then polls until self-test of the cDAQ module you are using succeeds. That is how I do in my startup application on NI Linux RT, which starts to run before the network is even up. But basically performing driver operation on the cDAQ chassis like self-test or device reset will trigger a reconnection from the host to the Ethernet cDAQ. After it reconnects successfully, the chassis will enumerate all the modules plugged into it.