A single bus cable carries addressed data instead of one conductor carrying each valve's signal.

On a multi-pin terminal every solenoid has a dedicated wire back to a PLC output. The connection is direct and physical: energise the output, energise that coil.

On a fieldbus terminal, the controller sends a message onto the network containing the states of all the outputs. A node on the terminal listens for messages addressed to it, decodes the relevant portion, and switches its solenoids accordingly.

So the cable carries data rather than power to individual valves, and the same cable can pass on to further nodes - other valve terminals, drives, sensors, operator panels - along one run.

The practical consequence is that the cable size and the controller's I/O requirement no longer scale with the number of valves. What scales instead is the address space, which is generous.

Per-station coil monitoring and node-level status, reported back to the controller as data.

Because the node has electronics at each station, it can detect whether current is flowing when a valve is commanded. That reveals an open circuit - a broken wire or a burnt-out coil - and a short circuit, and it identifies which station is affected.

Many terminals also report supply voltage, node temperature, and whether the pneumatic supply pressure is within limits where a pressure sensor module is fitted.

The value is that a fault becomes a message naming the station rather than a machine that has stopped for no visible reason. Maintenance arrives knowing what to replace, and on a remote or inaccessible installation that can be the difference between a planned visit and a lengthy investigation.

Some systems also count switching cycles per station, which supports condition-based replacement of valves that are approaching their rated life.

The major industrial protocols, with the choice dictated by the controller rather than by the terminal.

Valve terminal manufacturers offer node modules for the widely used industrial Ethernet and traditional fieldbus protocols, because a terminal has to fit whatever control system the machine uses.

The protocol is therefore usually decided before the terminal: the PLC family and the plant's existing network determine it, and the terminal is then specified with a matching node.

On many ranges the node module is a separate component that plugs onto the same valve manifold, so the same pneumatic hardware can be supplied for different protocols - and a machine can be adapted to a different control system by changing the node rather than the whole terminal, which is useful for machine builders supplying multiple markets.

Confirm the specific protocol version and conformance class required, since a node that supports a protocol family does not always support every profile within it.

Yes on most ranges - input modules on the terminal let sensors connect locally instead of running back to the cabinet.

A machine has sensors as well as actuators: reed switches on cylinders, proximity sensors, pressure switches. Conventionally each runs its own cable back to an input card.

If the valve terminal is already mounted on the machine and already on the network, adding input modules to it lets those sensors terminate locally. Their states are reported over the same bus cable, and the long individual sensor cables disappear.

That compounds the original saving considerably, because on many machines there are more sensors than valves.

It also puts the connection point close to the sensor, which shortens cable runs and reduces noise pickup.

Check the input module types available - digital, analogue, counter, and the connector style - and confirm the node can address the required number of inputs as well as outputs within the protocol's limits.

The terminal loses its commands, and what the valves then do depends on how the system is configured - which is a safety-relevant decision.

On loss of communication, a fieldbus node adopts a defined fault state. Typically it can be configured to de-energise all outputs, to hold their last state, or to adopt specified substitute values.

Each has consequences. De-energising sends every spring-return valve to its rest position, which is usually the safe state but will move actuators. Holding last state freezes the machine where it is, which may or may not be safe. Substitute values allow a defined safe configuration.

That choice must follow from the machine's risk assessment rather than being left at whatever the default is - and it interacts with the choice of spring-return or double-solenoid valves at each station.

It is also worth noting that the fieldbus is generally not the safety system. Safety functions normally use a dedicated safety protocol or hardwired circuits, and the standard bus is not a substitute.

Sooner than most people expect, once PLC output cards and installation labour are included rather than just the cable.

A multi-pin installation costs a multi-core cable, a connector, and enough PLC digital output cards to drive every valve. All three scale with the valve count.

A fieldbus installation costs a node module and a bus cable, and neither scales meaningfully - adding valves consumes address space, not hardware.

Comparisons that look only at the terminal price make fieldbus look expensive, because the node adds cost to the block. Including the output cards frequently reverses it at quite modest valve counts.

Installation labour points the same way: pulling and terminating one bus cable is quicker than a heavy multi-core, particularly where the terminal is far from the cabinet.

And if the machine will have several terminals or other networked devices, the bus cable is shared, which removes the comparison entirely.

Setting the node's address and parameters, loading its description file into the controller, and confirming the I/O mapping - none of it difficult, but none of it optional.

The node needs an address on the network, set by switches or by software depending on the protocol. Duplicate addresses are a common commissioning fault and produce confusing symptoms.

The controller needs the device description file for that node, which tells it what I/O the terminal presents. Once loaded, the stations map to controller addresses and can be labelled with their machine functions.

Fault-state behaviour is configured at this point, and it should be a deliberate decision rather than left at default.

Finally the mapping should be verified physically - energising each output and confirming the expected valve operates - because a mapping that is correct in software and wrong on the manifold produces a machine that runs its sequence in the wrong order.

Document the final mapping with the machine.