Newsletter Insert Sept. 2012
Drew & Scott’s Young Gun Automation Insert
Why Networking Protocol Specifications are like Facebook Profiles?
Drew Baryenbruch
Strange as this analogy may seem there are, I would contend, many parallels between Facebook Profiles and Leading Network Protocol Specifications. The basic tenant behind that argument is that Facebook is in essence a digital record of you. A log of your abilities, experiences and interaction someone could follow to “know” you. A technical specification does the same thing for a protocol. Now on to why this matters and what we can learn from it.
I took a moment to review Scott’s Facebook profile in order to make my point. There were photos of his recent wedding. This was an event I attended and may never live down around the office thanks to my friend alcohol… Pictures of his golden retriever pooch. How many pictures can a guy post of his dressed up dog before dude law is evoked? There were also pictures of him at Brewers games, a mention of his employment, marital status, interests and Alma Mater (did you know Alma mater is Latin for Nourishing Mother? I didn’t). To my dismay Scott is not living out an alternative identify via Facebook, or is he?
Scott’s profile highlights events in his life. These are all true event he took part in but are somewhat misleading when describing Scott. Scott has the ability to get married, dress up his dog, and graduate college but he doesn’t do these things regularly. I see more of him than I would like to admit and can assure you that for more than 50 hours a week he sits in front of a computer pounding out code. Yet on his profile his employment is merely a footnote. This isn’t an argument of how people define themselves but this same, somewhat misleading, highlighting is present in open networking protocol specs as well.
Take a look at a recent spec for EtherNet/IP, Profinet, or OPC UA. These are literally thousand page documents describing how to implement a protocol. Entire panels of engineers are locked away in windowless rooms for months on end with only Mt. Dew and Cheetos for nourishment as they define these protocols. They define the data modeling, supported physical layers and data exchange rules that define the protocol. That base step takes a week then they spend the rest of the time addressing every “what if” they can think of to make the protocol more encompassing. What if the customer has ASCII data, needs encrypting, need to meet safety standards or needs to move data faster? These “what ifs” all lead to features of the protocol. Some are natural fits, some could best be described as shoe horn additions. The features are like the interest, abilities and events on Scott’s Facebook profile. They are the interesting things that grab headlines and are used to differentiate when competing with other protocols.
Just because Scott has a picture of himself sky diving does not mean he does it regularly or can do it well. The same is true for many protocol features. Just because the feature as been defined and can be hypothetically supported does not mean it has been implemented in the market or that it ever will be accepted.
“But it’s defined in the Spec!” is the cry I hear a lot. Someone picked a protocol to implement based on an obscure feature and no controller on the market supports the same feature making the device worthless. This brings on the ever present Chicken and egg scenario. If there are devices driving a feature will the controllers build in support? Maybe yes, maybe no, it’s probably a pretty big risk though given the development dollars involved.
We now know Scott is not as interesting on a daily basis as his Facebook profile implies and X protocol is not as encompassing in the market as it is in it’s specification. So the natural question is, if you can’t trust a spec what do you follow?
It’s much like the difference between a friend and a Facebook friend. The only way to get to know a person or a protocol is to interact with them in real life. Doing this with a person is admittedly more straight forward but you can do the same with a protocol.
First talk to your customers. See if you are meeting their current needs or if you will be pushing a new protocol/feature at them. Look at the conformance spec. If you don’t need a particular feature to meet conformance chances are it is not standard in the market. Give the trade organization a call. The guys that run these know the protocol and more importantly know the vendors and their offerings. Take at look at the data sheets for the leading controllers and devices. There is always a main driver behind a protocol (Rockwell/EtherNet/IP, Siemens/Profinet, EtherCat/Beckhoff) their products are most likely driving the customers need for yours. Do all these steps and you won’t be able to help knowing a protocol intimately.
Now if only it were as fun to protocol stalk as it is to Facebook stalk. (For those not hip with the jive that is not a literal stalk)
Serial Communication: From the Time Before Ethernet!
Scott Zukewich
There are 3 major versions of serial communication you better get cozy with or risk being upset by a “twisted pair”.
RS232:
RS232 communication allows two devices to communicate between one another. Data cannot be exchanged at the same time. Typical devices call and respond to one another or one constantly listens while the other talks at will. This was common for computer peripherals until USB came along. (Tx connects to Rx and Rx connects to Tx for wiring).
RS485:
RS485 communication, also known as RS485 2-Wire Half Duplex, adds support for daisy chaining (see below) and increased noise immunity. Like RS232, only one device can effectively communicate on the wire at a time. This is why most protocols based on RS485 are master/slave based where the master controls who has the wire or token pass based where only the device with the token can use the wire. Either of these options eliminates multiple devices from talking at the same time which would create garbage data. (Tx- connects to Tx- and Tx+ connects to Tx+ for wiring).
RS422:
RS422 communication, also known as RS485 4-Wire Full Duplex, allows for one device to communicate to other devices and exchange data at the same time. Only one device can transmit and one device can receive at a time. No two devices can transmit or receive at the same time.
Supporting Multiple Devices:
On the RS485 and RS422 network, you can have multiple devices daisy-chained together. All of the wires (Tx-, Tx+, Rx-, and Rx+) must be connected to the same mating wire connection when daisy-chaining (Tx- to Tx-). Device 1 is connected to device 2 , 2 to 3 and so on down the line. The big advantage is savings in the cost of material and labor. Running a single snaked network uses less resources than a star topology where each slave has a homerun line back to the master.
Termination:
When Daisy-chaining, it is important to have termination at the two ends of the network. The need to use termination is based on the cable length and data rate being used. Ideally, termination resistors should be placed at the extreme ends of the data line, and no more than two terminations should be placed in any system that does not use repeaters. The terminators absorb excess transmitted energy at the end of a network. This prevents signal reflection from bouncing back towards transmitter, upsetting the signal and communication quality. Termination also lowers the line-to-line impedance when no device is transmitting.
Biasing:
You may run into a need for biasing.
When the RS485 network is idle, the Tx+ line should be at least 200mV above the Tx– line. This value is the potential difference between Tx– & Tx+. Adding biasing to a device allows you to correct differential voltage that is not at 200mV.
When do you need Biasing? Just like termination, the length of the network, electrical noise and the amount of data on the network plays a role.
Where do I place Biasing? Unlike termination, you can place biasing anywhere on the RS485 network there is an issue. Sometimes a single device on a network may have a biasing issue. The typical way to add biasing is with a pair of biasing jumpers. Most devices will offer instructions of how to apply or remove these jumpers.
As a last note about biasing jumpers, they always come in pairs. They should be installed together or removed together.
Recommendations:
Daisy Chaining is standard practice:
I had a customer call and tell me that they had wired up all ten of their devices and couldn’t figure out how to get all ten of their RS485 runs in our gateway. I replied they need to daisy chain all of the devices together.
Vendors expect RS485 networks to be daisy chained. It is best practice and saves money on connectors. You will not find many if any Modbus RTU Master devices with 32 terminal connections, 1 for each slave on the network. It doesn’t make sense. That might be a surprise to someone used to the typical star topology of RS232 or Ethernet.
Any Questions about your system? Give us a call or Email.