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-]

Did you check the event history (HMI app) if there was any error?

If control is switched off there is always an error message - except if the operator presses "control off" or the control off button has a wiring problem.

In case of the MainValve and SafetyValve add-ons the logic is:

_enableControlOn := BinIo.GetState(ParStart.IdxEnableControlOn);

IF( NOT _stdAddOnBaseData.Status.ErrorActive )
THEN
  OutImm.Ready := TRUE;
  
  IF( _enableControlOn )
  THEN
    // condition for control on is ok again (compressed air and bus ok) => reset OutImm diagnostic variable
    OutImm.ControlOffSet := FALSE;
  END_IF
ELSE
  OutImm.Ready := FALSE;
  // switch control off and set OutImm for diagnostics:
  OutImm.ControlOffSet := TRUE;
  BinIo.SetState(ParStart.IdxEnableControlOn, SetpointState := FALSE);
END_IF

[MarvinW]

Unfortunately my event history is spammed full of other events. But the problem happened again during my absence so I'm confident that it will shop up again.

A general question: If the hosting mode handler already set two other warnings and then the problem of the main valve happens, if it's a warning only then it won't be shown. Once one of the other warnings is fixed and acknowledge was pressed, will the warning show up then? I may have had the same situation with error events, but those were already cleared by the time I arrived at the station, so not sure.

[SteffenR-]

The safety add-ons are using only the event class ERROR, not WARNING. Events are not acknowledged automatically. After acknowledging an error event the error event is set again if the reason is still there.

One case which is usually hard to find is a short drop down of the compressed air, for example because of moving a big pneumatic cylinder or many cylinders at the same time etc. But also in this case there is an error message "Pressure present expected = 1". But after acknowledging it there will be no error anymore because the compressed air is present again.
The default time is T#250MS to ignore drop downs of the compressed air. It can be changed in CpStudio/OES.

In combination with a SafetyValve add-on the parameter rIsCompressedAirOn of the SafetyValve add-on helps to see the correct error event:

[MarvinW]

I managed to log in while the problem happens and this is what I observed.

At first there actually is an error about high pressure not present. I am not sure why this happens but also don't care too much. It's probably some timing thing when we turn on the power. In this machine, the main valve switches on with the main power, sort of like a pre-control-on.

I acknowledge errors on the HMI once which makes the error disappear and the main valve switching into a state that is basically OK, except that the OutImm.ControlOffSet is still true, and as expected the _enableControlOn is false. My question is why the valve is doing this? It is definitely stopping my machine from being operated (no control-on possible) without any error message being displayed.

I am also puzzled why this is happening now but did not happen before. I am not aware of any changes in the software or hardware that are related to this. But my colleagues may have made modifications to the power supplies or safety relais that I wasn't told about, which could influence the behavior when turning the power on. Could that behavior be the reason after all?