Newsletter Insert July 2013
Drew & Scott’s Young Gun Automation Insert
How to Earn Your Salt
Drew Baryenbruch
I submitted the title of this piece to Jessica and she asked me, “What does that mean?” I am still young enough to get a warm fuzzy feeling when I use a metaphor that makes me seem old fashion to a listener (I give those feelings 5 more years). Like most old sayings there are arguments over the origin but it was either Roman soldiers or sailors who were paid in salt, hence earning your salt meant earning your day’s wage. So what does it mean to earns ones salt in our industry?
The first step is to acknowledge that in this industry you are not going to be worth much salt at first. Sorry, I don’t care what prestigious university you graduated Magna Cum Laude from. Your education has prepared you to be a learner, which is important, but that’s about it. No degree program is going to cover the goofy segmented and legacy technology riddled environment we work in. You are going to have to get some good ole experience or be doomed to semi-mindless data input for the rest of your career.
I can remember the exact moment I realized I was essentially worthless. It was at the 2008 E-Drives show in Orlando, FL. I had been at RTA for over a year in a marketing role and was manning the booth while John was away. Two gentlemen approached and asked a very basic question, “What is different about Industrial Ethernet?” This wasn’t on the data sheets of my products! Cold sweat broke out. I two stepped while pulling half related facts out of my backside until I was saved/shamed. Joey Stubbs from the EtherCAT Technology Group was a booth over and had heard the conversation. He stepped in with a smirk that said, “I have listened to this train wreck long enough.” In retrospect I have never been so thankful to someone for making me look so dumb, because I was dumb. I vowed not to be “that guy” again.
Most people in this industry will start with a more technical background than my fluffy marketing degree provided, but you will still be green. Here is advice I believe has served me well. If you don’t know something, admit it. Pretending doesn’t serve anyone, especially you. Say, “I’m not familiar with that, what is it, how does it work, why is it different?” Take those answers and then research the topic further on your own. Gain a practical understanding that goes beyond fun facts. Then do whatever it is you do to remember what you’ve learned, everyone is different. The goal is to only ask about a particular topic once. There are enough topics to ask about that you don’t want to waste time on repeats.
The second step is being confident enough to use the experience you have. Most applications can be solved multiple ways. A basic level of experience will help you avoid the pit falls of potential solutions that will fail. A moderate level of expertise will open your eyes to a handful of plausible solutions. Here is the trick. It doesn’t matter which solution you chose. Real experience is judged in practical applications not theoretic ones. Early on you will not pick the most efficient solution. That means you will have to work that much harder to deliver. The trick is taking the leap on your experience and then making it work.
Again, remember the important part of experience is not the ability to point out shortfalls and risks in any given application. It’s to look at those risks, firmly chose a direction and then execute. There are far too many consultants, engineers and big companies that forget to apply their experience after pointing out the risks and shortfalls of every imaginable solution. I suppose the moral is don’t be a Debby Downer, be the Debby Do’er.
If you make that process of learning a habit, while also having the confidence to use the experience you are developing, you will very quickly separate yourself from the lowest common denominators. There are a lot of relatively useless undriven people waiting to be stepped over. If you are motivated and make gaining and applying experience a priority you will become worth your salt in short order.
Terminology & Device Types
Scott Zukewich
Device type terminology is one of the biggest obstacles that we deal with daily. All these islands of automation have led to countless and mostly pointless customization of phrases and terms, especially for networking protocols.
Apparently there is a rule that you can’t create an open protocol unless you customize every ancillary term in the said protocol. This might seem like a minor annoyance but I can tell you from experience in support that it can be a major obstacle to accurately communicating the issue at hand. This is especially true when you are supporting a gateway, because most customers understand only one of the protocols. They live in an “X” protocol world and now they need to connect to “Y’s” world.
The first thing to master is the role of the different device types in a given protocol.
Device Types:
Master-Slave is terminology that came about with serial protocols. A master directed the flow of data to some number of slave devices. When Ethernet arrived, the new protocols all broke from that device name terminology. Some hardcore techies will argue that there are differences that justify renaming the device types; there are differences, but I think it was just a move towards more PC terms. On Ethernet networks we have Client and Server devices. Servers are the slaves that serve up data and the Clients are the Master devices. To add another wrinkle, many leading protocols decided they needed their own names. See below:
Protocol | Control Device Type | End Device(s) Type |
Modbus RTU | Master | Slave |
Modbus TCP/IP | Client | Server |
Ethernet/IP | Scanner | Adapter |
Profinet | Controller | Device |
BACnet/IP | Client | Server |
How do I know what type of device I have?
Can your device open a connection or request data from other devices?
-If yes, it’s a Master.
-If no, it’s a Slave.
Can your device poll other points?
-If yes, it’s a Master.
-If no, it’s a Slave.
Can your device issue read/write requests?
-If yes, it’s a Master.
-If no, it’s a Slave.
Does your device expose data points to be accessed?
-If yes, it’s a Slave.
-If no, it’s a Master.
Does your device seem to do all these things?
-If yes, you’ve got an odd ball!
The Odd Balls:
That’s right, there are relationships and device types that are not Master-Slave in nature. The two most prevalent are peer-to-peer and token pass networks. In these cases either an external tool connects the data of the devices on the network or a user configures each device to read and write the values they require.
Protocols that use (or can use) device to device communication are Lonworks, BACnet MS/TP, CANopen and DFI.
If you have any questions about Terminology or Device types send us an email at DrewandScott@rtaautomation.com.