In simulated control no "real" hardware is supposed to be controlled.
A simulation is usually a loop over model time. Physical parameters of the modelled system are calculated at each time slice.
PLC cycle time is naturally assumed to be equal to the calculation time step.
The cycle time can be increased up to several calculation time steps easily.
The motivation to use trigger formalism in a simulation code is the following:
In the provided example HeatDiffusion1D, it is a very simple 1D heat diffusion along a bar and a temperature controller that can switch on and off the heater "installed" on the other side of the bar. There is a heat exchange with the environment along the bar.
When the overridden method Control.start()
is called for ControlSimulator,
Task.setOn()
is called internally for all linked tasks instead of Task.start()
as would be for RealtimeControl.
All activity in a simulated control scenario must be contained in onStart and onStop but there should be no loop in any tasks!
Check the provided example (HeatDiffusion1D), the line
Task sourceControlTask = new Task(onStart, onStop, -1, "source control task");
creates a task with no loop.
A real PC-based control can be implemented with the package.
However all pros and cons of a PC-based control remain valid, e.g. lack of GPIOs but a large on-board RAM and disk space, ability to perform complex operations with the data, etc.
It seems that the most natural implementation of such real-time control is a server PC that monitors dedicated controllers (e.g. terminal temperature controller, robot controller) and other servers/PCs.
Scan cycle in this case consists of network connections called from Runnable loop of the initialized tasks (i.e. objects of Task class).
Method realtimeControlExample()
provides an example of the real-time control that uses ControlRealtime class.
An open http weather server is pinged continuously and the data retrieval delay is logged. The first retrieval takes much longer on a home laptop either because of server-side caching or a new Java thread initialization and start on the first "ping".
The workflows in simulation and real-time are shown below: