Industrial Data Xchange (IDX) is a South African based IT industrial company with a global focus specialising in the provision of data communication solutions. On this blog, IDX experts comment on industrial communication protocols, trends, and tips as well as what is on the go in the labs at IDX.
In November and December 2015 we were hard at work with a
major update of the IDX StarNET Gateway. Firstly, we moved the entire gateway logic
into our IDX 8 Data Exchange framework, which has a couple of benefits. The
gateway is now part of the growing IDX 8-based software gateway family that is
operationally proven yet has powerful configuration capabilities that the old
text-file based configuration approach just won't match. IDX 8 also contains a number
of existing connectors that we felt would be beneficial to have in the StarNET
world, such as MODBUS RTU/TCP.
We also added two new StarNET interface types to address the
increasing number of requests for ESP communications. So the gateway can now
also act as both an ESP Tributary and Controller in the standard J/K table
exchange mode at all the standard ESP baud rates via one (or more) of the
built-in RS-232/422/485 serial ports.
A combination HDLC/ESP interface was commissioned and tested
at US Steel’s East Chicago Tin mill in December and is now running live as a
replacement for an old COMsoft SNL-based solution.
Finally, we moved the StarNET gateway to a new hardware
platform that allows for greater flexibility on the expansion side of things,
meaning practically any fieldbus with an available PCIe/PCI interface can now
be accommodated inside the gateway. We continue to add interfaces by popular
demand or when customers explicitly require a particular type of connection.
Looking forward, we hope to add a StarNET HDLC Master
implementation in the not-too-distant future as we currently already have a stand-alone
implementation we use for all our testing purposes.
Last week IDX were called to site at a large commercial residence building in Pretoria, South Africa. Where our client was implementing an IoT solution for remote monitoring and control of various HVAC and power systems in the building. The control system the SI chose in this case was a Modbus enabled Industrial Micro PC called the Revolution PI. The client had Modbus sensors connected to boilers, air conditioning systems, ventilation systems and power meters. The Modbus communications between the controller and the sensors were intermittently failing due to various installation and implementation faults:
1. Earthing and Shielding Within any fieldbus communication installation, one of the requirements to ensure uninterrupted operation is to implement adequate grounding and shielding techniques. Effective grounding and Shielding help to prevent electrostatic and electromagnetic pickup, which can lead to failed communications.
Some of the shielding and grounding requirements for a Modbus RS4…
In this blog, I will discuss the steps involved in getting the Netbiter to record and display values coming out of the ComAp Generator Panel, so that one can do remote monitoring and control of the generator. The Netbiter Model used in this case is the EC220 and the panel used is the InteliLite AMF 26 P. The steps followed here can be applied to any MODBUS device due to the generic nature of the Netbiter.
Step 1 - Physical Connection Check that the Control Panel has a communication module attached to the back of it. You will need to establish the medium (RS458/RS232) and the protocol spoken (MODBUS RTU/ASCII) - all of this information will come from the user manual of the generator. Finally confirm the communication settings (baud rate, parity, stop bits, etc) - these can sometimes be changed so check what they are on the actual panel. In this case, we have the following settings: MOUBUS RTU over RS232 (you'll need an external converter to convert the RS232 to RS485). Baud rate: 9…
Time to dust off the cobwebs and do some "legacy" development! In this blog, I'm going to show you how to get to a point where you can start writing Java code on the HMS Anybus Communicator. I find that it doesn't matter what language you code in, the tricky bit is getting to the point where you can simply create and run the time-honoured "Hello World!" program. Using new editors, sorting out dependencies, making physical hardware connections can take up a big chunk of your time.
First, some information on the hardware platform: The Anybus brand from HMS contains hundreds of gateways (or protocol converters) that can be used to convert between common industrial communications protocols such as PROFIBUS, MODBUS, Ethernet/IP, ControlNet, DeviceNet, PROFINET, CANOpen, J1939, etc. Check out anybus.com for a full list of protocols supported out of the box. Using these gateways you can for instance read registers from a MODBUS device and make them available to a PR…