Drive AO to 0 Before Undeploying NIVS Workspace

[Pie566942.0]

Hi All,

In NIVS 2011, our Simulink model outports are mapped to analog outputs.  Whatever value is latched to the outport when the sysdef undeploys is latched at the AO.  We'd like to set everything to 0 before undeploying the sysdef.  We can stop the model, but it still drives the channel.  We can set the channel value, but the model drives it even when stopped (this makes sense).  Ideally, we'd have an alarm/procedure combo, but we can't override the model output.  I've seen: http://forums.ni.com/t5/NI-VeriStand/reset-all-outputs-to-initial-values/m-p/2162306#M1980.  We can Fault the AO when the model is running or not.  We probed the AO after faulting it to 0 and undeploying the sysdef, and we didn't see it glitch high.  So, it seems to give us the behavior we want.  I'd like to check with the gurus to see if there's a better way to do this, or if there are known caveats to our approach.

Thanks for your time and insight,

Steve K

[0utlaw · Accepted solution]

Hi Steve,

My personal recommendation would be to have a conditional calculated channel mapped to the output rather than using faults, in this scenario the conditional channel's value (and therefore the AO) would toggle between the model's outport and a user channel that stores a default shutdown AO value depending on the status of the model.

The conditional trigger itself could be an outport of the model or stimulus profile (set a value high when the model starts and low again when shutting it down), or the status of the model could be determined using an independent poll -based on your post it sounds like you may already be doing this.

Regards,

[Pie566942.0]

Hi Tom,

Could you speak to the reason(s) behind this design?

Thanks,

Steve

[0utlaw]

Hello Steve,

As alluded to in my initial post; this is something of a personal preference, but as it requires no additional configuration beyond a few clicks in the project explorer, can be procedurally generated/configured using the VS API for LabVIEW or similar scripts, is easily expanded to cover other cases (the "isSimulationRunning" channel that controls the conditional channel could as easily be an "isFaultRequired" channel that could be modified from any location within the nivsproj, including an alarm procedure), and does not rely on communication between a host and RT target (as would be the case if using a Stimulus Profile or the Workspace Fault Manager tool to fault a channel) I feel it is a fairly robust and adaptable option.  I'm not 100% clear on how you intend to implement the fault described in your previous post, but depending on the intent, operating requirements, and approach I believe that either method could suffice.

Regards,

[Pie566942.0]

Hi Tom,

After looking at this on our system, I prefer your method over mine.  Your idea strikes me as an "OR" configuration, i.e. the channel is sourced by the model OR a constant value.  The fault is an "AND" configuration, i.e. the channel is driven by the model AND the fault manager.  I prefer one source per sink.  There's a few changes in SE to support it: create a User Channel, create a Calculated Channel per AO, edit the system mappings.

Thanks for the idea!

Steve K

[0utlaw]

Steve,

Thank you for the feedback, and best of luck with your application!

Regards,