MainValve Add-on sets control-off without any error

[MarvinW]

Today my colleagues called me to check why a station wouldn't control on. After investigating I found that the MainValve declared that it was preventing control-on through its OutImm.ControlOffSet. However, I could not deduce why it would do that. The add-on had no error. It was ready, CompressedAirOn was ok, _switchValveOn was OK, _pressurePresent was OK, _pressureNotPresent was false. I also physically checked the main valve and that was also OK.

I only have one other add-on controling the "_enableControlOn" flag and that is the control-on add-on itself. Its ControlOffSet was false.

I am using the AtmoSafetyBase library version 2.0.9.0. I strongly suspect that there is a bug in the library. Unfortunately I don't know what my colleagues did that lead to this state. I suspect they didn't do anything out of the ordinary though: just turn the power on and try to start the machine. This has never happened before with this machine and unless I'm called again tomorrow morning, I'm afraid it will be hard to reproduce.

But if a customer can't turn on their machine and there is no error message on the HMI telling them why, I think that's a very serious issue.

[SteffenR-]

The add-on resets ParCfg.IdxEnableControlOn only as long as an error is active. _enableControlOn is just the status of BinIo.GetState(ParCfg.IdxEnableControlOn), see modified source code above.

In your case the MainValve add-on is responsible for switching off control (because OutImm.ControlOffSet=TRUE; switch-on and drop-out time can maybe be adjusted to prevent the problem). The problem of not able to switch it on again is caused maybe by your safety logic or by a bus problem (ControlOn add-on checks if all Busmaster.OutImm.BusOk/CheckedBusOk=TRUE). What looks strange is that pressure is present, but control is off.

[MarvinW]

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?