Newsletter Insert September 2013
Drew & Scott’s Young Gun Automation Insert
The Real Time Automation Story
Drew Baryenbruch
It dawned on me that many of you may not know much about RTA. If you’ve read this far I am going to go out on a limb and assume you care (or are really bored). Since we believe customers are family, I thought it would be fitting to tell you all the RTA story.
Inception:
Real Time Automation roots go back to 1988. After stints at Kimberly Clark and Allen-Bradley, John Rinaldi decided to leave the automation world. He was going into the Toy business. He had some really cool ideas and designs for interactive/virtual reality toys. It turned out that the toy making business is pretty hard to crack and his ideas may have been a bit ahead of their time. No toy makers called, or returned his calls. Instead he got a call about programming some Allen-Bradly 2760 RB modules. He didn’t want the work but the offers were running low so he took the job. That led to more calls, more begrudged work and then it happened. John’s sister-in-law was coming to visit, so his wife decided he had enough business to get an office outside of her guest bedroom. Like that C&I Systems (Communications & ID Systems) was formed, which would eventually become RTA!
The Early Days:
After finding his first office on 52nd and Oklahoma, John had more work than he could handle alone. In 1989, Darryl started as a contractor, became John’s first employee and is still with the company 20 some years later. In the early 90’s RTA was a stereo typical 2 man engineering shop. Programming RB modules was the back-bone of the business complimented with sporadic OEM jobs and circuit board designs. They worked from one job to next and prayed the phone would keep ringing.
Adolescence – Becoming more than a Custom Engineer Firm:
In 1996, Jamin joined RTA as an Intern. His first project was to develop a DeviceNet Stack. Jamin is now our lead software engineer. Jamin’s first project was RTA’s first attempt at what would become a corner stone of our business, Source Code Software. RTA was still living project to project but starting with DeviceNet, then Modbus and eventually Ethernet/IP, RTA was no longer just a custom engineering shop, it was also a software company. In 2000 the name of the company officially changed to Real Time Automation.
Gateways are Born:
In 2005, amongst almost no fanfare, the 435NBX gateway was launched. The product let you move serial ASCII data into an Allen-Bradley PLC. RTA sold a grand total of 50 units that first year and it was apparent to no one how big standard product offerings would become to RTA. In the beginning John was both sales and support. Jeff also joined the RTA team in 2005.
In 2006, RTA landed its first distributor, Kendall Electric (they have been our top reseller ever since). Also in 2006, Emily and I joined the RTA team!
By 2007, 435’s and 490 products were 30% of our business. It was decided we had fully exploited the ASCII gateway market. (Boy were we wrong!) We would use the new IEC 61131-3 standard to create low level PLC’s on embedded devices.
The 460 Gateway Line is Born:
It turns out low end PLC’s from a no name company are not all that attractive. But it was through that failure that the 460 was born. We had the hardware and a library of protocols to work with. Instead of selling a PLC with a single protocol we would add a second protocol and use the Logic engine to link the data. Like that, the 460 line of gateways was born! (the Logic engine was eventually removed)
In 2009 Jessica and Scott join the RTA team.
In 2011 Kristin joined the RTA team.
In 2012 Carlos and Vince joined the team.
(I have only mentioned employees that are still with RTA. We have had a lot of true characters come through RTA, and most have given something that helped us get where we are today.)
RTA Today:
Today RTA is a 12 person operation focused on gateway products. We sell over 120 different versions of gateways and continually add new protocol support. We have created a niche with easy to use products, made in America, with our industry leading support.
What’s With all the BACnet MS/TP Masters?
Drew Baryenbruch
If you have a background in fieldbus protocols, or are new to networking standards, BACnet MS/TP is bound to drive you crazy with it’s unique network structures and lingo. This is especially true when it comes to defining what type of device you are dealing with. This can be a big problem because device definition is an essential piece of information needed in even the most basic application. The goal of this paper is to give you a basic understanding of different BACnet MS/TP devices and their roles in a network architecture.
What makes BACnet MS/TP Different?
Many of the leading network standards we deal with in Industrial and Building Automation are Master/Slave networks at heart. Some of the networks use more PC terms like Client/Server, Scanner/Adapter or Controller/Server, but at the root, much of the function is the same. A Master type device initiates the reading and writing of data to “X” number of Slave devices connected to it. A Slave type device simply responds to requests from a Master. Slaves are the end devices like scales, drives, photo eyes, etc. While Masters are PLC’s, HMI’s and controllers. BACnet MS/TP takes this way of thinking and turns in on it’s head.
Most BACnet MS/TP devices in a network are Master devices:
The confusing part of BACnet MS/TP for most people is the definition of Master and Slave devices, because in most BACnet MS/TP networks, there are only Master devices. There are devices that are BACnet MS/TP Slave devices, but most end devices are actually classified as Masters. Let’s examine why.
True BACnet MS/TP Slave devices are end devices that must be statically bound to a Master device; they cannot accept a token (we will get to that later). The Slave functions much like we would expect a Slave to function. The unexpected part is that there are very few Slave devices in the market. This is because one of the big benefits of BACnet MS/TP is the ability to auto discover devices and data on a network. Since BACnet MS/TP Slaves do not support this function, the market has adapted by enabling Master functionality in most end devices. This means that by definition the end devices like drives and meters we would expect to be Slaves are actually classified as Masters.
With All those Masters how is Network Traffic Controlled?
The answer to this question is found in the “TP” of BACnet MS/TP. The TP stands for Token Pass. Master devices on a network pass a token around that allows them to communicate on the wire. Only the device with a token can communicate and then pass the token to another device. While this is the most common way BACnet MS/TP devices communicate, we have to remember that there is also a Master/Slave (“MS”) communication option available. While Master/Slave communication is rarely used, it does offer faster communication and limits network traffic when compared to token pass systems.
The key to remember is Slave devices can only be statically bound to a Master and cannot accept a token. Masters can accept a token. Now on to how you can identify a device.
Identifying a Device:
All BACnet devices can be identified with a document called the PICS (Protocol Implementation Conformance Statement). This document has all the data needed to identify the type of the device and the features and functions it supports. It also contains the BIBBS (BACnet Interoperability Building Blocks Supports). The BIBBS is very important because it differentiates the different type of BACnet MS/TP. Yes, there are multiple.
The Different Type of BACnet MS/TP Masters:
There are many classifications of Master type devices under the BACnet MS/TP specification but we will focus on the three you are most likely to encounter – Building Controllers, Master Initiating devices and Master Responding devices. Please note the terms Master Initiator and Master Responder are not BACnet MS/TP specification terms. BACnet MS/TP has no naming associated with the different functions and we think that is a shame. Hence the RTA terminology for explanation purposes.
BACnet Building Controller Devices B-BC:
These devices are the central control systems in the BACnet system, much like PLC’s and controllers we are used to dealing with. These devices can do it all. In the PICS you will see a Device Profile of BACnet Building Controller (B-BC) and a data link layer option of MS/TP Master.
Master Initiator:
These Devices can establish connections to other BACnet MS/TP devices. They initiate a “Who is” call to identify devices on the network. They can then read and write data from other devices on the network. The PICS classification is a BACnet Application Specific Controller (B-ASC) with a Data Link Layer of MS/TP Master. In the BIBBS you would see a –A on the end of each supported Building Block.
Master Responder:
These devices can respond to “Who is” requests from initiators with an “I am” response. These are the devices we would normally think of as Slaves. When they are actually BACnet MS/TP Master Responders, they can accept a token and be discovered on a network by replying to a “Who is” request with an “I am” response. The PICS classification is a BACnet Application Specific Controller (B-ASC) with a Data Link Layer of MS/TP Master. In the BIBBS you would see a –B on the end of each supported Building Block.
While the two devices play different roles the only difference between the classification of the two Masters is a –A or –B at the end of supported Building Blocks in the BIBBS.
If you have any questions, send us an email at DrewandScott@rtaautomation.com.