Using the Ethernet Communication Network

Communication Parameters

Before network port communication can begin, configure the following Ethernet communication services and settings:

• Primary IP address setting

• Frame type setting

• Stored IP addressing settings

• Network port endian setting

• Fast device replacement (FDR) service

• Network Protocol selection

• Rapid Spanning Tree Protocol (RSTP)

• SNMP service

• Communication loss settings

• Configuration control

• IP Allowlist

Primary IP Address Setting

Configure the Ethernet Primary IP Address Setting parameter to add the IP address of the client device dedicated to remotely control the motor. This parameter consists of four integer values, from 0-255, separated by dots (xxx.xxx.xxx.xxx).

Frame Type Setting

Configure the Network Port Frame Type Setting parameter by selecting an Ethernet frame type:

• Ethernet II (Factory setting)

• 802.3 (recommended)

IP Addressing Settings

Unique IP address settings must be assigned to the LTMR controller (including an IP address, a subnet mask, and a gateway address) to be able to communicate over an Ethernet network. The positions of the controller’s two rotary switches determine the source of the controller’s IP address settings, which can be:

• A DHCP server

• A BootP server

• Stored IP address settings

If the controller’s Ones rotary switch is set to Stored IP, the controller will apply its stored IP address settings.

To input the LTMR controller’s stored IP address settings, configure the following parameters:

• Ethernet IP Address Setting

• Ethernet Subnet Mask Setting

• Ethernet Gateway Address Setting

Each of these parameters consists of four integer values, from 0-255, separated by dots (xxx.xxx.xxx.xxx).

Network Port Endian Setting

The Network port endian setting allows to swap the two words in a double word.

• 0 = least significant word first (little endian)

• 1 = most significant word first (big endian, factory setting)

Fast Device Replacement Service

The Fast Device Replacement (FDR) Fast Device Replacement service stores the LTMR controller’s operating parameters on a remote server and, if the controller is replaced, sends the replacement controller a copy of the original device’s operating parameters.

To enable the automatic backup of the controller’s operating parameters to the FDR server, configure the following parameters:

• Network Port FDR Auto Backup Enable parameter. It can be set to:

  • No auto backup

  • Automatic backup (copies the parameters from the controller to the FDR server)

• Network Port FDR Controller Interval parameter: the time (in seconds) between automatic backup transmissions.

  • Range = 30...3600 s

  • Increments = 10 s

  • Factory setting = 120 s

Network Protocol Setting

Select with this parameter the network protocol you want to use:

• Modbus/TCP

• EtherNet/IP

Rapid Spanning Tree Protocol

The Rapid Spanning Tree Protocol (RSTP) service manages the state on every port of each device in the local area network (LAN) loop. The RSTP loop configured with 16 LTMR controllers and two RSTP-enabled switches typically perform to resolve a communication loss at the LTMR controller is 100 ms...200 ms. Reconnection performances vary depending on PLC, services used, and IP address mode.

To configure the Rapid Spanning Tree Protocol (RSTP) service, set the following parameters:

• RSTP Enable: to enable/disable the RSTP feature. Values include:

  • 0 = Disable (factory setting)

  • 1 = Enable

• RSTP Bridge Priority: determines which bridge is elected as the root bridge. If the switch has a bridge priority that is lower than all the other switches, the other switches automatically select the switch as the root switch.

  • Range = 0x0000 (highest priority)...0xF000 (lowest priority)

  • Increments = 0x1000

  • Factory setting = 0x8000

• RSTP Hello Time: the time between each bridge protocol data unit (BPDU) that is sent on a port.

  • Range = 1...10 s

  • Increments = 1 s

  • Factory setting = 2 s

• RSTP Max Age Time: the max age timer controls the maximum length of time that passes before a bridge port saves its configuration BPDU information.

  • Range = 6...40 s

  • Increments = 1 s

  • Factory setting = 36 s

• RSTP Max Transmit Count: the number of BPDUs that can be transmitted within the hello time interval to avoid flooding the network.

  • Range = 3...100

  • Increments = 1

  • Factory setting = 6

• RSTP Forward Delay: the time that is spent in the listening and learning state to avoid unstable topology changes.

  • Range = 4...30 s

  • Increments = 1 s

  • Factory setting = 20 s

• RSTP Port Count: number of RSTP ports. Constant value of 2. Values include:

  • Factory setting = 2

• RSTP Port [1 or 2] Priority: Used to determine highest priority port in a multi-port device.

  • Range = 0...240

  • Increments = 16

  • Factory setting = 128

• RSTP Port [1 or 2] Path Cost: the path cost of this device used by each network device to calculate topology based on minimizing total path cost. Values include:

  • 200,000 = 100 Mbit/s (factory setting)

  • 2,000,000 = 10 Mbit/s

• RSTP Port [1 or 2] Disable: to enable/disable RSTP feature on each port individually. Values include:

  • 0x0001 = disabled

  • 0x0100 = enabled (factory setting)

On every network topology change, RSTP recalculates the optimum network path. It is recommended that network configuration does not change again during an RSTP operation. Following actions must be avoided on an operating network or network performance can be temporarily impacted:

• A network cable plug-out /plug-in or device power OFF/ON in less than 2 s

• In a daisy chain loop, remove/add two nodes in less than 30 s

Each device in an RSTP loop must have RSTP enabled for the feature to perform correctly. When RSTP is enabled, at least one port must be connected to another RSTP port to start any further Ethernet service.

Each RSTP device is setup with Configured Parameters to initiate calculation of the best BPDU (Bridge Protocol Data Unit) which will then be used by the full RSTP network as their Learned Parameters.

Network Port Comm Loss Settings

Configure the following parameters to determine how the LTMR controller will handle communication loss with the PLC:

• Ethernet Primary IP address setting: declares which PLC will be the Primary for Network Port Comm loss strategy. For more information, refer to the explanation of the Primary IP

• Network Port Comm Loss Timeout: the length of time communication with the PLC defined as Primary IP must be lost before the controller will signal a Communication Loss trip or alarm as well as activate Fallback strategy.

  • Range = 0...9999 s

  • Increments = 0.01 s

  • Factory setting = 2 s

• Network Port Fallback Action Setting: determines, with the controller’s operating mode, the behavior of logic outputs 1 and 2 when communication with the PLC that is declared as Primary IP is lost. For more information, refer to the explanation of the Primary IP. Values include:

  • Hold

  • Run

  • O.1, O.2 OFF

  • O.1, O.2 ON

  • O.1 ON

  • O.2 ON

  The factory setting is O.1, O.2 OFF.

• Network Port Trip Enable: signals a network communication interruption trip after the Network Port Comm Loss Timeout setting has expired.

  The factory setting is disable.

• Network Port Alarm Enable: signals a network alarm after the Network Port Comm Loss Timeout setting has expired.

  The factory setting is disable.

IP Allowlist

The IP Allowlist feature enables you to configure an Access Control List (ACL) of IP addresses that are allowed to communicate with the LTMR. When enabled, device addresses that are not inside the Allowlist will be blocked from communicating with the LTMR using Modbus/TCP, EtherNet/IP, or FTP. There are five configurable IP Allowlist ranges. If configured, the Primary IP address is automatically included as an additional entry in the Allowlist. Configure with the following settings:

• IP Allowlist Enable setting: Enables or disables the IP Allowlist feature. Disable by default.

  NOTE: At least one address has to be configured among the Primary IP or Allowlist ranges to be enabled.

• IP Allowlist Range [N=1-5] Address setting: Host identifier address used in conjunction with the subnet mask. Must be within the device operating subnet. Valid values 0.0.0.0 through 255.255.255.255. Default value 0.0.0.0.

• IP Allowlist Range [N=1-5] Subnet Mask setting: Bitmask with most significant values contiguously set to 1, the least significant bits set to 0 define the size of the available address range. Valid values 255.255.255.0 (subnet size = 256) through 255.255.255.255 (subnet size = 1). Default value 255.255.255.0.

  Subnet Mask	Addresses in Subnet
  255.255.255.255	1
  255.255.255.254	2
  255.255.255.252	4
  255.255.255.248	8
  255.255.255.240	16
  255.255.255.224	32
  255.255.255.192	64
  255.255.255.128	128
  255.255.255.0 (default)	256

Overview

The LTMR controller can receive or provide Ethernet services only if an Ethernet communications link exists. An Ethernet communications link can exist only when a cable connects one of the controller’s network ports to the network. If no network cable connection exists, no Ethernet service can start.

The behavior of the controller is described in each of the following situations:

• The LTMR powers up with no Ethernet communications link.

• An Ethernet Communications Link is connected to a previously unconnected controller after startup.

• All Ethernet Communication Links disconnected from the controller after startup.

• One (or more) Ethernet Communication Links are re-established to a controller after all Ethernet Communication Links had previously been disconnected.

No Ethernet Communications Link while LTMR is Powered Up

When the LTMR powers up with no network cable connected, the LTMR

• Signals an FDR trip if the rotary switches are in DHCP position,

• Signals an FDR trip for 10 s and then clears the trip automatically if the rotary switches are in Stored, BootP, ClearIP, or Disabled positions.

No Ethernet Communications Link at Startup

When, after controller startup, an Ethernet network cable is initially attached to a previously unconnected controller

• The controller starts its IP addressing service, which

  • Obtains IP address settings,

  • Validates IP address settings,

  • Checks that the obtained IP address settings are not duplicate,

  • Assigns the received IP address settings to the controller.

• After its IP address settings are assigned, the controller

  • Starts the FDR service and obtains its operating parameter settings, then

  • Starts its Modbus service.

The time to recover the link and start Ethernet services takes about 1 second.

Ethernet Communications Link Disconnected After Startup

When all Ethernet Communication Links are disconnected from the controller after startup:

• The IP addressing service is disabled and a Network Port Configuration Alarm (alarm code 555) is generated,

• All Modbus service connections are reset,

• If a Primary IP connection exists and:

  • The link cannot be re-established before the Network Port Comm Loss Timeout expires, the controller enters its pre-configured fallback state if the LTMR is in Network control,

  • The link is re-established before the Network Port Comm Loss Timeout expires, the connection to the Primary IP is maintained, and the controller does not enter its fallback state.

Link Reconnected After Disconnection

When one or more Ethernet Communication Links are re-established to the controller, after all Ethernet Communication Links had been disconnected after startup, the controller performs many, but not all, of the same tasks as when there is no Ethernet Communication Link at Startup No Ethernet Communications Link at Startup. Specifically, the controller

• Presumes the previously obtained IP address settings remain valid, then

  • Checks that the IP address settings are not duplicate,

  • Re-assigns the IP address settings to the controller.

• After the IP address settings are assigned, the controller

  • Starts its FDR service and obtains its operating parameter settings, then

  • Starts its Modbus service.

The time to recover the link and start Ethernet services takes about 1 second.

Overview

Each LTMR controller, in its role as communication server, could be configured to recognize another Ethernet device (typically a PLC) as the client device that controls the motor. This device is usually a device that initiates communication to exchange Process Data (control and status). The Primary IP is the IP address of this device.

The PLC should continuously maintain at least one connection, called a virtual connection or socket, with the communication server.

If the virtual connection between the Primary IP device and the LTMR server is interrupted, the LTMR controller waits a prescribed time, the Network Port Comm Loss Timeout, for a new connection to be established and application level messages sent between the Primary IP device and the LTMR controller.

If a connection is not reopened and messages are not received from the Primary IP before the timeout expires, the LTMR controller enters its fallback state, set by the Network Port Fallback Setting.

If application level communication is never established with the Primary IP, then the Comm Loss Timeout timer is never started; As a result Comm Loss Event and Fallback states can never be reached.

WARNING
LOSS OF CONTROL Configure a server IP on the Ethernet network. Do not use an IP address other than Primary IP to send network start and stop commands to the LTMR controller. Design the Ethernet network to block unauthorized network start and stop commands sent to the LTMR controller. Failure to follow these instructions can result in death, serious injury, or equipment damage.

Prioritized Primary IP Connections with Modbus/TCP

Connections between the LTMR controller and the Modbus client has a priority over connections between the controller and other Ethernet devices.

After the controller has reached its maximum number of eight simultaneous Modbus connections, the controller must close an existing connection to be able to open a new connection. If an additional connection is requested after the maximum number has been established, then the LTMR controller will close the connection whose most recent transaction is the oldest (least fresh) in order to establish the new connection.

All connections (up to eight) between the LTMR controller and the Primary IP client are preserved once communication has been established between them. The controller will not close a connection with the Primary IP address in order to open a new connection from a non-Primary IP address.

Configuring Primary IP

To enable connections to be made to a Modbus client, use a configuration tool to configure the following parameters:

Overview

The LTMR controller must obtain a unique IP address, subnet mask, and gateway address to communicate over an Ethernet network. The settings of the two rotary switches on the front of the LTMR controller determine the source of these required settings. These settings are applied only on power-up. The rotary switches look like this:

The settings of the rotary switches determine the source of the LTMR controller’s IP address parameters and the FDR service activation, as follows:

IP settings are assigned to the following parameters:

• Ethernet IP Address

• Ethernet subnet Mask

• Ethernet Gateway

Getting IP Parameters from a DHCP Server

To obtain IP parameters from a DHCP server, point each rotary switch to a numerical setting, as follows:

Device Name: The settings of the two rotary switches are used to determine each LTMR controller’s device name. The device name consists of a fixed part ("TeSysT") and a dynamic part, composed of:

The two-digit value (00-15) of the Tens rotary switch (xx)

The one-digit value (0-9) of the Ones rotary switch (y)

The DCHP server must be pre-configured with the LTMR controller’s device name and its associated IP parameters. When the DHCP server receives the LTMR controller’s broadcast request, it returns:

• The LTMR controller’s:

  • IP address

  • Subnet mask

  • Gateway address

• The DHCP server’s IP address

In the figure, above, the device name is: TeSysT084.

Getting IP Parameters from a BootP Server

To obtain IP parameters from a BootP server, point the right (Ones) rotary switch to either of the two BootP settings. (The left (Tens) rotary switch is not used.) The LTMR controller broadcasts a request for IP parameters to a BootP server, and includes its MAC address in the request.

The BootP server must be pre-configured with the LTMR controller’s MAC address and associated IP parameters. When the BootP server receives the LTMR controller’s broadcast request, it returns to the LTMR controller it's:

• IP address

• Subnet mask

• Gateway address

Using Stored IP Parameters

You can configure the LTMR controller to apply IP settings that have been previously configured and stored in the device itself. These stored IP parameters can be configured using your choice of configuration tool.

To apply stored IP parameters set the right (Ones) rotary switch to either of the two Stored positions. (The left (Tens) rotary switch is not used.)

The LTMR controller uses as its:

• IP address: the Ethernet IP Address Setting parameter

• Subnet mask: the Ethernet Subnet Mask Setting parameters

• Gateway address: the Ethernet Gateway Address Setting parameter

Configuring Default IP Parameters from the MAC Address

The LTMR controller derives its default IP parameters from its MAC address (stored in the device’s Ethernet MAC Address parameter). The MAC address is a unique identifier associated with the device’s network interface card (NIC).

As a prerequisite for using the default IP address, all bytes of the configured IP address must be set to zero.

To apply the LTMR controller’s default IP parameters, you must proceed in two steps:

The default IP parameters are generated as follows:

• The first two byte values of the IP address are always 85.16

• The last two byte values of the IP address are derived from the last two bytes of the MAC address

• The default subnet masks are always 255.0.0.0

• The default gateway is the same as the device’s default IP address

For example, for a device with a hexadecimal MAC address of 0x000054EF1001, the last two bytes are 0x10 and 0x01. These hexadecimal values translate to decimal values of 16 and 01. The default IP parameters for this MAC address are:

• IP address: 85.16.16.01

• Subnet mask: 255.0.0.0

• Gateway address: 85.16.16.01

IP Assignment Process

As depicted in the following graphic, the LTMR controller performs a sequence of inquiries to determine its IP address:

The following diagram depicts the assign default IP address process, referenced above:

IP Assignment and STS/NS LED

During the IP address assignment process while the LTMR is operating normally, is not in a trip state, and has not detected an alarm, the green STS/NS LED may indicate the following conditions:

Overview

The FDR service employs a central server to store both the IP addressing parameters and the operating parameters for an LTMR controller. When a LTMR controller is replaced, the server automatically configures the replacement LTMR controller with the same IP addressing and operating parameters as the replaced controller.

The FDR service includes configurable commands and settings that you can access using your choice of configuration tool. These commands and settings include:

• Commands that let you manually:

  • Backup the LTMR controller’s operating parameters, by uploading a copy of the device’s parameter file to the server from the controller, or

  • Restore the LTMR controller’s parameters, by downloading a copy of the device’s operating parameter file from the server to the controller.

• Settings that cause the FDR server to automatically synchronize the operating parameter files, in both the LTMR controller and the server, at configurable time intervals. If a difference is detected, a parameter file is sent from the controller to the FDR server (auto backup).

FDR Compatibility

TeSys T

FDR Server

The table below describes the compatibility of firmware versions between the data stored on an FDR server (PLC) and the new FDR client (TeSys T). Firmware 2.9 and above manages compatibility with previous versions of stored FDR files. Firmware 2.8 and below does not manage compatibility, so the firmware and hardware versions must match as illustrated in the following table:

		FDR Client (TeSys T)
		FW 2.6 and below	FW 2.7 and 2.8	FW 2.9+
FDR Server (Stored File)	FW 2.6 and below
	FW 2.7 and 2.8		The replacement TeSys T must have the same hardware generation (MBTCP or MBTCP+EIP) Hardware Generations.*
	FW 2.9+

Preconditions to FDR

Before the FDR services can function, the FDR server must be configured with:

• The LTMR controller’s network address and related IP addressing parameters, this is done as part of the IP addressing service,

• A copy of the LTMR controller’s operating parameter file, this can be sent from the controller to the server either manually or automatically, as described below. This will be a zero size file when unconfigured.

FDR and Custom Logic File

The FDR service stores custom logic to the operating parameters file if the custom logic file size is less than 3 kB (1.5 k Tokens as compiled in SoMove).

If the custom logic file size is more than 3 kB (1.5 k Tokens as compiled in SoMove), only the operating parameters are saved.

In this case, when you are replacing a device with a custom logic file size bigger than 3 kB (1.5 k Tokens as compiled in SoMove), the STS/NS LED of the new device flashes eight times signaling the detection of an system recoverable FDR trip condition.

To clear the trip and resume operations:

FDR Process

The FDR process consists of three parts:

• The assignment of IP address settings,

• A check of the operating parameter file at every LTMR controller startup,

• If auto synchronization is enabled, periodic checks of the LTMR controller’s operating parameter file from the FDR server.

These three processes are described below:

FDR startup process:

FDR Auto Backup process:

The following diagrams describe the controller’s FDR processes after the assignment of an IP address (see IP Assignment Process):

FDR Auto Restore Diagram

FDR Auto Backup Diagram

Configuring FDR

The FDR service monitors the operating parameter file maintained in your LTMR controller and compares it against the corresponding operating parameter file stored in the server.

When the FDR service detects a discrepancy between these two files:

• The Network Port FDR Status parameter is set, and

• The two operating parameter files, one in the server, the other in the controller, must be synchronized.

Synchronizing operating parameter files can be performed either automatically or manually, using your choice of configuration tool.

Automatically Backup Settings: By setting the following parameters, you can configure your LTMR controller to automatically synchronize its operating parameters with the FDR server:

Manually Backup and Restore Settings: By executing the commands described below, you can manually synchronize the operating parameter files in the controller and server:

FDR Trip Recovery

When the LTMR controller detects a trip condition that requires intervention during the FDR startup process, the STS/NS LED flashes as follows:

System recoverable trips:

Operations can resume after fixing the cause of the trip outside of the LTMR. System recoverable trips include:

• No response from IP server (Network Port FDR Status = 1).

• The parameter file server, or TFTP service, is unavailable (Network Port FDR Status = 2)

• No file on the parameter server (Network Port FDR Status = 3)

LTMR recoverable trips:

When the parameter file in the server is invalid or corrupt, the trip requires manual intervention to be cleared. Operations can resume only after a new parameter file is manually copied from the controller to the server using the FDR Data Backup Command and power is cycled to the controller. LTMR recoverable trips include:

• Version mismatch of the parameter file on the parameter server and the LTMR controller (Network Port FDR Status = 13)

• CRC mismatch between parameter file on the server and the LTMR controller (Network Port FDR Status = 9)

• Content of the parameter file is invalid (Network Port FDR Status = 4)

Incompatible FDR File on Server

FDR Status

The Network Port FDR Status parameter describes the state of the FDR service, as described below.

FDR Status:

FDR Restore Status

The FDR Restore Status parameter describes the state of the most recent FDR Restore process as described below:

Overview

Discovery is an automated method to identify and connect to a device with an unknown IP address, using a direct PC connection and a webpage access interface.

Discovery is only available on Microsoft Windows Vista, 7, 8, and 10 operating systems.

Overview

The LTMR controller reports diagnostic data describing its Ethernet network communications interface, including:

• Data parameters that describe the controller’s:

  • IP addressing settings

  • IP address assignment processes

  • Virtual connections

  • Communication history

  • Communication services and their status

• One parameter that describes the validity of the data in each data parameter

Ethernet Basic Diag Validity

The Ethernet Basic Diag Validity parameter evaluates and reports the validity of Ethernet network diagnostic data. A bit in this parameter represents the state of an associated Ethernet network data parameter.

The Ethernet Basic Diag Validity parameter is 32 bits long.

The bits of this parameter represent the validity of the following Ethernet data parameters:

Ethernet Global Status

The Ethernet Global Status parameter indicates the status of the following services provided by the LTMR controller:

• Fast device replacement (FDR)

• SNMP network management

• Modbus port 502 messaging (Modbus/TCP only)

This parameter is 2 bits long.

Ethernet Global Status is cleared on power cycle and controller reset.

Ethernet Services Validity

The Ethernet Services Validity parameter indicates whether the LTMR controller supports the port 502 messaging service.

The Ethernet Supported Services parameter is 1 bit long.

Ethernet Services Status

The Ethernet Services Status parameter indicates the status of the Ethernet Supported Services parameter, that is, the status of the controller’s port 502 messaging service.

This parameter is 3 bits long.

Ethernet Services Status is cleared on power cycle and controller reset.

Ethernet IP Address

The Ethernet IP Address parameter describes the IP address that has been assigned to the LTMR controller by the IP address assignment process.

The Ethernet IP Address consists of 4 byte values, in dot-decimal notation. Each byte value is an integer from 000-255.

Ethernet Subnet Mask

The Ethernet Subnet Mask parameter is applied to the Ethernet IP Address value to define the host address of the LTMR controller.

The Ethernet Subnet Mask consists of 4 byte values, in dot-decimal notation. Each byte value is an integer from 000-255.

Ethernet Gateway Address

The Ethernet Gateway Address parameter describes the address of the default gateway, that is, the node that serves as an access point to other networks for communications from or to the LTMR controller.

The Ethernet Gateway Address consists of 4 byte values, in dot-decimal notation. Each byte value is an integer from 000-255.

Ethernet MAC Address

The Ethernet MAC Address parameter describes the media access control (MAC) address, or hardware identifier, uniquely assigned to an LTMR controller.

The Ethernet MAC Address consists of six hexadecimal byte values, from 0x00-0xFF.

Ethernet II Framing

The Ethernet II Framing parameter describes the Ethernet frame formats supported by the LTMR controller, including:

• Capability: can the device support a frame format?

• Configuration: is the device configured to support a frame format?

• Operational: is the configured frame format operating successfully?

This parameter is three words long.

Ethernet II framing data is stored as follows:

Ethernet Received Correct Frames Counter

The Ethernet Received Correct Frames Counter parameter contains a count of the total number of Ethernet frames that have been successfully received by the LTMR controller.

This parameter is an UDInt parameter. It is cleared on power cycle and controller reset.

The Ethernet Received Correct Frames Counter consists of four hexadecimal values, from 0x00-0xFF.

Ethernet Transmitted Correct Frames Counter

The Ethernet Transmitted Correct Frames Counter parameter contains a count of the total number of Ethernet frames that have been successfully transmitted by the LTMR controller.

This parameter is an UDInt parameter. It is cleared on power cycle and controller reset.

The Ethernet Transmitted Correct Frames Counter consists of four hexadecimal values, from 0x00-0xFF.

Ethernet Opened Clients Counter

The Ethernet Opened Clients Counter parameter contains a count of the number of open TCP client connections. It applies only to devices with TCP clients.

This parameter is an UInt parameter. It is cleared on power cycle and controller reset.

The Ethernet Opened Clients Counter consists of two hexadecimal values, from 0x00-0xFF.

Ethernet Opened Servers Counter

The Ethernet Opened Servers Counter parameter contains a count of the number of open TCP server connections. It applies only to devices with TCP servers.

This parameter is an UInt parameter. It is cleared on power cycle and controller reset.

The Ethernet Opened Servers Counter consists of two hexadecimal values, from 0x00-0xFF.

Ethernet MB Detected Error Messages Sent Counter

The Ethernet MB Detected Error Messages Sent Counter parameter contains a count of the number of:

• EtherNet/IP or Modbus/TCP request packets with detected errors in the header that have been received by this LTMR controller (does not count detected errors in the data portion of EtherNet/IP or Modbus/TCP request packets)

• EtherNet/IP or Modbus/TCP exceptions due to incorrect combination of physical port and Unit ID Modbus Requests

This parameter is an UDInt parameter. It is cleared on power cycle and controller reset.

Ethernet MB Messages Sent Counter

The Ethernet MB Messages Sent Counter parameter contains the total number of Modbus messages, excluding Modbus error messages, that have been sent by this LTMR controller.

This parameter is an UDInt parameter. It is cleared on power cycle and controller reset.

Ethernet MB Messages Received Counter

The Ethernet MB Messages Received Counter parameter contains the total number of Modbus messages that have been received by this LTMR controller.

This parameter is an UDInt parameter. It is cleared on power cycle and controller reset.

Ethernet Device Name

The Ethernet Device Name parameter contains the 16 character string used to identify the LTMR controller.

This parameter is 16 bytes long.

Ethernet IP Assignment Capability

The Ethernet IP Assignment Capability parameter describes the available IP addressing sources for the LTMR controller. Up to four different IP addressing sources can be described.

This parameter is 4 bits long.

The Ethernet IP Assignment Capability parameter stores data as follows:

Ethernet IP Assignment Operational

The Ethernet IP Assignment Operational parameter describes how the current IP address was assigned to the LTMR controller. Only 1 (of 4) different IP address sources can be operational at any one time.

This parameter is 4 bits long.

The Ethernet IP Assignment Operational parameter stores data as follows:

Overview

The Modbus/TCP protocol is a client/server protocol:

1 Client (PLC, PC, or communication module)

2 Straight or crossed category 5 shielded/unshielded twisted-pair Ethernet cable with RJ45 connector

Only one device can transmit in one direction over a segment at any time.

The client manages and initiates the exchange. It interrogates each of the servers in succession. No server can send a message unless it is invited to do so.

The client repeats the question when there is an incorrect exchange, and declares the interrogated server absent if no response is received within a given time period.

If a server does not understand a message, it does nothing. It sends an exception response to the client when a message is understood but contains errors, or when the server is not able to handle the request (for example, due to resource problems). The client may or may not retransmit the request.

Modbus/TCP Dialog

Modbus/TCP supports only unicast dialogs, comprising requests made by a client to a server and the server’s response.

Direct server-to-server communications are not possible. For server-to-server communication, the client must therefore interrogate a server and send back data received to the other server.

Modbus/TCP Messaging

Modbus/TCP is the Modbus protocol encapsulated in TCP. The Modbus/TCP communications protocol combines the:

• Modbus application layer protocol (layer 7 of OSI model), which provides the messaging structure for organizing and interpreting data, and

• TCP transport layer protocol (layer 4 of the TCP/IP stack), which provides a transmission medium for communications between devices on an Ethernet network

The TCP frame, with embedded Modbus data, is sent via TCP to system port 502, which is exclusively reserved for Modbus applications, and added to a TCP/IP Ethernet data packet for network transmission.

Virtual Connections

Although there can be either one or two physical connections between a client and a server-depending upon the network topology Modbus/TCP supports the use of multiple virtual connections.

A virtual connection - or socket - combines:

• The client IP address (for example, the Modbus/TCP client)

• A unique port on the server

• The server IP address (the LTMR controller server)

• A unique port on the client

• The TCP protocol

Multiple virtual connections enable multiple simultaneous - instead of serial - transactions between the client and the server.

Modbus/TCP supports several types of simultaneous client/server transactions, as follows:

Modbus Requests

All physical communication ports–the LTME/HMI port and the two Ethernet network ports are available for Modbus messaging:

• Modbus/TCP using the network ports

• Modbus RTU using the LTME/HMI port

The LTMR controller supports the following Modbus requests, which can be performed using the physical ports and Unit ID/Slave address combinations described below:

The maximum number of registers per request is limited to 100.

WARNING

UNINTENDED EQUIPMENT OPERATION Use of this device on a Modbus network that uses the broadcast function should be considered with caution. This device has a large number of registers that must not be modified during normal operation. Unintended writing of these registers by the broadcast function may cause unexpected and unwanted product operation. For more information, refer to the list Communication Variables. Failure to follow these instructions can result in death, serious injury, or equipment damage.

Overview

The LTMR controller generally follows the Modbus requirements for the Exception Management.

Three special cases apply to the LTMR controller:

• Bit-Field Registers

• Exception Code 02 - Illegal Data Address

• Exception Code 03 - Illegal Data Value

Bit-Field Registers

Some registers in the Register Map are Bit field. Based on the LTMR controller state, some bits in those registers shall not be writable. In this case, the LTMR controller shall reject the write to those bits meaning that no exception shall be returned. For example, bits that can be written only in configuration mode will be ignored (no exception returned) if the LTMR controller is out of the configuration mode. The write to the bits not constrained by the LTMR controller state shall however occur.

Exception Code 02 - Illegal Data Address

In general, the LTMR controller shall return an illegal data address exception code if the address is out of range or inaccessible. Specifically, the LTMR controller shall return an illegal data address if:

• A Write request is sent to a Read only register.

• The permission to write a register is not granted because of the LTMR controller state: this is the case, for example, when a register that can be written only in configuration mode is written while the LTMR controller is out of configuration mode.

Exception Code 03 - Illegal Data Value

In general, the LTMR controller shall return an illegal data value exception code if there is a problem with the structure of the message, such as an invalid length. The LTMR controller shall also use this exception code if:

• The data to be written is out of range (for standard and Bit field registers): this is the case if a write request of 100 is sent to a R/W register with a range of 0-50.

• A reserved bit or register is written to a value different than 0.

• Motor low speed command (bit 704.6) is set while the motor controller mode selected is not a two-speed mode of operation.

Mirroring High Priority Registers

The LTMR controller provides a block of nine contiguous registers dedicated to scanning that mirror the values and functionality of selected high priority registers.

The LTMR controller reads the values of all high priority registers whenever it detects a change to any single high priority register, and writes the values of all high priority registers to the mirroring registers.

Because the mirroring registers are contiguous, it is possible to execute a single Modbus block read or block write request to these registers, thereby saving the time it would take to make separate Modbus read/write requests directly to each underlying high priority register.

Mirroring Status

Mirroring status is the first register, in the sequence of eight contiguous mirroring registers. Bits 0-2 of this register describe the status of read-only commands, and bits 8-10 describe the status of read/write commands.

Configuring I/O Scanning

Your success in configuring I/O scanning of registers depends upon:

• The register type

• The I/O scanning period

• The I/O scanning health timeout period

Total number of registers accessed (read and write) in I/O scan (counting the repeated registers also) shall not exceed 500 registers per second. This limit shall be calculated with all the combinations of request and also take into account multiple connections. If there are multiple connections to the LTMR Controller, the I/O scanning and I/O scanning health timeout settings for read and write transactions for registers are reduced. Any settings for I/O scan period or I/O scan health timeout, lower than described below, can cause the LTMR controller to send Modbus exception packets.

For higher performance, it is recommended to use the mirror registers when possible. Using the mirror registers decreases the load on LTMR controller as the registers are managed more efficiently in the mirror registers. For example:

• Instead of register 457 use mirroring register 2504

• Instead of register 704 use mirroring register 2507

I/O scanning is to be used for fast monitoring and control. Setting parameters and diagnostics should be done by acyclic requests. Keep in mind that cyclic writing to registers will overwrite values or commands that are sent via acyclic messages. For example, setting register 705 to zero via cyclic messaging will cancel out an acyclic FDR Backup Command before it is acted upon.

The following table describes the I/O scanning and I/O scanning health timeout settings for read and write transactions for registers of varying types with only one connection on the LTMR controller:

Example for a Valid I/O Scanning Configuration

Example 1: For a large site with 150 LTMR controllers and PLC connections at 3,400 words: Per LTMR: 10 read and 3 write, 200 register per second.

Example 2: For a small site with less than 50 LTMR controllers and PLC connection at 3,400 words: Per LTMR: 30 read and 3 write, 300 register per second.

Overview

EtherNet/IP is an application layer protocol treating devices on the network as a series of objects. It is an implementation of the Common Industrial Protocol (CIP) over TCP/IP.

The network carries control data and the properties of the device being controlled. It enables you to operate either in a client/server mode or a peer-to-peer mode.

Two main types of messages can be exchanged:

• I/O messaging, dedicated to fast exchanges of process data. Also called Class 1 Messaging or Implicit Messaging.

• Explicit messaging, dedicated to slower exchanges such as configuration, settings, or diagnostics data. Also called Class 3 Messaging.

I/O Messaging

I/O messages contain application-specific data. They are communicated across single or multicast connections between an application producer and its corresponding consuming application. Because I/O messages can carry time-critical messages, they have high-priority identifiers.

An I/O Message consists of a Connection ID and associated I/O data. The meaning of the data within an I/O Message is implied by the associated Connection ID. The connection endpoints are assumed to have knowledge of the intended use or meaning of the I/O Message.

Connection ID

Connection ID is the identifier assigned to a transmission that is associated with a particular connection between producers and consumers that identifies a specific piece of an application information.

I/O Message Types

EtherNet/IP devices are configured to produce a cyclic I/O message.

They produce their data at a precisely defined interval. This type of I/O messaging enables to configure the system to produce data at a rate appropriate for the application. Depending on the application, this can reduce the amount of traffic on the wire and more efficiently use the available bandwidth.

The following connections are defined:

For a full description of these defined Assembly Objects, see the Assembly Object section

Explicit Messaging

Explicit messaging connections provide multipurpose point-to-point communication paths between two particular devices. Explicit messages are used to command the performance of a particular task and to report the results of performing the task. You can, therefore, use explicit messaging connections to configure nodes and diagnose problems.

RPI Parameter

The Request Packet Interval (RPI) parameter defines the rate at which a remote device periodically sends its data.

In daisy chain, adapt RPI value according to number of information exchanged per device and number of devices connected:

• With five devices connected, the RPI value is 30 ms for five devices in Basic Overload profile selected (value is calculated with M340 and NOC card (BMX NOC0401)).

• With 16 devices connected, the RPI value is 80 ms for 16 devices in Basic Overload profile selected (value is calculated with M340 and NOC card (BMX NOC0401)).

Device Profiles

EtherNet/IP’s device models define the physical connections and promote interoperability among standard devices.

Devices that implement the same device model must support common identity and communications status data. Device-specific data is contained in device profiles that are defined for various device types. Typically, a device profile defines the device’s:

• Object model

• I/O data format

• Configurable parameters

The above information is made available to other vendors through the device’s EDS (electronic data sheet).

For a full description of the objects in the LTMR device profile, refer to LTMR Object Dictionary.

What is an EDS?

The EDS is a standardized ASCII file that contains information about a network device’s communications functionalities and the contents of its object dictionary, as defined by ODVA (Open EtherNet/IP Vendor Association). The EDS also defines device-specific and manufacturer-specific objects.

Using the EDS, you can use standardized tools to:

• Configure EtherNet/IP devices

• Design networks for EtherNet/IP devices

• Manage project information on different platforms

The parameters of a particular device depend on those objects (parameter, application, communications, and other objects) that reside on the device.

LTMR Controller EDS Files

EDS files and associated icons that describe the various configurations of the LTMR controller can be downloaded from www.se.com website (Products and Services > Automation and Control > Product offers > Motor Control > TeSys T > Downloads > Software/Firmware > EDS&GSD).

EDS files and icons are grouped in a single compressed Zip file that you must unzip to a single directory on your hard disk drive.

Selection Criteria for TeSys T LTMR Controller Variants

There are four EDS files corresponding to the four possible configurations of the TeSys T Motor Management Controller system:

In local configuration mode, the parameter Config via Network Port Enable must be disabled. This mode preserves the local configuration made using the LTMCU or SoMove with the TeSys T DTM through the HMI port and PLC configuration via the network is unavailable.

In remote configuration mode the parameter Config via Network Port Enable must be enabled. This enables the PLC to remotely configure the LTMR.

The Config via Network Port Enable parameter is set by default.

Overview

The EtherNet/IP protocol is used for object modeling. Object modeling organizes related data and procedures into one entity: the object.

An object is a collection of related services and attributes. Services are procedures an object performs. Attributes are characteristics of objects represented by values, which can vary. Typically, attributes provide status information or govern the operation of an object. The value associated with an attribute may or may not affect the behavior of an object. An object’s behavior is an indication of how the object responds to particular events.

Objects within a class are called object instances. An object instance is the actual representation of a particular object within a class. Each instance of a class has the same set of attributes, but has its own set of attribute values, which makes each instance in the class unique. The Object Dictionary describes the attribute values of each object in the device profile.

LTMR Object Dictionary

The general breakdown of the LTMR Ethernet brick object dictionary is the same for all EtherNet/IP devices:

These objects are described in detail in the following pages.

Description

The Identity Object, present in all EtherNet/IP products, provides identification of, and general information about, the device.

Class Code

The Identity Object class code is 0x01 as defined by CIP.

Class Attributes

Class Services

Instance Codes

Only one instance is implemented: Instance 1.

Instance Attributes

Instance Services

Description

The Message Router Object provides a messaging connection point through which a Client may address a service to any object class or instance in the physical device.

Class Code

The Message Router Object class code is 0x02 as defined by CIP.

Class Attributes

Class Services

Instance Codes

Only one instance is implemented: Instance 1.

Instance Attributes

Instance Services

Description

The Assembly Object binds attribute of multiple objects, which enables each object’s data to be sent or received over a single connection. Assembly objects can be used to bind input data or output data. The terms "input" and "output" are defined from the network's point of view. An input sends (produces) data on the network, and an output receives (consumes) data from the network.

Only static assemblies are supported.

Class Code

The Assembly Object class code is 0x04 as defined by CIP.

Class Attributes

Class Services

Instance Codes

Only one active cyclic connection at a time is supported per instance.

Instance Attributes

Instance Services

Output Assembly Data

Input Assembly Data

Description

The Connection Manager Object provides for and manages the run-time exchange of messages.

Class Code

The Connection Manager Object class code is 0x06 as defined by CIP.

Class Attributes

Class Services

Instance Codes

Only one instance is implemented: Instance 1.

Instance Attributes

Instance Services

Description

The TCP/IP Object provides description of an opened explicit connection and associated communicator.

Class Code

The TCP/IP Object class code is 0xF5 as defined by CIP.

Class Attributes

Class Services

Instance Codes

Only one instance is implemented: Instance 1.

Instance Attributes

Instance Services

Description

The Ethernet Link Object provides the characteristics for each Ethernet links of the product.

Class Code

The Ethernet Link Object class code is 0xF6 as defined by CIP.

Class Attributes

Class Services

Instance Codes

Two instances are implemented for the Ethernet Link object. Each instance represents one of the two Ethernet ports.

Instance 1 for Port 1, and Instance 2 for Port 2.

Instance Attributes

Instance Services

Description

The Control Supervisor Object models all the management functions for devices within the Hierarchy of Motor Control Devices.

Class Code

The Control Supervisor Object class code is 0x29 as defined by CIP.

Class Attributes

Class Services

Instance Codes

Only one instance is implemented: Instance 1.

Instance Attributes

Instance Service

Control Supervisor State Event

The following diagram shows the control supervisor state event matrix:

The following table describes the run/stop event matrix: