Controller Communication Interaction with Control Data
The controller runs the communication task separately from the application code. The controller runs communication asynchronously to the application. Therefore, it is important to make sure that communication that is delivered to the controller is complete before the application executes on the newly delivered data. This applies to data that is coming into the controller and data that is going out from the controller.
For example, if an HMI device writes a large block of recipe data to the controller, the application code can start to execute on that data before the data is written. This action results in half of the current recipe and half of the last recipe in the application space.
You can use the following methods to control the effects of asynchronous communication. Blocking access helps to prevent source data values from changing by communication during application execution. Allowing access means that communication can change source data values during application execution.
Application Construct | Tag Access | |||||
|---|---|---|---|---|---|---|
HMI | MSG | I/O Update | Produce/Consume | Other User Tasks | Motion Planner | |
UID/UIE | Allows | Allows | Allows | Allows | Blocks | Allows |
CPS | Blocks | Blocks | Blocks | Blocks | Allows | Allows |
Periodic Task | Allows | Allows | Allows | Allows | Allows | Allows |
These options rely on controlling when the main core can switch tasks. As a result, the communication task cannot change data when the control task is using it. Because the controller processes communication on an independent CPU core, these methods are no longer effective in all cases.
Because the controllers have 32-bit data integrity, this only applies to data structures larger than 32 bits. If word-level integrity is your primary concern, the 32-bit data integrity does not impact your data use.
Good programming practice dictates the use of two unique words at the beginning and the end of data. The controller validates the words to assure the entire structure has data integrity. We recommend that the handshake data is changed and the application code validates it every transaction before the controller application code or higher-level system reading controller data acts on it.
The following table shows that two data elements added to a structure for data integrity checking: Start Data and End Data. We recommend that the controller validates the Start Data value and the End Data value match before the controller acts on My_Recipe1.
If the Start Data and End Data values do not match, it is likely that communication is in the process of filling the structure. The same applies to higher-level systems that are receiving data from the controller.
Structure | My_Recipe1 | My_Recipe2 | My_Recipe3 |
|---|---|---|---|
Start Data | 101 | 102 | 103 |
Sugar | 3 | 4 | 8 |
Flour | 4 | 3 | 9 |
Chocolate | 2 | 2 | 4 |
Oil | 6 | 7 | 2 |
End Data | 101 | 102 | 103 |
TIP:
We recommend that you perform this test on a buffered copy of the data and not the actual data element being written to by the communication core. If you use buffered data, you help prevent the risk of the communication core changing data after you have passed the data valid test.
Provide Feedback