取消
显示结果 
搜索替代 
您的意思是: 

RT System Time change not working

已解决!
转到解答

Hello,

 

I have an NI Linux RT target running LabVIEW 2020.

 

I can successfully update the system time to the current client time using the Set Time.vi in the System Config Libarary.

 

However, after 10 or so seconds (I am reading the current time in a loop), the time skips about a minute forward and is no longer correct.

 

I have never set up network time synchronization on this target. I see no settings anywhere in MAX or in the web configuration. The KB explains how setting up NTP is a non-trivial task and I have certainly not done it.

 

What is going wrong?

 

Thanks

Nick
0 项奖励
1 条消息(共 8 条)
2,907 次查看

Once it jumps forward a minute, does it stay "out of synch" by the same amount?  It sounds like there may be a problem with comparing two clocks that are synchronized "to the nearest minute", but one is, say, 30 seconds ahead of the other.  If you are looking at time in H:M format, one will "jump ahead" by one minute when its minute "rolls over" at a different time from the other clock.  For example, I've got a RIO running as an NI Linux RT Target.  It says the time is 11:49, but my PC says 11:50, though I set it to the same time earlier.  But when the RIO rolls over to the next minute, it "catches up" and they are the same for the next 8-9 seconds (and then the Host "jumps ahead" again) ...

 

Bob Schor

0 项奖励
2 条消息(共 8 条)
2,882 次查看

Good idea but I am definitely viewing seconds as well. 

 

It does jump the same amount every time, regardless of what I set the clock to either. By that I mean that I can set the RT clock to whatever, and after a few seconds it jumps to 53 seconds ahead of 'real' time.

 

If I was an outside observer I would swear that it was synchronizing with some dodgy time server.

 

niNickC_0-1605027425719.png

 

 

Nick
0 项奖励
3 条消息(共 8 条)
2,879 次查看

Quick, patent it -- you've discovered Time Travel (by 5 seconds, but may you could iterate it ...).

 

Seriously, you may be correct that there may be a "hidden synchronizer" somewhere ...

 

Bob Schor

0 项奖励
4 条消息(共 8 条)
2,846 次查看

Ha! 

 

It is super suspicious... I might see if the problem persists if I connect over the USB network adapter.

 

I might see if support has anything to add... 

Nick
0 项奖励
5 条消息(共 8 条)
2,837 次查看

When you figure it out, post your Solution (you're allowed to give yourself credit if you post it first).  A very curious situation ...

 

Bob Schor

0 项奖励
6 条消息(共 8 条)
2,830 次查看
解答
已被主题作者 niNickC 接受

So the solution was to uninstall NI-Sync (which is included in the latest base image).

 

I don't really know anything about NI-Sync or these synchronisation protocols in general but it turns out that NI-Sync will set the OS clock to some arbitrary 'network time'. 

 

There is a KB to disable this:

 

https://www.ni.com/en-gb/support/documentation/supplemental/20/use-ntp-for-timestamping-measurements...

 

However, following the steps didn't work (the configgen tool errored with 'unrecognised arguments'). When I tried to query the parameter you are instructed to set (--getTKPluginConfig phc2sysEnable), I received the response ‘Command not supported for non-pxi devices’. So it seems that there may be some compatibility issue.

 

Anyway, uninstalling the driver completely allowed me to set the time.

 

I would argue that this is kind of a bug. If you install the standard image, you cannot set your OS clock.

Nick
0 项奖励
7 条消息(共 8 条)
2,792 次查看

Aha!  I was never entirely clear what those "Sync" functions were for, so I'm not sure I ever installed them!  Many thanks for persisting and figuring this out!

 

Bob Schor

0 项奖励
8 条消息(共 8 条)
2,776 次查看