One of the things that RTA doesn’t promote very much is our ability to do custom OEM solutions. These solutions serve customers with applications scenarios that have proprietary communication protocols, a unique footprint, special I/O requirements or some special logic.
We’ve done a lot of this work over the years. We’ve made custom hardware for all sorts of applications. For many, many years, customers have used our custom OEM hardware in automotive tool changer modules.
Today we mostly do custom configurations and brand labels of our off the shelf gateways. A lot of these are higher volume applications where the customer wants to use the same configuration in every module. In a lot of these cases, we put the customer’s logo on all the web pages and preset most or even all the configuration so that the unit can be easily integrated into the customer’s equipment. For example, in our 460MSBS, Modbus TCP to BACnet gateway, we would preset all the properties that are read from as BACnet device data. We would predefine all the destination Modbus registers for the Modbus side and we might even set the IP addressing. Really, anything is possible.
Unfortunately, there are still a lot of devices with proprietary protocols around. I don’t expect that to change. There are some management types and some engineers that just like having their own communication protocol so that outsiders can’t access their equipment without authorization. That can make some sense if the protocol allows a device to modify safety-related or critical operating parameters and change how the equipment works.
But often that’s not the case. Instead, the company has some software package that accesses their device and does reporting. To preserve the market for their software package, they might use proprietary communications. If they used some open protocol, someone could write a driver and pump the data into Excel, limiting sales of their software package. I know of an inspection company that uses this exact strategy. We’re creating an OEM module for them that provides access to their equipment from Allen-Bradley PLCs, Siemens PLCs and Modbus TCP Client devices.
We’ve done a lot of OEM packages that turn these kinds of proprietary protocols into open protocols. If you ever have a proprietary protocol and need it translated to some open standard, it can be a very simple and easy process or it can be extremely difficult and time consuming. It depends on the number of commands in the proprietary protocol, how much data is supported, how fast it communicates, and what the transport protocol is.
The transport protocols can vary. We’ve seen a lot of RS485 and Ethernet, but also a fair amount of CAN. Controller Area Networking (CAN) is a popular mechanism for easily connecting devices on a local network. It’s fast, with speeds up to 1MBaud, it’s easy to use, and there is little effort for the programmer since all he does is put the data block in the transmit registers. CAN has the additional benefit …