Talk:Modbus

message: I went to the site, and I can say it contains nothing useful from encyclopedic point of view. This link belongs to 'yellow pages'. Deleting. --matusz 09:32, 15 Oct 2004 (UTC)
replies: text: Count the devices. A reference refuting the statement would be most welcome. Modbus is everyone's second-favorite protocol (with their own, proprietary, superior protocol being offered to their customers who are englightened enough to realize that one vendor has every solution they could ever possibly need). I suspect that its popularity is due to being available royalty-free, though I have no reference for that. There's no such thing as a "Modbus" salesman any more than there's an "Ethernet" salesman.  --Wtshymanski 13:34, 26 August 2006 (UTC)

text: I agree with Jimwelch. I'll try removing the warnings and see if that edit sticks. If not, then I'd like more specifics about exactly what wording is objectionable. RussNelson (talk) 20:11, 31 January 2013 (UTC)
thread_title:  Neutral point of view 

message: Paragraph 1: "Modbus is a serial communications protocol...."
Paragraph 3: "Suppliers large and small, .... can become Modbus members."
80.45.129.137 (talk) 17:37, 2 December 2010 (UTC)
replies: text: Good remark. And the answer is: (a) Modbus is a protocol, while Modbus Organization is ... right, the organization, and (b) I clarified this point in the article. --Marius 12:20, 1 February 2011 (UTC)
thread_title:  Protocol or society? 

message: Why has the section on Modbus Protocol Variants been removed? My first introduction to Modbus was via this article, and the section on protocol variants was very useful in developing my understanding. I feel the article is much less useful and informative as a result of removing this section. 
Also, there is now no indication (except in passing) of how Modbus sits within a protocol stack. There is only reference to Modbus  over TCP/IP in passing, and no reference to RS485 as a physial layer for ModbusRTU. 
Stevegoobermanhill (talk) 12:33, 28 August 2013 (UTC)
replies: text: Yes. I just reviewed, and the October 2011 version of this article is better than the current version.  — Preceding unsigned comment added by 124.189.182.242 (talk) 11:53, 7 July 2015 (UTC)
replies: text: Reverted the 2013 vandalism that deleted that section  — Preceding unsigned comment added by 203.206.162.148 (talk) 11:48, 28 September 2015 (UTC)
thread_title:  Protocol Variants and Stack 

message: 6.1 example for response to function code 1
If data example is: 1010 0111 011(0 0000) last digits not requested,
the output is "E5 06" and not "06 E5".
84.144.140.73 (talk) 11:08, 13 June 2016 (UTC)
thread_title:  error in chapter 6.1 

message: The article here is pretty bad, looks like it came from someone's preliminary data sheets for a product or something, it actually lacks enough information to be useful. The whole article is pretty useless. What would salvage the article is some examples, in hex, data streams of commands and responses showing holding registers being requested and retrieved, coils being turned on or off, if they're controlling IO, a break down of addressing is what would help the most. As it is, the article likely could be removed from Wikipedia as useless. SoftwareThing (talk) 19:02, 2 October 2018 (UTC)
thread_title:  Some examples would help 

message: I'm currently writing a ModbusRTU implementation in C on an embedded device (STM32) and often get extremely curious about some aspects of the protocol that don't seem to be mentioned in the public specification.
For example, function codes in the range 1-65 are "public" (though some are "unassigned function codes reserved for future use"), but the defined ones seem to frequently "skip" values such as 9-10, 13-14, and 18-19. I found names for these in the "Modicon" spec (http://modbus.org/docs/PI_MBUS_300.pdf):
:9: "Program 484"
:10: "Poll 484"
:13: "Program Controller"
:14: "Poll Controller"
:18: "Program 884/M84"
:19: "Reset Comm. Link"
However, these seem like specialized, "private" functions. So why are they in the "public" space? Is there some historical reason?
Jrquant (talk) 22:13, 16 July 2019 (UTC)
thread_title:  Possible to add more about history / background / motivation? 

message: Under the "Modbus Plus" section we read:
But Modbus Plus is still listed under the "Protocol versions" section. Which is it?
93.66.24.54 (talk) 17:27, 9 July 2019 (UTC)
thread_title:  Modbus Plus, different protocol or not? 

message: The current procotol version V1_1b3 states the following:
* "TCP MODBUS ADU = 253 bytes + MBAP (7 bytes) = 260 bytes."
A total of 253 bytes for a Modbus PDU means that up to 125 registers can be read (there are no extra CRC bytes required for TCP connections). With function code 0x03 (Read Holding Registers) or 0x04 (Read Input Registers), the RESPONSE message size calculation is as follows:
253 bytes
- function code (1 byte)
- byte count (1 byte)
= 251 data bytes 
This is equal to 251/2 = 125 registers.
The calculation is slightly different for function code 0x10 (Write Multiple registers). Here, the REQUEST message size can be calculated by:
253 bytes
- function code (1 byte)
- starting address (2 bytes)
- quantity of registers (2 bytes)
- byte cound (1 byte)
= 247 bytes
This is equal to 247/2 = 123 registers.
So, for read operations the maximum is 125 and for write operations the maximum is 123 registers.
:I think the OP is correct, and the current lemma statement "[...] only 125 registers for Modbus RTU and 123 registers for Modbus TCP can be read at once." is wrong. The limit for function code 03 Read Holding Registers seems 125, regardless of whether its RTU or TCP. See MODBUS Application Protocol Specification V1.1b3 section 6.3 (p15). I suggest to fix accordingly: "[...] only 125 registers can be read."
:There is a 123 register limit, but its for function code 16 Write Multiple registers, see section 6.12 (p30). The current lemma statement "Because register values are 2-bytes wide and only 127 bytes worth of values can be sent, only 63 holding registers can be preset/written at once." ought to be reviewed. --nils (talk) 15:16, 11 November 2020 (UTC)
replies: text: I now edited the Read Holding Registers section accordingly, see . The limit mentioned in the Write Multiple registers section still requires review --nils (talk) 00:10, 12 November 2020 (UTC)
thread_title:  The statement "...and 123 registers for Modbus TCP can be read at once" is probably wrong. 

message: Is it worth adding some information about the start/stop bits for each transmitted byte (as distinct from the start/stop bits for the entire frames as are already tabulated).  This confused me a bit when comparing to the baseline Modbus documentation, e.g. section 2.5.1 at https://modbus.org/docs/Modbus_over_serial_line_V1_02.pdf for the RTU transmit mode.  — Preceding unsigned comment added by Bodypillow (talk • contribs) 21:46, 23 February 2021 (UTC)
thread_title:  Start / Stop bits for each byte 

message: The Modbus Organization has declared that 
    The organization is using "client-server" to describe Modbus communications, characterized by communication between [client device (s), which initiates communication and makes requests of server device(s), which process requests and return an appropriate response (or error message).
That's from reference number 5, from 2020: https://modbus.org/docs/Client-ServerPR-07-2020-final.docx.pdf
I've restored that sense is one place: there may be others. I also restored the text which explicitly notes that this 'client server' relationship (which is the normal unix sense, and the normal unix networking sense, ie tcp/ip), inverts the normal and historical English and Latin sense.  That extra sentence is in their precisely because people get this wrong, and confused.
I see that somewhere along the line, someone added a (now broken) link to something about "client server". It doesn't matter. It doesn't matter what *other* people think client-server means. It doesn't matter what you think client-server *should* mean. You do a disservice to readers if you here choose a meaning of "client-server" other than that chosen by the Modbus Organization 121.200.27.15 (talk) 06:24, 11 July 2023 (UTC)
thread_title:  Client and Server 

message: One meaning of "encyclopedic" is "comprehensive in terms of information", but that's supposed to mean knowledge about lots of different things: an encyclopedia is not a collection of poorly written textbooks or poorly written application notes. This is now unfocussed and full of fluff, with tutorial and technical content hiding the introductory and exploratory content.  It's unreadable. It's worthless garbage.
I considered just reverting it to April 2023, but why argue? It's now a private project for someone who is learning how to write and learning about Modbus. Perhaps one day that person will realize what a mess this is, and take it back to something useful to other readers. 121.200.27.15 (talk) 07:02, 22 March 2024 (UTC)
replies: text: I agree this article is a complete mess and needs a rewrite. I'm not a Modbus expert so I'm not going to rewrite it, though. PhotographyEdits (talk) 09:22, 22 March 2024 (UTC)
thread_title:  What a terrible mess - changes in late 2023