Freelance mixed process image access (e.g. for UDP send/receive)
Having read the Freelance engineering manual and the question "pro and contra of variable process image", some questions still remain, especially when using the UDP send/receive blocks (SR_USEND and SR_URECV).
I'd be glad about a little guidance or a best practice regarding process image access with those FBs. (We're not talking time critical here.)
The thing is, those blocks need to have direct access. What I presently do is, in the case of SR_USEND, fill the components of a structured type instance with data (double words) using process image access (@) and then feed the instance directly (no @) to SR_USEND. Similarly, with SR_URECV, I let the FB write to the instance directly (no @) and then extract the components over the process image (@).
In this setup, you always get access warnings during check (depending on the variable definition). Are there arguments for or against this approach, namely direct access by FB and process image access elsewhere? My main concern is about inconsistencies in the data, albeit I strongly suspect double word accesses to be atomic, i.e. a mid-update read of a double word (yielding half old, half new data) doesn't seem to be possible.
Thanks for your suggestions.
Best regards
Björn
Voted best answer
Firstly, the data consistency of basic data types (like DWORD) is implicitly guaranteed. The data consistency of the complete structure not implicitely guaranteed but needs to be explicitely secured by you, by having the SR_USEND FDB in the same task where you load its elements. Same is true for the SR_URECV and extracting the data,
When you load the elements of a structure using the process image (@), but feed the structure directly to the SR_USEND FB, the content of the global Variables is sent, which does not contain the changes from the process image yet. The process image changes are written back to the structure at the end of the tasks processing. That means, you are actually sending the previous state of your structure. The current state after copying the process image back is send next time.
In the receiving station you also have a delay.
1. The structure elements using a @ are copied to the process image (note this are from the previous receive)
2. The data gram with new data is received in the global variables
3. The extraction happens using the old copied values in the process image
4. The process image is written back to the global variables. Because you only read from the structure the newest received values (not processed yet) are not overwritten
That means, the data get one task cycle delay from the sending station and one task cycle delay from the receiving station before they land in the final variables.
If that is a problem, you would need to use the structure elements without the process Image (not using @), but then you get a warning in case of a redundant station
Hope that helps
Add new comment