FEATURE REQUEST GOAL
It would be prudent to throw an Error if the Encoder (and idem dito for the Decoder) cannot finish its job within a set of predefined CPU cycles. We can actually expose the cycle amount for diagnosis. This MaxCycleLimit (UDINT) should be set via an input of the Encoder/Decoder and could be set at a default of say 10.
When the Encoder (or decoder) starts, the number of cycles remaining (and counted down each cycle) is copied to an output: CyclesRemaining(UDINT).
If the Encoderfinishes within the set cycles as presumably the encoding / decoding will take only one cycle is taken.
Reasoning:
I doubt that the payload gets encoded within a single cycle when the payload gets bigger >= 500 values (arbitrairily chosen) or when the encoder process actually takes more time then say T#100ms.
The taken number of cycles can be calculated via: MaxCycleLimit (INPUT) - CyclesRemaining (OUTPUT)
Mitigation:
One could set a watchdog on the cycletime in the taskmanager, but the propsed soultion can help us define the limits better when we chose to stresstest the payload encoder /decoder.
Also the Professional Edition Code Profiler should help us here (should ask CODESYS for some temporary license when it is time for this)
Needed:
VAR_INPUT
MaxCycleLimit : UDINT := 10; ( Maximum number of cycles before an error is thrown )
END VAR
VAR OUTPUT
CyclesRemaining : UDINT := 10;
END VAR
Behaviour:
On start of encoding the MaxCycleLimit is taken and every cycle it is reduced by 1 (e.g 5, 4, 3, 2, 1, 0). If the remainder reaches zero a time-out error could be thrown. This remainder is then copied to the output of the function block
If an error occured during the count down, the remainder is reset if the block is reset (follow CBML rules)
If ready the the output is frozen until a new action is taken (start of encoding?)
Difficulty:
I don't know how the trigger for encoding / done / reset is implemented or how the continous behaviour of the state machine is implemented.
Diff:
Diff:
Diff:
Currently, encoding or decoding seems te take a single PLC Task Cycle. Therefore a "watchdog" seems unnecessary at this time.