I found the problem in my station. The IO signal for "Control Off" was constantly set. I don't know why it was like this or why this had never created any problems until about a week ago, but that's a different story. Why was this so hard to diagnose? The problem was that the ControlOn addon did not set its OutImm.ControlOffSet, which I was expecting it would in this kind of scenario. The reason why it was not set is the code in the add-on (NexeedControlOnAddon library 2.0.4.0): _enableControlOn := ( _busOk1 ) AND
( _busOk2 ) AND
( _busOk3 ) AND
( _busOk4 ) AND
( _busOk5 ) AND
( _busOk6 ) AND
( _busOk7 ) AND
( _busOk8 ) AND
( _busOk9 ) AND
( _busOk10 ) AND
( NOT _switchCtrlOff ) AND
( _userEnableControlOn );
_parStart.iBinaryIo.SetState(_parStart.EnableCtrlOnIndex, _enableControlOn);
_enableControlOnF( CLK := _enableControlOn );
IF( _enableControlOnF.Q )
THEN
OutImm.ControlOffSet := TRUE;
END_IF After gracefully calculating _enableControlOn it uses a falling edge trigger to set OutImm.ControlOffSet. But in my case, the problem was that _enableControlOn was always set to FALSE every since the first call of the addon's OnCall method. Why is there a falling edge here? If the add-on calculates _enableControlOn to be FALSE and sets the corresponding IO, then I expect the OutImm.ControlOffSet to be TRUE. Simple as that: IF( NOT _enableControlOn )
THEN
OutImm.ControlOffSet := TRUE;
END_IF I suspect the safety add-ons use a similar logic to calculate their own OutImm.ControlOffSet, which should also be changed accordingly. Unless there is a reason why there *must* be a falling edge?
... View more
