I'm doing some benchmark testing on MQTT DCMD to PLC write times.
I send a spBv1.0 DCMD message to a Transmission Gateway, which then writes a value to a tag T1. The tag path and tag value are in the message payload. The value is a usec Unix Epoch generated when publishing the message. The payload and metrics timestamps are generated at the same time (just before the payload) and are msec Epoch timestamps.
The PLC receives this value in T1, and copies it to a tag T2. Both Ignition tags are in a Tag Group called DCMD which is basically the Default + Optimistic Writes (no read after write) and 100ms poll time.
The Ignition GW and HiveMQ broker are both running in docker containers, and the MQTT message is published from the host. There's ~50000 usec time difference between the host and containers.
Here's a sample of the results:
Epoch Payload: 1745871572223060
T1 Timestamp : 1745871572230000
T2 Timestamp: 1745871570200000
This shows that the PLC copied the T1 value to T2 about 2 seconds before it got there. So time travel, right?
And because time travel would not be fun without being able to control it, I seem to be able cause some gating affect by changing the Optimist Write Time to 0 or -1 (thinking that would disable it), and doing that skews the T1 time so it's Timestamp is about 2 seconds before the value in the payload. Time travel control!!
Well I'm skeptical and at the very least my time machine needs some peer review.
EDIT: It just occurred to me that a much more simple test (with no MQTT, no DCMD) is to just use the Tag browser. So if write some value to T1 in the designer tag browser, T2 ends up with a timestamp ~2seconds before T1.
EDIT2: Forgot that Ignition is not getting the tag directly from the PLC, but from a Rockwell FTL OPC-UA server. The clock on that machine is about 2 seconds slower than Ignition's clock 