delay after reset device?

[Mark_Holm]

I want to reset my device, including both modules and chassis if the device is a cDAQ chassis, and then proceed to setting the device up for aquisition.  I find that if I do not include delays after the DAQmx Reset Device.vi, I get errors when I go on to setting up the channels and tasks.  As shown in the attached vi, the delays work, but I think this is not a robust method.  Is there a way to know, after a DAQmx Reset Device, when the device is again available for further interaction?

Thanks.

[Mark_Holm]

Here is a snippet version of the Reset Devices subVI with delays.  I'm trying to find a more robust way than delays to make sure the device is ready to work with setup and configuration VI's after Reset.

[alcava.cr]

Hi there, I ran a quick test with a peer and we did not experienced any problem. The difference with your code was that we first reset the device then we query the active devices. We compared the names of the active devices against a string constant, when the device was found the Boolean output was used as a stop condition, no delays used. Try inverting the order of the commands and eliminate the second reset. I hope this helps

[Mark_Holm]

Hi Alejandro,

I do not understand what you have done.  Could you post a snippet?

Thank you

Mark

[alcava.cr]

Here »

[Mark_Holm]

Hi Alejandro,

Here is my version of your suggestion.  I used serial number rather than device type.  Note that I want to reset all the devices in a chassis, plus the chassis itself, if the device is a chassis so I build an array with the module names followed by the Chassis name and then do the rest and wait for serial number operation on the array, one at a time.

When  I use this immediately before a vi that does some moderately extensive DAQmx channel and task setup, the setup vi still fails. It gives the following message

Error -201003 occurred at DAQmx Create Channel (CI-Position-Angular Encoder).vi:4

Possible reason(s):

Device cannot be accessed.  Possible causes:

Device is no longer present in the system.
Device is not powered.
Device is powered, but was temporarily without power.
Device is damaged.

Ensure the device is properly connected and powered.  Turn the computer off and on again.  If you suspect that the device is damaged, contact National Instruments at ni.com/support.

Device Specified: cDAQ2Mod1

Task Name: _unnamedTask<D7>

I am including snippets for both the Reset vi and the Is Device Chassis? vi.  The is Device Chassis vi is one I worked out a long time ago by empirical experimentation.  If you know of a better way to do that check I'd be glad to learn that too.

[Mark_Holm]

Sorry, the line that reads

then do the rest and wait for serial number operation on the array, one at a time.

shoud read

then do the RESET and wait for serial number operation on the array, one at a time.

[Mark_Holm]

When I take out the reset on the Chassis device, then everything is fine.  It looks like the reset on the Chassis device is the one causing problems.

[Mark_Holm]

I can do a Self-Test on the Chassis device without causing any problems.

[Mark_Holm]

OK,  here is what I have come up with.  Seems clumsy, especially doing multiple Self-Tests, but just using property nodes to see if modules and devices were responding wasn't getting the job done.  The properties would return even when the device or module was unavailable.

Self-Tests appear to return errors until the device and modules really are back awake and responding.

Again, the goal is to do a Reset on the device, even if the device is a cDAQ Chassis, and on any modules in a chassis and not return until the devices and modules are ready for action again.

I still need to build in a timeout function.

I am attaching both snippets and the vi's, so you can try this for yourselves.