No, in the example you have provided, this is not always guaranteed. Our OPC client part does not rearrange the order of incoming notifications, but on the OPC communication level, they may already be ordered differently from what their true sequence was.
Leaving aside the communication between the OPC server and the PLC, and the way the OPC server is implenmented (for which both you will need to contact the OPC server vendor), order can be different e.g. precisely due to the factors you have mentioned (the sampling and publishing interval). And, even if both items were on the same OPC subscription and with the same parameters, I am not aware of a clause in the OPC specs that would strictly require the order be kept.
If keeping the order is important, I can think of following approach:
- Based the logic not on the order of notifications, but rather than on the source timestamps. This will require to delay the actual processing by certain amount, so that the incoming notifications can be sorted. And, the value of that delay will then become a critical parameter that "somehow" needs to be guaranteed (which will require precise analysis of all the communication path between the source and receiver to see what the maximum delay might be - if possible at all).
- Use some kind of handshaking (additional nodes) and algorithm to assure the ordered delivery. This would, effectively, change the logic you have described (and will require changes on the PLC side).
Best regards/MfG
