Subscribe to receive Slightly Sensible blog posts by email:

Your email:

Get a catalog!

Slightly Sensible - B&B Insider

Current Articles | RSS Feed RSS Feed

Merry Modbus

Posted by Mike Fahrion on Mon, Feb 16, 2009 @ 09:33 AM
  
  
Add to delicious  delicious  
  

You know about my affinity for good ol' serial communications. Watching those familiar bits and bytes flow by gives me the same warm fuzzy feeling as sitting around a fireplace with stockings hung with care.

Elegantly simple and effective for so many applications.

But what story are those bits and bytes trying to tell, and how do they get the job done? More often than not, the protocol of choice is Modbus. Just like good ol' RS232 and RS485, Modbus is elegantly simple and singularly responsible for an amazing amount of automation around the world.

But, like the serial wires that carry its message, Modbus isn't always plug and play. Frustrating, real-world problems sometimes make Modbus a victim of its own simplicity.

Let's do a super-quick review of the three flavors of Modbus.

First off, there is Modbus ASCII. Communicating over 232 or 485, ASCII is ultra simple, human readable, 7 data bits, but not horribly efficient.

Then  Modbus RTU. Also over 232 or 485, with 8 data bits and better error checking, RTU is much more bus-efficient than ASCII, but also more sensitive to timing.

And now we've got Modbus/TCP, which nicely wraps Modbus packets for use over Ethernet, delivering all the speed and networking benefits of TCP/IP.

Regardless of which Modbus flavor you choose, all Modbus messages are a master-slave configuration where the master (often a programmable logic controller, or PC running supervisory software), must poll each node to determine its status.

So dear reader, I'm pondering - would you like to hear more about Modbus? How it works? Solutions to problems like:

Or are your problems trickier yet? Things like:

  • Connecting a Modbus ASCII device to Modbus RTU?
  • Connecting two Modbus devices that are hardwired to different baud rates?
  • Hanging Modbus serial devices on a Modbus/TCP network?
  • Magically remapping hardcoded Modbus ID's to non-conflicting addresses?

If you're interested I'll share those solutions with you next month (or faster - just drop me an email). Don't hesitate to challenge me with other real-world Modbus problems that you've run into. I want to hear about them. I stand at the ready to take on your Modbus woes.

So between Christmas shopping and competing with the Smiths for the best Christmas display control algorithm on your block, drop me a note to let me know when Modbus has left you feeling Grinch-like and I'll do what I can to ease your protocol afflictions in the new year.

Tags: 

Comments

How to convert modbus ASCII to modbus RTU and viceversa. 
 
 
 
Eg. If I have to communicate PLC (which have Modbus RTU support) and AC drive (which have modbus ASCII support) how can we do it??
Posted @ Friday, June 05, 2009 7:29 AM by Apurva
Easily done with the MESR902T <a>http://bb-elec.com/product_multi_family.asp?MultiFamilyId=86<a> 
 
Simply configure port one as RTU and port two as ASCII, then configure the routing for port one and two to connect to each other. Each port independently supports 232/422/485 so you can do physical layer conversions if needed as well. 
 
 
 
In your case, you'll use the Ethernet port only during configuration. Once configured, you'll just use the two serial ports.  
 
 
 
-Mike 
 
 
 
Posted @ Monday, June 08, 2009 9:32 AM by Mike Fahrion
Hello. I am setting up a Modbus RTU network using a Prosoft ControlLogix Modbus card. My concern is that the Prosoft card has a +, -, and common, the VFD I'm tying to has the same (+, -, and common), but another controller I'm using only has a + and - terminal with no common. It's in a noisy environment so I'm concerned with the controller that doesn't have the common connection. How can I avoid noise issues on the controller that has no common connection? This controller will be on the same network drop as the VFD. Should I still tie the common on the prosoft to the commons on the VFDs, and tie the cable should at one end where the Prosoft Modbus Card is located? Thanks for your input.
Posted @ Friday, April 22, 2011 4:40 PM by Matthew Popielarz
That last line I meant: tie the cable SHIELD at one end where the Prosoft Modbus Card is located.
Posted @ Friday, April 22, 2011 4:42 PM by Matthew Popielarz
Ugh - very frustrating when mfg's don't bring out a common for RS-485. 
 
 
 
Two possibilities; 
 
1. I like you're proposal. Use the common's where they exist. Use a shield and tie it to the location with the lowest impedance connection to earth ground. 
 
 
 
2. On your controller without a common connection - if it's port doesn't have built in isolation (good bet it doesn't, but check specs or call the mfg), then it's power supply ground is most likely the same ground reference as the 485 port so you could use it as your common. 
 
 
 
Finally - if you have trouble, you might consider putting an isolator (485OPDR, 485OPDRi) between the controller and the other nodes. This will allow that link to float, and also has some inherent filtering benefits against high frequency noise caused by VFD's. 
 
 
 
Good luck! 
 
-Mike 
 
Posted @ Saturday, April 23, 2011 6:51 AM by Mike Fahrion
Post Comment
Name
 *
Email
 *
Website (optional)
Comment
 *

Allowed tags: <a> link, <b> bold, <i> italics