VIPA CP143 TCP/IP, Руководство пользователя

Страница: 64 / 210

CP143 TCP/IP firmware CP143
H1 / TCP/IP manual
4-16 Rev. 00/07
4.3.3 Further information on the CP143 TCP/IP
4.3.3.1 System properties
The system properties of a CP must not be regarded as limitations or as design faults. Instead,
certain functions may not be accessible or they are purposely removed for the security of the overall
system.
•
The run-up time of the CP143 TCP/IP is app. 10 seconds. For this reason the requirements of
balanced syncronization characteristics (an HTB synchronization module waits between 8 and 10
seconds, depending on the type of CPU) can not be met. Thus the start-up OBs 20-22 must
perform the following actions:
−
poll the PAFE of the HTB in synchronous mode until this becomes 0. After 10 seconds
the tile will be set to active by the CP.
−
If the synchronous HTB still detects a PAFE after 15 seconds then the PLC, the
configuration of the PLC or the CP is incorrect. In this case the respective configuration
must be checked.
•
Depending on the sequence in which the synchronous HTBs were initiated, the CP may detect a
synchronous request and re-boot when more than one tile of a CP must be synchronized. Under
these conditions the CP would never be synchronized. Cure: use the respective switch to STOP
the CP, then synchronize all the required tiles. Change the switch back to RUN. At this point the
CP has been synchronized. This is reaction of the system can only occur during commissioning,
and then only, if the number of tiles of the CP is increased and the new synchronous HTB is not
accessed as the last one in the sequence.
•
The joker size (-1, 0xFFFF) is not permitted for the length of the ORG-format, the application (in
this case the PLC user) must specify the length of the receive data exactly.
•
Tasks having a priority of 1 can only send and/or receive the amount of data as defined by the
synchronous HTB. Tasks of this type are not blocked. This results in a maximum data transfer
rate of 512 bytes per task and a block size of 255 (see also block size).
•
RECEIVE tasks, that are mirrored as broadcast communication, can not receive all data messages
from a fast cyclic transmitter. Messages that have not been received are discarded to protect the
system.
•
The TCP/IP protocol stack has a global pool of buffers that contain the receive and transmit
buffers. It is possible that system collisions occur in this area if:
−
the data for a receive task was not retrieved. After a certain period of time a lack of
resources occurs, and other connections will issue disconnects once the respective
predefined time-out has occurred. Proper communications will only be possible once the
receive buffers of the original connection have been released (termination) or when the
available data was retrieved by means of the RECEIVE HTBs.
−
one or more cyclic transmitters place a heavy load on the CP. The CP will also terminate
connections when a lack of resources occurs.
−
a transmitter has sent two or more messages and the receiver did not have the opportunity to
retrieve them. In this case the unknown type of data would cause a collision in the receiver.
The CP does not permit that this situation occurs. The PLC application demands a definite
receive size which excludes the joker-size. The receive size of prio 0/1-RECEIVE tasks is
set implicitly by the defined block size (16, 32, 64, 128, 256, 512 bytes).