Rockwell Automation 20B PowerFlex 70, PowerFlex 700 Reference Manual - Manual (Page 93)

DPI
Rockwell Automation Publication PFLEX-RM001H-EN-P - June 2013 93
so support of message fragmentation is not required. The following types of
messaging are covered:
•
Drive status (running, faulted, etc.)
•
Drive commands (start, stop, etc.)
•
Control logic parsing operations (e.g., mask and owner parameters)
•
Entering Flash programming mode
•
“Soft” login and logout of peripheral devices (enabling/disabling of peripheral
control)
Peer-to-Peer operation
Peer-to-Peer messaging allows two devices to communicate directly rather than
through the master or host (i.e. drive). They are the same priority as C/S
messages and will occur in the background. In the PowerFlex 70 drive, the only
Peer-to-Peer functionality supports proxy operations for the LED HIM. Since
the PowerFlex 700 drive does not support an LED HIM, it will not support
Peer-to-Peer proxy operations. The Peer-to-Peer proxy operation is only used so
that the LED HIM can access parameters that are not directly part of the
regulator board (e.g. DeviceNet baud rate, etc.). The LED HIM is not attached
to a drive through a CAN connection (as normal DPI or SCANport devices are),
so a proxy function is needed to create a DPI message to access information in an
off-board peripheral. If an LCD HIM is attached to the PowerFlex 70 or 700
drive, it will be able to directly request off-board parameters using Peer-to-Peer
messages (i.e. no proxy support needed in the drive). Because the PowerFlex 70
supports the LED HIM, only 4 communication ports can be used. PowerFlex
700 drives can use all 6 communication ports because Peer-to-Peer proxy
operations are not needed. All Peer-to-Peer operations occur without any
intervention from the user (regardless whether proxy or normal P/P operation),
no setup is required. No Peer-to-Peer proxy operations are required while the
drive is in Flash mode.
All the timing requirements specified in the DPI and SCANport System,
Control, and Messaging specifications are supported. Peripheral devices will be
scanned (“pinged”) at a 10ms rate. Drive status messages will be produced at a
5ms rate, while peripheral command messages will be accepted (by the drive) as
they occur (i.e. change of state). Based on these timings, the following worst case
conditions can occur (independent of the baud rate and protocol):
•
Change of peripheral state (e.g. Start, Stop, etc.) to change in the drive – 10ms
•
Change in reference value to change in drive operation – 10ms
•
Change in Datalink data value to change in the drive – 10ms
•
Change of parameter value into drive – 20ms times the number of attached
peripherals
The maximum time to detect the loss of communication from a peripheral device
is 500ms.