how to do non-persistent digital output from a NI-DAQ?

[JoshB]

I'm using a USB-6251 DAQ unit and LabVIEW to drive a mechanical system with a stepper motor.  During normal operation, I set some of the digital outputs to 1 (to tell the motor to move).  However, if I get an error or the VI crashes or the user hits abort (basically, whenever the user doesn't stop it 'nicely'), those digital outputs are left at 1, and I would prefer they return to 0 (otherwise the motor can break things).  Any ideas how I would implement this?  Think of it as a 'deadman's switch' in LabVIEW.

Thanks,

Josh

[Norbert_B]

Josh,

the digital out lines of most NI devices are configured to keep the last written value until you switch of the power. There is no other way to reset that except writing a new value....

So first of all:

Remove "run continuously" and "abort" from the icon bar.

Make sure that the VI cannot crash by any thinkable means (Selfrecovering).

Create controls/methods to stop the application which make sure that the DOs are set to low.

If you cannot achieve something like this, you will need a "deadman's switch" in hardware in order to deconnect the DOs from your hardware devices.....

hope this helps,

Norbert 

[Wayne.C]

Josh,

In addition to Norbert's suggestions, I often disable the red 'X' in the upper right hand corner as well.  That way the user always shuts down the application on my terms and any necessary housekeeping can be performed before program exits.

If safety is critical, I might consider an external watchdog device that could disable things if the program locked up.

Message Edited by Wayne.C on 05-14-2009 11:41 AM

[JoshB]

Thanks for the suggestions.  I hadn't realized I could remove the abort buttons or disable the close button.  That takes care of a few problems at least.

Unfortunately, this doesn't take care of LabVIEW crashing.  I already ran into that problem once, and luckily it didn't damage any of the expensive parts of my setup.  When LabVIEW crashed, the motor kept on running happily overnight, not realizing that it was up against a hard stop.  The sound sure annoyed the first person into the office though!  He turned off the power.

Regards,

Josh

[Norbert_B]

Josh,

in such case, you should consider to insert a circuit breaker which will switch off the motor if the axis is beyond your limit....

hope this helps,

Norbert 

[JoshB]

My stepper motor controller does have some programmability, so I think I am going to hook up one of my sensors to it (not technically a limit switch, but it will serve the same purpose) and program the controller to monitor the sensor.  This is somewhat frustrating, as LabVIEW is already doing this as well, but it can't be 100% trusted to not crash.  I had thoughtof this earlier, but I was just hoping I could find a way to tweak the NI hardware setup to make it work without needing to change the programming of the stepper controller.

In the end, this isn't a safety issue but I do have a force transducer as part of the system, and I really don't want to overload it ($500  to replace).

Thanks for all of your suggestions,

Josh

[Wayne.C]

Josh,

Labview is very stable.  What I have found to be unstable are PC's running windows and my vi's.           Are you using the Error cluster in your LV program?   

Also, you are using USB hardware.  I have seen USB hardware lose its connection to a PC.  Sometimes it's because the PC went into a standby mode.  As a test you might create a simple program that just checks to make sure the DAQ hardware is still connected and let it run.