Application Note: RTMOE 4 Axis Cyclic Link Performance : Output Word

Brett Mernin, Applications Engineer

6/4/2014

The Unidrive M family’s implementation of IEEE 1588 (PTP) is commonly referred to as RTMOE, or Real
Time Motion Over Ethernet. To provide data to users, several scenarios of data transfer across a
network of Unidrive M’s will be tested in order to convey practical performance data points for
appropriate implementation of RTMOE with Emerson products.

This test will act as a baseline for basic data transfer among several drives, and will illustrate (practically)
the jitter that can be expected for data to be transferred, received, and executed among a bank of
Unidrive M’s communicating over Ethernet. In this case, a single 16-bit value writing to the output word
in Menu 8 will be transferred using Easy Links, and jitter will be measure by monitoring digital output 1
on the first (grandmaster) and last drives in the Ethernet daisy chain. A square wave will be created on
the outputs using an onboard user program in the grandmaster drive, which will have the frequency of
twice the time of the clock task.

The hardware configuration of this test is straightforward, and is shown below. 4 axes of M700
hardware were selected and upgraded to Ethernet FFM firmware 1.03.00.54, and then daisy chained
together using standard RJ45 Ethernet cabling. An oscilloscope was connected to the first output on the
grandmaster and final slave drive, and the bank of drives were configured and programmed using a PC
with Unidrive M Connect and Machine Control Studio (MCS).
The onboard user program in the grandmaster drive changed the state of an application menu integer
(18.011) from 0 to 1 or 1 to 0 every cycle of the clock task. This parameter was used so it could be used
to not only broadcast to the rest of the drives, but also loop back and be written to 8.073 (output
control word) on the grandmaster drive as well, whose first bit would control the first output on the
respective drive. The code running in the 4 ms clock task is shown below:

Master Drive : Onboard User Program On 4 ms Clock Task

As stated earlier, Easy Links were used to configure the synchronized data transfer over Ethernet. These
settings are shown below as well for the grandmaster and slave drives; and only changes from default
settings are highlighted here:

Master Drive : Slot 4 (FFM) Ethernet Settings:

Parameter Caption Value

2.025 Gateway Mode Gateway
2.030 VLAN Enable On
10.010 Tx1 Link Profile Sync
10.011 Tx1 Link Number 1
10.012 Tx1 Source Parameter 18011
10.014 Tx1 Link Transmission Type Broadcast
10.015 Tx1 Link Destination Address 255.255.255.255
10.016 Tx1 Message Rate 1 ms
10.040 Rx1 Link Profile Sync
10.041 Rx1 Link Number 1
10.042 Rx1 Destination Parameter 8073
10.043 Rx1 Parameter Count 1
10.044 Rx1 Source Type Local
11.001 Preferred Sync Master 1
11.030 Easy Mode Max Network Delay 3 ms
Slave Drives : Slot 4 (FFM) Ethernet Settings

Parameter Caption Value

2.030 VLAN Enable On
10.040 Rx1 Link Profile Sync
10.041 Rx1 Link Number 1
10.042 Rx1 Destination Parameter 8073
10.043 Rx1 Parameter Count 1
10.044 Rx1 Source Type Direct
11.001 Preferred Sync Master 0
11.030 Easy Mode Max Network Delay 3 ms

Although many of the settings in Easy Links may be familiar to previous Emerson products, there are
several that are unique to RTMOE on the Unidrive M, which are crucial to understanding the
performance and operation of the network:

1. Setting parameter 4.02.025 “Gateway Mode” to “Gateway” on the master drive allows the
master drive to act as an isolator (gateway) between the Unidrive M synchronized network and
any other synchronized fieldbus that may be coming into its switch. Without this setting, third
party PLC’s or other devices that are distributing synchronized timing pulses and information for
a synchronized network may interrupt and be interrupted by the same operation being
performed on the Unidrive M network of synchronized drives. Although there were no auxiliary
devices on the network for this test that could have caused that type of conflict, it is good
practice to use this setting on the first drive for the network of RTMOE, to ensure no conflicts
occur.
2. Setting parameter 4.02.030 “VLAN Enable” to “On” enables the information going in and out of
each drive in the local network to be tagged with the necessary timing information to ensure a
synchronized network. All drives in the network must have this setting.
3. Setting any Tx or Rx “Link Profile” setting (e.g. 4.10.010) to “Sync” allows that link to act as a
synchronized link over the network, and is necessary for RTMOE to function effectively. Setting
this to a “Standard” link will not allow the information going in or out of that link to be
synchronized to the grandmaster clock in the master drive. Additionally, if the user attempts to
set this setting to “Sync” and VLAN is not enabled on the drive, the drive will issue a trip.
4. As stated above, parameter 18.011 is the bit that is being toggled by the onboard user program,
and is being used as the transmit value on the master drive so it can also be “looped back” to
8.073 within itself. Looping it back allows it to be time stamped with the execution time for the
synchronized information, instead of being executed immediately (e.g. if the onboard program
wrote directly to 8.073). By setting 4.10.044 “Rx1 Source Type” on the master drive to “Local”
allows this to happen. The source type of “Local” will take the information generated in itself
through Tx1, and give it the same time stamping information that the rest of the drives will
receive.
 5. Finally, parameter 4.11.030 “Easy Mode Maximum Network Delay” gives the message being
sent and received an execution time relative to the absolute time that the message was sent by
the sending drive. Since the drives are synchronized to the grandmaster clock on the master
drive, each drive on the RTMOE network knows exactly what the current absolute time is at any
given time. When a message is sent by a drive, it is sent with a time stamp of exactly when it
was sent, as well as information on when to execute (write) the information to the target drive,
which is what 4.11.030 defines. This is the vehicle that allows the information to be executed at
the exact same time on the network. If the time it takes for a message to get from the sender to
the receiver exceeds the value in 4.11.030, the Ethernet module will trip. This is illustrated in
the following graphic, where the blue arrows show the flow of information over Ethernet, and
the red arrows show the execution (writing) of the information:

In this drawing, to is the absolute time that the message is sent from the master drive. T1, t2, t3,
and t4 are the times it takes the messages to get their destinations (e.g. 10us, 20us, 30us, and 40
us respectively). TE is the execution time of that message, and is equal to to + 4.11.030. Even
though the transmission times t1, t2, t3, and t4 may be different, te will be the same in all four of
the drives. To summarize another way, although the time between the receipt of the message
and the execution of the message may be different for each drive in the network, the absolute
timing for execution according to the grandmaster clock will be the same for each drive.

In addition to the Ethernet settings, in order to write to the first output on the drive through the Digital
I/O Output Register 1 (8.073), the first bit in Digital I/O Output Enable Register 1 (8.071) must be
enabled on each drive that 8.073 is being used. The Digital I/O Output Register is being used because it
not only allows the user to write directly to the output (instead of using a source address) but also
allows the user to write to it quickly, since the status of a selection of these bits is updated every 250 us,
as shown in the table below from the M700 Parameter Reference Guide:
Once the parameter files had been modified on all drives and the onboard user program had been
loaded and initiated on the master drive, the scope was adjusted to record the square wave coming
from digital output 1 on the master and last slave drive. After the network came into synchronization,
several scope captures were recorded to measure the jitter occurring between the two square waves.
The image below is of the scope capture (divisions of 2.5 ms), where the waves are offset vertically by
several volts so the shape of both waves can be seen. Additionally, the next image shows an expanded
view (divisions of 10 us) of a falling edge of the wave, for a better look at the jitter between the two
outputs:

2 Channel Scope Capture : 2.50 ms divisions

 2 Channel Scope Capture : 10 us divisions

Further detail is available on the scope with grid divisions down to 5 ns, but the exported graphics didn’t
have enough resolution to show in this report. With multiple samples taken and expanded to see the
jitter down to the nanosecond scale, it was observed that the jitter between the square waves of the
digital outputs seemed to follow the jitter of the network, which generally stayed at +/- 3 ns, but often
was +/- 1 ns. What this test shows a user of this technology, is that the data transfer and time stamping
used in Emerson’s implementation of RTMOE is capable at getting hardware responses and data
execution at jitter levels in a single nanosecond range or the level of jitter on the communications
network. This can serve as a baseline for small amounts of data transfer across a network of several
drives when looking to use RTMOE for synchronization. Further tests and reports will be completed that
implement motion, multiple protocols on the network, as well as larger amounts of information to
provide baseline data when designing new applications.