Implementing safeties in VeriStand

[_pepper]

What are your experiences with implementing safeties in VeriStand?  I have used them in the past and have had some limited success, though I've not worked with them enough to know the limitations.  We did have a hydraulic test stand about a decade ago that was running VeriStand, which was doing a multi-day continuous test with safeties implemented, and we had a computer crash overnight.  Because the system was set up where the SDF was deployed to the NI controller, but the stimulus profile that was running (using WTI Inertia) was native to the host computer, when the computer crashed, the NI controller just got locked on the step in the profile where it was at that time.  Luckily it was in a benign step in the profile, but it could have easily been in a much worse state.  We will have a need to run another similar test sequence, and I need to try to figure out how to implement safeties properly.  Any advice/experiences would be appreciated.  I'm not sure how to overcome the computer crash scenario, so I'm particularly interested in thoughts for that one.

[ZYOng]

Try GitHub - NIVeriStandAdd-Ons/Host-Heartbeat-Custom-Device

[_pepper]

That's a custom device I've not seen, thanks.  I'll give it a try to see if it will cover the computer crash scenario.

[ATarman]

We use a Watchdog Tool created by Wineman / Genuen that toggles variable on the host PC.  It is a .vi that is added into the project and runs on deployment - very simple and very light.  Because it is on the host PC, when the host PC disconnects from the cRIO real-time target, the variable that is changing state stops, which triggers a VeriStand alarm to shut the test down.  

If you have a relationship with Genuen - I would reach out to them.  It works great for us for power outages and when ICT updates force shutdowns of test cell PCs.  

[joshe]

we use this model to a DO to a BRENTEK    watchdog relay device.  The model will toggle at 1/2 your loop/model frequency

[_pepper]

Correct me if I'm wrong, but since the model would be deployed with the SDF, wouldn't it be running on the target controller, and thus would not have any knowledge of whether the host has crashed?  What I'd like to do is have a heartbeat on the host computer that would then be able to be reacted to by the deployed SDF.

I couldn't get the custom device mentioned above from Github to work.  I don't remember the exact error, but it seemed to be looking for some files that didn't exist.  I've only ever used custom devices that were installed using an installer package, haven't actually just pasted the code from Github into the custom devices folder.  So, I wasn't able to see if it would function like I had hoped.  If anyone has any experience with this custom device, I'm open to trying it again.

Finally, are there any good tutorials on creating alarms and procedures?  As I said in my original post, I've had limited success with implementing safeties.  I have a few examples from other projects on older versions of Veristand, but I've had limited success following them as examples on newer projects.

[_pepper]

After a lot of trial and error, I finally got a host heartbeat monitor that seems to be both simple and reliable.  See attached.  I created a standalone VI based off the one shared earlier that is compiled as an executable on the host computer.  The signal is fed into a user channel in VeriStand.  I then added a little code to a simulation model I that was already in my SDF using two Elapsed Time Express VI blocks that are monitoring both the on and off of the heartbeat and resetting the Express VI.  There is a 5 second timeout, so if one of the blocks doesn't reset in 5 seconds, it triggers the Host Disconnected boolean.  I have that signal fed over to an alarm to take action.  I opted to send the heartbeat to a user channel, and then connect that user channel to the Host Monitor inport on the model using the system mappings in VeriStand, but you could really bypass that step and just connect the heartbeat straight to the model.  However, it felt cleaner this way, in case I ever made a change to the model that affected the map from my compiled heartbeat program, I wouldn't have to go recompile the heartbeat program.  I had to mess with the pace of the heartbeat a little to get the model to monitor it properly, but it works great.  The only catch is that you have to either have the heartbeat running before deploying your VeriStand project, or create an enable in VeriStand to start monitoring for the heartbeat.  Otherwise, your alarm will likely trip before you remember to start the heartbeat.

I still think a good tutorial on all of the options available within the Alarms and Procedures functions in VeriStand would be quite helpful.  At this point I've only scratched the surface of what all is available within those functions.