DAQ Devices Reset

[thumble]

Hello,

I'm wondering if there is an option in nivssdf to ask VeriStand to issue a DAQ reset during undeployement in order to ensure that all the outputs revert to their default (safe) state when the target is undeployed.

The reason is because my project is controlling a test rig, part of a larger system, with many "system" outputs (i.e. anciliary control, sub-system interfaces, status lights, ...) with a nominal working state that is not 0. In case of an undeployment (normal cause: software update, abnormal cause: maintenance operator mistake ...) those output should revert to 0 so the overall system is in its default safe state. A specific RT sequence using faulting could solve the problem for planed undeployement but it's not handy, hard to maintain and not safe regarding abnormal or unexpected causes.

We're using VeriStand 2011SP1 along with LabVIEW 2001SP1

[JérémyC]

Hello thumble,

Would you like to reset your outputs to true default value or to specific values considered as default values?

I looked for an option which could allow to do something similar but I found nothing. I think you will have to create a piece of code in order to reset manually your outputs when a problem occurs. You can create un custom device for doing this. You could also try to quickly deploy again after undeploying in order to reset DAQ devices.

Here a procedure that an Application Engineer proposed to a customer who also wanted to put outputs of DAQ devices in a safe state. The only difference is that the customer was using a model:

1. If Stop Button is true then set model command to pause. This will stop the model so we can set the channels values back to the initial values.
2. Set all channel values to initial values by using the set multiple variables.

Then you can undeploy VeriStand and all the channels will be at an intial value.

For the procedure here are the steps that you will want to go through for a safe shutdown of your application:

1. Create a User Channel for the Stop Button.
2. Create the Procedure (Make sure it is not set to run at start. You can do this by clicking the Procedure section and unchecking the On start Execute Procedure box.).
3. Create a condition within the procedure. In the condition set the channel to check to the user channel, set the comparison to =, check the Use Constant Value checkbox and set the constant value to 1.
4. Create a set variable within the procedure. In the set variable select the channel to set as the model command, check the Use Constant Value checkbox and set the constant value to 1 (this should be the pause command for your model). You can make sure it is one by clicking on the model command in your model within VeriStand to confirm.
5. I would then add another condition to confirm the model has stopped. Set the If to the model command and if the value is equal to the pause model command (should be 1) then go to your first set of setting multiple variables. This will now start setting the channels to their initial values.
6. Once you have finished setting all of your channels you will want to use an end step within your procedure to finish the procedure.

Even if those steps cannot be directly applied to your application, I think that the idea of creating a procedure for ensuring that outputs are in a safe mode before undeploying is a good solution.

Regards,

[thumble]

Hi,

I agree, in normal operating the outputs are always controlled. The problem is when an unexpected usage occurs:

The system is currently in an adjusting phase and so the VeriStand project is started in configuration mode. When a change has to be applied we undeploy and re-deploy after the system has been set in a safe mode. When the software is considered stable we disconnect from the target and exit the VeriStand project.

The kind of accident that have occurred (more than once) is: the system is powered and by mistake the operator undeploys the target (because the undeploy button needs no confirmation, it's very easy to do that) or the operator exits VeriStand's project (directly or because of a logout or shutdown) and has forgotten to disconnect from target. This is an issue because the system gets uncontrolled with the PXI outputs locked at their current values.

So I think it would be better if:

1- The undeploy operation (from project manager) is submitted to an operator confirmation.

2- In case of a project manager shutdown, it disconnects from the target instead of undeploying it.

3- The DAQ manager should reset all its declared DAQ boards at undeployement phase (this could be an option for compatibility issues).

Best regards

[JérémyC]

Hi thumble,

To answer your questions :

1- The undeploy operation (from project manager) is submitted to an operator confirmation.

This does not exist but this could be implemented in LabVIEW with the VeriStand API. 

2- In case of a project manager shutdown, it disconnects from the target instead of undeploying it.

Building a EXE in LabVIEW will give the developer plenty of control over how the operator interacts with the setup.

3- The DAQ manager should reset all its declared DAQ boards at undeployement phase (this could be an option for compatibility issues).

This is not recommended. When the DAQ device is booting there should not be any load attached to the device. We cannot gaurantee how power may flow throught the device during initialization so reseting the device with load attached could damage the device. You should use either a procedure or a Real-Time Sequence to set the values of each channel. 

Unfortunately no these features do not exist by default. Running simulus on the windows side and sequences on the RT side will ensure that any clean up that needs to happen happens with each use of this test system. This could be automated within the stimulus profile editor and these sequences to set values could be written also.

You could also post your suggestion here : NI Idea Exchange : Additional NI Software Ideas

Regards,

[JérémyC]

Hi,

Here some additionnal information :

There are some tutorials in the help that will walk you through the stimulus profile editor.

Link for creating a real-time sequence

http://zone.ni.com/reference/en-XX/help/372846F-01/veristand/creating_rt_sequences/

Regards,

[thumble]

Hi,

The problem is not in the normal VeriStand usage, but in case of abnormal conditions or missuses by an operator. It’s not because the final user has been trained that he’s free of mistakes. My suggestions were to reduce hazardous conditions versus human failures.

Regards,

[dfnonn]

I have the same problem.  I am running a PID controller in VeriStand that controlls and electric motor.  If the test is running and the setpoint for the process variable is commanding the motor to run, and I undeploy to make changes, the PID remains at the last setpoint... the motor is running with no system definition deployed... this is not safe!!!  Then when I redeploy, the initial values for the setpoint are applied, and the motor stops. 

I understand that I can write a shutdown sequence/stimulus profile that will send everything into a safe state, but that doesn't work unless the operator runs that sequence before hitting the undeploy button. 

Did you ever find a solution to this problem? 

[Jiri_K]

Inertia addon?

http://sine.ni.com/nips/cds/view/p/lang/en/nid/209999 

[thumble]

Hello, The only way we've found is:

Best regard.

[dfnonn]

Hi Thumble,

How are you using those warning messages?  Are they simply decorations/icons in the workspace, or did you write some type of custom devie to get them to pop up once the user tries to hit the undeploy button?