We are still working on migrating to the new Bosch Connected Industry Online Portal. Stay tuned! Click here for the latest updates.
06-15-2023 01:11 PM
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.
Solved! Go to Solution.
06-21-2023 05:21 PM - edited 07-03-2023 03:33 PM
@MarvinW's code only works if DebounceTime is T#0S. Otherwise WaitIo/WaitBool returns "OK" for only once cycle and restarts the debounce timer and probably both sensors will not reach the setpoint state at the exactly same time. That means WaitIo/WaitBool in combination with a debounce time can only be used with a direct assignment _retVal:=WaitIo(...) or _retVal:=WaitBool(). This is the "problem" of the original post by tommy3000.
An alternative solution would be creating a BinIo flag with WaitIo:
_retVal := WaitIo(CallIdx := 1,
iBinIo := BinIo,
IoIdx := BinIo._120MB60xA, // BinIo flag with _120MB60xA := _120MB601A AND _120MB602A
SetpointState := TRUE,
DebounceTime := T#100MS,
Timeout := T#5S,
AutoClear := TRUE/FALSE,
EventClass := OpconEventClass.SOFTERROR);
06-22-2023 02:57 PM
@SteffenR- are you sure it wouldn't work with a debounce time? I specifically designed it so it can be used with a debounce time. Please have a closer look again and confirm or deny.
The variables _signal1Ok and _signal2Ok are variables of the chain that have to be reset before the respective step. Then I check the return value of WaitIo for OK and then set the _signalXOk to TRUE, which will happen after the IO signal passed the debounce time. If the return value of WaitIo is anything other than OK then it won't affect _signalXOk. The ELSIF then checks if the IO signal does not have the desired state (I assumed it should be TRUE) and then it resets the _signalXOk. This serves as a reset in case the IO signal falls off after the debounce time was passed successfully.
Only if both _signal1Ok and _signal2Ok are TRUE the step goes on. This requires that both signals have successfully passed the debounce time and that neither of them has reset before the other passed the debounce.
07-03-2023 03:29 PM
You are right, your code example in the previous answers works because _signal1Ok and _signal2Ok are remembering the state if WaitIo has already returned OK one time.
But you must be careful to reset these variables in all cases, for example in the previous step.