SPI Data Exchange
...
Clock domains and communication cycle
Figure 1 ctc clock domains
Operation of the device includes two clock domains, which run independently of each other. First clock domain is the fieldbus side. Commonly the PLC interacts with the device in one clock domain, where the PLC controls the timing of the output data. Second clock domain is drived by the AC through initiation of the SPI cycle, which reads the output data from the device and updates input data for the next fieldbus cycle. Therefore, a specific timing of the process data is set up as shown in Figure 2 Communication Cycle.
Following data transports occur:
New output data from PLC
Processing of output data in CC module and preloading of SPI transfer buffer
A finished SPI transfer initiated by the AC executes data exchange between AC and CC
Preloading of new input data for the next SPI transfer
A finished sequential SPI transfer executes data exchange between AC and CC, thus providing new input data for the next fieldbus transfer
Figure 2 Communication Cycle
Technical data
Transfer length:
Cyclic only: 72 Bytes
Cyclic + RPC data: 128 Bytes
Baud-rate: min ... maxmax. 10 Mbps, usually 2 Mbps.
Delay between SPI transfers: 0.5 ms ... Heartbeat Timeout (1 second)
Minimal round-trip time: 4 ... 6 ms (depending on the used protocol and setup)
SPI Timing
Following simplified diagram shows basic SPI timing which must be considered by the application controller.
Figure 3 Basic SPI timing
SPI Speed
The communication module supports SPI speed in the range of 29.3 kHz and 10MHz. Default SPI speed is 2MHz.
...
In Figure 3 Basic SPI timing, the communication scheme between AC and CC is shown. Following time needs to be considered by the Application Controller during communication.
: the SPI Setup Time .. Time - the time between activation of the module using the Slave Select signal and first data
The SPI Setup Time - must at least be 10ns, before the module accepts data over SPI.
...
The SPI frame must contain the structure from Table 118: SPI Frame Structure to get accepted by the irj45 module.
Bytes | Byte | Byte | Bytes | Bytes |
Fletcher-16 | Sequence | Data Length | Cyclic Data | RPC Data |
Table 18 SPI Frame Structure
The same layout is send back by the device containing its local sequence counter. The sequence counter is tracked and if it doesn't change during the heartbeat timeout the communication gets stopped until the sequence is updated again.
...
To calculate the Fletcher-16 checksum the this Wikipedia entry https://en.wikipedia.org/wiki/Fletcher%27s_checksum#Example_calculation_of_the_Fletcher-16_checksum can be used. Start index is byte 4 and end is at 127. After the calculation the value 0x0007 needs to be added to not have false positives if the whole area is set to zeros. In the frame the value has a width of 16 bit and needs to have the little endian encoding.
...
The RPC frame must contain the structure from Table 119: RPC Frame Structure to be accepted by the irj45 module.
Bytes | Byte | Byte | Byte | Byte | Bytes |
Fletcher-16 | Local | Remote | Data | Flags | Data |
Table 19 RPC Frame Structure
Each time a new local sequence is sent the irj45 will respond with the corresponding acknowledge in the second transferred frame. If no acknowledge was received the AC can retransmit its frame to re-request the acknowledge.
...
To calculate the Fletcher-16 checksum the this Wikipedia entry https://en.wikipedia.org/wiki/Fletcher%27s_checksum#Example_calculation_of_the_Fletcher-16_checksum can be used. Start index is byte 6 and end is at the included data length. After the calculation the value 0x0007 needs to be added to not have false positives if the whole area is set to zeros. In the frame the value has a width of 16 bit and needs to have the little endian encoding.
...
Bit | Bit | Bit | Bit |
Sync Request | Sync Acknowledge | Reserved | Request Acknowledge |
Table 20 RPC Header Flags
Sync Request
If set to 1 the irj45 module enters the RPC synchronization.
...
AC | irj45 Module |
Sync Request = 1 | |
Sync Request = 1 | |
Sync Request = 0 | |
RPC_Receive() | |
RPC_Receive() | |
RPC_Receive() |
Table 21 RPC Synchronization
After the synchronization has finished the irj45 both devices must initiate the generic RPC call SetupStateGet to verify if the partner device is in the same state. If one partner is already configured but the other is not, than the configured parter must reboot and the synchronization starts again.
...
Byte 0..1 | Byte 2..5 | Byte 6 .. x | Byte x+1 .. x+4 | Byte x+5..x+8 | Byte x+9 | Byte x+10 | Byte (x+11) .. (x+14) |
Static Identifier | Data Length | Data | Function Id | RPC Id(little endian) | CTC Id | Flags | Fletcher-16 |
Table 22 RPC Request Structure
Byte 0..1 | Byte 2..5 | Byte 6 .. x | Byte x+1 | Byte x+2 | Byte (x+3)..(x+4) |
Static Identifier | Data Length | Response Data | CTC Id | Flags | Fletcher-16 |
Table 23 RPC Response Structure
Static Identifier
The 2 byte static identifier is used on the irj45 module to detect the start of a new RPC request or response. If the identifier is also contained in the data bytes the Fletcher-16 checksum will make sure that it don't gets threaded like an RPC request/response.
...
Bit 0..1 |
0 – Response1 – Request |
Table 24 RPC Request/Response Flags
Data
The data part contains the virtual stack of the RPC request/response.
...
To calculate the Fletcher-16 checksum the Wikipedia entry https://en.wikipedia.org/wiki/Fletcher%27s_checksum#Example_calculation_of_the_Fletcher-16_checksum can be used. Start index is byte 16 and end is at the included data length. After the calculation the value 0x0007 needs to be added to not have false positives if the whole area is set to zeros. In the frame the value has a width of 16 bit and needs to have the little endian encoding.
...
Parameter | Description |
GOAL_PNIO_T *pPnio | GOAL PROFINET instance |
uint32_t idMiDmPeerFrom | Handle that receives data from CC |
uint32_t idMiDmPeerTo | Handle that sends data to CC |
GOAL_MI_DM_PART_T **ppPartDataOut | Output pointer to store the DM partition |
GOAL_MI_DM_PART_T **ppPartDataIn | Output pointer to store the DM partition |
uint32_t idApi | API id |
uint16_t idSlot | Slot id |
uint16_t idSubslot | Subslot id |
uint32_t lenDataOut | Output data length |
uint32_t lenDataIn | Input data length |
Table 25 goal_pnioDmSubslotAdd API Description
Map Subslot IOCS/IOPS - goal_pnioDmSubslotIoxsAdd
...
Parameter | Description |
GOAL_PNIO_T *pPnio | GOAL PROFINET instance |
uint32_t idMiDmPeerFrom | Handle that receives data from CC |
uint32_t idMiDmPeerTo | Handle that sends data to CC |
GOAL_MI_DM_PART_T **ppPartIocsOut | Output pointer to store the DM partition |
GOAL_MI_DM_PART_T **ppPartIopsOut | Output pointer to store the DM partition |
GOAL_MI_DM_PART_T **ppPartIocsIn | Output pointer to store the DM partition |
GOAL_MI_DM_PART_T **ppPartIopsIn | Output pointer to store the DM partition |
uint32_t idApi | API id |
uint16_t idSlot | Slot id |
uint16_t idSubslot | Subslot id |
Table 26 : goal_pnioDmSubslotIoxsAdd API Description
Map APDU Status – goal_pnioDmApduAdd
...
Parameter | Description |
GOAL_PNIO_T *pPnio | GOAL PROFINET instance |
uint32_t idMiDmPeerTo | (ignored) Handle that sends data to CC |
GOAL_MI_DM_PART_T **ppPartApduOut | Output pointer to store the DM partition |
Table 27 goal_pnioDmApduAdd API Description
Map Data Provider Status – goal_pnioDmDpAdd
...
Parameter | Description |
GOAL_PNIO_T *pPnio | GOAL PROFINET instance |
uint32_t idMiDmPeerTo | (ignored) Handle that sends data to CC |
GOAL_MI_DM_PART_T **ppPartDp | Output pointer to store the DM partition |
Table 28 goal_pnioDmApduAdd API Description