LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmx reset.vi and NI-9205

in a compact daq   CDAQ 9178, the following modules are inserted in the following order

NI 9205 (DSUB), NI 9264, NI 9482, NI 9482, NI 9482

 

I usually try to identify the boards by using daq max commands as attached in the vi

The issue here is :

If the DAQmx reset.vi is used, the 9205 module is not indentified

Is there is a reason for that?

I have been using this setup for a long time with Daq boards, and never had the issue.

Dr_Imad_0-1667595674197.png

Dr_Imad_1-1667595932277.png

Dr_Imad_2-1667596027315.png

 

 

 

 

0 Kudos
Message 1 of 6
(1,333 Views)

It is because you have an error as highlighted at the bottom.

santo_13_0-1667596316155.png

Note: DAQmx Reset.vi is a non-blocking call (means, it does not wait for the reset process to complete but just initiates a reset and returns), it takes a few minutes for the DAQmx device to complete reset and boot properly, if you query before the device boots up, you will get an error.

 

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
Message 2 of 6
(1,332 Views)

the issue here it never happens with boards (like PCI/e cards, that I used in the past) also with the other modules in the sane CDAQ.  Why specific to the 9205 ?

0 Kudos
Message 3 of 6
(1,320 Views)

@Dr._Imad wrote:

the issue here it never happens with boards (like PCI/e cards, that I used in the past) also with the other modules in the sane CDAQ.  Why specific to the 9205 ?


A number of potential reasons.

 

1) A PCI(e) card is located in the PC, Sending commands to it is usually equivalent to writing one or a few values into some register. With the hardware inside the PC, this is literally a move over the internal data bus that takes the CPI a fraction of a microsecond to do. For a cDAQ everything has to go through the network. DAQmx has to build a data package, send it to the device, the device decodes it, executes it and then sends back another package over the network to acknowledge the command with a pass or fail status and any other information it may have. This involves at least one bidirectional network transfer, sometimes more and that can easily take up many milliseconds for each single command.

 

2) Those C modules all have some internal hardware that needs to be (re)initialized. A Reset means basically forget everything I ever told you to configure your channels and go back to a defined default state. This can involve autocalibration routines that will be performed and that will generally require some time to execute as the settling times of the signals need to be fully observed. For calibration purposes you do not want to use almost correct values due to not fully observed settling times, but the values need to be as accurate as possible. Slower acquisition usually gives more accurate measurements, so a calibration routine can take up some serious time to perform. Some modules will therefore need some time after a Reset before they are in a state that they can answer other requests.

 

LabVIEW has to say this about the error you show in your example:

 

Error -88705 occurred at ..........

Possible reason(s):

The specified device is not present or is not active in the system. The device may not be installed on this system, may have been unplugged, or may not be installed correctly.

 

This would pretty much match with point 2) above and together with the additional network delay things simply get even more visible.

Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
0 Kudos
Message 4 of 6
(1,291 Views)

@Dr._Imad wrote:

the issue here it never happens with boards (like PCI/e cards, that I used in the past) also with the other modules in the sane CDAQ.  Why specific to the 9205 ?


It has nothing to do with the way you call reset, but an inherent behaviour of each DAQmx card, if you call reset and some other operation fast back to back you will definitely see the same issue in other cards as well.

 

The way I learnt this is on a PXI system involving 4463 and 4464, these were on a top-of-the-line system with PXIe controller, so I would say this is nothing specific to 9205, just give each card its own time to complete the reset process and don't rush it.

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
0 Kudos
Message 5 of 6
(1,265 Views)

The 9205 actually does do quite a bit during reset.  One thing that actually takes quite some time is the internal temperature compensation.   Of course,  that means the device must forget everything it knew about its internal temperature and take some temperature readings to find what it's current stable temperature is after waiting for any self-heating effects of the internal sensor.   This takes time.  It will not respond to other commands while it is performing this vital process. 


"Should be" isn't "Is" -Jay
0 Kudos
Message 6 of 6
(1,259 Views)