To troubleshoot your model, first familiarize yourself with the PTP standard, and then with the specialized requirements of the Simulink® Real-Time™ implementation.
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 enters the
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
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
To use the same Ethernet card for PTP as for data
In the Create Ethernet Packet block,
set Ether type to a nonzero value that is different
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
look for one of the following 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 enters the
FAULTY state. Try the following:
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 mechanism to
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.