ICF Ethernet-only communication, by design

Overview

The Instrument Control Framework (ICF) is a modern instrument communication architecture used by several gas chromatograph platforms. A defining characteristic of ICF is that it supports Ethernet-based communication only.

This requirement is not configurable and does not depend on the chromatography data system (CDS) in use. Instruments that rely exclusively on serial communication protocols such as RS-232 cannot support ICF-based digital control.

This limitation exists at the framework and instrument architecture level. It is not caused by Chromperfect or by any other third-party CDS, and it cannot be resolved through software drivers, protocol converters, or external adapters. A new video about this topic is now available on the Chromperfect YouTube channel

Watch our YouTube video for a detailed breakdown

What Is ICF?

ICF (Instrument Control Framework) is a vendor-developed communication framework designed to standardise how instruments exchange digital control commands, method parameters, status information, and runtime data with external software.

Unlike earlier serial-based control models, ICF was designed around modern network principles, including:

• Persistent Ethernet connections

• Structured message-based communication

• Deterministic timing and synchronisation

• Improved diagnostics and error handling

• Compatibility with contemporary operating systems and security models

From its inception, ICF assumed the presence of native Ethernet capability on the instrument itself.

ICF Ethernet-only communication - Ethernet Is a Mandatory Requirement

ICF does not treat Ethernet as a convenience layer. It treats it as a core dependency.

As a result:

• RS-232 communication is not supported

• USB-to-serial adapters do not provide compatibility

• RS-232-to-Ethernet converters or network serial hubs do not work

• No CDS can emulate or bypass ICF requirements

If an instrument does not contain Ethernet hardware capable of speaking the ICF protocol natively, ICF communication cannot be established.

This is a hard architectural limit of the framework.

Why RS-232 to Ethernet Converters Do Not Work

A frequent misconception is that a serial-only instrument can be made ICF-compatible by adding an RS-232-to-Ethernet converter or serial device server. While these devices expose a network endpoint, they do not change the instrument’s communication model.

Such devices only tunnel raw serial data over a network. They do not:

• Implement the ICF protocol

• Provide network session management

• Support ICF message framing or state awareness

From ICF’s perspective, the instrument remains serial-only. The presence of a network cable does not equate to Ethernet-native ICF capability.

Example: Shimadzu GC-2014 (Illustrative Case)

One commonly referenced example is the Shimadzu GC-2014, which was supplied in multiple configurations during its production life.

• Ethernet-enabled GC-2014 systemsThese units include controller hardware capable of supporting ICF communication.

• RS-232-only GC-2014 systemsThese units lack Ethernet capability and cannot support ICF digital control.

In this specific case, manufacturer-supplied hardware upgrades may be available that replace or augment the controller, adding native Ethernet functionality. Where such upgrades exist, they can enable ICF compatibility because they fundamentally change the instrument’s communication architecture.

External converters do not achieve this.

This example is illustrative only. The same principles apply broadly to all serial-based instruments, including older gas chromatographs originally designed around RS-232 communication (for example, early serial-only generations of network-optional systems).

Available Options for Serial-Based Instruments

Laboratories operating serial-only instruments are not without options. The appropriate path depends on required functionality, automation level, and long-term planning.

1. Manufacturer Hardware Upgrades (Where Available)

Some instruments can be upgraded with vendor-approved Ethernet controllers or interface boards. This is the only path that can enable ICF digital communication.

Availability depends on:

• Instrument model and revision

• Manufacturer support lifecycle

• Regional service and parts availability

Where supported, this approach provides full ICF compatibility.

2. Native Serial Drivers from Third-Party CDS Vendors

Many third-party chromatography data system vendors — including Chromperfect — have developed in-house native serial drivers for specific instruments.

These drivers communicate directly with the instrument over RS-232 and often provide capabilities well beyond analog-only acquisition, including:

• Instrument method control

• Autosampler control

• Event timing and coordination

• Improved metadata capture compared to analog workflows

• 
  

While this approach does not involve ICF, it represents a significant step up from analog-only acquisition and remains a practical and widely used solution for legacy instruments.

Importantly, this functionality exists outside of ICF and does not conflict with ICF limitations.

3. Analog Data Acquisition

Analog acquisition remains an option where digital control is not available or required. External analog interfaces can capture detector signals reliably, but with inherent limitations:

• No digital instrument control

• Reduced metadata and audit information

• Increased manual interaction

This approach is often used where instruments remain analytically sound but cannot be economically upgraded.

4. Planned Migration to Ethernet-Based Instruments

For laboratories prioritising:

• Full automation

• Modern compliance workflows

• Long-term operating system support

• Standardised network infrastructure

  
  

Migration to Ethernet-native instrumentation is often the most sustainable long-term solution.

CDS Independence and Clarification

It is critical to distinguish framework limitations from CDS capability.

ICF constraints apply before any chromatography data system is involved. If ICF cannot establish communication due to missing Ethernet hardware, no CDS — regardless of vendor — can change that outcome.

Conversely, serial-based control implemented via native CDS drivers is a separate and valid communication model, independent of ICF.

Key Takeaway

ICF is Ethernet-only by design.

Serial-based instruments cannot support ICF digital communication, and no adapters or protocol converters can alter that fact.

However, serial instruments are not obsolete. Manufacturer hardware upgrades, native serial drivers from third-party CDS vendors, analog acquisition, and planned migration all remain viable paths depending on laboratory requirements.

Understanding where ICF fits — and where it does not — is essential for making informed integration and upgrade decisions.