So there is no SIR[1]=condition or SIR[4]=condition in one of the 64 lines of Safe I/O Connect? If this is the case and if you are not able to find something in the DCS setup, it would be helpful to get an AoA backup. Then I can have a look on it tomorrow morning.
DCS Safety I/O Connect
-
ezraseth -
May 16, 2023 at 4:15 PM -
Thread is marked as Resolved.
-
-
okay there is as follows
SIR[4]=SIR[3] AND !SSI[9]
SIR[1]= SSI[11] AND SIR[2]
With that being said
SIR[2]= SSI[8] AND !CSI[16]
-
SIR[3]= CSI[3] AND CSO[3]
-
That is what we need.
SIR[3] is ON when CSI[3] AND CSO[3] are both ON. According to your screenshot, CSI[3] is OFF. CSIs are normally coming from the PLC. So you or your PLC guy should check on the PLC side why CSI[3] is OFF. Also check CSI[16] which is part of the SIR[2] condition.
SSI[9] is T2 mode. The signal is inverted which means it is ON as long as you are in T1 or Auto mode.
SSI[8] is T1 mode and SSI[11] is the Safety bypass. Enabling the bypass will turn the signal ON.
-
thank you! Im going to try and get with him tomorrow on that. Its AB Logic. Hopefully we can find out where these bits are in the program.
-
hello again . Got the Controls Engineer at to look into this issue. We found some things but apparently we dont have the "safety edit software" to modify anything. It does look like the button on the HMI, that allows that single robot to run with the fence open, is tied into a CSO/CSI in the logic. I asked if he could run it up the chain of command that we get this software and tie the rest of the robots into it as well. Not sure if thats going to happen but we will see. Either way if it comes down to it i can make it work for mastering/ect. And then just revert it back...thanks again for the help everyone. I guess im going to mark this as resolved!
-
Resolved
-
Thanks for providing the solution!
-