Master-Slave chain Setup

Hello,

I am trying to setup a Master Slave Setup as follows:
I have a Master Clock Device which is sending PTP sync messages to the Windows 7 PC, which receives them on Ethernet Interface 1 (ptpd.exe is then synchronizing the clock).
From here I setup another ptpd.exe process for Ethernet Interface 2 to send out PTP sync messages to a PTP-capable ethernet-camera.
So I was able to see there is synchronization happening on Windows and also on the camera, but the precission was really bad and both clocks wer lagging and jumping back and forth (seconds).

I then switched to Windows 10 PC and only synced the camera with the PC using PTPSync. This worked fine and I achieved a accuracy in µs. But I still need to include the master clock for the PC.
I tried to do it via Windows 10 PTP Service, but without success.

My question now is how do I need to setup the sync manager properly to realize the Master-Clock->Slave Win10PC eth1->Master Win10PC eth2->Slave camera chain?

Thanks in advance for your help!

So is the root of the issue that you cannot get Windows to sync with your PTP clock using the service?

Thanks!
Ritchie

Hey,

sorry if my description was unclear.
The root issue is that I don’t get 2 parallel PTP syncs running in my top down structure. (see picture)


Sync between PC and camera is working, sync between Master-Slave (red connection) not.
Is the way I am doing it the right way to create 2 processlaunchers in PTPSync Manager?

OK - thanks, yeah. I think understand. I’m not sure about having two instances of ptpd being launched (never tried that).

I think I would try starting with a single one and trying to get local Windows clock sync’ing first.

Then you can try adding -u ADDRESS option for example to rebroadcast feed to camera (assuming it supports such). Could also try the -h end-to-end mode.

You might also need to remove -g option, so do not run as slave only.

Regardless, during this config debugging phase I would enable -V for verbose messages - just remember to turn it off later.

Hope that helps!

Thanks,
Ritchie

I didn’t ask - do you have to use second interface for camera, or is it OK to use same interface for both sets of traffic?

Thanks for the tips, I will try them tomorrow.
Actually it has to be a seperate interface because GigE Vision Protocol is used for the camera and it can get really busy on this interface and I want to avoid frame drops.

Hi,
I didn’t find the time the last weeks to step forward with this topic. I tried as you suggested and tried to first get the Windows clock synced. For this I set up a fresh Win10 Pro installation and disabled NTP Client on registry.
I observed the same behavior as described in this thread: Clock going nuts - #12 by ritchiecarroll
In the first seconds it’s looking good. Using the w32tm /stripchart /computer: command shows an accuracy around 3ms which would be acutally enough for my purposes. But some time later the clock is going crazy and jumping around.
I retried with different clock master - same behavior. Also when I unplug the clock master the clock keeps going crazy. So I highly assume it must be realted to the PTP Sync Manager settings.
Any idea how to fix this?

Hello again,

today I performed some further tests and it looks like it won’t run as we thought.

PTPSync can either be the master for the camera or the Slave for the grandmaster.
I did some pcap traces with wireshark with the following settings:
String1:

FileName=ptpd.exe; Arguments={-b {0D58C4F0-B3AB-46A6-8F7C-39B09F79AA94} -V -h -n 2 -y 2 -m 1 -u 192.168.47.2}; ForceKillOnDispose=True

String2:

FileName=ptpd.exe; Arguments={-b {0D58C4F0-B3AB-46A6-8F7C-39B09F79AA94} -V -h -n 2 -y 2 -m 1}; ForceKillOnDispose=True

Wireshark_Traces_PTP.zip (3.1 KB)

For better unterstanding:
192.168.47.1 - Win10 Ethernet Interface1
192.168.47.2 - Camera
192.168.50.30 - Win10 Ethernet Interface2
192.168.50.50 - Grandmaster (Announce=4sec, Sync=4s)

I also tried to use the same IP-band for both interfaces without success.

If you have any further idea what I can try please let me know.