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 in that power is right in the wiring for the network. You can power a bunch of devices right from the network.
Today we use a lot of modules, small PCB’s, for our OEM solutions. We can put our gateway software on these devices. We can put your custom code in there and we can make these devices support your proprietary protocol.
And if one of these modules doesn’t meet your needs, we can do custom hardware, but that often requires some significant volume.
We can do most anything to meet your OEM requirements. You can take advantage of all the technologies we use, the off the shelf modules we use, and the creativity of our engineering staff to meet the needs of your custom applications. To get started, simply click the Contact Us button at the top of our home page.