To have any react "fast", like external command inputs, if they are wired to a digital input, you can enable a hardware interrupt to be triggered when those command inputs change state or become a specific state.  The hardware interrupt can then start a specific OB to act on the changed input.

The time interrupt OB already suggested, configured to execute every 5.0 sec (do you need 5.00000000000 sec?  Or is 5.0, 5.00, or 5.000 close enough?).

In the time interrupt and hardware interrupt OBs, they would execute an FB or FC related to the external commands or the 5s interval.

By the way, requiring 5.000000000 seconds in a PLC that is not locked to a proper calibrated time source is not really a great idea.  Maybe you can get 5.000 seconds over a day, accounting for time drift.  If you use proper time syncing, you can achieve microsecond accuracy, perhaps even nanosecond on high end s7-1500's.  The best you can do on an s7-1200 (you don't specify in your post) is maybe 1-2ms with any consistency.

U_27dbf69d-f1a5-4610-8970-316b780be900

Hi all,

I would like to use a cyclic OB to execute a function. The OB time must go from fast (10ms) to slow (>= 1s). However, the OB should start cycling only after a start command and react as fast as possible to commands such as stop, trip etc.
In this case a cyclic OB does not seem to be the optimal solution: if I don't go wrong, it start cycling immediately after the CPU start or immediately after downloaded to the CPU, not after a start event. Moreover, it reacts quickly to external commands only if its cycle time is quite low (10ms in my case). Not if I use 10s for example. A better solution seems to be using a time delay OB and convert it in a cycling OB: in this case a start command in OB1 can start the time delay OB almost immediately by calling the SRT_DINT function with a time of 1ms. Then, within the time delay OB, I recall the SRT_DINT function with the correct cycle time (for example 5s). Again, in OB1, I can stop the time delay OB almost immediately by calling the CAN_DINT function.
My problem now is this: the solution seems to be excellent, but again only when the time of the time delay OB is slow, not when the time is fast. If I understand good from the user guide of the function SRT_DINT, when the set time is less than the cycle time (for example 10ms in my case) then the CPU cycle time is used to cycling the OB, so this is no more constant. This could be a problem because I want the precision of the time.
Any idea?

You might have misunderstood.

I suggested a two-pronged approach.

Approach 1: Time-interrupt OB to handle the repetitive process aspects, but for sure include logic that allows it to return without doing anything - like for calibrations, or when there is nothing to do.  It calls an FB/FC with proper parameters to let the FB/FC know it was called via time-interrupt OB - routine, and handle accordingly.

Approach 2: Hardware-interrupt OB to handle disruptive external input driven aspects, but again, include logic that allows it to return without doing anything - like during calibrations, or when there isn't anything to do. Be sure to call the same FB/FC with a parameter alerting it of the type of event it needs to handle - urgent, and let the FB/FC handle accordingly.

Examples of nothing to do: someone pushes the stop button and nothing is running, or the e-stop is already activated, or when attempting to act on the stop PB is simply silly and waste of logic processing.

Examples of differences in handling.

During calibration, a routine call from the time-interrupt OB might verify the time-interrupt OB is running at the proper time interval for calibration.  If it needs to run faster, have it query the current interval and then set it as needed. Once the calibration rate is set, make sure and save that state so the next time it gets called, it does not need to check the current rate provided it is still in calibration mode.  Once calibration mode ends, it should revert back to standard time-interrupt interval/offset.

Be careful to manage the time-interval and offset relationships across all interrupting OBs so they do not all fire at exactly the same time and interrupt each other.

Time to cheat.

In the PLC cyclic logic running scan time << 5s, when any external (HMI) command arrives, turn on a spare digital output which is wired to a spare digital input.

In that digital input's hardware config, set up hardware interrupt.  In the hardware interrupt, do as I mentioned previously.  Execute the logic executed when the periodic OB is called, and if needed, speed up the 5s OB as required, then slow it back down as needed.

U_27dbf69d-f1a5-4610-8970-316b780be900

Sorry 0_Einstein, my answer was for jacek d, not for you. In any case, to clarify, all the commands come from the graphical interface or from the internal logic of the PLC, not from physical inputs.
However, with the code attached (here I only show a trivial counter) I almost got what I wanted:
a cyclic OB that starts almost immediately only after giving a start command (you can see the counter immediately going to 1), starts cycling with the correct frequency (slow, in this case 5 seconds), but is stopped almost immediately by a stop command.
What still does not work well is the first OB call: it is clear that the counter often goes from 1 to 2 in less than 5 seconds.

However, you highlighted a problem to solve that I had not considered: my OB can be interrupted by other OBs. This can affect the accuracy of the ramp. Thanks.