Skip to content
English
Contact us
  • There are no suggestions because the search field is empty.

Communication / Network Alarm – Initial Guidance

Use this guide when a communication or network-related alarm is active on the HMI. This guidance applies when the system indicates loss of communication between the PLC and one or more connected devices, such as pumps, VFDs, valves, valve feedback modules, or remote I/O.

What the alarm means

A communication or network alarm indicates that the PLC has lost communication with a connected device.

This does not automatically mean that:

  • the device is defective

  • a motor, pump, or valve has failed

  • hardware replacement is required

In most cases, the affected device is electrically intact, but power or communication to the device is interrupted.

Typical causes

Communication alarms are most commonly caused by:

  • Tripped breakers or fuses in the electrical cabinet

  • Loss of 24 VDC supply to devices or remote I/O

  • Local faults on devices such as VFDs

  • Loose or disconnected Ethernet / fieldbus cables

  • A single device blocking communication in a daisy-chained network

It is common that one affected device causes alarms on several others, even though only one unit is actually at fault.

Initial checks (always start here)

When a communication or network-related alarm is active, always start with the simplest and most common causes.

Perform checks in the following order:

Electrical cabinet

  • Check whether any breakers have tripped

  • Check 24 VDC multi-fuses supplying:

    • PLC

    • Remote I/O

    • Valve feedback modules

    • Communication equipment

  • Restore tripped breakers or fuses before proceeding

Local device status

  • Check local isolators or breakers on devices such as VFDs

  • Check whether any device shows a local fault or alarm (e.g. on the VFD display)

  • Clear local faults where possible

24 VDC supply

  • Verify that 24 VDC is present at affected devices and I/O modules

  • Loss of 24 VDC supply is a very common root cause and may cause multiple devices to appear offline at the same time

Network connections

  • Inspect Ethernet / fieldbus cables for loose or damaged connectors

  • Reseat connectors where necessary

  • An Ethernet cable tester can be a useful tool to verify cable integrity

Many communication alarms are resolved at this stage.

Important distinction: local device fault vs. communication loss

Before deeper investigation, determine whether the issue is:

A local device fault

  • A fault or alarm is visible directly on the device

  • The device is not ready for operation

  • Communication will not resume until the local fault is cleared

or

A communication loss

  • The device appears powered and healthy

  • No local fault is shown

  • The PLC cannot establish communication

A single device with a local fault can block communication for downstream devices in a daisy-chain network.

Use of electrical documentation

When investigating communication or network-related alarms, it is important to refer to the electrical documentation for the specific system.

The electrical documentation shows:

  • how devices are powered (including 24 VDC supplies)

  • how communication is routed (PLC, VFDs, remote I/O)

  • whether devices are daisy-chained or independently connected

Following the electrical documentation helps ensure that:

  • upstream power and communication paths are checked first

  • simple causes such as power loss or tripped fuses are identified early

  • unnecessary component replacement is avoided

Always use the documentation applicable to the specific project and system generation.

Reset behavior

After restoring power or clearing a local device fault:

  • Perform a Reset from the HMI

  • Allow the system time to re-establish communication

  • Observe whether alarms clear and device status updates correctly

Some communication alarms will not clear automatically without a reset, even after communication is restored.

When to stop and contact LiqTech Service

Contact LiqTech Service if:

  • Communication alarms persist after power, fuse, and cable checks

  • Multiple resets do not restore communication

  • Communication faults occur repeatedly without a clear cause

  • System operation cannot be stabilized

Alarm ID reference – Communication and network related alarms

The following alarm references are examples observed on LiqTech Crossflow systems.
They are provided to help identify alarms related to loss of communication, missing response, or power-related signal loss.

Other project-specific alarm IDs may exist.

MK6 – Numeric alarm IDs

  • 6 – Network communication fault

  • 99 – 24V trip

MK8 – F-series (FM01)

  • F0130 – Pump communication fault

  • F0131 – Drive not responding

  • F0132 – Network communication error

MK8 – D-series (project based)

  • D0004 – Communication fault

  • D0303 – Drive communication fault

  • D0304 – Drive communication fault

  • D0417 – Communication error

  • D0418 – Communication error

  • D0419 – Communication error