Talk:Modbus

Neutral point of view

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)

This is trying to sell Modbus and is wrong. I'm a senior automation specialist of multiple decades, and it's false that modbus is popular and easy to deploy because royalty free. Bacnet, however, *IS* those things, and is modern and functional while modbus is obviously immature, crude, featureless, difficult, not automatic. This article is not serving the public. — Preceding unsigned comment added by 108.169.8.25 (talk) 16:41, 18 March 2021 (UTC)

I think this page was written by a MODbus salesman. It is very POV.

Where are the sources to state that Modbus "is the most commonly used communication interface". I could have easily said the same about EtherNET/IP, Profibus, DeviceNET, DH+, ControlNET or RemoteI/O.

Wikipedia is a place to learn and share information, not to advertise.

ProdigalSon 08:51, 26 August 2006 (UTC)

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)

As an engineer for a company which is an end-user of these products, I agree with Wtshymanski. We absolutely prefer Modbus because it's universally useful - we don't need NDAs or expensive licensing fees to make devices work with our in-house software. Just a modbus mapping spec, a day or two writing a new device module for our software, and it just works. Contrast to Profibus or DeviceNET... not a happy experience. Even getting HART specs out of some device manufacturers is like trying to get blood out of a stone. For Modbus, companies like Emerson, General Monitors, etc. have an appendix in the user manual which is all you need to make things work. Generally, it's the DeviceNet/ProfiBus manufacturers who want to lock you into their software. Such manufacturers who want vendor lock-in do NOT use Modbus.

As someone who helps in software development for natural gas equipment, I would agree that Modbus is the most widely used. However this is from my point of view and I have no physical proof to back this up. I would agree that without references, that statement does not belong here.

Alshain01 13:05, 19 April 2007 (UTC)

Removed commercial (non free) link from Free section. Moved to commercial section -- user:wpostma

I think it is time to remove the NPOV warning, the article has been cleaned as requested by polite comments. If you think otherwise please justify. Jimwelch (talk) 14:43, 16 January 2013 (UTC)

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)

most commonly?

Written in article: "It has become a de facto standard communications protocol in industry, and is now the most commonly available means of connecting industrial electronic devices." But http://www.controldesign.com/industrynews/2010/021.html says it's number 3. That is a contradiction.--UlrichAAB (talk) 03:01, 21 August 2010 (UTC)

That reference talks about Ethernet. This article is about Modbus. --Wtshymanski (talk) 12:59, 23 August 2010 (UTC)

Indeed the link above only covers Modbus over TCP; but are there any surveys/sources supporting this claim in the article? -- intgr [talk] 16:33, 24 August 2010 (UTC)

Gosh, there's no references. Better delete it, then. After all, Wikipedia doesn't run on common sense or knowledgeable editors. --Wtshymanski (talk) 18:00, 24 August 2010 (UTC)

Sorry, that was supposed to be a polite reference request, don't take it personally. I didn't say anything about deleting.

Stating that something is "the most common" is a big claim to make. The statement is fairly ambiguous, so I don't think it's unreasonable to ask for sources. Obviously you wouldn't cover surveying methodology in the article, hence why pointing to a source is useful. -- intgr [talk] 18:41, 24 August 2010 (UTC)

I've just spent 15 minutes with Google Books, which is 14 3/4 more minutes research than most Wikipedia articles get. One would hope a subject matter expert would add more, although one's touching faith in the notion that someone who gets paid to know about things would spend his valuable time on Wikipedia might be ill-founded in reality. --Wtshymanski (talk) 18:48, 24 August 2010 (UTC)

I've made an edit for it. "Modbus is now a commonly available means of connecting industrial electronic devices"

is not technically correct as "a commonly available means of connecting" refers to physcial connection like RF, RS485,... while Modbus is an application protocol, i,e it has its specific data frame, and operates in a wide range of communication channel in wire and wirelessnot technically correct as "a commonly available means of connecting" refers to physcial connection like RF, RS485,... while Modbus is an application protocol, i,e it has its specific data frame, and operates in a wide range of communication channel in wire and wireless

So I change it to "Modbus has become a de facto standard communication protocol for communication between industrial electronic devices in a wide range of buses and network". This is based on the official doc of the MODBUS organization. Anonymous Agent (talk) 09:50, 10 October 2023 (UTC)

Which industry? I work with automation systems focused on residential and commercial (The "CEDIA Industry") but not industrial, and I have implemented drivers for hundreds of devices over the years and I rarely come across devices supporting the Modbus protocol. No VCR/DVD player speaks it, nor Jandy or Compool controllers, nor Lutron or Vantage lighting controllers, nor GE security systems - just to name a few off the top of my head. Maybe the statement is true among industrial automation systems - it seems popular in that realm - but very far from the truth among other commercial and residential applications. --108.95.137.143 (talk) 00:49, 11 April 2012 (UTC)IanEpperson

I have been working as an automation engineer for many years using most common industrial fieldbuses. Modbus is not my favorite, but I still agree with the article. It's definitely one of the most spread protocols, supported by many companys. I do not think the article is like an advertisment. I think it's quite balanced. — Preceding unsigned comment added by 81.16.173.217 (talk) 21:31, 30 November 2012 (UTC)

Protocol or society?

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)

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)

Protocol Variants and Stack

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)Steve

Seconded. I expect a wikipedia article to give a good general overview. No indication of physical layer (RS485), or any indication of exactly how slave units respond with their data, or relative timings. — Preceding unsigned comment added by 86.29.242.49 (talk) 11:13, 4 January 2014 (UTC)

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)

Reverted the 2013 vandalism that deleted that section — Preceding unsigned comment added by 203.206.162.148 (talk) 11:48, 28 September 2015 (UTC)

error in chapter 6.1

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)LPA

External links

Per WP:ELNO point 14, we do not maintain lists of links to vendors/providers on Wikipedia. Also on WP:EL, 'Wikipedia uses the same standards for evaluating links to websites owned by for-profit and (real or purported) non-profit organizations.' so the fact that these are free implementations makes no difference. Wikipedia is a place for laypeople to get a general understanding of a topic, not a place for engineers or developers to find help doing implementations. - MrOllie (talk) 15:19, 20 December 2016 (UTC)

>Wikipedia is a place for laypeople to get a general understanding of a topic, not a place for engineers or developers to find help doing implementations.

That is nothing but opinion.

WP claims to not have fixed rules to grow and evolve to help people yet so many editors have fixed thinking. I read all the time '...not a link farm...' yet the WP format is not always the best and the data listed on another site, its presentation, layout, etc.. are better for understanding. Yet no, the rules say blah blah blah.

Some of the links you deleted show the data in action, it needs to be done in a program for the "laypeople" to get a better understanding. Yet no, the rules say blah blah blah.

The real kicker with you removing the links is, not one person complained. Just an editor being a ...

I have been a financial supporter of WP in years past; supporting WP ended yesterday. WP better evolve or it will cease. <- My opinion, as valuable as yours. — Preceding unsigned comment added by 70.196.110.216 (talk) 01:55, 22 December 2016 (UTC)

Wikipedia articles may include links to web pages outside Wikipedia (external links), but they should not normally be placed in the body of an article. All external links must conform to certain formatting restrictions.

Some acceptable links include those that contain further research that is accurate and on-topic, information that could not be added to the article for reasons such as copyright or amount of detail, or other meaningful, relevant content that is not suitable for inclusion in an article for reasons unrelated to its accuracy.

Removal of the links is vandalism. On the other hand, there is no point re-creating the content of the Modbus protocol documents -- commands, coils etc. That stuff could mostly and thoughtfully be removed, which would make the article much shorter. — Preceding unsigned comment added by 203.206.162.148 (talk) 23:45, 16 January 2017 (UTC)

Removing the links only made the editor satisfied. It did not help a single person. It did not help WP.

Some examples would help

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)

I have tried to add links to free software that logs/parses messages and labels the commands but a..h... editors continue to remove the links. Crap about not a link farm, etc., that the links/programs help people understand, what an encyclopedia was intended to do, the protocol does not matter. WP is stuck in the past of text and pictures that is all a printed encyclopedia offered. In years past I donated money to support WP. I stopped donating long ago after enough time on WP and seeing the f..... attitude of editors. So sad. — Preceding unsigned comment added by 174.207.14.179 (talk) 01:10, 18 October 2018 (UTC)

And is it not typical that an editor removed my comment because it told the truth (IMHO) about some editors and that is not allowed. Grow a thicker skin.

Possible to add more about history / background / motivation?

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)

Modbus Plus, different protocol or not?

Under the "Modbus Plus" section we read:

Despite the name, Modbus Plus[15] is not a variant of Modbus. It is a different protocol, involving token passing It is a proprietary specification of Schneider Electric, though it is unpublished rather than patented. It is normally implemented using a custom chipset available only to partners of Schneider.

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)

The statement "...and 123 registers for Modbus TCP can be read at once" is probably wrong.

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)

I now edited the Read Holding Registers section accordingly, see [1]. The limit mentioned in the Write Multiple registers section still requires review --nils (talk) 00:10, 12 November 2020 (UTC)

Start / Stop bits for each byte

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)

@Bodypillow: I totally agree with you, the information state in Modbus RTU frame format missed the important information about the Start/Stop bit information which makes me confuse like you. By the way, according to me, this part also has the issue when they state the length of Start and End are 28 bytes but I don't find that information in section 2.5.1 of Modbus over serial line V1 02 --Anonymous Agent (talk) 15:48, 11 August 2021 (UTC)

I think there is some confusion. The 3.5 character times delays aren't start or stop bits, they are silence periods (no bits, just silence) so devices know where the packet boundaries are located. They are not 28 bytes, they are 28 bits, which is simply 3.5 character times for 8 bit characters -- 3.5 times 8 = 28. Start and stop bits are for framing characters on a communications line. The transmitter will begin a character with a "start" bit, typically the low voltage state ("idle" is the high voltage state), transmit 8 data bits, then end the character with a "stop" bit, typically the high voltage state (which you'll recall is "idle"). This article probably needs some judicious links to the RS-485 article which describes the signaling in more detail. Tall Girl (talk) 22:55, 20 January 2022 (UTC)

Client and Server

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)

What a terrible mess - changes in late 2023

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)

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)