I want to resolve
IEEE 1588 block precision time protocol (PTP)
To troubleshoot your model, first familiarize yourself with the PTP standard, and then with the specialized requirements of the Simulink® Real-Time™ implementation. For more information, see Precision Time Protocol and PTP Prerequisites, Limitations, and Unsupported Features.
To identify PTP model or configuration problems, check for these issues.
Configure all PTP nodes in a network with
the same Delay measurement mechanism. If you configure
a slave node with a different setting from the master node, the slave node
Configure all PTP nodes in a network with the same Timescale or Arbitrary timescale epoch value. If you configure the master and slave nodes with differing timescales, the representation of time in time-of-day format differs for the two nodes.
Configure all nodes in the PTP networks with the same Announce interval and Announce receipt timeout. Differing values of these parameters in a PTP network can lead to unpredictable behavior.
Avoid using inherited sample time everywhere in your model. Inherited sample time occurs throughout your model when you make the following settings:
Fixed step size →
the Configuration Parameters dialog box
Sample time →
all of the blocks of your model.
The sample time that Simulink calculates can be greater than the PTP message transmission intervals, resulting in an unusable model.
The PTP configuration subsystems include configuration blocks for the associated transport protocol. If you use a separate Ethernet card for data transmission, include a separate network configuration block. Assign it a Device ID different from the one already in use by the PTP configuration block. Multiple network configuration blocks with the same Device ID cause a build error.
The PTP Over Ethernet block creates PTP messages with
Ether type set to
hex2dec('88F7'). To use the same Ethernet card for
PTP as for data transmission:
In the Create Ethernet Packet block, set
Ether type to a nonzero value that is
hex2dec('88F7') (for example,
In the Ethernet Rx block, set Filter
Specify types to
match. Set Receive these
types to the value that you set in the Create
Ethernet Packet block (for example,
If you include more than one slave node in the network, configure the master node to use the standard PTP multicast address for transmitting messages. The master node must transmit the same synchronization message to all the slaves.
Using the IEEE 1588 Sync Execution block to make measurements across multiple target computers at the same simulation step can lead to a CPU overload. Also, the kernel interrupt clock controller can shorten some time steps up to 10% of the model fundamental sample time.
If you get CPU overloads, consider decreasing the value of the Proportional gain parameter of the IEEE 1588 Sync Execution block or increasing the sample time of your real-time application.
If you use the IEEE 1588 Sync Execution block in your model, configuring EtherCAT® distributed clocks in master shift mode in the same model produces a build error. To include IEEE® 1588 synchronized execution and EtherCAT distributed clocks in the same model, use EtherCAT bus shift mode.
The synchronization accuracy depends upon the value of Sync interval. The smaller the value, the more accurate the synchronization. If your model fails to meet your required synchronization accuracy, try decreasing the value of Sync interval.
You can use IEEE 1588 Sync Execution block to synchronize two PTP models with differing fundamental sample times. Their execution is synchronous at a PTP time equal to the least common multiple of the two rates.
When a slave node enters the
FAULTY state, look for one
of these conditions:
The slave node is configured with a different Delay measurement mechanism setting from the master node setting.
The slave node model sample time setting is greater than the master node Sync interval setting.
The slave node Announce interval setting is shorter than the master node Announce interval setting.
The slave is not receiving a response from the master to delay request messages sent by the slave. This behavior occurs, for example, if the slave node is configured to use a delay measurement mechanism setting different from the master node setting.
If the master node fails to read a required timestamp from the Ethernet
card due to contention for the timestamp register, the transmission can
fail. After a master node fails five consecutive times to transmit a
Pdelay_Resp_Follow_Up message to its slave nodes, it
FAULTY state. Try these options:
Reduce the number of slave nodes in the network.
Shorten the sample time for the subsystem that represents the master node. The master node cycles through the slave messages faster and reads the timestamp register more often.
Increase the Min delay or pdelay request interval of the slave nodes. The slave nodes generate messages less often.
Connect a peer-to-peer transparent PTP clock between the master
and slave nodes. Set Delay measurement
for all of the nodes. The peer-to-peer
transparent PTP clock has a separate timestamp register for each
port, taking the load off the master node.
For more information, see IEEE Std 1588-2008 Clause 10.
IEEE 1588 Adjust Time | IEEE 1588 Create Message | IEEE 1588 Ethernet | IEEE 1588 Process Message | IEEE 1588 Read Parameter | IEEE 1588 Real-Time UDP | IEEE 1588 Setup | IEEE 1588 Sync Error | IEEE 1588 Sync Execution | IEEE 1588 Sync Status