How a Partnership with Matrix Technologies Benefits You

How a Partnership with Matrix Technologies Benefits You

We use loyalty programs daily for groceries, fuel, travel, clothing, entertainment and other purchases. These programs provide mutual benefit for the consumer as well as the business. Consumers receive incentives to patronize a particular business and the businesses receive more predictable sales.

An engineering partnership is another mutually beneficial relationship. Developing a partnership with an engineering services and systems integration company like Matrix Technologies, Inc. provides you with access to the multitude of experiences our 300-plus employees have acquired collectively over the past 40 years. We often leverage these experiences to help you develop clear project definition of scope, schedule and budget, thus allowing more diversification for your employees to oversee multiple capital investments. Consistent project execution and implementation are propagated.

A core engineering team assigned to the partnership ensures continuity on your projects, clear definition and understanding of roles and responsibilities, value-based engineering, and protection of intellectual property. This mutually beneficial model supports corporate standards development and enrichment based on industry best practices. The partnership may be expanded to also address document control procedures and templates.

In short, a partnership with Matrix Technologies, Inc. allows you to tackle complex projects with confidence, knowing we understand your unique operation.

Benefits of Partnership

  • Dedicated core team
    • Continuity and familiarity
    • Mutual benefit
    • Quick response and mobilization
    • Clear definition of roles and responsibilities
    • Protection of intellectual property
  • Standards
    • Contribute to corporate standards development and enhancement based on best practices related to industry and safety
    • Document control procedures and templates
      • Level of detail required to meet expectations
    • Consistent project execution and implementation processes
  • Experience
    • Identify value-based engineering options to address original project basis
    • Identify and manage timeline and budget risks throughout project
    • Interface to contractors
      • Communicate scope and timeline requirements
      • Reduce RFIs and COs through construction management
    • Access to a vast knowledge base of process and technology advancements
  • Streamlined bidding process
    • Engineering services
    • System integrations services
    • Construction services
    • Pre-negotiated term and conditions
    • Negotiated rates

Matrix Technologies is one of the largest independent process design, industrial automation engineering, and manufacturing operations management companies in North America. To learn more about our manufacturing operations management capabilities and manufacturing process control solutions, contact Deborah Zimmerman, PE, Director of Project Management.

© Matrix Technologies, Inc.

RS-232 is Simple, Robust Serial Communications Method

RS-232 is Simple, Robust Serial Communications Method

All communications are serial communications, from the high-tech data bouncing around satellites to synchronizing your phone to a computer. Even human speech is a form of serial communication. This article discusses a simple yet robust communication method that has been around for nearly 60 years: RS-232.

RS-232 is a standard that defines the electrical characteristics and timing of signals, the meaning of signals, and the physical size and pinout of connectors. RS-232 was developed in the early 1960s and is still in use and remains relevant today. Throughout this article we use RS-232, but RS-422 and RS-485 have basically the same functionality.

All Serial Communications Use the OSI Model

Before looking at RS-232 specifically, let’s discuss the OSI model for data communications. OSI is “Open Systems Interconnection.” The OSI model has been around since the late 1970s and is still very relevant. The model partitions a communication system into seven abstraction layers.

A layer serves the layer above it and is served by the layer below it. For example, a layer that provides error-free communications across a network provides the path needed by applications above it, while it calls the next lower layer to send and receive packets that comprise the contents of that path. Two instances at the same layer are visualized as connected by a horizontal connection in that layer. See the accompanying illustration.

OSI model
OSI model

RS-232 Interfaces are Still Useful

Thanks to their simplicity and past ubiquity, RS-232 interfaces are still used—particularly in industrial machines, networking equipment, and scientific instruments where a short-range, point-to-point, low-speed wired data connection is fully adequate.

Per the OSI model the physical layer (level 1) is responsible for the transmission and reception of unstructured raw data between a device and a physical transmission medium. It converts the digital bits into electrical, radio or optical signals. RS-232 resides in the physical layer since the specification defines voltage levels and wire connections (pin-out). Although most devices climb up the layers slightly by adding stop bits and parity, which for practical purposes can be thought of as being part of the RS-232 specification.

Physical connections for serial communications use “D” shell connectors, named because they are shaped like a “D”. Below are DB-9, DB-15 and DB-25 connectors. RS-232 initially used the 25-pin but has evolved to the 9-pin. RS-232 communications may be involved if a piece of equipment has any of these.

DB-9, DB-15 and DB-25 Connectors

The Modbus standard defines an application layer messaging protocol, positioned at level 7 of the OSI model that provides “client/server” communications between devices connected on different types of buses or networks. It standardizes a specific protocol on a serial line to exchange Modbus requests between a master and one or several slaves. Basically this means that a Modbus-compliant device provides for the full data transfer per the OSI model. As a software developer using two Modbus devices, we can work at the highest application layer. We can send and receive data to a specific data location on a specific device and we’re done. The software layers in the OSI model are still there, but are done by the Modbus protocol.

Modbus is mentioned because it has been around forever, is simple, and is well documented. Many original equipment manufacturers (OEMs) still use Modbus protocol for data communications. Much of the data is useful not only for proper operation but for energy consumption. As OEMs modernize and get smarter about their equipment they make that data available and Modbus is still a viable way to extract the data. Of course we can also send data to OEM equipment via an RS-232 connection. This allows sending setup and running parameters to the equipment.

Interfacing to RS-232 Can Be a Challenge

As mentioned above OEMs still use RS-232, but we also need a way to interface to the OEM machine. Obviously computers can be used, but they are not as easy as one would imagine. Computers originally had an on-board RS-232 port, but that stopped years ago. A USB to RS-232 adapter is now required. The custom software is required to read and write data. In our industrial control environment programmable logic Controllers (PLCs) are extremely common and can be used to interface with RS-232 devices. Many PLCs still have an onboard RS-232 interface that can be used to transmit and receive simple data, like a scale weight. Software is still required, but can be much simpler.

Matrix has had experiences where we were asked to retrieve and send data from OEM equipment via Modbus. To do this we simply purchased a Modbus interface module, such as Prosoft. Understanding, collecting and presenting the OEM data was still required, but we did it at the application layer. All software required for the other layers was part of the Prosoft module.

Home-grown Protocol Creates Issues

Some OEMs may create their own protocol and use the RS-232 interface. The OSI model is still used, but the software to read and write the data per the OSI model is missing. In these cases it is necessary to create the layers per the OSI model. A protocol analyzer is a handy tool in these instances to help troubleshoot protocol issues. Sometimes documentation can be misleading or just missing.

Matrix has had experiences where a piece of equipment had valuable data and a description of how the data was assembled and sent, but that was all. The equipment just sent data out an RS-232 port. We were required to create the software to read the data without any structured protocol. In this case it isn’t necessary to build the entire OSI model, but conceptually all the layers are accounted for.


RS-232 was developed back when TV was in black and white, a radio in your car was an option, Gilligan had an island, and Watergate was just a hotel, but it is still relevant today. Just understanding that it exists and that it is possible to send and retrieve various operational parameters is important.

Matrix Technologies is one of the largest independent process design, industrial automation engineering, and manufacturing operations management companies in North America. To learn more about our automated manufacturing system capabilities and manufacturing process control solutions, contact Bob Taylor, Senior Engineer.

© Matrix Technologies, Inc.