Digital inputs filter plugin for Data Loggers

Latest version: 5.0.1 build 1126. November 28, 2025.

The Digital Inputs Filter is a plugin for our data loggers (for example, Data Loggers) that reduces redundant records by exporting only meaningful changes or events from digital I/O modules. It operates on binary signals (True/False or 0/1) provided by devices such as ADAM-6050, ICP-CON 7041, MOXA ioLogik E2210, or similar. These devices connect via Ethernet or serial links to monitor discrete inputs and present each input as a variable (DI0...DI15). The filter sits after a parser module (MODBUS RTU, MODBUS/TCP, ADAM, ICP-CON or ASCII) and controls whether a received packet should be forwarded to export modules (database, Excel, Access, DDE, OPC) or suppressed.

Download  | PDF manual

Why use the filter - practical benefits

• Reduce database size and network traffic by exporting only relevant digital events (transitions or configured states).
• Improve signal/noise ratio for analytics and reporting because repeated identical states will be exlcuded.

How it works - configuration and behavior

The module evaluates variables with names ending DI0 through DI15 supplied by the parser (in the parser you can define a custom name). Default operation ignores all packets until you define rules for one or more inputs (up to 16). Each rule can specify:

• Which DI pin to monitor (DI0...DI15).
• Trigger condition: export on state change (low → high or high → low) or always export the current state.
• Initial state handling: choose an explicit initial internal trigger state or set to "Undefined" so the first reading is exported and subsequent readings are compared to the actual samples.
• If multiple rules match a single incoming packet, the filter clones the packet and exports one packet per configured input, adding a message to each clone that identifies the input and the event. If the parser returns a DI variable with an empty value, the filter ignores that variable for the current packet.

Examples of use with Serial Data Logger

Example - Door open/close logging. Incoming (from MODBUS RTU parser):

DI1=0;DI2=1;DATE_TIME_STAMP="2025-11-28 08:00:00"

Later:

DI1=1;DI2=1;DATE_TIME_STAMP="2025-11-28 08:00:00"

Configuration: define a rule to export when DI1 changes state.

Result: the first packet is ignored (no prior state or set initial state to match); on change to 1, the filter forwards a packet with an appended message like: "DI1 changed 0 → 1". The export target could be an SQL Server table with columns: timestamp, input, old_value, new_value, message.

Best practices and notes

1. Define only the inputs you need to monitor to minimize system load.
Choose the correct initial state option depending on whether you want a first-sample event or to suppress it.
2. Combine message-rich exports (databases, OPC) with archival exports (CSV/Excel) to support both real-time monitoring and historical analysis.
3. Test the filter with a simulated data stream or brief logging session to confirm behavior before deploying to production.