WaitIo, WaitBool functions

[tommy3000]

Hello everybody

I have a question regarding the WaitBool and WaitIo functions.

The behaviour of this function is, after reaching the condition of the function and returning OK, in the next cycle the return value switch back to RUNNING. Using more than one function calls in one step causes the problem, that reaching on wait function condition, the other is still running, so the step stays active, the wait function does not keep the OK state.

So I'm not able to set every function there on _tmpRetVal and collecting all tmpRetVal at the end  before returning OK for the next step.

[SteffenR- · Accepted solution]

This behaviour is known, but it is the "safe" variant.

If the function would continue returning OK, it could happen that it returns OK in the next step with different parameters as well.

It would be necessary to save and compare all parameters or to save and compare SFCCurrentStep (= step name in which WaitIo/WaitBool is called).

Currently you have to use a separate step for each instance (CallIdx). Of course, this eleminates the advantage of these methods to add such a check via Online Change (because usually changes in the SFC chain are causing memory shifts which could cause other problems).

[florrens]

Can I use WaitBool / WaitIo then to solve the following case? I want to continue in my step chain only if 2 independent signals are present at the same time. If one signal was present but gets lost while waiting for the other signal I do not want to continue.

For my understanding I cannot use 2 steps one ather the other since I then cannot check the first signal while waiting for the 2nd signal. Also two parallel steps will not work if I use a wait step ("wait for other branch") in each branch. When one of the signals was present (e.g. the first signal) this branch will forward to the wait step (_retVal := OK;). Since there is no monitoring in this step I will not notice when the first gets lost while waiting for the 2nd signal.

[SteffenR-]

The use case of @florrens can currently be solved by using the WaitBool method. Disadvantage of this solution is that you have to create an own event on the handler (EVENT_SENSOR_NOK) :

_retVal := WaitBool(CallIdx := 1,
                    Value :=
                             ( BinIo._120MB601A ) AND
                             ( BinIo._120MB602A ),
                    SetpointState := TRUE,
                    DebounceTime := T#100MS,
                    Timeout := T#5S,
                    AutoClear := TRUE/FALSE,
                    EventClass := OpconEventClass.SOFTERROR,
                    EventNo := Loc120_Handler.EVENT_SENSOR_NOK,
                    AddText := '');

[MarvinW]

I think SteffenR's solution is probably the best here.

If you don't want to create your own event message or want to retain the original event messages created by BinIo for your digital inputs, then you need to create two FB variables, e.g. _signal1Ok and _signal2Ok. Then the following should work:

Step 1:
// reset variables
_signal1Ok := FALSE;
_signal2Ok := FALSE;
_retVal := OK;

Step 2:
// wait until both checks have returned OK one time
_tempRetVal1 := WaitIo( your first signal's parameters here );
IF ( _tempRetVal1 = OK )
THEN
  // remember OK
  _signal1Ok := TRUE;
ELSIF ( NOT BinIo._yourFirstSignal )
THEN
  // signal lost again => reset
  _signal1Ok := FALSE;
END_IF

_tempRetVal2 := WaitIo( your second signal's parameters here );
IF ( _tempRetVal2 = OK )
THEN
  // remember OK
  _signal2Ok := TRUE;
ELSIF ( NOT BinIo._yourSecondSignal )
THEN
  // signal lost again => reset
  _signal2Ok := FALSE;
END_IF

IF ( _signal1Ok ) AND
   ( _signal2Ok )
THEN
  _retVal := OK;
END_IF

 But it's not very elegant, so I'd prefer SteffenR's solution wherever possible.