Customer's Girlfriend Sends Mike an Email

Hey Mike,

This is the hapless girlfriend who shares an email account with a techie who subscribes to your newsletter.

The amount of dry poopey emails that we get in our inbox is criminal, and it's pathetic that the other electronic types are perpetrating the geek image that's out there by doing these incredibly boring emails. I mean come on? 'All you've ever wanted to learn about C++, Extensive Layer Management Plug-In for mental ray Pipeline? BRUTAL! Thank you for the sense of humour in your newsletters.

Mike - I think you need to start a 'how to write a cheese free newsletter course' I can think of many companies that need your help!

Signed,
Disgruntled Dish

Merry Modbus from Mike at B&B Electronics

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:

• Adding Modbus RS-232 devices to a Modbus 485 network?
  http://www.bb-elec.com/productsubcat.asp?MainCategoryId=3
  
• Adding more sensors data to a Modbus network - wirelessly?
  http://www.bb-elec.com/product_multi_family.asp?MultiFamilyId=67

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.

Happy Connections,

Mike Fahrion
(815)433-5100
support@bb-elec.com