Troubleshoot Precision Time Protocol Configuration

I want to resolve IEEE 1588 block precision time protocol (PTP) configuration problems.

What This Issue Means

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.

Try This Workaround

To identify PTP model or configuration problems, check for these issues.

PTP Block Configuration in Model

  • 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 enters the FAULTY state

  • 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 sizeauto in the Configuration Parameters dialog box

    • Sample time-1 in 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 different from hex2dec('88F7') (for example, hex2dec(‘0010’).

    • In the Ethernet Rx block, set Filter criteria to Specify types to match. Set Receive these types to the value that you set in the Create Ethernet Packet block (for example, [hex2dec('0010')]).

  • 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.

PTP Synchronization Accuracy

  • 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.

PTP Faulty States

  • 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 Follow_Up, Delay_Resp, Pdelay_Resp, or Pdelay_Resp_Follow_Up message to its slave nodes, it enters the 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 mechanism to Peer-delay 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.

See Also

| | | | | | | | |

Related Topics

External Websites