Ni-Sync using PXI and Windows PC

[KeithLV]

Hello,

I am running LabVIEW 2015 SP1.

I have NI-Sync16.0 and VISA 16.0 installed.

I have the PXI Platform Services 16.0 runtime and configuration installed.

I am attempting to run a 1588 Timerserver with a PXIe-1065 with a 8135 CPU controller and a normal windows laptop.

The PXI has a 6682 Timing Module.

I intend to make the PXI the "grandmaster" for the timeserver.

The ethernet is connected between the Laptop and the 6682 card ethernet port.

I have been following this guide to configure the PXI to host the 1588 Timeserver: http://www.ni.com/tutorial/53115/en/

"B. Configuring through LabVIEW

The NI-Sync driver provides LabVIEW example code for configuring 1588 synchronization. You can locate these examples in LabVIEW by navigating to the NI Example Finder, then selecting Hardware Input and Output»Timing and Synchronization»Time-based. The two examples of interest for 1588 synchronization are “Set Time Reference” and “Start 1588 and Wait for Quality”."

I tried running the Example VIs, but I continue to get errors where the resource for the grandmaster is not seen by the Laptop:

I did change the Time Reference to the "1588 Ordinary Clock".

I also added the IP addresses of the PXI into the test VIs.

I also attached the altered example VIs for reading the 1588.

1) Does the PXI have to be listed as a remote system on the Laptop?

Please look here @ figure1:http://www.ni.com/tutorial/12871/en/

2) Do I need to add the PXI as a VISA resource on the Laptop in order to pull the NI-Sync Clock from the PXI grandmaster?

3) I have no idea which one of the attached VIs are meant for reading and which is meant for writing to the 1588 clock. Which one should I have on my Laptop which reads in the 1588 grandmaster clock sent by the PXI?

4) Do I need to have the PXI added as a remote device on the Laptop?

The PXI is not showing up in MAX on the Laptop.

Thank you,

Keith

[QueenSelene]

Hi Keith,

Thanks for your detailed problem description. In answer to questions 1&4, if the PXI controller is running a Real-Time operating system then yes, it should show up as a remote system in MAX as seen in that tutorial. However, if the PXI controller is running Windows it shouldn't show up under remote systems, it behaves just like any other PC on the network so to access it you can either remote into it or connect a monitor and keyboard.

As regards to questions 2&3, I'm not sure yet with your specific setup, I'll look into those VIs some more and let you know if I can come up with anything. Thanks!

[KeithLV]

Selene,

I found this article: http://forums.ni.com/t5/LabVIEW/ptp-Synchronization-on-Windows/td-p/2898126

It states the windows OS needs to be running a PTP timeserver in the background. (Greyware "Domain Time II")

For linux machines, they mention there are many more options. A PTP time server package called "PTPd" is one option. I assume this can be pulled via APT-GET.

I plan to use the PXI 6682 as the "Grandmaster" for the 1588 PTP time server.

1) My question:

What do I use for a PC for time synchronization with 1588? NI-Sync, or NI-TimeSync???

I understand cRIOs use NI-TimeSync

I understand PXI and PXIe chassis use NI-Sync.

I have no idea if I can sync the 1588 clock from a PXI chassis to the windows laptop using LabVIEW...

I was hoping to do everything within LabVIEW (I want to avoid using 3rd party software (Greyware) to synchronize the PTP 1588 time server.

Thank you,

Keith

[LindsW]

Hi Keith,

Is your PXIe-8135 controller running Windows or RT? As Selene mentioned, this will impact what you’re supposed to see in MAX, as well as how you run the NI-Sync examples.

If it’s an RT target, you will need to add it under Remote Systems in MAX and then deploy the example VIs to it in LabVIEW. If it’s a Windows target, you will not see it in MAX on your laptop, and you can just run the example VIs directly on the controller. Either way these examples need to be run on the target itself, not your laptop. You should run both Set Time Reference and Start 1588 and Wait for Quality on the controller to begin participation in 1588. Once those VIs are running, you don’t need to do anything else on the PXI side. You just need to connect the NIC of your PXI-6682 to the network with your laptop.

As for your laptop, you will need to use the Greyware software you mentioned, or some other 1588 client to act as a 1588 slave because LabVIEW doesn’t have a 1588 client on Windows. I’m not very familiar with how these clients work, but I imagine it probably synchronizes the Windows system time. If that’s the case, you wouldn’t need to directly interface with the client from LabVIEW. You could just read the OS time from LabVIEW.

[KeithLV]

LindsW,

I am using the PXIe-1065 with a PXIe-8135 CPU with Windows OS (PXIe-8135 does NOT have a RT, realtime processor).

The PXIe is the grandmaster for the PTPv2 time server.

I have a cRIO-9035 I am interchanging with my laptop (choosing either or because I do not have a switch at the moment).

When I am using the cRIO, I am using the second ethernet port (port 1, not port 0) to see the 1588 PTPv2 comms from the PXIe.

I wanted to find a free solution for this PTP problem for LabVIEW, no matter what platform.

(The following approach is for software PTP only)

I am able to see the timestamps using Wireshark (well known ethernet network debugging tool).

I see that the PTPv2 protocol is accessible using UDP communications.

Please see this article: https://wiki.wireshark.org/Protocols/ptp

I added a "ptp" filter in the top filter bar to make wireshark only show 1588 PTPv2 comms from the PXIe.

I am able to get the output and in returns the format of dat/time in seconds and the time is immediately followed by the nanoseconds.

I double mouse clicked on the Event in wireshark and the entire UDP PTPv2 packet can be seen!!!!!! AWESOME!!!!

I am using an example project in order to test the timeserver.

I attached the example project containing the working cRIO VI and the NOT WORKING Laptop VI.

The cRIO-9035 uses NI-TimeSync and I am able to receive the 1588 system time from the PXIe correctly and flawlessly.

I also attached the separate PXIe project that sends the PXIe 1588 server using 1588 using NI-Sync.

Review:

The cRIO uses NI-TimeSync

The PXIe uses NI-Sync.

The Laptop must pull apart the UDP packet on its own.

My predicament:

I am getting UDP error 56 in LabVIEW or error 60 when I change the port.

The issue seems to be that the UDP ports 319 and 320 (the event and general messages on the PTP 1588 comms) are already "open", thus when I attempt to "reopen" the UDP port by using LabVIEW's "Open UDP Connection" VI, the port is already in use and cannot be accessed...

1) Is there a way to read the "raw" UDP packet from the PXIe 1588 comms (read raw UDP data across the port) without trying to re-open the UDP port?

2) Is there a way to somehow read the output of the Wireshark program and send the data into LabVIEW?

Thank you,

Keith

[QueenSelene]

Hi Keith,

If I understand you correctly the problem now is getting your laptop to access the 1588 clock which requires a 1588 client. I've honestly never manually done this before or worked much with PTP, as I think it's much more common (and definitely less time consuming on your part) as LindsW said to just use some sort of third party 1588 client, and so if at all possible I would definitely recommend that. 

I think it would also be helpful for me to take a step back, why do you need the laptop to be synchronized with your PXI controller? Are you taking measurements with your laptop or otherwise why do you need this synchronization?

As far as the errors go that you're getting with the Open UDP VI in LabVIEW, I wasn't able to find anything referencing this error in this specific context. I was able to find some mention of manually closing ports, so this might be something you can look into?

You can probably pull data from Wireshark and read it in LabVIEW but I think this would introduce some latency that would defeat the purpose of the synchronization.

[KeithLV]

Selene,

I am saying if Wireshark can do this,

From WireShark Wiki:

https://wiki.wireshark.org/Development/LibpcapFileFormat

From my understanding WinPcap is an open source program running built into Windows that runs to "peek" at all Ethernet traffic.

WinPcap might have been installed with Wireshark, I am not sure...

If you did not download WireShark, you might need to download WinPcap from http://www.winpcap.org

Because PTP 1588 is essentially UDP, I looked for a PTP LabVIEW program.

http://www.ni.com/example/27660/en/

I am now experimenting on parsing the PTP headers and data from the "raw" traffic on the Ethernet port of the Windows Laptop.

-Keith

[QueenSelene]

Hi Keith,

Okay, did you have any success parsing the PTP headers and data from the raw traffic on the Ethernet port on the laptop? Are you using that example you linked as a starting point?

[KeithLV]

Selene,

I managed to get the 1588-2008 Time server with PTPv2 working with LabVIEW.

The Windows laptop was connected with a PXIe-1065 (NOT REALTIME, RT processor -- Windows OS only) where the PXIe is the 1588 PTPv2 grandmaster.

The PXIe has a NI-8135 processor and it is running NI-Sync on the PXIe.

I have a cRIO-9035 running NI-TimeSync (registers on the same 1588 network).

The windows laptop runs LabVIEW 2015.

The PXIe runs LabVIEW 2013.

I attached the PXIe and Laptop LabVIEW projects.

The LabVIEW program works by changing the Windows System Time when it receives "Announce Message" updates from the PXIe grandmaster over 1588 PTPv2, but there seems to be a significant delay while the LabVIEW code runs on the Laptop end.

The Program works by interfacing with the open-source "WinPcap library" to pull the raw Ethernet traffic into LabVIEW. It calls multiple functions in the "lvwpcap.dll" file.

I then pulled the additional 1588 PTPv2 information using Wireshark as a template (Wireshark had descriptions on each byte in the 1588 PTPv2 packet, so everything was identifyable).

1) Is the delay caused by the event structure in the "1588Timerserver_WithLaptop_PTPv2_WindowsSyncWith1588Clock.vi"?

2) I am unable to get the Laptop synchronizing with the PXIe with less than 100 milliseconds of error (I need the PXIe and the Windows Laptop matched in time to 1 millisecond synchronization error).

To point out the error, look in "1588Timerserver_WithLaptop_PTPv2_WindowsSyncWith1588Clock.vi" at the "TimeDifference1588_Windows" indicator. This indicator shows how the Windows system time deviates from the received time from the PXIe over 1588 PTPv2.

3) Does anyone know how I should be acknowledging and nacks work for PTPv2?

I do not get status data from the grandmaster unless a cRIO or another PXIe is hooked up on the same network.

I assume the follow up messages are all coming from the cRIO on the same network.

4) I tried changing the "Log Sync Interval" NI_Sync variable on the PXIe end, but that did not cause the data to be more responsive on the Windows laptop LabVIEW VI.

5) Do you know how I can decrease the error in synchronization down to the rated "sub-millisecond" resolution of 1588 PTPv2?

I understand 1588 PTPv2 can be synchronized down to the nanosecond level, but I was hoping I would be able to do this on a Windows laptop running LabVIEW.

Thank you,

Keith

[LindsW]

Hi Keith,

My two cents - I don’t think you’re going to be able to achieve 1 ms accuracy writing your own 1588 client in this way. For one thing, the 1588 clients available for purchase include servo algorithms that gradually adjust system time and filter jitter, as well as numerous other advantages that improve synchronization performance.

Another thing to note is that there’s a difference in performance depending on whether you are implementing hardware or software 1588. So while nanosecond synchronization is possible with 1588, you’re not going to be able to achieve that with software timestamping on a Windows client. (In the case of the PXI-6682, hardware timestamping is being used, which is why we are able to achieve a typical synchronization of ~100 ns. cRIOs on the other hand running NI-TimeSync use software 1588, which is why the accuracy is ~1 ms.)

Also, note Windows is not as deterministic as a real-time OS so you are going to see some performance degradation because of that as well.

Again, to go back to one of Selene’s earlier questions – what will you be doing with the synchronized time on Windows? Are you performing acquisition on your laptop that needs to be timestamped? Or is it possible that getting accurate timestamps on your cRIO and PXI targets could be sufficient?

I'll defer to others to help you with your UDP questions if you decide to continue going down that route.