Archives

KEY FEATURES AND BENEFITS

• From the Vibro-Meter® product line

• VM600 CPUM/IOCN rack controller and 

communications interface card pair with 

support for Modbus RTU/TCP and PROFINET, 

and a front-panel display

• “One-Shot” configuration management of 

protection cards (MPC4 and AMC8) in a 

VM600 rack using an Ethernet or RS-232 serial 

connection to a computer running the 

VM600 MPSx software

• Front-panel display for visualisation of 

monitored outputs and alarm limits from 

protection cards

• Front-panel alarm reset (AR) button

• VM600 MPS rack (CPUM) security

• Industry standard fieldbus communications 

interfaces: Modbus RTU/TCP and PROFINET

• Two Ethernet connections and up to three 

serial connections (RS-232 / RS-422 / RS-485) 

can run simultaneously

• Communications redundancy with multiple 

fieldbuses: Ethernet and/or serial

KEY BENEFITS AND FEATURES (continued)

• VM600 system event and measurement event 

logs available via the VM600 MPSx software

• Supports live insertion and removal of 

protection cards (“hot-swapping”) with 

automatic configuration

• Ethernet (100 Mbps) communication

• Front-panel status indicators (LEDs)

• Compatible with all VM600 ABE04x 

system racks

APPLICATIONS

• Rack controller for a VM600 system

• Communications gateway between VM600 

and third-party systems, such as a DCS or PLC

• Enables sharing of measurement data from 

VM600 monitoring cards in machinery 

protection, condition monitoring and/or 

combustion monitoring applications

Information contained in this document may be subject to export control regulations of the European Union, USA or other countries. 

Each recipient of this document is responsible for ensuring that transfer or use of any information contained in this document 

complies with all relevant export control regulations. ECN N/A.

DESCRIPTION

Introduction

The VM600 CPUM and IOCN modular CPU card 

and input/output card is a rack controller and 

communications interface card pair that acts as 

a system controller and data communications 

gateway for a VM600 rack-based machinery 

protection system (MPS) and/or condition 

monitoring system (CMS) from Meggitt’s 

Vibro-Meter® product line.

Different versions of CPUx/IOCx card pair

Different versions of CPUx/IOCx rack controller 

and communications interface card pair are 

available, as follows:

• The CPUM/IOCN is the original version with a 

front-panel display and support for

Modbus RTU/TCP and PROFINET

(PNR 200-595-VVV-VVV).

• The CPUR/IOCR is a version with rack controller 

redundancy and support for Modbus RTU/TCP 

(PNR 600-007-VVV-VVV).

• The CPUR2/IOCR2 is a version with 

mathematical processing of fieldbus data and 

support for Modbus TCP and PROFIBUS DP

(PNR 600-026-000-VVV).

VM600 rack-based monitoring systems

The Vibro-Meter® VM600 rack-based monitoring 

system is part of Meggitt’s solution for the 

protection and monitoring of rotating machinery 

used in the power generation and oil & gas 

industries. The VM600 is recommended when a 

centralised monitoring system with a medium to 

large number of measurement points (channels) 

is required. It is typically used for the monitoring 

and/or protection of larger machinery such as 

gas, steam and hydro turbines, and generators, 

smaller machines such as compressors, fans, 

motors, pumps and propellers, as well as balanceof-plant (BOP) equipment.

A VM600 system consists of a 19″ rack, a rack 

power supply and one or more monitoring card 

pairs. Optionally, relay cards and rack controller 

and communications interface cards can also be 

included.

Two types of VM600 rack are available: a VM600 

ABE04x system rack (6U) that can house up to 12 

monitoring card pairs, and a VM600 ABE056 

slimline rack (1U) that can house 1 monitoring 

card pair. VM600 racks are typically mounted in 

standard 19″ rack cabinets or enclosures installed 

in an equipment room.

Different VM600 monitoring cards are available 

for machinery protection, condition monitoring 

and/or combustion monitoring applications. For 

example, machinery protection cards such as the 

MPC4/IOC4T machinery protection card pair and 

AMC8/IOC8T analogue monitoring card pair, 

and condition monitoring cards such as the 

XMV16/XIO16T monitoring card pair for vibration 

and XMC16/XIO16T monitoring card pair for 

combustion.

The RLC16 relay card is an optional card used to 

provide additional relays when the four relays per 

MPC4/IOC4T or AMC8/IOC8T card pair are not 

enough.

The CPUx/IOCx rack controller and 

communications interface card pairs (CPUM/

IOCN, CPUR/IOCR or CPUR2/IOCR2) are optional 

cards used to provide additional VM600 system 

functionality such as configuration management, 

“hot-swapping” with automatic reconfiguration, 

front-panel display, CPUx/IOCx card pair 

redundancy, fieldbus data processing, frontpanel alarm reset (AR) button, MPS rack (CPUx) 

security, system event and measurement event 

logging, fieldbus communications (Modbus, 

PROFIBUS and/or PROFINET) and/or 

communications redundancy.

Note: Different versions of CPUx/IOCx rack 

controller and communications interface card 

pair support different combinations of VM600 

system functionality.

VM600 rack-based monitoring systems 

complement the VibroSmart® module-based 

distributed monitoring systems that are also 

available from Meggitt’s Vibro-Meter® product 

line.

DESCRIPTION (continued)

CPUM/IOCN card pair and VM600 racks

The CPUM/IOCN card pair is used with a VM600 

ABE04x system rack and a CPUM card can be 

used either alone or with an associated IOCN 

card as a card pair, depending on the 

application/system requirements. 

The CPUM is a double-width card that occupies 

two VM600 rack slots (card positions) and the 

IOCN is a single-width card that occupies a single 

VM600 slot. The CPUM is installed in the front of the 

rack (slots 0 and 1) and an associated IOCN is 

installed in the rear of the rack in the slot directly 

behind the CPUM (slot 0). Each card connects 

directly to the rack’s backplane using two 

connectors.

Note: The CPUM/IOCN card pair is compatible 

with all VM600 ABE04x system racks.

CPUM rack controller and communications 

interface functionality

The modular, highly versatile design of the CPUM 

means that all VM600 rack configuration, display 

and communications interfacing can be 

performed from a single card in a “networked” 

rack. The CPUM card acts as a “rack controller” 

and allows an Ethernet link to be established 

between the rack and a computer running one 

of the VM600 MPSx software packages (MPS1 or 

MPS2).

The CPUM front panel features an LCD display 

that shows information for the CPUM itself and for 

protection cards in a VM600 rack. The SLOT and 

OUT (output) keys on the CPUM front panel are 

used to select which signal to display.

As a fieldbus communications interface for a 

VM600 monitoring system, the CPUM 

communicates with MPC4 and AMC8 cards via 

the VME bus and with XMx16/XIO16T card pairs 

via an Ethernet link in order to obtain 

measurement data and then share this 

information with third-party systems such as a DCS 

or PLC.

LEDs on the CPUM front panel indicate the OK, 

Alert (A) and Danger (D) status for the currently 

selected signal. When Slot 0 is selected, the LEDs 

indicate the overall status of the whole rack. 

When the DIAG (diagnostic) LED shows green 

continuously, the CPUM card is operating 

normally, and when the DIAG LED blinks, the 

CPUM card is operating normally but access to 

the CPUM card is restricted due to VM600 MPS 

rack (CPUM) security.

The ALARM RESET button on the front panel of the 

CPUM card can be used to clear the alarms 

latched by all protection cards (MPC4 and 

AMC8) in the rack. This is a rack-wide equivalent 

of resetting alarms individually for each card using 

discrete signal interface alarm reset (AR) inputs or 

VM600 MPSx software commands.

The CPUM card consists of a carrier board with 

two PC/104 type slots that can accept different 

PC/104 modules: a CPU module and an optional 

serial communications module.

All CPUM cards are fitted with a CPU module that 

supports two Ethernet connections and two serial 

connections. That is, both the Ethernet redundant 

and serial redundant versions of the card.

The primary Ethernet connection is used for 

communication with the VM600 MPSx software 

via a network and for Modbus TCP and/or 

PROFINET communications. The secondary 

Ethernet connection is used for Modbus TCP 

communications. The primary serial connection is 

used for communication with the VM600 MPSx 

software via a direct connection. The secondary 

serial connection is used for Modbus RTU 

communications.

Optionally, a CPUM card can be fitted with a 

serial communications module (in addition to the 

CPU module) in order to support additional serial 

connections. This is the serial redundant version of 

the CPUM card.

The CPUM module’s primary Ethernet and serial 

connections are available via connectors (NET 

and RS232) on the front panel of the CPUM. 

However, if the associated IOCN card is used, the 

primary Ethernet connection can be routed to a 

connector (1) on the front panel of the IOCN 

(instead of the connector on the CPUM (NET)). 

When the associated IOCN card is used, the 

secondary Ethernet and serial connections are 

available via connectors (2 and RS) on the front 

panel of the IOCN.

IOCN card

The IOCN card acts as a signal and 

communications interface for the CPUM card. It 

DESCRIPTION (continued)

also protects all inputs against electromagnetic 

interference (EMI) and signal surges to meet 

electromagnetic compatibility (EMC) standards.

The IOCN card’s Ethernet connectors (1 and 2) 

provide access to the primary and secondary 

Ethernet connections, and the serial connector 

(RS) provides access to the secondary serial 

connection.

In addition, the IOCN card includes two pairs of 

serial connectors (A and B) that provide access to 

the additional serial connections (from the 

optional serial communications module) that can 

be used to configure multi-drop RS-485 networks 

of VM600 racks.

Front-panel display

The CPUM front panel features an LCD display 

that uses display pages to show important 

information for the cards in a VM600 rack. For the 

CPUM itself, card run time, rack system time, rack 

(CPUM) security status, IP address/netmask and 

version information are displayed. While for MPC4 

and AMC8 cards, measurements, card type, 

version and run time are displayed.

For MPC4 and AMC8 cards, the level of the 

selected monitored output is displayed on a 

bargraph and numerically, with the Alert and 

Danger levels also indicated on the bar-graph. 

Measurement identification (slot and output 

number) is shown at the top of the display.

VM600 MPS rack (CPUM) security

The CPUM supports features that can be used to 

limit the functionality of a VM600 rack’s 

machinery protection system (MPS) that is 

available via the system Ethernet connections of 

a CPUM/IOCN card pair. Enabling VM600 MPS 

rack (CPUM) security helps to reduce the 

possibility of interference in the machinery 

protection function of the rack itself and in the 

machinery being monitored. Accordingly, CPUM 

rack security makes it easier for operators to 

comply with international security/critical 

infrastructure regulations.

The security features consists of two specific levels 

of protection integrated in the CPUM card: CPUM 

access lock (a “hardware” security feature) and 

VM600 MPSx password validation (a “software” 

security feature). Refer to the VM600 machinery 

protection system (MPS) hardware manual and 

the VM600 MPSx software manuals for further 

information.

VM600 event logging

The CPUM card automatically logs VM600 system 

events and measurement events to non-volatile 

memory in order to provide valuable information 

on the operating history of a system. Up to 10000 

of the most recent events are stored on the card 

for download as user-readable event log files 

using the VM600 MPSx software.

Software

The CPUM/IOCN is software configurable using 

the CPUM Configurator software.

The VM600 MPSx software supports the 

configuration and operation of MPC4/IOC4T 

card pairs for machinery protection applications, 

including the processing and presentation of 

measurement data for analysis. VM600 MPSx is 

also used to configure and manage CPUM/IOCN 

card pairs.

Note: The VM600 MPSx software is from the

Vibro-Meter® product line.

Applications information

The VM600 CPUM/IOCN rack controller and 

communications interface card pair is 

recommended for applications using multiple 

monitoring cards in a VM600 rack.

The rack controller functionality makes it easier to 

work with a VM600 machinery monitoring system – 

for installation, configuration, management and 

general operation. The CPUM/IOCN can 

manage the configuration of MPC4/IOC4T and 

AMC8/IOC8T card pairs, including hot-swapping. 

It can also manage the configuration of XMx16/

XIO16T card pairs, eliminating the need for a 

VibroSight Server in certain applications.

The communications interface functionality 

makes it easy to further process and share data 

from the monitoring cards (MPC4, AMC8 and/or 

XMC16) in a VM600 machinery protection, 

condition monitoring and/or combustion 

monitoring system with third-party systems such as 

a DCS or PLC using industry standard fieldbuses.

For further information, contact your local 

Meggitt representative.

Processing functions

Rack controller

• VM600 monitoring card configuration 

management

: Acts as a rack controller that manages the configuration of MPC4/

IOC4T and AMC8/IOC8T card pairs, including support for

“hot-swapping” with automatic configuration.

Can also manage the configuration of XMx16/XIO16T card pairs, 

for applications that do not require a VibroSight Server.

• Front-panel display : LCD display that uses display pages to show important information 

for the cards in a VM600 rack:

• Card run time, rack system time, rack (CPUM) security status, 

IP address/netmask and version info are displayed for the CPUM.

• Measurements (bargraph with alarm levels, and numerically), 

card type, version, and run time are displayed for the MPC4 and 

AMC8 cards in the rack.

• Fieldbus data processing 

(mathematical processing)

: Further processing of system data (measurement data and status 

information) before being shared by fieldbus.

The further processing supported includes basic mathematical 

functions such as arithmetic and logical operations, data selection, 

comparison, min/max and scaling functions, bit manipulation and 

packing/unpacking functions, and many supporting functions.

There is also a data freeze detection function that can be used to 

help detect if a data value has stopped being updated.

• Alarm reset : CPUM front-panel button used to manually clear the alarms (and 

relays) latched by MPC4/IOC4T and AMC8/IOC8T card pairs in the 

rack

• VM600 MPS rack (CPUM) security : Used to limit the functionality of a machinery protection system 

(MPS) that is available via the system Ethernet connections of a 

CPUM/IOCN card pair, helping to reduce the possibility of 

interference in the machinery protection function of the rack itself 

and/or in the machinery being monitored

• Event logging : VM600 system event and measurement event logging with up to 

10000 of the most recent events stored on the CPUM (in nonvolatile memory).

Note: System event logs and measurement event logs are 

downloaded from a CPUM using the VM600 MPSx software.

• Status indication : CPUM front-panel LEDs (front of VM600 rack) indicate the mode of 

operation and status of the CPUM card

Communications interface

• VM600 rack (system) 

communications

: Uses a VME communications link for communications with

MPC4/IOC4T and AMC8/IOC8T card pairs (via the VME bus on the 

VM600 rack’s backplane).

Uses a system Ethernet connection for communications with a 

computer running software such as VM600 MPSx.

• Fieldbus communications

(data gateway)

: Acts as a fieldbus server (slave) device that obtains data from 

cards in the VM600 rack (that is, from MPC4/IOC4T and

AMC8/IOC8T card pairs) to share with fieldbus client (master) 

devices such as a DCS or PLC:

• The CPUM can act as a Modbus server and use the fieldbus 

interfaces to share data via Modbus RTU and/or Modbus TCP.

Note: The configuration of the fieldbus interfaces and the definition 

of the data to be shared via fieldbus is defined by a Modbus 

configuration file that is uploaded to the CPUM card using the 

CPUM Configurator software.

Fieldbus interfaces

Number of channels : Multiple fieldbus interfaces (ports).

Ethernet and/or serial: Modbus and/or PROFINET.

Data transfer

• Modbus : Up to 131072 registers/words and 131072 coils/bits total.

That is, up to 2 × 65536 registers/words and 2 × 65536 coils/bits 

(holding and discrete).

• PROFINET : Maximum slot size of 128 bytes.

Note: PROFINET is supported by later versions of the CPUM card 

running firmware version 081 or later.

It was originally only supported by earlier versions of the CPUM card 

running a special PROFINET version of firmware (version 801) that is 

no longer supported.

Contact your local Meggitt representative or Meggitt SA for further 

information.

CPU module (CPUM PC/104 slot 1)

Note: The CPU module is fitted to all versions of the CPUM card.

Module type : PFM-541I or equivalent

Processor type : AMD Geode™ LX800

Processor Speed : 500 MHz

Memory : 256 MB DRAM

Power supply to module (input) : 5 VDC, <1.8 A

Operating system : QNX

Communication interfaces – serial

Number : 2

Primary serial interface

• Network interface : RS-232

• Data transfer rate : Up to 115.2 kBaud

• Network topologies : Point-to-point

• Protocols : Meggitt TCP/IP proprietary protocol for communication with the 

VM600 MPSx software

• Function : VM600 rack configuration and communications using the 

VM600 MPSx software

• Connector : RS232 on CPUM card (see Connectors on page 10)

Secondary serial interface (requires IOCN card)

• Network interface : RS-232 or RS-485 (half-duplex (2-wire) or full-duplex (4-wire))

• Data transfer rate : Up to 115.2 kBaud

• Distance between devices : According to the relevant standard

• Network topologies : Point-to-point for RS-232 links.

Point-to-point or linear (daisy-chained) for RS-485 networks.

• Protocols : Modbus RTU 

• Function : Fieldbus Modbus RTU communications

• Connector : RS on IOCN card (see Connectors on page 10)

• RS-485 (fieldbus) isolation : 500 VDC

S

SPECIFICATIONS (continued)

Communication interfaces – Ethernet

Number : 2

Primary Ethernet interface

• Network interface : 10/100BASE-TX – Ethernet / Fast Ethernet

• Data transfer rate : Up to 100 Mbps

• Distance between devices : Up to 100 m

• Protocols : Meggitt TCP/IP proprietary protocol for communication with the 

VM600 MPSx software, Modbus TCP and/or PROFINET

• Function : VM600 rack configuration and communications using the 

VM600 MPSx software, fieldbus Modbus TCP communications

and/or fieldbus PROFINET communications

• Connectors : NET on CPUM card or 1 on IOCN card (see Connectors on page 10)

Secondary Ethernet interface (requires IOCN card)

• Network interface : 10/100BASE-TX – Ethernet / Fast Ethernet

• Data transfer rate : Up to 10 Mbps

• Distance between devices : Up to 100 m

• Protocols : Modbus TCP

• Function : Fieldbus Modbus TCP communications

• Connector : 2 on IOCN card (see Connectors on page 10)

Serial communications module (CPUM PC/104 slot 2)

Note: The serial communications module is optional and is only fitted to the serial redundant version of the 

CPUM card.

Module type : AIM104-COM4 or equivalent

Power supply to module (input) : 5 VDC, <220 mA

Isolation : >100 VDC

Communication interfaces – serial

Number : 2

Serial interfaces

• Network interface : RS-422 or RS-485 (half-duplex (2-wire) or full-duplex (4-wire))

• Data transfer rate : Up to 115.2 kBaud

• Distance between devices : According to the relevant standard

• Network topologies : Point-to-point for RS-232 links.

Point-to-point or linear (daisy-chained) for RS-422/ RS-485 networks.

• Protocols : Modbus RTU

• Function : Fieldbus Modbus RTU communications

• Connectors : A and B on IOCN card (see Connectors on page 10)

• RS-485 (fieldbus) isolation : 500 VDC

Notes

Jumpers on the CPUM and IOCN cards are used to configure the required operation of serial and Ethernet 

interfaces and connectors. Refer to the VM600 machinery protection system (MPS) hardware manual for 

further information.

System communications

Internal : VME bus interface (A24 / D16 master mode) for communication 

with protection cards (MPC4 and AMC8) via VM600 rack 

backplane

External : System communication interfaces (serial and Ethernet) for 

communication with VM600 MPSx software running on an external 

computer.

See Communication interfaces – serial on page 6 and 

Communication interfaces – Ethernet on page 7.

External communication links/connections

• Connection to a computer/network : A serial communication interface (RS232 on CPUM card) can be 

used for connections/communications between a CPUM/IOCN 

card pair and a computer/network, using a standard serial cable.

See Communication interfaces – serial on page 6 and Connectors 

on page 10.

An Ethernet communication interface (NET on CPUM card or 1 on 

IOCN card) can be used for connections/communications 

between a CPUM/IOCN card pair and a computer/network, using 

standard cabling.

See Communication interfaces – Ethernet on page 7 and 

Connectors on page 10.

• Connection to a fieldbus

(third-party system)

: A serial fieldbus communication interface (RS on IOCN card) can 

be used for connections/communications between a CPUM/IOCN

card pair and serial-based fieldbuses (Modbus RTU).

See Communication interfaces – serial on page 6 and Connectors 

on page 10.

An Ethernet fieldbus communication interface (NET on CPUM card 

or 1 on IOCN card, or 2 on IOCN card) can be used for 

connections/communications between a CPUM/IOCN

card pair and Ethernet-based fieldbuses (Modbus TCP).

See Communication interfaces – Ethernet on page 7 and 

Connectors on page 10.

• VM600 MPSx software : Used for the configuration and operation of MPC4/IOC4T and 

AMC8/IOC8T card pairs (using the CPUM/IOCN card pair as a 

communications gateway)

• VibroSight® software : Used for the configuration of CPUM cards

Configuration

CPUM/IOCN card pair : Software configurable via Ethernet or serial, using a computer 

running the VM600 MPSx and CPUM Configurator software.

Note: Serial (RS-232 / RS-422 / RS-485) line configuration and 

Ethernet port to connector routing is determined by jumpers on the 

CPUM and IOCN cards.

SPECIFICATIONS (continued)

Time synchronisation

Time reference for CPUM : Network time protocol (NTP) server or

CPUM’s internal real-time clock (RTC) with battery backup

Protocol used between VM600 cards 

and host computer

: Network time protocol (NTP)

Note: When VM600 system event and/or measurement event logging is used, the time and date must be 

configured for the CPUM in order for the timestamps in the event log files to be correct.

Environmental

Operating

• Temperature : −20 to 65°C (−4 to 149°F)

• Humidity : 0 to 90% relative humidity, non-condensing

Storage

• Temperature : −25 to 80°C (−13 to 176°F)

• Humidity : 0 to 90% relative humidity, non-condensing

Approvals

Conformity : CE marking, European Union (EU) declaration of conformity.

EAC marking, Eurasian Customs Union (EACU) certificate/

declaration of conformity.

Electromagnetic compatibility : TR CU 020/2011

Electrical safety : TR CU 004/2011

Environmental management : RoHS compliant

Russian federal agency for technical 

regulation and metrology (Rosstandart)

: Pattern approval certificate CH.C.28.004.A N° 60224,

dated 11.11.2015

Power supply (to CPUM/IOCN)

Source : VM600 rack power supply

Voltage : 5 VDC

Power consumption

• CPUM : <10 W

• IOCN : <2 W

Total power consumption

(CPUM/IOCN card pair)

: ≤12 W

Control inputs (buttons)

CPUM

ALARM RESET : Used to reset all latched alarms (and associated relays) for all 

protection cards in the VM600 rack (MPC4/IOC4T and AMC8/

IOC8T)

OUT+ and OUT− : Used to select a measurement channel for the currently selected 

protection card (slot)

SLOT+ and SLOT− : Used to select a slot (protection card) in the VM600 rack

Note: OUT and SLOT button combinations are also used to enable 

or disable VM600 rack (CPUM) security, that is, limit the VM600 MPSx 

software to “read only” operations.

Status indicators (LEDs)

CPUM

DIAG : Green LED used to indicate the status of the CPUM card: off, 

normal operation and status of VM600 MPS rack (CPUM) security

OK : Green LED used to indicate the status of the OK system check 

(sensor OK link check) for the currently selected measurement 

channel

A

(Alert)

: Yellow LED used to indicate the status of the alarm monitoring (Alert 

or Alert−) for the currently selected measurement channel

D

(Danger)

: Red LED used to indicate the status of the alarm monitoring 

(Danger or Danger−) for the currently selected measurement 

channel

Note: In addition to the LED indicators, a front-panel display is fitted to all versions of the CPUM card.

Connectors

CPUM

• NET : 8P8C (RJ45), female.

Used for the primary Ethernet connection.

• RS232 : DE-9 (9-pin D-sub), female

Used for the primary serial connection.

IOCN

• RS : 6P6C (RJ12/RJ25), female.

Used for the secondary serial connection.

• A : Two 6P6C (RJ12/RJ25), female.

Used for additional serial connections (requires the optional serial 

communications module).

• B : Two 6P6C (RJ12/RJ25), female.

Used for additional serial connections (requires the optional serial 

communications module).

• 1 : 8P8C (RJ45), female.

Can be used for the primary Ethernet connection (instead of the 

CPUM connector (NET)).

• 2 : 8P8C (RJ45), female.

Used for the secondary Ethernet connection.

Physical

CPUM

• Height : 6U (262 mm, 10.3 in)

• Width : 40 mm (1.6 in)

• Depth : 187 mm (7.4 in)

• Weight : 0.40 kg (0.88 lb) approx.

IOCN

• Height : 6U (262 mm, 10.3 in)

• Width : 20 mm (0.8 in)

• Depth : 125 mm (4.9 in)

• Weight : 0.25 kg (0.55 lb) approx.

To order please specify

Type Designation Ordering number (PNR)

CPUM Different versions of the VM600 modular CPU card:

– Ethernet redundant

Modular CPU card with a CPU module that supports two 

Ethernet interfaces and two serial interfaces.

This CPUM supports Ethernet interfaces on the front panel 

(CPUM) and the rear panel (IOCN), a serial interface (RS-232)

on the front panel (CPUM) and a serial interface (isolated

RS-232/RS-485) on the rear panel (IOCN).

200-595-0Ss-33h

(601-003-000-VVV3610-1CC-CCC 

when pre-configured See notes)

– Ethernet redundant varnished

Same as the (standard) Ethernet redundant version, with a 

conformal coating for additional environmental protection.

200-595-0Ss-33hl

(601-003-000-VVV3V610-1CC-CCC 

when pre-configured See notes)

– Serial redundant

Modular CPU card with a CPU module that supports two 

Ethernet interfaces and two serial interfaces, and a serial 

communications module that supports additional serial 

interfaces.

This CPUM supports Ethernet interfaces on the front panel 

(CPUM) and the rear panel (IOCN), a serial interface (RS-232)

on the front panel (CPUM) and a serial interface (isolated

RS-232/RS-485) on the rear panel (IOCN). It also supports two 

additional serial interfaces

(RS-422/RS-485) on the rear panel (IOCN).

200-595-0Ss-53h

(601-003-000-VVV5610-1CC-CCC 

when pre-configured See notes)

IOCN Different versions of the input/output card for the CPUM:

– Ethernet redundant 200-566-000-1Hh

– Ethernet redundant varnished

Same as the (standard) Ethernet redundant version, with a 

conformal coating for additional environmental protection.

200-566-000-1HhL

Notes

Different versions of the CPUM card can be supplied pre-configured with different configurations, as denoted by the 9-digit code in 

the ordering number (610-1CC-CCC).

“1CC-CCC” represents the different configurations that can be used by a finished product. For example, 610-100-000 corresponds 

to the ‘standard’ configuration that is uploaded to a CPUM card (200-595-0Ss-HHh), if no other configuration is specified. For 

information on other configurations. Contact your local Meggitt representative or Meggitt SA for further information.

“Ss” represents the firmware (embedded software) version and “Hh” the hardware version of a card. “S/H” increments for major 

modifications that can affect product interchangeability and “s/h” increments for minor modifications that have no effect on 

interchangeability.

“VVV” represents the different firmware (embedded software) versions and hardware versions that can be used by a 

finished product.

RELATED PRODUCTS

ABE04x VM600 system racks : Refer to corresponding data sheet

CPUR and IOCR VM600 rack controller and communications 

interface card pair

Note: With rack controller redundancy and 

support for Modbus RTU/TCP

: Refer to corresponding data sheet

CPUR2 and IOCR2 VM600 rack controller and communications 

interface card pair

Note: With mathematical processing of 

fieldbus data and support for Modbus TCP 

and PROFIBUS

: Refer to corresponding data sheet

AMC8 and IOC8T VM600 analog monitoring card and

input/output card

: Refer to corresponding data sheet

MPC4 and IOC4T VM600 machinery protection card and

input/output card

: Refer to corresponding data sheets

RLC16 VM600 relay card : Refer to corresponding data sheet

Meggitt (Meggitt PLC) is a leading international engineering company, headquartered in England, that designs and delivers high-performance 

components and subsystems for aerospace, defence and selected energy markets. Meggitt comprises four customer-aligned divisions: 

Airframe Systems, Engine Systems, Energy & Equipment and Services & Support.

The Energy & Equipment division includes the Energy Sensing and Controls product group that specialises in sensing and monitoring solutions for a 

broad range of energy infrastructure, and control valves for industrial gas turbines, primarily for the Power Generation, Oil & Gas and Services markets. 

Energy & Equipment is headquartered in Switzerland (Meggitt SA) and incorporates the Vibro-Meter® product line, which has over 65 years of sensor 

and systems expertise and is trusted by original equipment manufacturers (OEMs) globally.

All information in this document, such as descriptions, specifications, drawings, recommendations and other statements, is believed to be 

reliable and is stated in good faith as being approximately correct, but is not binding on Meggitt (Meggitt SA) unless expressly agreed in 

writing. Before acquiring and/or using this product, you must evaluate it and determine if it is suitable for your intended application. You 

should also check our website at www.meggittsensing.com/energy for any updates to data sheets, certificates, product drawings, user 

manuals, service bulletins and/or other instructions affecting the product.

Unless otherwise expressly agreed in writing with Meggitt SA, you assume all risks and liability associated with use of the product. Any 

recommendations and advice given without charge, whilst given in good faith, are not binding on Meggitt SA. Meggitt (Meggitt SA) takes 

no responsibility for any statements related to the product which are not contained in a current Meggitt SA publication, nor for any 

statements contained in extracts, summaries, translations or any other documents not authored and produced by Meggitt SA.

The certifications and warranties applicable to the products supplied by Meggitt SA are valid only for new products purchased directly from 

Meggitt SA or from an authorised distributor of Meggitt SA.

In this publication, a dot (.) is used as the decimal separator and thousands are separated by thin spaces. Example: 12345.67890.

Copyright© 2019 Meggitt SA. All rights reserved. The information contained in this document is subject to change without prior notice

The effectiView eV035-TST and eV035-TNT are compact HMI panels with a 3.5” TFT display and 

touchscreen interface. They are the ideal choice for entry-level HMI applications without 

compromising performance. 

• 3.5” TFT color display, 256 colors, LED 

backlight

• 320×240 pixels

• Resistive touchscreen

• Portrait mode operation

• 10/100 Ethernet interface (eV035-TNT only) 

• 4MB user memory

effectiView is a family of HMI operator panels offering an excellent price/performance factor; the 

level of functionality they offer is state-of-the-art for applications in factory and building automation. 

The eVDesigner software is the programming tool for all eV products. 

The powerful simulation module of the eVDesigner simplifies development and shortens the 

development time.

• Efficient and intuitive programming with 

the eVDesigner software. Powerful project 

manager workspace with support of 

multiple applications. 

• Ample choice of communication drivers 

for industrial devices. 

• Multiple driver communication capability 

• Full vector graphic support with TrueType 

fonts. Portrait mode operation. 

• Display dynamic data in multiple formats: 

numerical, text, bargraph, slider, gauge 

and graphic image formats. Multiple 

image formats supported: bitmap, JPEG 

and dynamic GIF. Multiple object 

properties with dynamic control, including 

visibility and position. 

• Pop-up screens and windows. 

• Data acquisition and trend presentation. 

Trend data can be transferred to a host 

computer. 

• Recipe data storage. Recipe data can be 

transferred to a host computer. 

• Multilanguage applications with Unicode 

support. Up to 10 run-time languages are 

possible. Application text can be 

exported/imported for translation. 

• Powerful script language with easy-to-use 

editor. Macro commands can be triggered 

by touchscreen, events and timers. 

• Alarms and historical alarm log. Alarm 

and event information can be printed or 

transferred to a host computer. 

• Multiple level password protection. 

• Data sharing with Ethernet-based network. 

The effectiView eV035-TST and eV035-TNT are compact HMI panels with a 3.5” TFT display and 

touchscreen interface. They are the ideal choice for entry-level HMI applications without 

compromising performance. 

• 3.5” TFT color display, 256 colors, LED 

backlight

• 320×240 pixels

• Resistive touchscreen

• Portrait mode operation

• 10/100 Ethernet interface (eV035-TNT only) 

• 4MB user memory

effectiView is a family of HMI operator panels offering an excellent price/performance factor; the 

level of functionality they offer is state-of-the-art for applications in factory and building automation. 

The eVDesigner software is the programming tool for all eV products. 

The powerful simulation module of the eVDesigner simplifies development and shortens the 

development time.

• Efficient and intuitive programming with 

the eVDesigner software. Powerful project 

manager workspace with support of 

multiple applications. 

• Ample choice of communication drivers 

for industrial devices. 

• Multiple driver communication capability 

• Full vector graphic support with TrueType 

fonts. Portrait mode operation. 

• Display dynamic data in multiple formats: 

numerical, text, bargraph, slider, gauge 

and graphic image formats. Multiple 

image formats supported: bitmap, JPEG 

and dynamic GIF. Multiple object 

properties with dynamic control, including 

visibility and position. 

• Pop-up screens and windows. 

• Data acquisition and trend presentation. 

Trend data can be transferred to a host 

computer. 

• Recipe data storage. Recipe data can be 

transferred to a host computer. 

• Multilanguage applications with Unicode 

support. Up to 10 run-time languages are 

possible. Application text can be 

exported/imported for translation. 

• Powerful script language with easy-to-use 

editor. Macro commands can be triggered 

by touchscreen, events and timers. 

• Alarms and historical alarm log. Alarm 

and event information can be printed or 

transferred to a host computer. 

• Multiple level password protection. 

• Data sharing with Ethernet-based network. 

Digital Wiegand Multi I/O

Management Device

The TK_S014 Wiegand module enables connectivity of any standard 

device which uses the industry standard wiegand protocol, including 

biometrics. 

Also enables step-by-step migration of current installations to save time 

and move to new Temaline access control technologies and benefits.

MAJOR BENEFITS

Easy to install:

The direct LON connection and embedded I/O simplifies installation and 

engineering and reduces the number of system devices.

Flexibility: 

Select the reader you prefer in terms of design or re-use existing devices 

for cost-saving purposes.

Investment protection: 

As your network grows, the solution can scale and devices can be re-used.

l Standard DIN/

Omega RAIL 35

l TK_S014 supports 

Two “Wiegand 7 

Wire” connected 

card readers and 

the I/O associated 

with a single door.

l Echelon “LON” 

Device

l Tamper-proof 

housing

l Internal I/O for 

door control

l Supervised inputs

l RoHS compliant, 

so environment 

respectful

PHYSICAL SPECIFICATION

Protection Rating IP31

Dimensions (H x W x D) 90mm x 105mm x 70mm

Weight 0.2kg

ENVIRONMENTAL

Operating Temperature Standard DIN/omega Rail 35

Operating Humidity 0°

C / +50°

C

Certification

Directive EMC 89/336/EEC, 92/31/EEC

Low Voltage Directive 93/68/EEC

RoHS/WEEE compliant device

Directives 2002/95/EC 2002/96/EC

› External power source supported but not required 

› Compact size 

› Converts RS-422, and both 2-wire and 4-wire RS-485

› RS-485 automatic data direction control 

› Automatic baudrate detection 

› 15 KV serial ESD protection

› Built-in 120-ohm termination resistors

The TCC-80 provides complete signal conversion between RS-232 and 

RS-422/485, without requiring an external power source. It supports 

both half duplex 2-wire RS-485 and full duplex 4-wire RS-422/485, 

either of which can be converted between RS-232’s TxD and RxD lines. 

In addition, the TCC-80’s 15 KV ESD protection guards against damage 

from electrostatic discharge.

Automatic data direction control is also provided for RS-485, in 

which the RS-485 driver is enabled automatically when the circuitry 

senses the TxD output from the RS-232 signal. This means that no 

programming effort is required to control the transmission direction of 

the RS-485 signal.

The RS-232 port of the TCC-80 is a DB9 female socket that can 

connect directly to the host PC, with power drawn from the TxD, 

RTS, or DTR line. Regardless of whether the signal is high or low, 

the TCC-80 can obtain enough power from the data/handshake line. 

However, external power can be used if the handshake line is not 

available, if the serial cable is too long, or if the RS-232 device is a low 

power device. For external power, a 5 to 12 VDC power supply can be 

connected using an adaptor or a USB power cord

When installing a TCC-80 converter, it is important to pay attention 

to power consumption, RS-232 cable length, and RS-422/485 

transmission distance. In general, the TCC-80 obtains 50 mW from 

the power source. Standard PC COM ports can provide 70 to 90 mW 

of power if the TxD, RTS, and DTR lines are connected. Moreover, 

Port Power Dissipation

the RS-232 cable should be shorter than 15 m (@ 9600 bps) to 

ensure that less power is lost from the host/device to the TCC-80. 

The remainder of the supplied power is used for transmitting the 

RS-422/485 signal.

Specifications

PIN RS-232

1 DCD

2 TxD

3 RxD

4 DSR

5 GND

6 DTR

7 CTS

8 RTS

DB9 female

connector

DIP Switch Settings

5 4 3 2 1

9 8 7 6

RS-232 Side

Connector: DB9 female

Signals:

RS-232: TxD, RxD, RTS, CTS, DTR, DSR, DCD, GND

(Loop-back wiring: RTS to CTS, DTR to DSR and DCD)

RS-422/485 Side

Connector: Terminal Block or DB9 male

Signals (interface selected by DIP switch):

RS-422: TxD+, TxD-, RxD+, RxD-, GND

RS-485-4w: TxD+, TxD-, RxD+, RxD-, GND

RS-485-2w Signals: Data+, Data-, GND

RS-485 Data Direction Control: ADDC® (automatic data direction 

control)

Serial Transmission

Baudrate: 300 bps to 115.2 Kbps

ESD Protection: 15 KV

Pull High Resistance: 1k ohm

Pull Low Resistance: 150k ohm

Physical Characteristics

Case: ABS + PC

Weight: 50 ± 5 g

Dimensions: 42 x 80 x 22 mm (1.65 x 3.15 x 0.87 in)

Environmental Limits

Operating Temperature: 0 to 60°C (32 to 140°F)

Operating Humidity: 5 to 95% RH

Storage Temperature: -20 to 75°C (-14 to 167°F)

Power Requirements

Source of Input Power: RS-232 port (TxD, RTS, DTR) or power input 

jack

Input Voltage: 5 to 12 VDC

Power Consumption: 10 mA @ 5 V (with termination disabled)

Surge Protection: Embedded 15 KV ESD Surge Protection

Regulatory Approvals

CE: Class B

FCC: Class B

Warranty

Warranty Period: 5 years

Details: See www.moxa.com/warranty

Ordering Information

Optional Accessories (can be purchased separately)

Package Checklist

• TCC-80 media converter

• USB power cord (50 cm)

• Quick Installation Guide (printed)

• Warranty Card

Available Models

TCC-80: Port-powered RS-232 to RS-422/485 converter with 15 KV serial ESD protection and 

terminal block on the RS-422/485 side

TCC-80-DB9: Port-powered RS-232 to RS-422/485 converter with 15 KV serial ESD protection 

and DB9 male connector on the RS-422/485 side

Power Adaptor

CBL-F9M9-20: DB9 male to DB9 female RS-232 cable (20 cm)

7 10/100 Base TX and 3 RJ-45/SFP combo (10/100BaseTX, 100Base-FX )

Flexible Fiber connection-Multi or Single mode fiber 

cable

Comprehensive Ring Technology- Multiple Super Ring 

(MSRTM)

Latest Rapid Super Ring Technology- 5 ms failover time, 

zero for restore time

Multi-path, Multi-node backup technology-Rapid Dual 

Homing (RDHTM )

Multiple ring coupling technology- MultiRingTM

Ring Path Aggregation technology – TrunkRingTM

Flexible Ring architecture- TangentRingTM,CrossRingTM

, AnyRingTM

Support device recovery utility – JetViewTM

High Speed Fabric-32Gbps with Non-blocking technology 

LACP /VLAN / GVRP /QoS /IGMP Snooping/Rate 

Control/ Online Multi-Port Mirroring

Secured by Port, Access IP, SSH and HTTPS Login

IEEE 802.1x with Local and remote authenticate service.

(YHQW1RWL¿FDWLRQE60736103WUDSDQGVVWHPORJV

Cisco-Like CLI, Web, SNMP/RMON for network 

Management

Redundant DC Power Inputs, Digital Input and Relay 

Output

1.5KV Hi-Pot Protection for ports and power

,QGXVWULDO+HDW GLVSHUVLQJ GHVLJQ aÛ& RSHUDWLQJ

temperature, Rigid Aluminum Case Complies with IP31

The JetNet 4510 is a Managed industrial Ethernet 

Switch, equipped with 7 ports 10/100TX and 3 

ports 10/100 RJ-45 / 100FX SFP combo ports. 

The JetNet 4510 is designed as rugged surface in 

aluminum alloy material and with wide operating 

temperature. The software supports full L2

management features, ring redundancy, network 

Overview

control, security and alert features. The JetNet 

4510 also supports RS-232 console for out of band 

management and the combo port design could 

enlarged connection from 10 ports pure 10/100Mbps

pure copper to 7 ports 10/100Mbps copper plus 3 

¿EHUSRUWVZLWKPXOWLPRGHRUVLQJOHPRGHWUDQVFHLYHU

in random.

It is critical for industrial applications that network 

remains non-stop. Korenix Rapid Super Ring 

technology provides network redundancy that can 

self-recover in less than 5 ms at full load. Besides, 

JetNet 4510 provides users with many advanced 

management features. It can be configured smartly 

by console CLI and web browser, the network 

DGPLQLVWUDWRUFDQGH¿QHHYHQWQRWL¿FDWLRQWREHVHQW

via E-mail, SNMP trap, Syslog or relay output. Online 

status of each port is also shown on web page. To 

optimize network traffic, network administrators 

can segment ports into different VLANs, or filter 

S

multicast traffic by IGMP Snooping. Bandwidth 

can be managed by port rate control to avoid 

abnormalbroadcast storm. To enhance security, 

port access can be limited to pre-defined IP 

address table, binding MAC address to specific 

port or managed by HTTPS or SSH or perform 

access security through IEEE 802.1x mechanism. 

Network determinism is answered by QoS, Quality 

of Service, for traffic prioritization. JetNet 4510

is the perfect combination for intelligent network 

management and robust network operation.

The JetNet 4510 equips three combo Fast Ethernet 

ports, each combo port combining one Small Form 

factor Pluggable (SFP) socket for 100Mbps multimode or single mode SFP transceiver and one RJ-45 

copper port in 10Mbps full duplex, 100Mbps half /full 

duplex link mode. The switch will automatically detect 

3 Flexible Fast Ethernet Combo Ports

the cable connections priority for combo port. Users 

can connect two 100Mbps SFP ports of JetNet 4510

as a Fast Ethernet Fiber Redundant Ring topology 

and the third combo port as a fiber uplink port or 

applicable port.

Comprehensive Redundant Solutions- Multiple Super 

Ring (MSRTM) Technology

It is critical for industrial applications that network 

remains non-stop. The JetNet 4510 supports new 

generation of ring technology – MSRTM which 

includes various new technology for different network 

redundancy applications and architectures. With the 

MSRTM technology, the failover time could be short 

less than 5 milliseconds and with zero second restore 

time. Unlimited device connective, user can enlarged 

the ring architecture as the campus need without 

delay of the data traffic. The MSRTM also facilitates 

the JetNet 4510 to connect with core management 

switch via standard Rapid Spanning Tree protocol 

though multiple paths or multiple nodes

to increase the reliability by Rapid Dual Homing 

(RDHTM) technology. To higher link availability and 

increase link capacity, the JetNet 4510 has been 

implemented IEEE 802.3ad Link Aggregation Control 

Protocol (LACP). With LACP technology, the JetNet 

4510 can negotiate an automatic port bundling 

dynamically between switches. Two or more Fast 

Ethernet connections are combined in order to 

increase the bandwidth and to create resilient and 

redundant links, it also allows two power inputs 

for power redundancy and wide DC power range, 

from DC 12V to DC 48V plus supporting DC-48V in 

industrial applications.

Rapid Super Ring (RSR) Technology

Rapid Super Ring is Korenix 2nd generation Ring 

redundancy technology. The recovery time is 

enhanced from 300ms to 5ms for copper ring, 20ms

for Fiber ring. The Ring Master can be auto-selected 

by the RSR engine. The 1st Ring Port of the R.M. is 

the primary path. The 2nd Ring Port of the R.M. is 

the block path. Once the primary path is failure, the 

2nd path will be recovered within 5ms. Besides, the 

restore time is also enhanced to zero in R.M. auto 

Rapid Dual Homing (RDHTM) Technology

In the MSR technology includes a new Dual Homing 

technology- Rapid Dual Homing (RDHTM) which 

provides flexible uplink connection in multiple node 

to node or multiple paths to one to obtain more 

HI¿FLHQFDQGUHOLDELOLWWKDQEHIRUH:KHQRXZDQW

connect multiple RSR or form the redundant topology 

with other vendors, RDHTM allows you enable RSTP 

and RSR at the same device and break the limitation 

of ring node. Thus you have more flexibility and 

standard (RSTP) way to construct your network 

topology

MultiRingTM Technology

The MultiRingTM is a new technology that construct 

coupling ring without control port and achieve 

different coupling architecture by TangentRingTM or 

CrossRingTM (Note-1) technology which provides node 

or path backup ability

By the MultiRingTM Technology, user can enlarge the 

network campus just apply different Ring ID which 

is different with neighborhood to get unlimited Ring 

Coupling ability. 

Link Aggregation Control Protocol, TrunkRingTM

Technology

Link Aggregation Control Protocol allows you to group 

multiple Ethernet ports in parallel to increase the link 

bandwidth. The aggregated ports can be viewed as 

one physical port, so that the bandwidth is higher 

than just one single Ethernet port. The member ports 

of the same trunk group can balance the loading 

and backup with each other. The LACP feature is 

usually used when you need higher bandwidth for the 

backbone network. This is an inexpensive way for 

you to transfer much more data. If the trunk port 

also assigned as a ring port then it will become as 

a TrunkRingTM – which mean is the bandwidth of 

ring path have increased by port trunk technology 

and there is no recovery time when failure occurred. 

The JetNet 4510 provides a simply, easily way to 

aggregate port bandwidth into Rapid Super Ring.

Robust Mechanism Design

Korenix JetNet 4510 outstanding outlook is attractive 

and with strong functionality. The special fan-less 

mechanical design adapts the thermodynamic 

technique to ventilate heat generated from Fast 

(WKHUQHWPRGXODUHI¿FLHQWO7KHIRUPIDFWRUZLWKQLFH

LQZDUGFXUYDWXUHRQWKHVLGHVGULYLQJDLUÀRZWKURXJK

the enclosure, it helps carrying the rising heat 

toward the top ventilation holes to let the chimneyHIIHFWÀRZVEHFRPHYHUHIIHFWLYH8VLQJDOXPLQXP

extrusion case with industrial arts quality, IP 31 class 

of protection, light weight, rigid assembly, excellent 

thermal conductivity, fin-type by extending heat 

dissipation surface assures units can be operated 

under harsh industrial environment reliably

Technology

Standard:

IEEE 802.3 10Base-T Ethernet

IEEE 802.3u 100Base-TX Fast Ethernet

IEEE 802.3u 100Base-FX Fast Ethernet

IEEE 802.3x Flow Control and Back-pressure

IEEE 802.1p class of service

IEEE 802.1Q VLAN

IEEE 802.1D-2004 Rapid Spanning Tree Protocol (RSTP)

IEEE 802.3ad LACP

IEEE 802.1x Port based Network Access Control

Performance

Switch Technology:

Store and Forward Technology with 32Gbps Switch Fabric

System Throughput: 2.976Mpps/ 64bytes packet length

Transfer packet size: 

64 bytes to 1522 bytes (with VLAN Tag)

Transfer performance: 14,880pps for Ethernet and 

148,800pps for Fast Ethernet

MAC Address: 8K MAC

Packet Buffer: 1Mbits

Relay Alarm: 

Dry Relay output with 1A@DC 24V contact ability

Management

&RQ¿JXUDWLRQCisco-Like CLI, Telnet, Web, TFTP/

:HE8SGDWHIRU¿UPZDUHDQGFRQ¿JXUDWLRQEDFNXSDQG

restore, DHCP Client, warm reboot, reset to default, Admin 

password, Port Speed/Duplex Control, status, statistic, MAC 

address table display, static MAC, Aging time, SNMP v1,

v2c, v3, Traps and RMON1

SNMP MIB: MIBII, Bridge MIB, VLAN MIB, SNMP MIB, 

RMON and Private MIB

Port Trunk: Up to 5 Static Trunk and with IEEE 802.3ad

LACP protocol

VLAN: 802.1Q VLAN, GVRP. Up to 64 VLAN groups

Port Trunk: Up to 5 Static Trunk and 802.3ad LACP 

Quality of Service: Four priority queues per port, 802.1p

COS and Layer 3 TOS/DiffServ

IGMP Snooping: IGMP Snooping V1/V2 /V3 for multicast 

¿OWHULQJDQG,*034XHU99

Rate Control:,QJUHVV¿OWHULQJIRU%URDGFDVW0XOWLFDVW

8QNQRZQ’$RUDOOSDFNHWVDQG(JUHVV¿OWHULQJIRUDOO

packets

NTP: Network Time Protocol to synchronize time from 

internet or local PC

Embedded Watchdog: Embedded hardware watchdog 

timer to auto reset system when failure

Port Mirroring: 2QOLQHWUDI¿FPRQLWRULQJRQPXOWLSOH

selected ports

Port Security: Port security to assign authorized MAC to 

VSHFL¿FSRUW

IP Security: IP address security to prevent unauthorized 

access

E-mail Warning: $XWRPDWLFHPDLOZDUQLQJESUHGH¿QHG

events

System Log: Supports both Local mode and Server mode

DHCP: DHCP Client, DHCP Server with IP binding MAC or 

excludes IP address functions

Port Based Network Security: IEEE 802.1x for user 

access authentication with local access list or remote 

Radius server

Network Redundancy

Rapid Spanning Tree: IEEE802.1D-2004 Rapid Spanning 

Tree Protocol. Compatible with Legacy Spanning Tree and 

802.1w

Multiple Super Ring(MSRTM): New generation Korenix 

Ring Redundancy Technology-Multiple Super Ring.

The MSRTM supports 5ms failover time and zero delay 

of restore time with R.M. auto selection, it also backward 

compatible with legacy super ring in slave mode

Rapid Dual Homing (RDHTM): Support multiple node to 

QRGHPXOWLSOHSDWKWRRQHQRGHWRREWDLQPRUHÀH[LEOHDQG

reliable architecture

TrunkRingTM: Provides port aggregate function in ring 

path to get more bandwidth for higher throughput ring 

architecture

MultipleRingTM: New generation of ring coupling technology 

without extra control port. It equipped 2 types of connection 

architecture- TangentRingTM and CrossRingTM (Note-1)

Any Ring: Inter-operate with other venders’ redundant ring

Interface

Number of Ports: 

10/100TX: 7 x RJ-45, Auto MDI/MDI-X, Auto Negotiation

10/100TX: 3 x RJ-45, combo with SFP

100Base-FX: 3 x SFP with Hot- Swappable

Cables:

10Base-T: 2-pair UTP/STP Cat. 3, 4, 5 cable, EIA/TIA-568B

100-ohm (100m)

100 Base-TX: 2/4-pair UTP/STP Cat. 5 cable, EIA/TIA-568B

100-ohm (100m)

Diagnostic LED:

10/100 RJ-45: Link /Activity(Green), Full duplex/Collision 

(Yellow)

Port 8~10 Copper: Link/Activity(Green)

Port 8~10 SPF: Link/Activity(Green)

Unit: Power(Green), Digital Out(Red), Digital Input(Green), 

R.M.(Green)

RS232 Console: RJ-45 Connector, Pin3: TxD, Pin6: RxD, 

Pin5:GND

Power: 2 sets of power Input

Digital Input: 

2 sets of Digital Input

Logic Low (0): DC 0~10V

Logic High(1): DC 11~30V

Alarm: VHWVRI5HODRXWSXWIRUSUHGH¿QHGHYHQWV

Reset: Reset button is provided to restore default settings

Power Requirements

System Power: Dual Power Input, DC 12~48V/-12~-48V 

with Reverse Polarity Protection

Power Consumption: About 11.5 Watts @ DC 48V

Mechanical

Installation: DIN-Rail mount or Wall Mount

Case: IP-31 protection, aluminum metal case

Dimension: 137mm(H) x 96mm (W) x 119mm (D) 

( without DIN rail clip)

Weight: 0.915 g without package

Environmental

Operating Temperature: -10 ~70O

C

Operating Humidity: 5% ~ 95% (non-condensing)

Storage Temperature: -40 ~ 85O

C

Hi-Pot: 1.5KV for ports and power

Regulatory Approvals

EMI: FCC Class A, CE/EN55022. Class A

EMC Immunity Interface: EN61000-4-2, EN61000-4-3, 

EN61000-4-4, EN61000-4-5, EN61000-4-6, EN61000-4-8, 

EN61000-4-11

Safety: UL, cUL

Shock: IEC60068-2-27

Vibration: IEC60068-2-6

Free Fall: IEC60068-2-32

MTBF: 249,683 Hours ,*MIL-HDBK-217F GB(MILITARY 

HANDBOOK) standard

Warranty: 5 years

Note-1: Available in the further, please contact with Korenix 

sales windows for more detail information

Ordering Information

JetNet 4510 Industrial 10-Port Managed Fast Ethernet Switch

Includes:

7-ports 10/100Base-TX and 3 10/100/ 100FX SFP Combo ports Switch

Wall mounting plate and six screws

Quick Installation Guide

Documentation CD-ROM

Ordering Accessories

JetNet 4510 Industrial 10-Port Managed Fast Ethernet Switch

Includes:

7-ports 10/100Base-TX and 3 10/100/ 100FX SFP Combo ports Switch

Wall mounting plate and six screws

Quick Installation Guide

Documentation CD-ROM

SFP100MM: 100Mbps SFP Transceiver,1310nm, multi-mode, 2KM, -10~70O

C

SFP100MM-w: 100Mbps SFP Transceiver,1310nm, multi-mode, 2KM, -40~85O

C

SFP100SM30: 100Mbps SFP Transceiver,1310nm, single-mode, 30KM, -10~70O

C

SFP100SM30-w: 100Mbps SFP Transceiver,1310nm,single-mode, 30KM, -40~85O

C

 GENERAL

This document describes the general specifications 

of the FCN autonomous controller with NFCP501/

NFCP502 CPU module. (FCN is an acronym for field 

control node.)

Notation in this document:

• The term “FCN” refers to the module consisting type 

autonomous controllers.

• The term “FCN-500” refers to the autonomous 

controllers with NFCP501/NFCP502 CPU module.

For Function, refer to FCN Autonomous Controller 

Functions (FCN-500), GS 34P02Q03-01E.

FCN Autonomous Controller 

Hardware (FCN-500)

Yokogawa Electric Corporation

2-9-32, Nakacho, Musashino-shi, Tokyo, 180-8750 Japan

GS 34P02Q14-01E

GS 34P02Q14-01E

©Copyright Mar. 2016(YK)

20th Edition Apr. 1, 2022(YK) 

 FEATURES

• High-performance, high-reliability modular controller

• Memory with ECC

• Low heat dissipation eliminates the need for a fan

• A wealth of RAS features — CPU self-diagnostics, temperature monitoring, I/O diagnostics, and more

• The CPU, power supply module, internal communication bus on backboard (SB bus), E2 bus (extension bus), and 

control network (Ethernet port 1 and 2) can all be duplexed, and all modules are hot-swappable. Use a couple of the 

CPU module of the same type to make the CPU module duplex configuration.

• Can function as link active schedulers (LASs) for low-speed voltage mode (H1) FOUNDATION Fieldbus segments, 

and link up FOUNDATION Fieldbus-enabled field devices. 

CONFIGURATION

An FCN-500 consists of the following: 

• Base module

• Power supply module

• CPU module

• E2 bus interface module (extending the unit) (*1)

• SB bus repeat module (extending the SB bus to connect an extension unit) (*1)

• I/O modules

*1: SB bus repeat module and E2 bus interface module can not be used together.

There are four types of base module.

– NFBU200 base module (long): Control unit and extension unit sharing, 

 duplexed power supply possibility

– N2BU051 base module (short): Control unit and extension unit sharing

– NFBU050 base module (short): Control unit only, for low power

– N2BU030 base module (compact): Control unit and extension unit sharing

l Control unit alone

The control unit is unit with CPU module. The maximum number of I/O modules that can be implemented depends on 

the type of base module and the number of CPUs.

Maximum I/O Module Configurations

Base Module Unit Configuration Standard Duplexed (*1)

NFBU200 base module (long) Control unit alone Max. 8 modules Max. 6 modules

N2BU051 base module (short) Control unit alone Max. 3 modules Not applicable (*2)

NFBU050 base module (short) Control unit alone Max. 3 modules Not applicable (*2)

N2BU030 base module (compact) Control unit alone Max. 1 module Not applicable (*2)

*1: When CPU modules are duplexed

*2: Neither power supply nor CPU modules can be duplexed on N2BU051, NFBU050 or N2BU030

Example: Standard control unit

Example: Control unit with duplexed CPU and power supply modules

Example: Short control unit

Example: Compact control unit

l Unit extension with E2 bus

Up to eight extension units can be connected to the control unit using the E2 bus interface modules. Two ports of 

the E2 bus interface module mounted on the control unit can be connected to extension units as separate lines. The 

maximum number of extendable units that can be connected is a maximum of 8 units in total of two lines. Three types 

of base modules (NFBU200, N2BU051 or N2BU030) can be used as control unit and extension unit. By installing two 

E2 bus interface modules in each base module, it is possible to duplex E2 bus. (*1)

Connect each E2 bus interface module with UTP straight cable (CAT 5e or higher). The distance between units can be 

extended up to 100 m.

*1: When using the compact base module for the control unit, it is not possible to duplex the communication lines.

Maximum I/O Module Configurations

Note: NFCP501/NFCP502 CPU module style S2 or later is required to use the E2 bus interface module.

*1: When CPU and E2 bus interface modules are duplexed.

*2: When NFBU200 base modules are used in all extension units.

Extension of Transmission distance by Optical fiber

The transmission distance between units can be extended by converting the system from UTP straight cable to 

fiber optic cable with third party’s media converters. Only Layer 1 (Physical Layer) media converters which simply 

convert packets from electric signal to optical signal can be used for the E2 bus. Refer to the verified media converter 

information and precaution on Yokogawa Partner Portal STARDOM site when choosing the model.

Example: Standard control unit + 8 extension units with E2 bus interface modules / 1 lines

Example: Control unit with duplexed CPU modules, power supply modules, and E2 bus + 8 extension units 

/ 1 lines

Example: Control unit with duplexed CPU modules, power supply modules, and E2 bus + 8 extension units 

/ 2 lines

Note: The CPU module, power supply module, and E2 bus can be made duplex individually, when required

Example: Mixed base module configuration, E2 bus + 8 extension units / 2 lines

Note: Three kinds of base modules (NFBU200, N2BU051 or N2BU030) can be arranged according to the number of I/O points 

and installation environment required for the control unit and extension unit. 

Power supply for 2-wires types of transducers and 

signal conditioners 

] μA to mV conversion for long distance signal 

transmission

] Certified for use with measuring chains in potentially 

explosive atmospheres

] Galvanic separation voltage: 4 kVRMS

] High rejection of frame voltage

] DIN-Rail mounting

The versatile GSI 124 galvanic separation unit replaces 

its predecessors: GSI 122, GSI 123 and GSI 130. The 

GSI 124 is for use with piezo-electric transducers with 

integrated electronics (eg. CE XXX), piezo-electric transducer signal conditioners (eg. IPC XXX) and proximity 

probe signal conditioners (eg. IQS 4XX series).

The unit is intended for use in 2-wire transmission systems at high frequencies. More generally, it may be used 

to supply any electronic system having a consumption of 

less than 20 mA.

The GSI 124 avoids the use of Zener barriers for Exi 

applications. It allows the transmission of AC signals 

over long distances. The unit rejects a large amount of 

the RMS voltage of ground noise and avoids AC noise 

pickup which can occur between the sensor case and 

the poles of the sensor.

BLOCK DIAGRAM

Environmental characteristics

General

Temperature

• Operating : 0°C to 70°C

• Storage : -20°C to +85°C

Vibration (according to IEC68.2.6) : 5Hz to 35 Hz, 90 minutes/axis

0.15 mm peak below resonance frequency, 1 g peak above

Humidity (according to IEC68.2.30)

• Operating : Up to 90%, non-condensing

• Storage : Up to 95%, non-condensing

Shock 

(according to IEC68.2.27)

: Half-sine, 6 g peak, 11 ms, 3 shocks/axis

Induced signal susceptibility 

(according to IEC61000-4-4/5)

: Performance criteria B

RF susceptibility 

(according to IEC61000-4-3)

: Performance criteria A

RF Emissions 

(according to IEC61000-4-3)

• Limits at 1 m : 30 MHz to 230 MHz < 60 dBμV/m (quasi-peak)

: 230 MHz to 1000 MHz < 67 dBμV/m (quasi-peak)

Electrostatic discharge

(according to IEC61000-4-2)

: Performance criteria B

Explosive atmospheres (ordering option A2)

• EC type examination certificate : LCIE 05 ATEX 6033 X

II (2) G (outside potentially explosive zone) [EEx ib] IIC

For specific parameters of the mode of protection concerned and special conditions for safe use, please refer to 

the “EC type examination certificate” that is available from Vibro-Meter SA on demand.

• cCSAus certificate : cCSAus certificate 1699234

Class I, Div 1, Groups A,B,C,D [Ex ia]

Electrical Characteristics

Power supply (user side)

Supply voltage

• With IPC XXX and CE XXX : 20 VDC to 30 VDC

• With IQS 4XX : 22.5 VDC to 30 VDC

Current consumption (with 24 VDC supply)

• Without load on transducer side : ≤ 20 mA

• With 12 mA on transducer side : ≤ 50 mA

• With 20 mA on transducer side : ≤ 70 mA

• With a short-circuit on transducer side : ≤ 70 mA

Output signal (monitor side)

Voltage output dynamic range (with 10 kΩ load) : ≥ 2 VDC

≤ U supply – 2.5 VDC

Output impedance : ≤ 1 Ω protected against short-circuits

Power supply voltage rejection ratio

• Standard (ordering option A1) : ≥ 55 dB at 10 Hz to 400 Hz

: ≥ 35 dB at 400 Hz to 100 kHz

• Explosive (ordering option A2) : ≥ 55 dB at 10 Hz to 400 Hz

: ≥ 35 dB at 400 Hz to 5 kHz

: ≥ 28 dB at 5 kHz to 100 kHz

Thermal output signal offset drift (0 … 70°C) : ≤ 4 mV/°C (200 ppm/°C)

Thermal output signal sensibility drift (0 … 70°C) : ≤ 100 ppm/°C

AC output signal residual noise

• Band width: 0 to 1 kHz : ≤ 2 μVRMS/√Hz

• Band width: >1 kHz : ≤ 4 μVRMS/√Hz

Input signal (transducer side)

Output supply voltage on 2-wires transmitting line : 21.5 VDC ± 2.5 VDC (without load)

Impedance : ≤ 90 Ω

Current dynamic range on 2-wires transmitting line : 0 mA to 20 mA

Short-circuit current limit on 2-wires transmitting line : ≤ 30 mA

Maximal load capacitance

• Standard : Cmax = 200 nF

• Explosive atmospheres : Cmax = 99 nF

Maximal load inductance

• Standard : Lmax = 30 mH

• Explosive atmospheres : Lmax = 25 mH

Transfer Characteristics (ordering option B)

Sensitivity

• IPC XXX and CE XXX : 1 V/mA ± 10 mV/mA

• IQS 4XX : 3.2 V/mA ± 32 mV/mA 

Output offset voltage (zero)

• IPC XXX (12 mADC on transmitting line) : 7 VDC ± 100 mVDC 

• CE XXX (5 mADC on transmitting line) : 7 VDC ± 100 mVDC 

• IQS 4XX (17.5 mADC on transmitting line) : 8 VDC ± 100 mVDC

Band width

IPC XXX and CE XXX (ordering option B1 and B2)

• Frequency band with a transfer inside ± 0.5 dB : DC to 20 kHz

• Typical frequency cut at -3 dB : 30 kHz

IQS 4XX (ordering option B3)

• Frequency band with a transfer inside ± 0.5 dB : DC to 10 kHz

• Typical frequency cut at -3 dB : 25 kHz

Linearity : < 0.2%

Galvanic separation voltage 4 kVRMS

Physical Characteristics

Dimensions : See mechanical drawing

Weight : 130 gr

Electronic housing material : Polyamide (PA 6.6) green

Electrical connections : With terminal screw – see m

o order please specify:

Type

Designation

Ordering number

: GSI 124 

: Galvanic separation unit

: 244-124-000-02X-A -B 

In this publication, a dot (.) is used as the decimal separator and thousands are separated by spaces. Example : 12 345.678 90. Although care has been 

taken to assure the accuracy of the data presented in this publication, we do not assume liability for errors or omissions. We reserve the right to alter any 

part of this publication without prior notice.

Overview

This reference guide is designed to help applications software programmers interface with Watlow®

CLS200 and MLS300 controllers and CAS200 alarm scanners via serial communication.

The following chapters are included in this guide:

• Anafaze/AB Protocol—gives an overview and explanation of the Anafaze/Allen Bradley 

communications protocol

• Modbus®-RTU Protocol—gives an overview and explanation of the Modbus®-RTU 

communications protocol

• Data Table Summary—provides standard controller data table maps for the parameters (one for 

each protocol)

• Parameters Description—describes each parameter

• Glossary—explanations of commonly used terms and acronyms

Chapter 1: Anafaze/AB 

Protocol

This chapter explains the ANAFAZE/Allen Bradley protocol.

Anafaze/AB Protocol Basics

This protocol is used with a serial communications link (EIA/TIA-232 or EIA-TIA-485) configured as 

follows:

• 2400 or 9600 baud 

• 8 data bits

• One or 2 stop bits

• No parity

Protocol Syntax

The controllers use a half-duplex (master-slave) protocol to interface to high-level software. The host 

software is considered the “master” and the controller is considered the “slave.” In other words, the 

software can request information from the controller or download information to the controller. The 

controller can only respond to communications transactions initiated by the host software. The controller 

cannot initiate communications.

Control Codes

The controller and host software communicate by sending and receiving information in a “packet” 

format. A packet consists of a sequence of bytes in a specific format; it can be as large as 256 bytes of 

data. (For more information about packets, see the Packet Format section later in this chapter.)

The numbers in the packet are sent in binary format. However, our examples show bytes in hexadecimal 

forma

Control code abbreviations in this manual

Transaction Sequence

Here are the four steps in a transaction between the host software and the controller. The following 

example shows the transaction as an exchange of packets. The example also assumes that there are no 

communication errors in the exchange.

1. The host software sends a packet that contains a read command or write command.

2. The controller sends a DLE ACK to the host software.

3. The host software receives a reply packet from the controller.

4. The host software sends a DLE ACK.

Transaction flow with no error handling

NOTE Due to the difference between the processing speeds of the controller and PC, it may be 

necessary to delay the computer’s acknowledgement (ACK) in order for the controller to receive it. 

A delay of 200ms should suffice.

The flowchart below shows one way for the host software to handle error checking. If you are writing 

simple software, you don’t necessarily need to use error handling routines as complete as these

Transaction flow with error handling

Packet Format

Messages are transmitted in the form of packets. Command and reply packets specify the source and 

destination addresses, whether to read or write, the block of data to read or write, etc.

A packet contains a sequence of binary bytes formatted this way:

Sending Control Codes

To send a control code, send a DLE before the control code to distinguish it from data.

Sending a DLE as Data

When you send a byte with 0x10, (a DLE), the controller and software interpret it as a command. 

Therefore, to send a DLE as data, send another DLE immediately before it (DLE DLE).

Codes in a Packet

This section describes the sequence of bytes in a packet, in the order the host software or controller 

sends them

DLE STX (byte) signals the beginning of a transmission. Every packet of information starts with the 

control codes DLE STX.

DST (byte) the address of the destination device (usually a controller; the first CLS200 controller is at 

0x08).

NOTE: When host software communicates with a CLS200 controller via the ANAFAZE or AB 

protocol, it does not send the controller’s actual address. Since the protocol reserves device 

addresses 0 to 7, the host software sends the value (controller address + 7), instead of the actual 

device address.

SRC (byte) the device address of the packet’s source. The host software is usually designated address

0x00.

CMD (byte) indicates the command that the host software sends to the controller. The software sends a 

read (0x01) or write (0x08). When the controller replies, it returns the read or write command with the 

7th bit set—in other words, it sends 0x41 or 0x48.

STS (byte) indicates the controller’s general status and error flags to the host software. The controller

ignores the status byte in the host software’s command packet. The table below lists status byte values 

and definitions.

An “n” in the status bytes below indicates that the associated nibble may contain additional information. 

In most cases, the status byte is composed of two independent nibbles. Each nibble is independent so 

that two codes can return at once. For example, status code F1 indicates that data has changed (Fn) and 

the controller is being updated through the front panel (0x1).

TNSL least significant byte of the transaction number. This is the first half of a “message stamp.” The

controller sends back the TNSL and TNSH exactly as it received them, so host software can use the 

TNSL and TNSH bytes to keep track of message packets.

TNSH most significant byte of the transaction number. This is the second half of the “message stamp.

ADDL the low byte of the beginning data table address of the block of data to read or write.

ADDH the high byte of the beginning data table address of the block of data to read or write.

DATA the new values to be set with a write command, or the requested data in a response to a read 

command.

DLE ETX ends every packet of information. Signals the end of a transmission.

BCC or CRC one or two-byte error check at the end of the packet. There are two error check methods: 

Block Check Character (BCC), which requires 1 byte, and Cyclic Redundancy Check (CRC), which 

requires 2 bytes.

Error Checking

The default error check method, BCC is easier to implement than CRC, and is acceptable for most 

applications.

Select one error check method and configure both software and controller for that method, or they will 

be unable to communicate.

The error check methods work this way:

Block Check Character (BCC)

BCC checks the accuracy of each message packet transmission. It provides a medium level of security. 

The BCC is the 2’s complement of the 8-bit sum (modulo-256 arithmetic sum) of the data bytes between 

the DLE STX and the DLE ETX. (1’s complement +1)

• BCC does not detect transposed bytes in a packet.

• BCC cannot detect inserted or deleted 0 values in a packet.

• If you have sent 0x10 as data (by sending DLE 0x10) only one of the DLE data bytes is included in 

the BCC’s sum (the DLE = 0x10 also).

For instance, the block read example shown in the examples section, adds 0x08 00 01 00 00 80 02 10. 

Note that the 0x10 representing DLE has been left out of the calculation. The sum should come to 0x9B.

1001 1011 = 0x9B

0110 0100 = 1’s complement

______ +1 = 2’s complement

0110 0101 = 0x65

Cyclic Redundancy Check (CRC)

CRC is a more secure error check method than BCC. It provides a very high level of data security. It can 

detect:

• All single-bit and double-bit errors.

• All errors of odd numbers of bits.

• All burst errors of 16 bits or less.

• 99.997% of 17-bit error bursts.

• 99.998% of 18-bit and larger error bursts.

The CRC is calculated using the value of the data bytes and the ETX byte. At the start of each message 

packet, the transmitter must clear a 16-bit CRC register.

When a byte is transmitted, it is exclusive-ORed with the right 8 bits of the CRC register and the result 

is transferred to the right 8 bits of the CRC register. The CRC register is then shifted right 8 times by

inserting 0’s on the left.

Each time a 1 is shifted out on the right, the CRC register is Exclusive-ORed with the constant value 

0xA001. After the ETX value is transmitted, the CRC value is sent, least significant byte (LSB) first. 

Structured English procedure from AB Manual

data_byte = all application layer data, ETX 

CLEAR CRC_REGISTER

FOR each data_byte

GET data_byte

XOR (data_byte, right eight bits of CRC_REGISTER) 

PLACE RESULT in right eight bits of CRC_REGISTER

DO 8 times

Shift bit right, shift in 0 at left 

IF bit shifted =1

XOR (CONSTANT, CRC_REGISTER) 

PLACE RESULT in CRC_REGISTER

END IF

END DO

END FOR

TRANSMIT CRC_REGISTER as 2-byte CRC field

Examples

The host software sends two kinds of commands: block reads and block writes. This section shows 

examples of both commands.

Note: If you read data from a loop set to SKIP, the controller will send an empty packet for that loop.

This section does not show how to calculate the error check value included with every packet. For help 

calculating the error check value, see the section on BCC or CRC.

Block Read

This example shows the block read command the host software sends, the controller’s responses, and the 

software’s acknowledgment.

Situation: Read process variables for loops 1 to 8.

• 8 process variables 2 bytes each = 16 bytes from data table address 0x0280.

Block Write

This section describes the block write command.

This example shows the block write command the master sends, the controller’s responses, and the 

master’s acknowledgment:

Situation: Write setpoint of 100 to loop 6.

• 1 setpoint 2 bytes per setpoint = 2 bytes to address 0x01CA (0x01C0 + xA, a 10-byte offset).

• Character values are represented in hexadecimal.

• The sender is device address 0.

• The destination is device address 8 (controller address 1).

• The software sends transaction number 00.

Message Data

Some messages contain data. What the data is and how much depends on the command used and the 

purpose of the message.

Data for a Read Command

For a block read command, the data block consists of one byte that indicates the number of bytes to read 

(up to 244 bytes of data). The controller sends back a packet with a data block that contains the 

requested bytes.

Data for a Write Command

For a block write command, the block contains the bytes to write (up to 242 bytes of data). The 

controller sends back a message packet without data.

Two-Byte Data Types

For two-byte data types, like process variable and setpoint, the controller or host software sends the data 

in two-byte pairs with the least significant byte first.

Figuring Block Size

To read parameter values, you must know how many bytes to request. Parameter values are stored 

contiguously such that the setpoints for all the loops are stored together and in loop number order. For 

example, to read the deviation alarm deadband value for loops one to five, you would read five bytes 

starting at 0x05A0. Some parameters, such as setpoint, require two bytes of memory to store. So, for 

example, if you want to read the setpoint for four loops, you must read eight bytes.

Calculate total block size in bytes for most loop parameters this way (do not forget the pulse loop):

(Data Size) * (Number of Loops)

Some parameters have values for both heat and cool. Calculate block size for such a parameter this way:

2 * (Data Size) * (Number of Loops)

One exception is the units for each loop. Calculate the data size for the units this way:

3 * (Number of Loops)

Parameters that are not loop parameters (like system status, digital inputs, or digital outputs) have 

specific data sizes. These data sizes are listed in the data table in the next section.

Anafaze/AB Data Table Summary

Each address holds one byte of data. Each parameter value requires one or two addresses to store 

depending on the type of data. The tablebelow indicates the number of bytes for each data type. The 

data type for each parameter is indicated in the tables on the following pages.

Because each loop is individually configurable, the number of instances of many parameters depends on 

the number of loops in the controller. Therefore, the number of bytes for these parameters is listed in the 

tables on the following pages in terms of the number of loops in the controller.

The storage requirements for some parameters depend on the number of digital inputs or digital outputs 

in the controller (MAX_DIGIN_BYTES and MAX_DIGOUT_BYTES). The storage of ramp-soak 

profile parameters depend on the number of profiles (MAX_RSP), the number of segments per profile 

(MAX_SEG), the number of triggers per segment (MAX_TRIG) and the number of events per segment 

(MAX_EVENT).

The table below shows the values for each of these factors. Use them to calculate the number of bytes 

for each parameter.

Ordering of Heat and Cool Channel Parameters

For parameters that have both heat and cool settings the heat values are stored in the first registers and 

the cool values are stored in the registers starting at the listed address plus MAX_CH.

Note: Data table parameters 46 to 60 and 100 are ramp-soak parameters. They are only used in 

controllers with the ramp-soak option. Parameters 81 to 95 are enhanced features and only available in 

controllers with the enhanced features option.

Ordering of Ramp-Soak Profile Parameters

Ramp-soak profile parameters are ordered first by profile, then by segment where applicable. So, for 

example, the first eight bytes of the Ready Events parameter are the ready segment event states for the 

first profile (profile A) and the next eight bytes are for profile B and so on. In the case of the segment 

triggers, the first byte contains the first trigger setting for the first segment of profile A, the second byte 

contains the settings for the second trigger for the first segment of profile A, the third byte contains the 

settings for the first trigger for the second segment of profile A and so on.

Overview

This reference guide is designed to help applications software programmers interface with Watlow®

CLS200 and MLS300 controllers and CAS200 alarm scanners via serial communication.

The following chapters are included in this guide:

• Anafaze/AB Protocol—gives an overview and explanation of the Anafaze/Allen Bradley 

communications protocol

• Modbus®-RTU Protocol—gives an overview and explanation of the Modbus®-RTU 

communications protocol

• Data Table Summary—provides standard controller data table maps for the parameters (one for 

each protocol)

• Parameters Description—describes each parameter

• Glossary—explanations of commonly used terms and acronyms

Chapter 1: Anafaze/AB 

Protocol

This chapter explains the ANAFAZE/Allen Bradley protocol.

Anafaze/AB Protocol Basics

This protocol is used with a serial communications link (EIA/TIA-232 or EIA-TIA-485) configured as 

follows:

• 2400 or 9600 baud 

• 8 data bits

• One or 2 stop bits

• No parity

Protocol Syntax

The controllers use a half-duplex (master-slave) protocol to interface to high-level software. The host 

software is considered the “master” and the controller is considered the “slave.” In other words, the 

software can request information from the controller or download information to the controller. The 

controller can only respond to communications transactions initiated by the host software. The controller 

cannot initiate communications.

Control Codes

The controller and host software communicate by sending and receiving information in a “packet” 

format. A packet consists of a sequence of bytes in a specific format; it can be as large as 256 bytes of 

data. (For more information about packets, see the Packet Format section later in this chapter.)

The numbers in the packet are sent in binary format. However, our examples show bytes in hexadecimal 

forma

Control code abbreviations in this manual

Transaction Sequence

Here are the four steps in a transaction between the host software and the controller. The following 

example shows the transaction as an exchange of packets. The example also assumes that there are no 

communication errors in the exchange.

1. The host software sends a packet that contains a read command or write command.

2. The controller sends a DLE ACK to the host software.

3. The host software receives a reply packet from the controller.

4. The host software sends a DLE ACK.

Transaction flow with no error handling

NOTE Due to the difference between the processing speeds of the controller and PC, it may be 

necessary to delay the computer’s acknowledgement (ACK) in order for the controller to receive it. 

A delay of 200ms should suffice.

The flowchart below shows one way for the host software to handle error checking. If you are writing 

simple software, you don’t necessarily need to use error handling routines as complete as these

Transaction flow with error handling

Packet Format

Messages are transmitted in the form of packets. Command and reply packets specify the source and 

destination addresses, whether to read or write, the block of data to read or write, etc.

A packet contains a sequence of binary bytes formatted this way:

Sending Control Codes

To send a control code, send a DLE before the control code to distinguish it from data.

Sending a DLE as Data

When you send a byte with 0x10, (a DLE), the controller and software interpret it as a command. 

Therefore, to send a DLE as data, send another DLE immediately before it (DLE DLE).

Codes in a Packet

This section describes the sequence of bytes in a packet, in the order the host software or controller 

sends them

DLE STX (byte) signals the beginning of a transmission. Every packet of information starts with the 

control codes DLE STX.

DST (byte) the address of the destination device (usually a controller; the first CLS200 controller is at 

0x08).

NOTE: When host software communicates with a CLS200 controller via the ANAFAZE or AB 

protocol, it does not send the controller’s actual address. Since the protocol reserves device 

addresses 0 to 7, the host software sends the value (controller address + 7), instead of the actual 

device address.

SRC (byte) the device address of the packet’s source. The host software is usually designated address

0x00.

CMD (byte) indicates the command that the host software sends to the controller. The software sends a 

read (0x01) or write (0x08). When the controller replies, it returns the read or write command with the 

7th bit set—in other words, it sends 0x41 or 0x48.

STS (byte) indicates the controller’s general status and error flags to the host software. The controller

ignores the status byte in the host software’s command packet. The table below lists status byte values 

and definitions.

An “n” in the status bytes below indicates that the associated nibble may contain additional information. 

In most cases, the status byte is composed of two independent nibbles. Each nibble is independent so 

that two codes can return at once. For example, status code F1 indicates that data has changed (Fn) and 

the controller is being updated through the front panel (0x1).

TNSL least significant byte of the transaction number. This is the first half of a “message stamp.” The

controller sends back the TNSL and TNSH exactly as it received them, so host software can use the 

TNSL and TNSH bytes to keep track of message packets.

TNSH most significant byte of the transaction number. This is the second half of the “message stamp.

ADDL the low byte of the beginning data table address of the block of data to read or write.

ADDH the high byte of the beginning data table address of the block of data to read or write.

DATA the new values to be set with a write command, or the requested data in a response to a read 

command.

DLE ETX ends every packet of information. Signals the end of a transmission.

BCC or CRC one or two-byte error check at the end of the packet. There are two error check methods: 

Block Check Character (BCC), which requires 1 byte, and Cyclic Redundancy Check (CRC), which 

requires 2 bytes.

Error Checking

The default error check method, BCC is easier to implement than CRC, and is acceptable for most 

applications.

Select one error check method and configure both software and controller for that method, or they will 

be unable to communicate.

The error check methods work this way:

Block Check Character (BCC)

BCC checks the accuracy of each message packet transmission. It provides a medium level of security. 

The BCC is the 2’s complement of the 8-bit sum (modulo-256 arithmetic sum) of the data bytes between 

the DLE STX and the DLE ETX. (1’s complement +1)

• BCC does not detect transposed bytes in a packet.

• BCC cannot detect inserted or deleted 0 values in a packet.

• If you have sent 0x10 as data (by sending DLE 0x10) only one of the DLE data bytes is included in 

the BCC’s sum (the DLE = 0x10 also).

For instance, the block read example shown in the examples section, adds 0x08 00 01 00 00 80 02 10. 

Note that the 0x10 representing DLE has been left out of the calculation. The sum should come to 0x9B.

1001 1011 = 0x9B

0110 0100 = 1’s complement

______ +1 = 2’s complement

0110 0101 = 0x65

Cyclic Redundancy Check (CRC)

CRC is a more secure error check method than BCC. It provides a very high level of data security. It can 

detect:

• All single-bit and double-bit errors.

• All errors of odd numbers of bits.

• All burst errors of 16 bits or less.

• 99.997% of 17-bit error bursts.

• 99.998% of 18-bit and larger error bursts.

The CRC is calculated using the value of the data bytes and the ETX byte. At the start of each message 

packet, the transmitter must clear a 16-bit CRC register.

When a byte is transmitted, it is exclusive-ORed with the right 8 bits of the CRC register and the result 

is transferred to the right 8 bits of the CRC register. The CRC register is then shifted right 8 times by

inserting 0’s on the left.

Each time a 1 is shifted out on the right, the CRC register is Exclusive-ORed with the constant value 

0xA001. After the ETX value is transmitted, the CRC value is sent, least significant byte (LSB) first. 

Structured English procedure from AB Manual

data_byte = all application layer data, ETX 

CLEAR CRC_REGISTER

FOR each data_byte

GET data_byte

XOR (data_byte, right eight bits of CRC_REGISTER) 

PLACE RESULT in right eight bits of CRC_REGISTER

DO 8 times

Shift bit right, shift in 0 at left 

IF bit shifted =1

XOR (CONSTANT, CRC_REGISTER) 

PLACE RESULT in CRC_REGISTER

END IF

END DO

END FOR

TRANSMIT CRC_REGISTER as 2-byte CRC field

Examples

The host software sends two kinds of commands: block reads and block writes. This section shows 

examples of both commands.

Note: If you read data from a loop set to SKIP, the controller will send an empty packet for that loop.

This section does not show how to calculate the error check value included with every packet. For help 

calculating the error check value, see the section on BCC or CRC.

Block Read

This example shows the block read command the host software sends, the controller’s responses, and the 

software’s acknowledgment.

Situation: Read process variables for loops 1 to 8.

• 8 process variables 2 bytes each = 16 bytes from data table address 0x0280.

Block Write

This section describes the block write command.

This example shows the block write command the master sends, the controller’s responses, and the 

master’s acknowledgment:

Situation: Write setpoint of 100 to loop 6.

• 1 setpoint 2 bytes per setpoint = 2 bytes to address 0x01CA (0x01C0 + xA, a 10-byte offset).

• Character values are represented in hexadecimal.

• The sender is device address 0.

• The destination is device address 8 (controller address 1).

• The software sends transaction number 00.

Message Data

Some messages contain data. What the data is and how much depends on the command used and the 

purpose of the message.

Data for a Read Command

For a block read command, the data block consists of one byte that indicates the number of bytes to read 

(up to 244 bytes of data). The controller sends back a packet with a data block that contains the 

requested bytes.

Data for a Write Command

For a block write command, the block contains the bytes to write (up to 242 bytes of data). The 

controller sends back a message packet without data.

Two-Byte Data Types

For two-byte data types, like process variable and setpoint, the controller or host software sends the data 

in two-byte pairs with the least significant byte first.

Figuring Block Size

To read parameter values, you must know how many bytes to request. Parameter values are stored 

contiguously such that the setpoints for all the loops are stored together and in loop number order. For 

example, to read the deviation alarm deadband value for loops one to five, you would read five bytes 

starting at 0x05A0. Some parameters, such as setpoint, require two bytes of memory to store. So, for 

example, if you want to read the setpoint for four loops, you must read eight bytes.

Calculate total block size in bytes for most loop parameters this way (do not forget the pulse loop):

(Data Size) * (Number of Loops)

Some parameters have values for both heat and cool. Calculate block size for such a parameter this way:

2 * (Data Size) * (Number of Loops)

One exception is the units for each loop. Calculate the data size for the units this way:

3 * (Number of Loops)

Parameters that are not loop parameters (like system status, digital inputs, or digital outputs) have 

specific data sizes. These data sizes are listed in the data table in the next section.

Anafaze/AB Data Table Summary

Each address holds one byte of data. Each parameter value requires one or two addresses to store 

depending on the type of data. The tablebelow indicates the number of bytes for each data type. The 

data type for each parameter is indicated in the tables on the following pages.

Because each loop is individually configurable, the number of instances of many parameters depends on 

the number of loops in the controller. Therefore, the number of bytes for these parameters is listed in the 

tables on the following pages in terms of the number of loops in the controller.

The storage requirements for some parameters depend on the number of digital inputs or digital outputs 

in the controller (MAX_DIGIN_BYTES and MAX_DIGOUT_BYTES). The storage of ramp-soak 

profile parameters depend on the number of profiles (MAX_RSP), the number of segments per profile 

(MAX_SEG), the number of triggers per segment (MAX_TRIG) and the number of events per segment 

(MAX_EVENT).

The table below shows the values for each of these factors. Use them to calculate the number of bytes 

for each parameter.

Ordering of Heat and Cool Channel Parameters

For parameters that have both heat and cool settings the heat values are stored in the first registers and 

the cool values are stored in the registers starting at the listed address plus MAX_CH.

Note: Data table parameters 46 to 60 and 100 are ramp-soak parameters. They are only used in 

controllers with the ramp-soak option. Parameters 81 to 95 are enhanced features and only available in 

controllers with the enhanced features option.

Ordering of Ramp-Soak Profile Parameters

Ramp-soak profile parameters are ordered first by profile, then by segment where applicable. So, for 

example, the first eight bytes of the Ready Events parameter are the ready segment event states for the 

first profile (profile A) and the next eight bytes are for profile B and so on. In the case of the segment 

triggers, the first byte contains the first trigger setting for the first segment of profile A, the second byte 

contains the settings for the second trigger for the first segment of profile A, the third byte contains the 

settings for the first trigger for the second segment of profile A and so on.