Our company, Industrial Data Xchange, shares its name with our software suite, IDX. IDX first came into being in 1995 as an industrial data communications suite at a time when there were few options when interconnecting real-time data systems between vendors. The original IDX concept is fairly straightforward – it provides a pool of tags (or Slots) to which various modules, akin to plugins, can commonly read and write real-time data using Actions. The trick is that the modules implement the custom code to interface with a specified system but also know how to share data into the IDX tag pool. Therefore, as long as one has the modules developed for the system one wants to share data between, IDX becomes a common real-time data hub. Over time, many PLC, DCS and protocol-specific modules were developed, but for us, the most frequently used are OPC DA, IDX TCP (our proprietary TCP protocol), @aGlance, Gensym G2 and MODBUS, in the various flavours.
Today, IDX 7 is largely still based on the original IDX concept, and has proved reliable while extensible over the years and is still in use as our primary data exchange product. However, early 2011 we released IDX 8 which, while carrying the same name as its predecessor, now has a much wider functionality footprint. Whereas IDX 7 addresses real-time data exchange only, IDX 8 introduces a common platform for all our industrial communications solutions. The goal is to tightly integrate our various products in a common, user friendly platform that can scale from simple, single machine installations to enterprise-wide deployments which can be managed from a single point.
Currently, IDX 8 provides Tag Management, Data Exchange, Alarms and Events and Historian functionality. These function modules are separately licensed items that provide specific, yet often overlapping functionality:
· Tag Management - synchronise tag configuration between systems
· Real-time Data Exchange – share real-time data between systems
· Alarms and Events (Emails/SMS) – generate human-readable events
· Historian – store real-time data history
In the next few blog posts, will be providing a general overview of the various modules in IDX 8, interesting features and new developments.
Popular posts from this blog
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 req
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. S tep 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 RS
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