INTRODUCTION
We are well aware that when customers begin to use digital conditioners that they start on a journey of learning a new language. There are many advantages to using digital solutions, but there is a lot to learn, and the prospect of spending time learning to use a new technology can rule out these products when timescales are a factor. This blog is the first entry of an introduction to the language used in digital conditioners.
Mantracourt provide a range of signal converter modules which take load cell or strain bridge inputs and provide a data output in a variety of bus and protocol formats.
Most of our customers are quite happy with the concept of analogue signals which are output from signal conditioners and the methods of using that signal to display or log information. With this in mind I am only discussing the output from the conditioner and the ways that this data is transferred to the user interface or display.
This entry will focus on the physical connection. This connection can be on a signal bus (i.e. multiple devices connected to the same set of wires) or a simple point to point link. The useful aspect of the physical connection is that as long as the physical connections use the same interface it doesn’t care about what the data is that is sent over the link.
As an analogy, it’s quite readily accepted that two mobile phones can connect to each other and send an audio signal. It doesn’t care about the language that you speak, just that the protocol between the handsets match. However if we try to use a handheld walkie talkie we won’t be able to communicate with the mobile phone. Essentially the two handsets are sending the same audio information but because the communication methods are different it is not possible to pass on any information. This is the same for the physical interface between digital devices. If you have an output that is of one type at the sensor, it must be the same at the receiver.
In our products, we focus on four physical interfaces:
CAN
Lots of our customers request controller area network (CAN) compatible products. Often people are unsure of the difference between the CAN serial interface and the protocol that sits on top of that interface. Physically CAN nodes communicate using a differential balanced pair of wires and it is designed to be robust and reliable in busy and noisy environments. A common observation with CAN is that users don’t realise that it requires a termination resistor at each end of the bus in order to function properly. It is heavily used in the automotive sector and is gaining traction in other sectors (i.e. control systems).
There are certain aspects of CAN that make it unique in our list of physical connections. Unfortunately the drivers required for use on a PC tend to be proprietary and this is probably the biggest drawback when supporting CAN on a PC. This means that when we provide software to configure the product it will only work with a specific hardware adapter (in our case ixxat). Of course it is still possible to use other hardware interfaces but it will require the user to develop their own custom software in order to configure and talk using that interface.
USB
USB is commonly used on PCs and mobile platform devices. It is probably the easiest platform to use but of course has its limitations. It is often used in office, test and laboratory applications as it is so simple. The interface itself allows us to provide software that can automatically connect to a device, configure and collect data. It removes many of the more difficult aspects which arise when customers are introduced to digital conditioners as many of the configuration steps in the other options are hidden away.
The problem with USB is that it will only work on cable lengths of less than 5 metres and it is not generally used to connect to industrial controllers. There is also a limit on the data rate that can be achieved but this is often related to the PC performance rather than USB. Another note of caution is in the use of USB Hubs. For reasons I won’t dwell on they often cause trouble. Be careful when using HUBS and try to avoid daisy chaining them together.
RS485
RS485 is a serial interface suitable for signal busses. As with CAN this serial format also uses a differential balanced signal pair to communicate and it needs to have termination resistors at each end of the bus (even in single point to point applications). It is capable of very long links (1200 m at 100 kB/s) and is commonly used in industry for logic controllers. Unfortunately there is an added complication with RS-485 where it can be used in either a 2-wire (Half duplex) or 4-wire mode (Full Duplex). This often changes a configuration setting on the serial interface hardware. It is widely available and the connection to a PC is standardised. Most serial port interfaces simply show up as a COM port on your PC. This means that we can be much more flexible with our configuration software on this interface. As far as a PC is concerned it is presented exactly the same as an RS232 connection.
RS485 is ideal for industrial applications as it has a good degree of fault tolerance and noise immunity.
RS232
RS232 has been the standard point to point communication channel for what seems like forever. The interface to a PC is the same as RS485 although the hardware is different (either a different setting on the hardware or a different device, depending upon the vendor). It is very simple but it can only operate as a single point to point link. As such it is often used for evaluation and doesn’t require the termination resistors we have talked about. RS232 is suitable for short cable lengths up to 15m and is not as noise immune as RS485 or CAN interfaces.
So, we now have our communication interfaces. Each of the interfaces above can have different protocols, or in keeping with our mobile phone analogy languages, transmitted along the physical wires. As with any protocol there are pro’s and con’s associated with them. Some are very simple to implement and debug but they tend to be slow. Others are very quick but debugging and explaining their operation tends to be more challenging. We offer a number of industry standardised and proprietary protocols. The different protocols will be discussed in our next blog on this topic.
For more detailed advice and support please contact us at mantracourt.com.
This article was written by Dr. Clive Vallance, Senior Electronics Engineer, Mantracourt Electronics Ltd
Download PDF
