When using the Basic project profile in BCS Tools 3 tasks are created.
MainTask
ExternInterruptTask00
TimeInterrruptTask00
Since the priority is within the range 0-15 all tasks are handled as
realtime tasks. (For more details regarding Task priority and scheduling see
related links.)
What is not seen in the project is that there is an
additional task called ConfigurationTask, this task handles services in the
backplane like "Read module diagnostics", "Send module parameters",
"Communication with NX5000 module", etc.....
This task has Priority 4 and
executes cyclic with an interval of 4 - 30ms depending on the amount of I/O
modules installed -> it will interrupt the MainTask.
This is an
example of why the communication processing of the NX5000(ethernet) module is
handled by the ConfigurationTask. Imagine that the application executed by the
MainTask takes approx 100ms to execute.
To maintain a good communication
performance the ConfigurationTask keeps interrupting the MainTask to ensure a
good communication bandwitdh with the NX5000 modules.
How is the I/O update synchronized
with the user program?
The I/O update is synchronized with
the MainTask and it is divided into three parts.
1. Read Inputs, CPU
sends an EtherCAT frame to get the inputs from the mounted modules
2.
Execute the POU:s associated with the MainTask.
3. Write Outputs, CPU
sends an EtherCAT frame to set the outputs to the mounted modules
When using additional tasks like a time interrupt task the I/O update is not
performed, if an I/O update is required in tasks you have to use the
REFRESH_INPUT/REFRESH_OUTPUT instructions located in the NextoStandard
library.
NX5001, Profibus DP Master.
The NX5001
works like a regular I/O module, however in this case the I/O image is much
bigger (while a regular module can have a few bytes of I/O, NX5001 can handle
up to 3584 bytes for inputs and 3584 bytes for outputs.
In the begining of
the MainTask (before running the user code), the CPU reads the input image from
NX5001, the same thing happens in the end of MainTask (after running the user
code) for the output image.
The Profibus DP scan is carried out in a
asynchronous mode totally indpendent of CPU<->NX5001 local bus scan.
NX5001 scans all Profibus DP slaves and store the input/output image into a
triple buffer scheme (internal to NX5001),
meaning that CPU can access
this data anytime without any need of waiting (data is always ready).
Consistency issues?
Since PROFIBUS has no support for 32-bit, the only way to achieve this is
mapping the information into two standard 16-bit channels.
This is a
standard practice found on several slaves. Regarding the consistency,
theoretically you would only have problems if these two 16-bit parts
could be accessed separately and asynchronously.
However this is
impossible.
- Data update on PROFIBUS Slave: the servo ensures that
these 2 16-bit parts will be updated on PROFIBUS Slave chip memory at the same
moment.
- NX5001 reads the inputs from the servo: all the inputs from that
slave will come in one same PROFIBUS telegram. (no way to read each 16-bit part
individually)
- CPU reads the inputs from NX5001: all the inputs (from all
slaves) are read in the same moment on MainTask before the execution of user
program.
MODBUS Master/Slave, DNP3These protocols (MODBUS, DNP3 and any other future similar protocols) runs on
low priority ("normal" scheduler, non-real time). It means that they only run
when MainTask is not running.
They will only update data (%I, %Q or
Symbolic Data) when MainTask is not running, because they can not "wake up" and
execute during the execution of MainTask.
However, there is a special
case: MainTask can start to execute exactly when MODBUS is updating data
(because it is real time and can interrupt the MODBUS task).
The
consequence is that if MODBUS Master (for example) is performing a read command
of 125 Holding Registers, the MainTask can interrupt it in the middle of this
update so it may see some Holding Registers with value of previous polling and
some withe the value of the latest polling.
In this special case there is
an interlock implemented to lock MainTask execution when MODBUS is updating a
mapping data. Each mapping can have maximum of 250 bytes, in practice it will
take a few microseconds to copy this data.
MODBUS data is never
updated in the middle of MainTask execution (cycle time).