Newsletter Insert May 2012
Drew & Scott’s Young Gun Automation Insert
Changing of the Guard
All this talk of grey beards brings up what will be a daunting reality unfolding over the next decade. All those grey beards will be retiring. Florida and Arizona will brace for an influx of permanent snow birds while the automation community witnesses a mass exodus of collective knowledge.
CEO’s are salivating at thought of replacing 1000’s of highly paid, tenured engineers with entry level replacements but are beading sweat at the thought of the transition. Let’s face it they have good reason for their apprehension.
We work in a unique industry. The technology replacement models learned in business school don’t apply. A Geek Squad-er at Best Buy doesn’t have to learn about Beta, VHS cassettes, tube TV’s or even RCA connectors anymore. A new technology changes the market and near total replacement takes place in a number of years or months. This makes the knowledge and skills associated with the departed technology little more than a fun fact for trivia. Anyone found a use for their amazing VHS tracking ability lately? Our industry is the exact opposite my friends. In fact many factory floors are still dominated by technology that was released before you or I were born. If our industry was Best Buy, ribbon printers, serial cables, and Walkmans (the original) would still be the backbone of the business.
This is why our industry is bracing for change. The necessary collective knowledge of the past 4 decades is moving on. That leaves two options for most companies; upgrade their lines or train a new staff. Upgrading is an expensive proposition when you are talking about an automation line. There are good arguments for the payback of improved efficiency with upgraded processes and protocols but I promise for every company that ops to upgrade there are at least as many companies that live by the motto, “If it ain’t broke don’t fix it.” That means we have to become familiar with technology fit for history books to be effective. It’s time to train ourselves.
That’s the idea behind this bimonthly insert. Get Generation Y ready to take the reigns. Scott and I both fall in the 20 something range. The challenge of learning these lessons are still fresh in our minds. Each issue we will tackle a new protocol or topic with both background information and practical tips. Hope you enjoy,
Modbus: Great Grandfather and a Still Dominant Force all at Once
Modbus was arguably the first true open industrial protocol standard for PLC’s. It was invented back in 1979 by Modicon as a way to communicate with a PLC. In 30+ years it has found its way into every application imaginable. Modbus enabled devices dominate Industrial, Building and just about any other Automation you can think of. You can’t avoid running into Modbus so you might as well learn it
Why So Popular:
Modbus is dirt simple. It is a low cost and easy to implement protocol. That has led to massive adoption.
Flavors:
Modbus RTU – Is a Master/Slave protocol based on the serial RS-232, RS-422 or RS-485 physical layer, primarily RS-485. It provided the backbone technology and data structure of most subsequent versions. This is the most widely used and adopted protocol in automation. Masters control the reads and writes to all Slave devices. Slaves sit there presenting and accepting data from a Master.
Modus TCP/IP – Is (for basic understanding) Modbus RTU on Ethernet TCP/IP with a 6 byte header to allow routing. There are a few other differences beyond the physical layer but the base technology and data representation are the same. Instead of Master/Slave they use the terminology Client/Server. The Client is the Master and Servers are the Slaves. The Server term throws a lot of people off. Just think it sits there and serves up data.
Modbus ASCII – Is used in serial communication & makes use of ASCII characters for protocol communication. This version never gained wide spread adoption. Avoid it if you can!
Modbus+ – Is a proprietary version of Modbus controlled by Schneider Electric. Shouldn’t have to worry about this one.
Modbus PEMEX – Is an extension of Modbus that allows for the support of historic and flow data. It was designed for the process industry and also never gained wide spread adoption.
Troubleshooting Modbus
Making a Connection:
When working with Modbus with RTU or TCP/IP the first step is always double checking for fat finger errors. Make sure you have the correct serial settings, Slave addresses for your Modbus RTU device and double check the Server’s IP Address and Unit ID on Modbus TCP Network.
Forehead Slappers:
Remember on RS-485 the two communication lines are + and –. Sometimes referenced as A (-) and B (+). You must match up like kinds + to +, – to –. Reversing them will not hurt the device but will not allow communication. Also make sure your connections are tight. A loose RJ45 or screw terminal have sent many an engineer in search of other causes to very simple problems.
If you have your settings right and connections tight you should be receiving good communication, or errors. Either of those outcomes proves your settings and connections are correct!
Moving Data Between Devices:
One of the biggest headaches you will run into with Modbus is the documentation. Every manufacture has their own way of phrasing which registers to read/write and what data type they are. You need to find the answers to the following questions:
Q: What Modbus function codes are supported?
Q: What Registers do you want to read and write?
Q: What data type are each of the registers?
This is the information you need to configure your Master/Client device. Remember the Slave devices just sit there. The action of reading and writing is all done in your Master/Client device. You have to input the read and write mapping for each Slave device in the controller. If there are incorrect values in your mapping table you will receive either invalid data or timeouts/errors.
Understanding Addresses:
The first digit in the address represents the data type that will be used. 0 = Read/Write Coil Status, 1 = Read Input Status. 3 = Read Input Register and 4 = Read/Write Holding Register. The remaining digits represent the address location.
Example:
Register “400001” the 4 means this is a Holding Register and the 00001 is it’s location. You would use function code 3,6, or 16 depending whether you are reading or writing the address. This information can be found in the device documentation.
Extra Modbus RTU Tips:
All devices must have a unique Slave address between 1-247. On a RS-485 network, Slaves may be daisy-chained together to allow a Master to communicate to multiple slave devices.
Extra Modbus TCP/IP Tips:
Modbus TCP/IP Servers’ unique identifiers are a combination of the IP Address and the Unit ID. The IP Address is the primary field followed by the Unit ID (0-247) as the secondary field. You can choose how to differentiate units . Multiple TCP/IP devices on a network can have the same Unit ID at different IP Addresses. There are also devices out there that have multiple Unit ID’s at the same IP address. One physical device represents multiple devices on the network. You see this a lot in gateway and enabling devices. Either is acceptable so be prepared to encounter both.
Tools Available
There are great tools from Win-Tech http://www.win-tech.com that have free trials available and cost under $100 to own. The site and tools look like they came out of the early 90’s but they are proven tools every control engineer should have.
ModScan32 acts as a Modbus RTU Master or a Modbus TCP/IP Client that can communicate to multiple Slave/Server devices. http://www.win-tech.com/html/demos.htm
ModSim32 is a Modbus RTU Slave / Modbus TCP/IP Server allowing connection to a Master/Client. Download this free tool to simulate a Slave/Server.
Also available is ModCheck from Real Time Automation. This is our version of ModScan32. It doesn’t have all the functionality of ModScan32 but it does all the basics and the price is right, FREE!
Email DrewandScott@rtaautomation.com if you would like a copy.
Examples:
A list of the Most Common Function Codes:
Function Code 1: Read Coil Status
Function Code 2: Read Input Status
Function Code 3: Read Holding Register
Function Code 4: Read Input Register
Function Code 5: Write Single Coil Status
Function Code 6: Write Single Holding Registers
Function Code 15: Write Multiple Coil Status
Function Code 16: Write Multiple Holding Registers