DAQFactory Introduction

Recently I had an assignment to interface and display sensor data on an old Windows XP laptop. The client was reusing some existing infrastructure, sensors and serial communication radios, to display real-time sensor information at a remote office location. The original effort was to interface Excel serially to existing sensors. The client had already selected a 4-20mA DAT3015-I sensor interface that used Modbus protocol.

I hadn’t planned on the Modbus protocol. Although I have worked with data communications with sensors for more than 35 years, I had never worked with Modbus. Modbus is an application layer messaging protocol that provides client/server communication over different types of busses and networks. Modbus has been a serial de facto standard since 1979 and has a request/replay PDU structure.

Although there are Excel VBA code to support Modbus, I assumed that if the standard has been around since 1979 with companies are still building Modbus protocol hardware, there must be commercially available software for Windows XP that would work for this application.

I performed an industry survey and found about 10 software packages that met our requirements. I selected DAQFactory Express since it has custom screens that contain multiple real-time indicators and graphs, it appeared to be a robust environment with flexible compatibilities including custom coding, and the Express version is free. The free version limits the number of pages (2), I/O (8 channels), and screen components (11).

The display used a single screen and had indictors for

  • 2D trending graph showing real-time sensor data
  • Instantaneous sensor values in mA and GPM (converted data)
  • Signal status using colors and blink text when an error was detected
  • Real-time operating controls (stop/continue), reset, test mode and mode indicators
  • Error feedback
  • Display control (graph data and error thresholds)
DAQFactory Finished Product

DAQFactory has multiple setup screens for device setup (physical interface and protocol), channel setup, conversion formulas, and others. DAQFactory provides a lot of flexibility in setting up your device interface and how data are handled within the environment. DAQFactory is not limited to Modbus protocol and supports even custom interfaces.

I chose to use DAQFactory sequences, which are code segments similar to C in syntax and is object oriented. For this application the primary sequence is GetData that is used to get sensor current readings, the device name, and reset coil status (a Modbus thing). All other sequences work with runtime operation such as stop/continue and entering/exiting test mode.

Sequences have a nice try/catch structure to handle events like data timeouts. With the Modbus protocol and server requests data from the client. Sometimes the message is missed and no data are received from the client. The try/catch is perfect to handle this type of error. To read data from the DAT3015-I, a simple method was used that specified the data type, address, and number of values.

inputData = Device.DAT3015.ReadHoldingS16(1,40015,2)  // read registers (15 & 16)

This call created the properly formatted Modbus string that was sent to the client and received the response and placed the 16-bit signed data into an 2-D array, inputData. To get the instantaneous values from the most recent data a simple array access was used.

Outfall_uA = inputData[0][0]     // outfall uA value reg 40015
Overflow_uA = inputData[0][1]    // overflow uA value reg 40016 

The most recent data are then converted and added to the real-time graphical display using the AddValue method.

 // convert data algorithm, data in uA
 // if < 4mA GPM = 0
 // GPM = uA * 1.25 - 5000
       
 // Outfall sensor
 if(Outfall_uA < 4000)
    OF01_Outfall.AddValue(0)
 else
    OF01_Outfall.AddValue(Outfall_uA * 1.25 - 5000)
 endif
  
 // Overflow sensor
 if(Overflow_uA < 4000)
    OF01_Overflow.AddValue(0)
 else
    OF01_Overflow.AddValue(Overflow_uA * 1.25 - 5000)
 endif 

A 2D trending graph was used for each sensor and displays GPM verses time. The graphs auto scales in the y-axis (GPM) utilizing the Min/Max expressions on the channel data (e.g. Min(OF01_Outfall)). The time scale is user adjustable using the runtime display control at the button of the display. This setting uses a registry variable and is retained between DAQFactory restarts.

Instantaneous values for mA and GPM are displayed for each sensor using Variable Value Components. The value is set using an expression to the most recent reading and conversion (e.g for mA Overflow_uA/1000, for GPM OF01_Overflow[0]). The [0] index is the most recent value. No color changes or actions are associated with these objects.

Each sensor has a prominent display using a Descriptive Text Component (OutfallStatus, OverflowStatus). An inline if expression on the sensor uA variable is used to generate either a 1 (good) or 0 (problem).

iif(abs(Outfall_uA) < Registry.signalThreshold,0,1)

Overall the project was a success. The develop time was short and help by the client sending the DAT3015-I for integration test prior to installation. The client was able to install and add the DAQFactory project to the Windows XP laptop. Once the client found a problem with an interface cable, the system ran without an issues. I highly recommend DAQFactory.