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.
IDX 8 Historian
Industrial Data Historians are fairly common place.
Generally they fall into two categories: enterprise-class historians such as
OSISoft PI and Wonderware Historian, which bristle with features and carry a
correspondingly enterprise-class price tag, and then there are the “cheap”
historians (or sometimes glorified file loggers), that log data, but usually
have significant performance or other functional limitations.
The IDX 8 Historian is aimed at users that don’t want to
spend the earth to get a solution that fits in between these two cases, that
will provide data logging that is extensible to fairly large capacities and without
the multitude of features most users don’t know how to or even wish to use.
Our historian is built on Microsoft SQL 2008 (or above). Certain
features introduced in SQL 2008 have made it viable to implement data logging
with performance we were happy with (rough ball park figures show we routinely
achieve around 20-30K sustained writes and 30-50K reads per second using SQL
Express using ordinary workstation hardware). We are aware there are more than a few other
historians built on SQL. However, we believe our approach is a little different
and we like to believe this is what makes our Historian more than just another
SQL data logger. Firstly, in order to address cost issues, a primary design
goal for us was to ensure the Historian could use any edition of SQL server.
You may be aware a SQL server license, particularly for the Enterprise edition
can become quite pricey, and is often a non-starter for SMB’s that wish to add
the benefits of historical data to their production analysis. Thus, the IDX
Historian is able to run on anything from the Express (free) edition up to the
Enterprise edition, although we envisage most customers won’t gain any
advantage of going beyond the Standard Edition for IDX Historian use. The IDX
Historian segments data across tables and multiple databases, so unless you
plan to store more than 10GB of raw data per day (the database size limit for
SQL Express 2008 R2) or need performance beyond what Express edition can
provide (Express is limited to the use of 1 CPU and 1GB of RAM), the free
Express edition is the likely starting point, from which you can always update
to SQL Standard if required.
To start using the Historian, the first and generally only
configuration step required is to set the Period and Segment Count settings.
The Period setting defines how data is split across SQL databases, currently
Month, Week or Day. The Segment Count setting defines how data is divided across
tables within a database. For example, if you select the Period to be Day, if
the Segment Count is set to 12, the data for each day will be split into 12
tables spanning two hours each. Point of
note here is that once the Period and Segment Count settings are defined, they
cannot be changed without backing up and clearing any existing historical data.
Therefore, these settings should be chosen with care.
Currently, real-time data logging is supported via IDX 8
Data Exchange. IDX 7 also supports logging via the Historian Client which
allows IDX 7 instances on different machines to safely log data into the
Historian. The Historian Client uses disk-based buffering to ensure captured
real-time data is not lost in the case where communications between the client
and server is lost or if the Historian server machine is restarted for example.
The IDX Historian Client has both .NET and COM registered APIs that can be used
to integrate real-time data from other sources, and is freely available on
request, along with C# and C++ code samples. Additional historian configuration
is performed on a per-tag basis via IDX Tag Manager (or on the slots in IDX 7),
to set options such as data compression (5 compression methodologies are implemented,
including the Swinging Door algorithm).
Data can also be queried from the SQL database directly,
allowing for additional data analysis and reporting, without the requirement
for additional OLEDB or other clients.
Viewing "interesting" historical data with the IDX Historian data viewer.
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…
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…
We are proud to
announce the IDX ifm VSE Gateway, our custom cost-effective gateway solution
for the ifm VSE002/100 vibration monitoring diagnostic devices. The IDX ifm VSE Gateway is a DIN-rail mountable industrial
communication gateway that allows real-time vibration monitoring data from the
ifm VSE diagnostic device series to be made available via a variety of standard
industrial data protocols and/or interfaces. The Gateway has been specifically designed to work with the
ifm VSE002 and VSE100 monitoring devices, and each gateway connects to up to 10
VSE devices via Ethernet. The IDX Gateway exposes the VSE vibration monitoring
data via interfaces based on the RS-232/485 or Ethernet interfaces, such as
MODBUS TCP/RTU and OPC Data Access (DA). Alternatively, a custom protocol
interface can be cost-effectively developed if required. The gateway is configurable using the IDX software suite
using one of the Ethernet connections, allowing for the possibilities of exposing
diagnostic data …