If you have ever read our insert, it is probably clear I am much more interested in the business and market trends of our industry than the bits and bytes. Scott is the silver pinkie ring wearing code monkey, I am a business grad who got lost at the career fair 7 years ago. The differences between us never cease to amaze me. On the outside you might think we are a lot alike. We are both in our mid to late 20’s, enjoy sports, and have been known to solve the problems of the world over a few (or many) drinks together. It’s the wiring upstairs that always makes me wonder if we are the same species.
We see things differently, on different levels and in totally different light. Stick me in front of code and I would mistake it for a connect the dots puzzle. Stick Scott in front of a keyboard to explain any technical subject and try to keep your eyes from crossing. What is it with engineers and adjectives? Why do you all insist on using so many of them in such strange places? Does the term complete not imply the same thing as fully complete? They say that writing reflects the way one thinks, and that thought always humbles me a bit. Engineers must have cogitative abilities far beyond my own to function and create things with such noisy and inefficient thoughts.
I suppose the moral of this rant is that it takes all kinds. Scott can do things with code I could never dream of, but he needs me to act as his interpreter to the world or his creations would never find the commercial success we both need to stay employed. We are just two interdependent species working together for a common good. Like those little birds that pick the bits out of the crocodiles teeth. All that’s left is to decide who is playing the croc and who plays the bird. That is sure to create an argument that will be office entertainment for years to come.
Note: The idea behind this bimonthly insert is to get Generation Y ready to take reins of the Automation industry. Scott and I both fall in the 20 something range. If there are particular topics you would like addressed drop us an email.
I think there is an intriguing opportunity on the horizon for young controls engineers. I doubt it will be surprising but let’s look at the manufacturing jobs data from 2008-2013. They tell the story we have been hearing for the last three years. 2008 and 2009 were really bad years and we are slowly climbing out of the recession.
The problem is when you compare manufacturing employment to GDP recovery (Yes, GDP encompasses services and other factors, but it is a decent comparison for this argument). GDP has recovered far more than employment.
Without getting lost in the economics, we have data that loosely shows we are delivering as many goods as we used to but we don’t have as many jobs. Record profits and cash holdings among fortune 500 companies is another example that backs this assumption.
I worked with a gentleman at a food processing plant a while back. The company was growing and as a result they were adding 3 new lines. This guy was the company’s only control engineer, 2 others had been let go in 2009. He is solely responsible for the operation and upkeep of 268 PLCs across 10 lines! I hope this is an extreme case, but it illustrates my point. The guy is really good at his job but when you are pushing at 110% 60-80 hours a week, you work to get things done. We all know that getting something done and getting something done to the best of one’s ability is different.
That’s the Opportunity:
When these companies finally loosen up and invest in new employees, the employees will be entering environments that have been just getting by for 2-4 years. That means there is a lot of unexplored room for improvement.
Can you imagine how much room for improvement my food processing example holds? For years, a single control engineer has had one goal, make sure it works. Can you imagine how much data is unused or how many inefficiencies there are that haven’t been looked at? The latest tools and technologies in our industry give us the ability to monitor and control to levels never imagined in the past. Most companies are not exploiting the technologic abilities of their systems. It might be a good idea to show them how.
When Drew and I started this automation insert back in May of 2012, the first topic that I talked about was troubleshooting Modbus. I pointed out some general information about Modbus TCP & RTU networks. We also talked about some room for discrepancies in the wild, somewhat open world of Modbus. A subject we did not touch on deeply enough was Modbus Function codes. One of the most common questions we receive is, “What Modbus function codes does your device support?”
Let’s take a small step back and first explain what a Modbus function code is. A function code determines whether the data packet is a read or write request. Upon a read/write request, the Master sends out the request with a specific function code. The Master’s function code in the request must be supported by the Slave in order for communication to occur.
All Slave devices should identify the function codes that they support, but of course some documentation is easier to find or better than others. There is nothing in the device data that will identify the functions supported. It is important to note what your device supports because then you can tell the Client/Master what function codes to use for each and every point of data.
The most common function codes are 1, 2, 3, 4, 5, 6, 15, and 16. It is also important to mention there are four different types of data: Coils, Inputs, Input Registers and Holding Registers. Coils and Holding Registers are read/write data structures, while Inputs and Input Registers are read only. A Coil or Input status is a single bit of information while a Holding / Input Register is a 16 bit value. You can combine multiple registers to form a 32 or 64 bit value.
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 Register
Function Code 15: Write Multiple Coil Status
Function Code 16: Write Multiple Holding Register
Most devices will support function codes 1,2,3,4 and will support either 5 & 6 or 15 & 16. If you have a Slave device that supports a function code other than 1,2,3,4,5,6,15, and 16, make sure you find a specialized Master device that will support those function codes.
Knowing what function codes your device supports will greatly reduce the amount of time spent installing a device on the network.
If you don’t know what function codes your devices support and cannot locate the documentation, you will have to resort to trial and error.
To do this, you have to get a Modbus test tool (email DrewandScott@rtaautomation.com for a free one), then send out different functions codes. If you are able to exchange data, your device supports that function code. Not a lot of fun but sometimes you have to do what you have to do.
If you have any questions about what Modbus Function Codes your device supports or any other Modbus questions, you can send us an email at DrewandScott@rtaautomation.com.