By Ken Gifford
Under cover of darkness the night of April 18, 1775 a man peers out his window with a watchful eye. As he gazes intently at the old church, suddenly the light of two lanterns pierces the darkness. The man rushes out of his house and mounts his already saddled horse, and begins a breakneck ride towards Lexington to warn the leaders of the fledgling revolution.
If you haven’t already guessed, the man’s name is Paul Revere. I love this story – not only because it takes place on my birthday (no, not in 1775!) but because of the adventure it represents. This also illustrates an interesting method of communication. There were several scouts watching various avenues of approach the British might use, and once spotted, a predetermined signal was set – “one if by land, two if by sea” to communicate their approach, and thus the predetermined response. Much of what we do in the industrial world works much like this. We monitor events such as alarms, or condition changes, and then determine an action in response. Of course, it’s not entirely practical to have a contingent of people watching the process intently and lighting lanterns or shouting if something seems awry. Not to mention that it is particularly hard to see what is going on inside of a PLC. Thank goodness today we have digital communications!
Of course, transmitting information across a wire is nothing new – the telegraph has existed since 1809 – but today machines can talk to machines without human interaction, and we can have the machine send out a message when action is needed. Make no mistake though, it is a jungle out there – just saying something communicates via “Ethernet” doesn’t mean it’s plug and play. Let’s discuss a bit about communication “standards” and “protocols”. A standard usually is in reference to the media used, i.e. the type of wire, what kind of signal (voltage, current), how far it can be run, etc. A protocol dictates what the transmission contains, i.e. start signal, message contents, end signal, etc. An analogy I like to use is this – think of speaking verbally as the “standard” and the language we are speaking as the “protocol”. For example, if one person is speaking English to someone who only speaks Mandarin Chinese, they are both speaking verbally but there is no conversation taking place. This illustrates why it is important to understand what the standard and the protocol you are dealing with. Like I mentioned earlier, many vendors will tout their product’s ability to communicate via “Ethernet” (a standard) but fail to mention what protocol is used. You unbox the unit only to find it uses Modbus TCP (a protocol) but your network is built on Rockwell Ethernet IP (a different protocol).
Where to begin?
First, identify what information you want communicated, and to where. Are you wishing to gather the data into a central data store (Historian)? Or perhaps you want to transmit recipe information or work orders from another system directly to the machine? Once you know what data you are moving where, doing an investigation of existing equipment to understand what standards and protocols are available is the next step. Once this is established, a strategy can be determined for making the communications happen. This is where we can help! We excel at inter-system communications, and have a wealth of experience with machines old and new. If you’re network is homogenously Ethernet, perhaps all that is needed is a protocol converter to make disparate systems communicate. A protocol converter does just that, it converts one protocol to another, sort of like a translator. The signal passed from one system to the other is transformed so the receiving machine understands the data transmitted, and vice versa. Or it may be that a media/protocol converter is needed. This device will actually change not only the protocol, but also the standard used. We routinely bring old Allen Bradley PLC5 processors onto Ethernet networks for the purpose of data collection. In these instances we are converting the DF1 protocol, which is using serial communications, and converting to Ethernet IP an Ethernet protocol.
One question that may arise is, why Ethernet? The industrial world tends to be slow to adopt change, instead being focused in using older proven technologies in the interest of reliability, even if it sacrifices speed. Ethernet on the other had has become so common, reliable and simple to deploy making it an easy choice. Data can even be transmitted wirelessly. A word of advice however, when deploying Ethernet within the manufacturing environment it is highly recommended to use equipment designed for the rigors found there. Unlike the front office, you will encounter environmental challenges such as more extreme temperatures and electromagnetic interference. Industrial networking equipment is designed specifically for this environment, making your network much more reliable.
Watch for Part Three– “Now that we have all everything communicating – what do we do with all of this data?”
Part One of Demystifying Automated Data Acquisition can be found here: https://www.surecontrols.com/demystifying-automated-data-acquisition/
