DO[1] = DI[1] AND F[1]
There is a somewhat convoluted way of handling this "in the background" via I/O interconnect, with use NSIs and SPOs through the DCS Safe I/O connect Option, if you have it.
DO[1] = DI[1] AND F[1]
There is a somewhat convoluted way of handling this "in the background" via I/O interconnect, with use NSIs and SPOs through the DCS Safe I/O connect Option, if you have it.
- Interconnect DO[1] to any always Off input, e.g. SI[15].
- Control DO[1] in BG logic.
BG logic prevails over Interconnect.
If BG logic is stopped, the DO[1] becomes subject to the Interconnect and will switch Off.
Throwing out another option.
Create 2 BG Logic programs that monitor each other. If either one is stopped it will shut off the DO within a few milliseconds, long before a person can stop the other program.
But if the power to the robot has been off ,how long does the system have to wait to get up to temp? Why not have a normally closed contact send the heater on input and the DI coming back opens it?
But if the power to the robot has been off ,how long does the system have to wait to get up to temp? Why not have a normally closed contact send the heater on input and the DI coming back opens it?
If I have anything NC in this circuit, I'm practically asking for a thermal runaway. I need this to "fail off," partly due to thermal runaway issues, partly b/c I'm dealing with thermoplastic material -- if I let it get solid, I can always re-melt it, but if I keep it at operating temperature for too long, it can "bake" inside the extruder and become thermosetting, which could only be fixed by dismantling the entire unit (nearly impossible with solid baked plastic everywhere) and burning out the hardened material.
This application can deal with long heat times, but can't deal with the aftereffects of either thermal runaway or "baking".
If you are not using PNS, another option would be to make a KAREL program that runs in a loop, configure sys vars to auto-start it at boot time.
Check this thread: Run KAREL program at startup
Also maybe add a "hidden" directive.
$MIX_BG[1].$STATUS
the index is which BGlogic program, in this case 1.
Status: 1= stopped, 2 = running in normal mode, 4 = running in high mode
Well, this just came in very handy on a different project, so thanks again.