Modbus TCP and RTU is a time sink.

It seems that 1 out of 5 posts on this forum is about some form of Modbus. This is an indication to me that there is a design or documentation error with Modbus XXX,
I/we have found that supporting Modbus XXX is a time sink. There reason why is that the Modbus RTU version is timing dependent and few can implement the timing requirements especially when trying to transmit at rates over 9600 baud. How does one measure 1.5 or 3.5 character times on a PC or PLC? You can't. Another issue is that the specification doesn't cover how REALs, DINTS or DWORD are transferred. It seems that everyone does their own thing and assume it is right and everyone should do what they do.

We took a different approach. We used a Modicon/Schneider PLC as the reference. We can transfer 32 bit values back and forth with Modicon PLCs with no problem. However, not everyone is taking the same approach so often bytes or words need to be swapped around to the format they need.

When Modicon decided their PLC supported 32 bit REALS they should have updated the specifications on byte and word ordering. This was not done so Modicon TCP and RTU are still a pain and a time sink to implement.

There needs to be a new simple standard that at least can send data back and forth on 32 bit boundaries.
 
"There needs to be a new simple standard that at least can send data back and forth on 32 bit boundaries. "

There is - it's called Modbus !!
When Modbus was a PLC manufacturer Modbus was based on simple solid 16 bit architecture; this worked for us, for them and everyone else for decades. The fact that msb / lsb (Most significant bit etc) was the wrong way round compared to Allen Bradley / Rockwell and others PLCs mattered not.

Since then everyone and his dog (including Us !) have implemented slightly different versions using our own evolutionary methods to suit different situations.

So, are you going to scrap Modbus and design a new standard that we (and the rest of the world) can follow: can I suggest you have 32bit and 64bit boundary versions to work to...
 
One of my MOST FAVORITE sayings is:

"The good thing about standards is: There are so many to choose from!!!"

And MODBUS certainly fits that statement perfectly. Is it a time sink? No doubt. But, then, wasn't DOS and isn't MS-Windows, and ... and ... and ... I used to really love my iPhone--because it was intuitive and it just worked. Now? With iOS 14.n.n, it's no longer as intuitive as it was AND it's buggy and doesn't always work; I am closing all open app's at least three times a week and re-booting my iPhone. (I tried going to Android--even bought a Google Pixel phone--but with guaranteed support for only two years of Android updates, it was like buying (paying for!) obsolescence--and some of the app's were just unintelligible. And, the possibility for viruses was also becoming more and more of a worry.) My point is: in my opinion everything these days is becoming more and more complicated and less and less user-friendly. MODBUS, in my personal opinion, has NEVER been that simple or easy. Back in the early days of digital Mark* turbine controls, it was all there was for communicating with the Bailey's and ABB's and WDPF's of the world--and with run-time and compiled versions of some MODBUS apps the Mark* was FOREVER being blamed for communication problems (which were ALWAYS found to be on the DCS/BOP end!!! because GE had their MODBUS standard and the DCS/BOP people had their MODBUS standard(s) and the programmers were ALWAYS trying to get every signal value in the fastest time but their end couldn't take the data as fast as the Mark* could send it--but it was ALWAYS the Mark*'s fault; NOT).

Love it or hate it (I choose the latter, mostly because of the lack of time-stamps and latency), it's around to stay.

And, no one has mentioned OPC!!!! If you haven't played with that, you're in for a real treat.

As always, YMMV! (Your Mileage May Vary)
 
Modbus a time sink - no it isn’t !
Modbus rtu link as the abbreviation suggests started as a modem protocol for remote stations. It just worked.
Using Allen Bradley PLC2/5/SLC5 made the 16bit architecture easy with remote devices whose name / type / manufacture you never heard of - again it just worked !

The last Modicon PLC project I did {before Schneider got involved} had 2 PLC connected via Modbus via non-standard RS422 line drivers. In an area prone to thunderstorms, we catered for comms loss. And Modbus fell over - then on retries recovered without intervention. It just worked. It’s a +35yr old protocol.

As above
If you want something better / faster / equally as reliable, market your own protocol. If successful you might make a name for yourself. I’ve seen Ethernet crashes not caused by lightning but excessive data handling / packet ownership difficulties. I trust this has improved in recent years with IOT / IIOT.
 
There is - it's called Modbus !!
It seems that every 5th thread is about how to implement some for of Modbus. This is an indicator that it isn't so simple.

Since then everyone and his dog (including Us !) have implemented slightly different versions using our own evolutionary methods to suit different situations.
This is OK if you are writing the code for the master and slave but it isn't when you expect your device to play well with others.
That is a huge problem when company A's version doesn't play well with company B's version and the end user is stuck in the middle.

For our part, we considered being able to talk to a Modicon/Schneider PLC to define the standard if the specifications were clear or not defined.

So, are you going to scrap Modbus and design a new standard that we (and the rest of the world) can follow: can I suggest you have 32bit and 64bit boundary versions to work to...
I prefer AB's DF1. It isn't timing dependent. It is better documented, at least it was. The application layer on top of DF1 allowed for a larger addressing space. It could be full duplex if point to point. However, it would be easy to stick any 32 or 64 bit aligned
packets.
 
Your conclusion is in my opinion incorrect; Modbus was implemented to be simple and straightforward, and in the 1980’s it was. By comparison, Siemens ‘library’ comms for the S5 then the S7 were in comparison, horrendous.

Because of this Modbus historically has become one the most famous, well known and popular protocol - note above I previously used the word reliable. I’ve not seen a comparable protocol in those terms. Which is why you see so many posts on this forum. Apart from node address No. there was no coding involved for the then ‘slaves’ which was another reason of increasing popularity.

Think about it - how many intrumentaction manufacturers are there worldwide; each one builds in it’s own comms protocol according to it’s own design criteria. About 30yrs ago this started to happen - no 2 instruments would connect to PLC’s whose own protocol differed by Manufacturer. Modbus was a Godsend ! to then System Builders.

You want convoluted solutions - Modbus was never designed for it !
 
Modbus was implemented to be simple and straightforward, and in the 1980’s it was
No! Explain how one measured 1.5 or 3.5 character times. This is something that was rarely done correctly. Sometimes PLC couldn't transfer a packet without there being way over 1.5 character times between characters because of the scan time.
Our controller would see the gap between characters and think the next character was the start of a new packet. PC had interrupts in the 18.7 ms range which is too slow.

We used DMA to send and receive characters so our controller was always fast enough when sending but not always for receiving at 115.2K baud.

The original Modbus ascii would work but it was slow. Modbus ascii didn't rely on character times to delimit messages. Sending numbers as ascii hex was twice a slow.

Now the big issue is byte ordering for 32 bit values. Again, when it doubt we used the ability to communicate with a Modicon PLC with 32 values as the standard. Other company ignored this and just did what they wanted.
 
"Modbus was implemented to be simple and straightforward, and in the 1980’s it was
No!"
It is a statement of historic fact that you can't change.

Clearly you are not 'listening' to what I am saying. Your last posting is all about speed and what has PLC scan time to do with comms link timing ? In those day 1200baud was the norm with nothing out there able to transmit or receive faster than 9600baud. If there were framing errors we could 'scope them. In my days of UARTs and programming in Assembler {Language}, CPU operation and data transmission / reception were independent of each other.
 
You are the one not listening. How do you measure 3.5 character times back then on a PLC? How do you do it today? If you don't know about the 3.5 character time specification then you haven't read the specifications. There is also a 1.5 character time spec. This is the part that is difficult to implement correctly when using Modbus RTU.

No one has refuted by comments about limited address space, character timing and byte ordering.
 
“How do you measure 3.5 character times back then on a PLC”
YOU DON’T ... In my day it was oscilloscope - now it’s very high speed oscilloscope or high spec data analyser at the baud rates you have quoted. For a fixed baud rate you can work out mathematically character timings, if that’s what you want to do.

In all your postings you haven’t explained what you are trying to achieve.
For the avoidance of doubt
I totally and wholly refute your comments about limited address space, character timing and byte ordering.
Modbus is what it is.

You appear to be involved in computer hardware where speed is of the essence. Modbus was and still is an industrial utility where reliability is a million more times more important than speed.
Sorry we can’t help you more on this subject.
 
“How do you measure 3.5 character times back then on a PLC”
No need to do strictly 3.5. Because: there must be minimal 3.5 character times, so 4 is also good. This is easy to time on a PC.
 
Waiting longer is safer but slower. The real problem is sending the characters without a 1.5 character time gap and at higher baud. Early PCs couldn't do it because the serial chips didn't have a character buffer. Even then the PCs would get busy by someone moving a mouse or accessing a disk and the serial buffer wouldn't get filled in time or they wouldn't read the incoming characters in time. PLCs were often prone to not sending characters within 1.5 character times. Sometimes there would be many millisecond delays as PLCs didn't their house keeping. Modbus RTU was usually more reliable if there was a dedicated CPU enhanced serial card in the PLC rack. I much prefered the Rockwell DF1 protocol because it wasn't timing dependent, it could be full duplex, and it has a bigger addressing space.
I hate Modbus because I/we have wasted so much time trying to help customers with other equipment with poor implementations. Look at this forum. Every week someone has problems with Modbus RTU.
BTW, we used DMA to send characters out so there would be no gaps between characters. Sometimes the PLCs would choke because they didn't implement CTS and RTS handshaking correctly.
 
I wrote my first Modbus stack beginning of the 90's on a 10 MHz AT PC. The 3.5 character timing I solved by programming the 2nd (unused) COM-port to use the double bitrate and then time it to send 7 characters. But although it now was spec-conforming, the slave's implementations I worked with were slower anyway, so the response was always sent much much later than the 3.5 character interval expired.
Keeping the 1.5 character delay was more difficult, but could be solved with some assembly code. And, Modbus is not the only one with such inter-character timing requirements, Profibus/DP has something similar. But I think many Modbus implementations have a state-machine that ingest the header, and then 'know' how much data to expect (or, like in Modbus/ASCII, just swallow everything in until the CRLF is received). No need to wait for 3.5 character timeout.

Finally, the comment that Modbus has problems because there are so many mentioned in this forum... if we would have a forum for another protocol than there would be many questions too. It is not for nothing that Wireshark has dissectors for many industrial protocols, and that lots of companies live of selling (say) Profibus troubleshooting equipment and courses.
 
I think the reason Modbus RTU has so many reported 'problems' and questions is simply because of how predominant it is in industry. I can't think of any vendor that doesn't provide some level of support for it natively. There's really no other protocol like it around. And that it has both a direct serial format, and also an IP version, makes it incredibly universal.

The majority of asynchronous serial protocols have far more complexity around timing requirements than does ModbusRTU. That ModbusRTU almost always works via USB<->Serial / IP<->Serial devices is evidence of this. Try the same with Profibus / DF1 / DeviceNet / other and see how well it works.

The 3.5 char inter message timing is a very common asynchronous frame-oriented message construct. It's not at all difficult to do on a PC. You just have a delay(xxms) in your code before you send a new message.

I don't consider the device number restriction to be significant. It's just the reality of a historical format. It's great that it has such a high limit to start with. Many other protocols used far fewer addressing bits, and only allowed for 16 devices or such. Some (like DF1) extended the protocol to provide for routing information, but this makes the protocol more complex, and for an open protocol like Modbus would have been very difficult to get other vendors to support uniformly.

The data sizing / handling of non-16bit variables is also just a historical factor. You've got to remember that Modbus is of the era of the Atari Model 800 (8-bit) computer. People just weren't throwing around 32-bit integers, or 32-bit floating point values, and hence the protocol designers didn't think about it at the time. That they used 16-bit registers was already quite amazing (instead of just bytes).

To put the complaints in context... I don't hear you complaining about how the Atari Model 800 doesn't support HDMI, or your 1920x1080 colour LCD monitor.
Why doesn't Atari upgrade the Model 800... because there's no financial incentive.
Why didn't Modicon 'upgrade' the Modbus standard.. because there was no financial incentive. They proposed their extensions for how to handle 32-bit values.. they used those extensions in their products. Other implementers did not. Some other implementers proposed their own methods (perhaps you know of Enron?)..

Modbus is really quite amazing (for its legacy). If you really don't like it. Then you could use a different protocol.
 
I am posting these questions, seems like they fit into this topic.
I have a communication link, Modbus RTU at 9.6 KB/s, timeout= 1 sec, polling rate = 0.3 sec, a complete pull of data is done in 3 requests. During 24 hours have 6~10 timeouts, Customer does not like this timeouts even that they are 10 faulty request in 86400 total requests per day. Communication link reports Timeout issue, most of the people says slave is not responding, but this may come from Master from a 3.5 char or 1.5 char Modbus standard violation, but determine the exact cause of this timeout needs an accurate timing tool.
Most of oscillators with it's base cycle can not provide an exact multiple of cycles for the baud rate, 3% deviation I have heard is acceptable, every bit is composed of around 16 cycles of tapped frequency. Every time a byte with its start bit, it syncs with the beginning of other party, but they will finished with some error in every byte, could it be a source of error this difference?
 
I think if most any installation scrutinized an RS-485 bus (outside of lab conditions) to this level, you would find occasional errors. Although RS-485 is quote robust, allowing long cable runs and minimizing the impact of external noise and interference, it's not a perfect system. Of course, the longer the cabling, higher the baud rate, more devices on the network, etc. the worse things can get. Now, that's not to say it's impossible to achieve error-free communications, depending on the conditions and environment. It is certainly a noble sentiment to strive to achieve 100% error-free communications and should be the goal in any installation.

The most likely cause of a timeout error, as you mentioned, is that the slave is not responding. This could be caused by the request being corrupted (by external interference, for example) or incorrectly received by the slave (perhaps the slave was not quite ready to receive the request yet and missed the first byte or two, or a partial thereof). Lack of RS-485 common-mode reference, improper shielding, improper termination, cable length, baud rate, slave processing time, master polling frequency, etc. are all parameters that could affect communications and cause intermittent errors.

If the issue were a timing violation of the Modbus spec, the master would very likely have received partial packets and should instead report a checksum error or invalid packet error of some sort.

You are correct regarding the fact that there is always some baud rate error due to the oscillator frequencies in devices, however, I highly doubt that is the cause of the issue you're seeing. If it were, you would likely have much more frequent errors.
 
I think if most any installation scrutinized an RS-485 bus (outside of lab conditions) to this level, you would find occasional errors. Although RS-485 is quote robust, allowing long cable runs and minimizing the impact of external noise and interference, it's not a perfect system. Of course, the longer the cabling, higher the baud rate, more devices on the network, etc. the worse things can get. Now, that's not to say it's impossible to achieve error-free communications, depending on the conditions and environment. It is certainly a noble sentiment to strive to achieve 100% error-free communications and should be the goal in any installation.

The most likely cause of a timeout error, as you mentioned, is that the slave is not responding. This could be caused by the request being corrupted (by external interference, for example) or incorrectly received by the slave (perhaps the slave was not quite ready to receive the request yet and missed the first byte or two, or a partial thereof). Lack of RS-485 common-mode reference, improper shielding, improper termination, cable length, baud rate, slave processing time, master polling frequency, etc. are all parameters that could affect communications and cause intermittent errors.

If the issue were a timing violation of the Modbus spec, the master would very likely have received partial packets and should instead report a checksum error or invalid packet error of some sort.

You are correct regarding the fact that there is always some baud rate error due to the oscillator frequencies in devices, however, I highly doubt that is the cause of the issue you're seeing. If it were, you would likely have much more frequent errors.
In a Master query, if slave does not see more than 3.5 char of silence in the link, it will not respond, and Master will timeout, and will do next query after, Master can not receive any partial package from slave, slave is ignoring this request for not seeing 3.5 char of silence, I don't understand how can come up checksum error, or invalid packet.
So, about occasional errors, what is reasonable rate of failure for Modbus links?, what about rates for Profibus DP?, are they similar?, do we have statistics?
 
In a Master query, if slave does not see more than 3.5 char of silence in the link, it will not respond, and Master will timeout, and will do next query after, Master can not receive any partial package from slave, slave is ignoring this request for not seeing 3.5 char of silence, I don't understand how can come up checksum error, or invalid packet.
A timeout, by definition, is the master waiting for a response after sending a request (i.e. not transmitting anything more on the bus) and not receiving a response after a given amount of time (typically in the hundreds of milliseconds range). The 3.5 char time is far smaller than the timeout time of the master. Therefore, it is impossible for there to be less than a 3.5 char silence time on the bus while the master is waiting for a response to its request. Note that a Modbus RTU master must send only one request at a time and wait for the response or a timeout.

If the slave were violating the Modbus timing, for example transmitting bytes in its response with more than 3.5 character time between them, this could cause the master to receive several partial packets instead of a single response packet.
 
I go way back. Do you remember modems? I use to use x-modem, y-modem and even Kermit. These modem protocols were simple and not timing dependent. Back when there were Bulletin Board Services your modem had to connect withe the BBS modem. This usually wasn't a problem. The modem protocols were very simple and often multiple protocols were supported. The big difference was usually the packet size and sometimes, how to ack a packet.

Modbus RTU is a pain to support. As someone above said, everyone had there variations but usually they couldn't adhere to the timing specifications. Back when we were using AMD 80186s we used DMA for sending and receiving so the computer was always more than fast enough even at 115,200 Baud.
Few PLCs have DMA and if they do, you don't have access to it.
 
Top