简体   繁体   English

通过 PTP 同步多个 Allied Vision GenICam 相机的时间戳

[英]Synchronizing the timestamp of multiple Allied Vision GenICam cameras through PTP

I am developing a system with multiple industrial Allied Vision Mako-cameras.我正在开发一个带有多个工业 Allied Vision Mako 相机的系统。 I need those cameras to be synchronized, for which Allied Vision recommends the PTP protocol.我需要同步这些相机,Allied Vision 建议使用 PTP 协议。 Therefore, I have a time-server which acts as a PTP master clock.因此,我有一个时间服务器作为 PTP 主时钟。 The cameras are connected to that server through an Ethernet switch.摄像机通过以太网交换机连接到该服务器。 Unfortunately, that switch is not PTP-enabled, meaning that it introduces latency when delivering the PTP packets.不幸的是,该交换机未启用 PTP,这意味着它在传递 PTP 数据包时会引入延迟。 This causes the cameras to remain in PtpStatus == Uncalibrated .这会导致相机保持在PtpStatus == Uncalibrated

As far as I understand the Allied Vision GigE-Features manual, PTP causes the camera's timestamp to be synchronized across all cameras, ie GevTimestampValue should be the same on all cameras at any given time.据我了解 Allied Vision GigE-Features 手册,PTP 导致相机的时间戳在所有相机上同步,即GevTimestampValue在任何给定时间在所有相机上都应该相同。 However, during an experiment where I filmed a clock with multiple cameras, I observed that the timestamp delivered by two different cameras was about 187511041595600 ticks off (approx. 187511 seconds) while the clock visible in the frame shows the actual time difference of approx.然而,在我用多个相机拍摄时钟的实验中,我观察到两个不同相机提供的时间戳约为 187511041595600 滴答(约 187511 秒),而帧中可见的时钟显示的实际时差约为0.04 seconds. 0.04 秒。

Therefore, my questions are:因此,我的问题是:

  • Did I understand the PTP interface of Allied Vision correctly?我是否正确理解了 Allied Vision 的 PTP 界面?
  • Is maybe PtpStatus == Uncalibrated causing this to not work?可能是PtpStatus == Uncalibrated导致这不起作用?

After some investigative work, I found the cause and will share my findings here, in case someone else is stuck in the same situation:经过一些调查工作,我找到了原因,并将在这里分享我的发现,以防其他人陷入同样的境地:

Short answer:简短的回答:

  • The cause of my issues is indeed my switch.我的问题的原因确实是我的开关。 I replaced it with a different switch temporarily which fixed the problem.我暂时用一个不同的开关替换了它,这解决了这个问题。
  • I did understand PTP correctly, however, the cameras need to be at least once in PtpStatus == Slave in order to be in sync.我确实正确理解了 PTP,但是,相机需要至少在PtpStatus == Slave中出现一次才能同步。 If they loose synchronization later, they will revert to Uncalibrated and remain somewhat in sync, but if they never were in PtpStatus == Slave , they are not yet synchronized.如果它们稍后失去同步,它们将恢复为Uncalibrated并保持一定程度的同步,但如果它们从未处于PtpStatus == Slave中,它们尚未同步。 This caused the timestamps to be way off.这导致时间戳偏离。

Long answer: I configured my switch to mirror the ports to which the time server and the camera are connected to my laptop.长答案:我将交换机配置为镜像时间服务器和相机连接到我的笔记本电脑的端口。 With WireShark, I was then able to investigate the PTP traffic and found out, that the Sync and Delay_Req packets get delivered, which causes the cameras to transition from Listening to Uncalibrated (My time server does not send Follow_Up ).使用 WireShark,我能够调查 PTP 流量并发现SyncDelay_Req数据包被传递,这导致摄像机从Listening转换为Uncalibrated (我的时间服务器不发送Follow_Up )。 However, the Delay_Resp (which is sent by the time server) gets dropped by the switch.但是, Delay_Resp (由时间服务器发送)被交换机丢弃。 It thus seems that my switch is misconfigured in some way, letting those other multicast packets pass while dropping Delay_Resp .因此,我的交换机似乎以某种方式配置错误,让那些其他多播数据包在丢弃Delay_Resp时通过。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM