I have the T3E-886 polled by a Modbus/RTU master.
The master repeatedly requests 32 registers, starting at address 100.
Every so often I notice that the T3E starts sending a reply packet, but then makes a ~40ms pause mid-packet.
Modbus/RTU does not allow any gaps in the byte stream within a packet.
I also notice that the RTU ‘-’ signal is not driving the full 5V even though my bus us not loaded at all. This appears the same on both my (new) units. However this makes it very clear in the attached capture that our master times out on the interrupted packet and sends the next poll in the middle of the second part of the reply packet.
Obviously I can adjust timing in the master, but the root problem here is the non-consecutive bytes from the T3E.
Reading 32 registers: Have you tried the block read function, that will reduce the overhead a lot and hopefully smooth out the glitches. If that is not possible the only other option is to slow down the polling rate. The devices do a pretty good job of keeping up with rapidfire polling but there are limits.
Voltages: Its the differential voltage you are interested in plotting. A - B signal should be 1.5 to 5V for high and +/- 200mv for low. If you are seeing unexpected voltages you could try adding EOL resistors, in my experience they’re optional in smaller networks.
Firmware version: I dont know off hand what the latest version is but when you’re having trouble its always a good step to update to the latest. You can do that by firing up T3000 and navigate to help → check for updates → download & update firmware.
We’re reading the 32 registers all in one block, using Modbus command 0x03 (Read Holding Registers). Is there a more efficient way?
I agree that the differential between A and B is what’s most important, but typically you’d expect both A and B to swing between 0 and 5V in reference to the common. Please see the attached captures. The top two rows are logical levels, and the bottom two are the analog levels. In this case the weak drive on the second leg helps us identify the issue. In the last capture you can clearly see our master sending the next request on top of the second half of the reply from the T3E.
Using the T3000 software, it identifies the firmware version as 6.7. Looking at updates, the revision list shows the most recent as rev 64 (no dot). There is no version 6.7 in the revision log. I’m assuming “6.7” is newer than “64” ?
Hi Maurice,
I have a theory of what might be going on.
The -886 saves the output state in NVM so that it can reload the previous state after a power cycle - good feature.
I find that the above described glitch happens shortly after any write to change an output state. It often happens exactly 1000ms after the write, but sometimes longer.
Could it be that the write-to-NVM function has higher priority than the UART sending data? That would explain the split packets.
Also, please clarify if 6.7 is the most recent firmware version, and how it relates to the version numbering in the revision log.
The latest firmware is rev68, the recent changes to these versions are not particularly significant. The serial communication part is the same in all versions. Indeed, as you said, if the output changes, we will write flash. It will definitely cause the serial communication to pause.
However this is a serious departure from the Modbus specification and will cause communication errors.
Per the spec (see attached extract), any gap longer than 1.5 character times within a packet cause the recipient to discard the message.
The behavior of the -886 further complicates the issue by continuing to send the remainder of the packet several 10’s of milliseconds later. This not only cause an error in the communication with the -866, but also interferes with other devices on the same bus.
I’m hoping you consider addressing this in the near future as this is preventing us from using the device as it stands.
I’m very curious about your application. The write flash function is only activated when the output value changes. Even if the flash is written once every 5 seconds, we only occasionally encounter the situation you mentioned. Under normal circumstances, this fault tolerance rate should be completely acceptable. Therefore, I’m not sure if there are other factors causing the communication interruption.
I agree that the master should be resilient and recover from comm errors. After all it is a serial bus, and errors must be expected.
I do not think it is acceptable that a device knowingly transmits out-of-order though - even if it is only after outputs change state.
It would be less severe if the transmit buffer was cleared completely during the flash write. This would avoid the T3E stepping on other device’s communication, and just cause an incomplete packet error for the master.
I notice this issue happens after changing relay output states, and also after changing the analog output values. One potential use for the analog outputs is for some form of PID control, and that would require very frequent writes to change the output value, consequently causing a lot of errors
Interestingly, the analog outputs do not restore their state after a power cycle. The relay outputs restores, but not the analog outputs. Is this intentional?
May I suggest making the write-to-flash/output-state-recovery optional? I imagine that most applications where there is a master controller, the master unit will keep state and restore all devices as needed after a power cycle. At least that’s how our systems work.
FYI, we also tested /TCP, and did not find any issue while using that communications mode.
Chelsea bumped up the polling rate to 200 ms and she increased the writes to one every 5 seconds. The communications was still hitting above 99%. What would you consider is acceptable, we will see what we can do.
PID: You need to be careful with a lot of writing, the flash has a life of something like 1million writes. That would be 2 years at one minute write intervals, worst case scenario where a new value is written each time. When you send a value is the same as before this doesn’t count as a write cycle so in a normal HVAC application where things are not changing that fast even with a PID loop, we havent seen flash failures as an issue.
Proposed New Feature: Power Up State for outputs
last <Whatever they were at when power went off.
default <Off for relays, 0V for analog outputs.
I very much appreciate the support from you and Chelsea! Thank you!
Noted about the flash-wear and writes.
That would be a good reason to have the option to turn off state-recovery - in case we’d want to use the device in an application requiring frequent adjustments, like a PID.
I have not tested it, but I guess the same thing happens when writing configuration registers (like input mode). I can’t see a reason those would change frequently, so I think we can live with that.
As for error statistics, we’ve implemented support for hundreds of different /RTU devices over the last 15 years, and in a bench-top system where there is no significant external interference I would expect less than one error per million packets. We have actual installations running for years with no bus errors.
Good discussion and thanks for all your detailed troubleshooting. We have marked down a future reature to disable the flash writes for power up state. Chelsea will work on it when we have a moment. If you have any experience with C programming you could work on it and we’ll merge your changes, the repo is here:
