Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

cDAQ: automatic module detection

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

0 Kudos
Message 11 of 16
(3,156 Views)

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

 

0 Kudos
Message 12 of 16
(3,124 Views)

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)

 

 

0 Kudos
Message 13 of 16
(3,091 Views)
Hi Martin, thanks for the code snippet. Unfortunately, this is the code which I tested before which should work IMO but does not. The problem is: If the module is not detected as present in the chassis (in NI MAX, it looks like Bogomir's screenshot), the DAQmx task "Device" node will return the error "-201003" and will return an empty array. It only returns the actual device, if the module was already properly detected. In this case, I don't need to reserve it (in my specific case, the reservation is done only once (manually) and usually never changes). Hope it gets clearer now. Best regards, Henning
0 Kudos
Message 14 of 16
(3,085 Views)

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

0 Kudos
Message 15 of 16
(785 Views)

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.

0 Kudos
Message 16 of 16
(773 Views)