User guide

17
VTB USER GUIDE
5.1 Task Plc
This task is the higest priority one: it is deterministic and run at fixed time making it suitable to manage situation that
need a fast and precise response time. This task can not be interrupted by no other tasks but it can instead interrupt any
other. Normally it is used by AXIS CONTROL OBJECTS or fast PLC cycles, but it can contain every type of code sequence
exluding some IFS functions like:
GRAPHICS FUNCTIONS
AXIS INTERPOLATION (xxx.MOVETO, xxx.LINE_TO)
MANAGE OF CANOPEN SDO.
STATIC CYCLES
(see the single functions for details)
The typical sample time is 2 milliseconds wich is an enough time to manage a lot of application (for example 6 AXIS
interpolation), however it can go down also under 1 millisecond when the charge of work is less stressful and for CPU
with high computing power. In this task is also managed the CAN OPEN and ETHERCAT protocol in DETERMINISTIC mode.
However it is advisable that its elapsed time doesn't exceed 60% of sample time, else we risk to slow or even to stop
the other tasks. The TASK PLC HASN'T A SECTION TO INSERT ANY OBJECT, therefore if there is some code wich have to
run inside, it must be written at the moment of object design. IF THE CODE INSIDE TASK PLC BLOCKS IT ALL SYSTEM GO
IN CRASH.
To verify the elapsed time of TASK PLC there are two field in DEBUG.NET application:
PLC TP and PLC TM never must exceed the sample time.
VTB defines some
NOTE ON CONCURRENT PROGRAMMING
The use of CONCURRENT programming requires particular WARNING as in all MULTITASK systems. To avoid unexpected
operation it's recommended do not call the same function from INTERRUPT TASKS and COOPERATIVE TASK in the same
application. In other words the functions managed by MAIN TASK can be called without problems from PAGE TASK, but
NOT ALSO from TASK TIME e TASK PLC and vice versa.
That is because if an INTERRUPT TASK using a function occurs exactly while a COOPERATIVE TASK is running in the same
function, that could lead to abnormal operations in the application.
SHARING OF VARIABLES
Again in CONCURRENT programming can also occur some problem when variables are shared between INTERRUPT
TASKS and COOPERATIVE TASK. Practically if managing of the variable don't provide an ATOMIC ASSEMBLER
INSTRUCTION, this can cause false reading value when it is written by a TASK and read by another. According to the CPU
type of the system these problems can occur in the following type of variables:
Sistem
Variable type
32 bit
FLOAT
To overcome this problem VTB offers the possibility of a SECURE SHARING OF VARIABLES. Indeed in the variables
declaration dialog there is an apposite field to enable the secure sharing. However, because a lot of use of this facility
can generate jitter problem we recommend to use the enable of secure sharing of variables only when ABSOLUTELY
NECESSARY.
The same problem could also occur when using data array shared by more process. A simple example can be the use of
array to data exchange in MODBUS protocol. These problems can arise when, for example, the writing process of data
and the reading one are asynchronous. It can happen indeed that a reading process starts when the writing one has
filled the array only partially. In this case the reading process will read a lot of new data and some from the old scan. It's
evident in this situation false value readings can occur. System isn't able to understand these situations therefore to
solve it there is the needs of semaphores at application level.
Task plc has also an INIT section. All code insert here will run only one time at system reset.