Counter Output Failsafe in the event of a PC Crash

[MrMattPayne]

We have a system that actuates parts using a counter output from a PCIe-6353 to drive a solid-state relay which delivers actuation voltage to the part. Recently we had a PC freeze up and presumably since the counter output was never commanded to stop, the parts apparently continued cycling unmonitored and indefinitely until someone found it and reset the PC. I'm trying to think of an easy way to prevent the parts from being cycled in the event of a crash by the PC.

One idea I had was obviously to set the counter output task to finite samples. Currently we set the counter output for continuous samples, start the task, and once the desired number of cycles are read by an AI task, all tasks are stopped. Maybe if we preset the number of counter pulses, we'd at least have a limit to how many times the parts would be cycled.

I then thought of splitting the cycles up into chunks, say 1000 cycle segments, and if the PC freezes then there will be at most 1000 unmonitored cycles. I don't think we want to do that because I doubt the transition from one segment to the next will be seamless, but maybe I underestimate myself. 

Both these ideas assume that once a finite counter output task is started, it will stop itself regardless of whether or not the PC is still responsive. Is that true? I don't know how to force the PC to freeze to test this.

Feel free to throw any other ideas out there as well. I'm trying to avoid hardware changes because we have 10 or so of these machines and they are unfortunately of pretty low priority, so anything outside of a code change is unlikely to happen. Thanks!

[CDuck]

I did exactly what your idea is when driving a motor that would result in destroyed parts if not stopped. For example say it needed to drive 100k steps I would tell the motor to go 1k steps 100 times. 

If your hardware control loop is isolated you shouldn't have much more than a few ms seam.  You could even run the next command a bit early.  In my example run it at 995 steps so you would then tell it to go 1005 steps. And once again wait for (command) to be 99.5% done.

Other wise if you could have a timed relay as an e-stop where you have to continously send messages to the relay to stay powered.  If it doesn't receive a message it would time out.

Just some ideas.  Would like to know what you end up doing for the next time I work on a project like this

[MrMattPayne]

That sounds about right CDuck! My concern is we're often cycling at 50hz with a max of 500hz which means the entire period is only 2ms so any hiccup would be significant in these faster parts. It's probably not actually significant to the outcome of the test to have a blip every 1000 cycles or whatever, but I don't wanna open that can of worms. If I get a chance I'll try this out and see how it works in practice. Did you ever verify the effectiveness of doing this? By that I mean did you verify that if the program stops/crashes, the output only goes another 1000 steps and stops?

I think that a hardware solution like that would certainly be the easiest and probably most reliable way, but for now I won't really be able to try any. Right now I'm seeing how it goes with just changing to finite samples (the full amount), but it's hard to test whether or not it'll work without knowing how to force the PC to freeze!

[BertMcMahan]

Output tasks are buffered for AO, at least, and I'd assume it's the same for counter output tasks. This means there is literally zero "seam" or downtime or anything between successive writes. I use this method for nearly all of the AO tasks I do as I need to be able to change the output on the fly.

Another thing to look into is the DAQmx Watchdog, but I don't think your device supports a watchdog on a counter output: https://www.ni.com/en-us/support/documentation/supplemental/13/how-to-use-and-implement-the-watchdog...

[CDuck]

Yeah it worked where if I aborted the program the motor would just finish the 1000 steps it was running.  Missing a couple ms was no concern to me. 

I'm interested in what bert is saying quite a bit, as what I was describing was a DIY watchdog.  Watching is definitely a valuable keyword for researching this stopping method

[MrMattPayne]

Yeah it looks like my series X DAQ card only supports watchdog functionality on the DO lines, though that could easily be used to set up what you were talking about. If the watchdog timed out, it could turn off a relay and interrupt power to the parts, even though the counter might still be running.