CIP Suite — EtherNet/IP Nodes

A suite of nodes for communicating with Rockwell Automation and Allen-Bradley PLCs, and other CIP-capable devices, using the EtherNet/IP (Ethernet Industrial Protocol) protocol.

Overview

The CIP Suite connects FlowFuse flows to industrial control systems across the full spectrum of Rockwell Automation hardware, from modern ControlLogix and CompactLogix controllers to legacy SLC 500 and PLC-5 systems. It provides dedicated nodes for reading and writing tags, continuous tag monitoring, tag discovery, controller management, and advanced CIP objects covering motion, energy, time synchronization, security, and more.

This is a FlowFuse Certified Node. Unlike community nodes, which vary in quality and can go unmaintained without warning, FlowFuse vets Certified Nodes for quality, security, and support, and maintains them on an ongoing basis. Read more about Certified Nodes. It is built on the st-ethernet-ip protocol driver.

What is EtherNet/IP?

EtherNet/IP (Ethernet Industrial Protocol) is an industrial network protocol that adapts the Common Industrial Protocol (CIP) to standard Ethernet. It's the primary communication protocol used by Rockwell Automation and Allen-Bradley industrial controllers and devices.

Supported Hardware

Use case

Manufacturers running Allen-Bradley and Rockwell controllers typically have production data trapped on the plant floor. It's visible on an HMI, but invisible to anything above it. The CIP Suite closes that gap in both directions: it reads live tag data off the PLC into your flows, and lets flows write values and commands back when your use case requires it.

Example: tracking line performance in real time

A CompactLogix controller on a packaging line exposes tags for ProductionCount, ConveyorRunning, and RejectCount. Without this suite, getting that data into a dashboard or historian usually means an OT engineer manually configuring a separate SCADA tag, or a nightly CSV export that's already stale by morning.

With the CIP Suite, the flow looks like this:

1. Connect: a cip-endpoint configuration node holds the shared connection to the PLC, with automatic reconnection.
2. Subscribe: a cip-subscribe node scans the tags cyclically and emits messages on change, with deadband filtering to suppress noise.
3. Enrich: a function node attaches a line ID, timestamp, or shift code, and converts raw units into something business-readable.
4. Deliver: the enriched payload is published to an MQTT broker or Unified Namespace, written to a historian, or dropped straight into FlowFuse Tables.

The result: production counts, machine states, and reject rates are available to dashboards, analytics, and other systems within moments of changing on the floor. No polling scripts, no OPC server to license and maintain, no manual tag mapping in a separate SCADA package.

Where this shows up in practice

• OEE and downtime tracking: feed ConveyorRunning and cycle-time tags into a calculation flow to surface availability and performance losses as they happen, instead of reconstructing them from end-of-shift reports.
• Live operations dashboards: wire tag changes straight into FlowFuse Dashboard widgets so operators and supervisors see machine state and counts update in real time.
• Recipe and setpoint downloads: use cip-write to push new setpoints, batch parameters, or recipe values to the PLC from an MES, a dashboard form, or a database lookup.
• Threshold alerting: route a Temperature or Pressure tag through a switch node and fire a Slack, Teams, or email notification the moment a value crosses a quality limit.
• Unified Namespace / MQTT bridging: treat the PLC as a data source feeding a plant-wide UNS, so IT and OT systems consume the same live tag data instead of duplicating integrations per PLC.
• Legacy modernization: connect SLC 500, MicroLogix, and PLC-5 systems through the PCCC nodes and bring decades-old equipment into the same data pipeline as modern controllers, without touching the ladder logic.

Why it scales beyond one PLC

Only the source and sink nodes are protocol-specific. The transform stages of a flow, such as renaming tags, adding context, and routing data, don't care what protocol the data came from. The same flow pattern you build for one Allen-Bradley line can be reused for a Siemens PLC over OPC UA or a Modbus device just by swapping the protocol nodes, which matters a lot on a mixed-vendor plant floor.

Requirements

• Node.js >= 16.0.0
• Node-RED >= 2.0.0
• Access to the FlowFuse Edge Certified Nodes catalogue (part of the FlowFuse Edge offering)

Installation

Because this suite is part of the FlowFuse Edge Certified Nodes catalogue, which is part of the FlowFuse Edge offering, make sure your account has access before installing. Contact our sales team if you don't.

Install via the Palette Manager (recommended)

1. Open the Palette Manager from the top-right menu in the FlowFuse editor.
2. Switch to the Install tab.
3. Search for the FlowFuse Edge Certified Nodes collection.
4. Locate @flowfuse-certified-nodes/cip-suite and click Install.

After installation, all nodes appear under the CIP Suite category in the palette.

Nodes in the Suite

Core CIP Nodes (Logix controllers)

Legacy PCCC Nodes (SLC 500 / MicroLogix / PLC-5)

Advanced CIP Object Nodes

Tag Addressing

CIP Symbolic (Logix)

PCCC (SLC 500 / MicroLogix / PLC-5)

Configuration

cip-endpoint

cip-pccc-endpoint

Usage

Reading tags

Send a message to a cip-read node with the tag name configured on the node or in msg.tagName. The output:

{
  "payload": 1250,
  "tagName": "ProductionCount",
  "dataType": "DINT",
  "timestamp": 1710000000000
}

Writing tags

Send a message to a cip-write node with the value in msg.payload:

{
  "payload": 42,
  "tagName": "TargetSpeed"
}

Bit-level writes use the atomic CIP Read-Modify-Write service where the controller supports it, so individual bits change without race conditions.

Subscribing to tag changes

The cip-subscribe node scans a group of tags cyclically and emits when values change. Multi-tag output:

{
  "payload": { "Tag1": 42, "Tag2": 3.14 },
  "tags": [
    { "name": "Tag1", "value": 42, "type": "DINT", "changed": true },
    { "name": "Tag2", "value": 3.14, "type": "REAL", "changed": false }
  ],
  "scanRate": 1000,
  "timestamp": 1710000000000
}

Deadband filtering suppresses small fluctuations on analog values so only meaningful changes flow downstream.

Reading legacy controllers

The cip-pccc-read node returns data-file values from SLC 500, MicroLogix, and PLC-5 controllers:

{
  "payload": 1234,
  "address": "N7:0",
  "fileType": "Integer",
  "timestamp": 1710000000000
}

Node Status Indicators

Best Practices

Connection Management

• Share a single cip-endpoint configuration node across all read, write, browse, and subscribe nodes talking to the same PLC.
• The endpoint reconnects automatically at the configured retry interval; use a status node if you need to react to connection changes in your flow.
• All nodes skip new requests while a previous one is in flight, which protects the PLC from overload.

Network Configuration

• Ensure your FlowFuse instance can reach the PLC IP address.
• Configure firewall rules to allow TCP port 44818 (EtherNet/IP).
• Use static IP addresses for PLCs in production environments.
• Use the routing path setting to reach PLCs behind ControlLogix backplanes or across multiple hops.

Tag Selection and Scan Rates

• Only subscribe to tags you need to minimize network traffic.
• Use appropriate scan rates based on how quickly data changes; faster scan rates increase CPU and network load.
• Use deadband filtering on analog tags to avoid flooding downstream systems with insignificant changes.

Writing Safely

• Validate values in a function node before they reach a cip-write node, especially when values originate from dashboards or external systems.
• Prefer bit-level writes for command bits so unrelated bits in the same word are never disturbed.
• Keep safety functions and interlocks in the PLC program. Never rely on a flow to enforce a safety condition.

Error Handling

• Connect a catch node to handle errors gracefully.
• Use the admin metrics endpoint (GET /cip-endpoint/:id/metrics) to monitor response times, error counts, and uptime.

Troubleshooting

Cannot Connect to PLC

• Verify IP address and network connectivity (ping test).
• Check the slot number matches your controller configuration.
• For Micro800 controllers, enable Micro800 mode on the endpoint.
• Verify firewall settings allow TCP 44818.

Tags Not Updating

• Confirm tag names match exactly (case-sensitive).
• For program-scoped tags, use the full Program:ProgramName.TagName format.
• For legacy controllers, verify the data-file address format (e.g. N7:0, not a tag name).
• Check the scan rate isn't too slow for your application.

Connection Drops Frequently

• Reduce scan rates to decrease network load.
• Check network stability and switch configuration.
• Verify the PLC isn't overloaded with connections from other clients.