1588 priority between PharLap and Linux cRIOs

[CyGa]

Hi,

I'm trying to force a specific cRIO to be the 1588 master on a network.

On this network I can have several PharLap controllers (9082) and several Linux controllers (9035 and 9039). They are all connected to the same switch.

Using System Configuration API I can set the Pharlap 1588 priority 1 and 2 to a specific value. To do the same on the Linux controllers, I programmatically apply the method explained here : http://digital.ni.com/public.nsf/allkb/10E7079FCE1A0840862580DD005F99F9

If I want to set a controller to be a MASTER I set priority 1 and 2 to 1. SLAVES are set with priority 1 and 2 to 200.

SLAVEs are always set first to 200, last device to be set is the MASTER to 1.

What happens is :

• If the PharLap controller is set MASTER, Linux controller stay to the required SLAVE state ONLY if they are linked to the same switch. If I add another switch to increase the delay between the Pharlap controller and the head switch, the priority os not respected and the 1588 algorithm decides that the Linux target has to become master. In that last case, the log shows that the Linux controller switches between SLAVE to MASTER and then 1588 is deselected. (see log1)
• If the Linux controller is set to MASTER, 1588 daemon starts and is almost immediatley stopped (time reference 1588 deselected ; see log2). However, ptp_Eth1.status file says it is master and is regenerated every 1 seconds (see log3). At the same time, the PharLap controller which is supposed to be SLAVE, is seen in MAX as MASTER !

How to make all these working ? Is there a better way than playing with priorty to set a specific device to be a 1588 MASTER ?

[dmysliwiec13]

Hi! 

Would it be possible for you to attach your code where you used the system configuration API?

Danielle

Applications Engineer 

[LindsW]

Hi zyl7,

For the first case you mentioned with the PharLap controller being set to MASTER – I believe our PharLap & VxWorks controller default to only synchronizing the local subnet (i.e. Time to Live for PTP packets is set to 1). You can modify that default by changing the MulticastMsgTTL property as explained in this KB.

But that doesn’t really explain the second case where the Linux controller is set to be the master. (If I remember correctly I think the default TTL on Linux RT is 64, so having two switches should not be a problem.) So the fact that the LinuxRT master can’t be seen by the PharLap controllers makes it sound like maybe there’s a problem with the packets not getting passed through your switch. Are you using a 1588-enabled switch? Have any 1588 settings been applied?

Also to clarify one thing you said-- when a target becomes master, it’s expected that the 1588 time reference becomes deselected. This doesn’t mean the daemon has stopped, it just means that the 1588 time reference on that device is not driving that device’s time. In other words, it’s not applying time corrections to its clock from any other 1588 device, which is correct since it’s the master on the network.

And another note-- setting priority2 is probably overkill for your application. This article does a decent job of explaining what factors the best master algorithm takes in when picking the 1588 master. Priority2 would only come into play if there’s a tie in Priority1 AND several other factors (clock class, accuracy, etc.).

[CyGa]

Hi,

Thank you for your answer.

Pharlap and linux cRIOs are both on the same subnet. It is just that making some tests, one switch became full, so I added a switch to the first one and connected the Pharlap target on the second switch (while Linux target stayed on the first one).

Switches are standard, not particularly 1588 transparent.

You can find attached the code (which is built as a System Explorer run-time button for VeriStand). I have disabled code related to VS, so you can run it directly in LV. Code to launch is 'SetTargetTime-SystemAPI-SysExploButtonRelated.vi'.

Another thing that I noticed, in that order : 

1. I apply priority 1 and priority 2 to 200 on the linux target (tsm.json), then restart the target
2. At the same time, I apply priority 1 and priority 2 to 5 on the Pharlap target (sysconfig API)
3. Linux reboots, ptp enters in UNKNOWN mode, then PTP_SLAVE, then PTP_MASTER. At that time, if I open eth0_ptp.status file on the linux target, it says that priority 1 is 5 and priority 2 is 200
4. The Pharlap target is still seen as MASTER in MAX

This number '5' on the Linux target is very strange (like if it comes from the Pahrlap setting) ! 

And also having 2 MASTER is very strange !

[CyGa]

Hi,

Just a follow up message. Has anybody have found something ?