Hello,
Can you elaborate? Do you mean turning the DO manually from the DO screen on the TP? Why bglogic is not possible or even interconnect? The DO will be turned to the necessary state, even if somebody wants to change it.
Maybe use an USB password file? And setup custom password levels to fully protect DO's?
Or shell + password protect system variables (to not be able to stop shell).
BG logic RO=DO AND Condition, where the DO is the control and RO is the valve.
You may run 2 BG programs with the same logic for redundancy.
Of course, the BG logic should ignore pause conditions.
Aren't there DO (In Menu->Setup->General) that could be use with background logic that would do just that, on our arcmate when the selector was on Auto the "Weld enabled" came on and green lights were flashing when a cycle was running
I've set up a similar safeguard to prevent a tool changer from being unlocked.
BG logic:
If UO[3], DO[5] =F[5]
If !UO[3], DO[5] = off
Use F[5] in your program to turn on/off the waterjet. If the program is not running it will not let it turn on, even if you manually force the DO on, it will turn back off immediately (couple msec). Set F[5] off at initialization of main program in case operator accidentally turned it on. If program is paused then resumed, so will the waterjet.
Sent from my VS985 4G using Tapatalk
HawkME, and what happens when somebody will stop bglogic?
Hello mr. Fabian Munoz,
I used this concept for triggering an alarm. If robot was idle for too long in auto mode i will generate an alarm.
USE PMC or BG logic, what-ever you feel easy.
U can find TP enable or disable feedback in so7 ( pls check for your robot ) it will say whether ur robot is in normal mode ( manual ) or production mode ( auto ).
One of your DI or Do ( range between 80 -85 ) i cant remember, it will tel u whether your robot is idle or working.
So assign on digital output as dummy ( i.e., this will be used to switch on and off your water jet output in program)
so now u can make logic
BG logic example:
use mixed logic instruction.
if so7 = on ( TP enable ) and dxx ( robot busy) = on and do = on ( dummy output, u can set this output were ever u need) then dox ( water jet output ) = on
PMC:
use above logic in ladder diagram.
240% auto control... 
Note : u cant force on and off your water jet output even in manual mode.
u should stop ( BG or PMC logic whatever u used ) to force this output.
hope this helps.
@ mr. andreic
Logic inside BG routine will not work.
U can force on and off outputs inside BG logic routine...
I use BG logic for this all the time. If a DO it's manually forced, the BG logic immediately turns it back off. If you really are worried about an operator defeating that then either password protect or run it thru a PLC.
Sent from my VS985 4G using Tapatalk
... Sergei. Your idea doesnt stop anybody from just selecting I/O, Digital and turn the DO on (make it green) ...
Correct. But, if the condition is False, it will not activate the valve RO.
The condition was specified as "robot is in auto and running the cycle" in your question.
You did not say that even under that conditions you want to forbid manual activation.
If so, let the running program activate two bits (e.g. flags).
Only when both are On, the background logic will activate the valve.
Let the background logic reset each after certain time being On alone.
The time should be short enough to make impossible consecutive manual activation of both.
If you can endanger people by turning on WaterJet, you shoud use DCS ...
"If you can endanger people by turning on WaterJet, you shoud use DCS .."
I'm not sure about that, dha. Indeed, "safety" is whatever the controller is engineered to do. The code runs just the same if it is safe as it is not.
That is, there is no "safe" state except decided by logic as programmed. by a human. safety either hardware or software is determined on a case by case basis - as you know
While I accept logic in safety plcs and dual-check-safety might be preferable to other methods, let;s accept that DCS is probably prohibitive in some cases.
These proprietary systems are tools - just tools - to achieve the engineering safety standards your team lives by -
The controller doesn't ask you when it arms the servo and brakes enable - it sees an input and acts on it - I don't see how we can make computers emotional - unless we tell them
Display More
"If you can endanger people by turning on WaterJet, you shoud use DCS .."I'm not sure about that, dha. Indeed, "safety" is whatever the controller is engineered to do. The code runs just the same if it is safe as it is not.
That is, there is no "safe" state except decided by logic as programmed. by a human. safety either hardware or software is determined on a case by case basis - as you know
While I accept logic in safety plcs and dual-check-safety might be preferable to other methods, let;s accept that DCS is probably prohibitive in some cases.
These proprietary systems are tools - just tools - to achieve the engineering safety standards your team lives by -
The controller doesn't ask you when it arms the servo and brakes enable - it sees an input and acts on it - I don't see how we can make computers emotional - unless we tell them
I agree. But you have to secure critical functions of the machine and if the worst happens you are responsible.
Code written in DCS cannot be stoped or modified without a password.
run your output to a safety relay and have your systems safety voltage run the coil. DCS I/O is your best bet, it is all dual-chain and can give you a safety rated signal for T1/T2/Auto. you can also set it up to ensure that it remains in an area, restrict joint positions, speeds ect.
Fabian why don't you use a interconnect DI-DO and have the PLC condition the input to only work in Auto.
