Could someone please tell me which are the standards (ISO or others, if there are any) you need to follow for working with modbus in general and in particular under linux environment?
Sorry, there are none in the formal "standards" world. Go to http://www.modbus.org and follow the documents there.
Modbus is older than ISO/OSI and although Modbus may be a big fish in our small Automation pond, it's a pretty minor tadpole in the huge IT/Computer ocean of networks and data comms.
There are supposed to be, but from what I've see you are best guided by what is supported on the other end. I've puttered around with a fairly straightforward expansion of the example provided by Modicon with good results, but many remote racks, etc. can't handle high repetition rates, back to back packets, etc. that PC host to PC host
cause no problems. Still looking for Modbus/TCP IO hardware that can be scanned at high speed. THE standard is the Modbus.org documentation, such that it is.
In "theory" Modbus is a half-duplex protocol on TCP, so many slaves
won't expect fast 2nd responses on the same socket. This is a very fuzzy
area as people have done what was "best" (however that's defined), not
what's "requested in spec".
Also, many products work on strict cycles, so if they only handle comms
requests 25 times a second you'll never get more than 25 polls handled
per second even if the IO block CPU is 92% idle (good old fashioned PLC
paradigm)
Try polling over multiple sockets. SOME I/O products MAY handle this
better. So 10 messages per second on 3 sockets instead of trying 30 on 1
socket. This also may help IN SOME PRODUCTS with the fixed comm cycle
times as they'll handle 3 transaction per "comm cycle" instead of the 1
they'd handle with only 1 socket.
But this is all vendor-specific behavior - try and see. I know earlier
Modbus/TCP documents suggested the multiple parallel sockets as a way to
move more data faster. This has been omitted now as it is a worrying
suggestion (ie: if 4 clients all try to open 20 sockets in parallel to a
single small embedded client that only supports 16 sockets total - you
have some "fun" in a bad, unpredictable way.)
Unfortunately, at this stage of the game, the only "universal" solution that avoids tweaking for idiosyncracies is to poll at 10 Hz. Even that might be tolerable if you could fire and forget. However the TAT for some of these is the limiting factor. Of course, in context, many, even highly touted, networked PLC systems can't really do better than that anyway. (And before you guys flame me, put a pulse generator on an input and see how fast a square wave you can _really_ track. It's very educational) One wonders how they found a processor that slow or a stack that bad in today's market.
My solution is to make the rack I'm designing practical either as a PLC or as remote IO. But that's hardly universal as World+Dog will soon be building Ethernet IO and most will support Modbus/TCP. I'm intensly interested in what can be achieved in the real world with a fast processor and stack at each end, for speed, jitter and uncertainties. It could be calculated, but Linux changes every week for the better, making it difficult to predict what will meet the real world. My goal is networked IO that is truly comparable to attached IO. OSS and Open Hardware should achieve that, as even if I'm not smart enough to do it, someone else in the community is.
This whole area is kind of a dirty little secret, when you start actually testing equipment, you'll know why I chuckle when folks damn Ethernet for determinism and the like in comparison with the schemes provided by Big Automation. The real world performance I found was often orders of magnitude less than the theoretical numbers used in advertising. And again, please put facts before flames. I actually tested everything I could get access to. And will continue if someone makes it available.
But, Ethernet capable IO with Modbus/TCP is still a watershed development as it makes many types of non-traditional platforms viable. That's a good thing. If only more stuff were opened up life would be easier. Modbus isn't a be-all end-all, but it's a good start. No doubt standardization will follow.
I had a look - such vendor product documents are VERY dangerous to use as a "Modbus Guide" because they freely mix core Modbus and vendor-specific extensions to Modbus. You are FAR better off look at one of the PUBLIC standards on the http://www.modbus-ida.org website
(You'll notice the new web address: http://www.modbus-ida.org, as of Oct 15 Modbus and IDA-Group have merged. http://www.modbus.org will still exist forever, but we are trying to broaden the scope)
Facebook
Google
GitHub
Linkedin
