I learned a PPT download from NI official website that introduce the TSN，noted that：
Sync unaffected by cable length
Does that mean the IEEE802.1AS support the transmission by fiber（Fiber Converter）？
Solved! Go to Solution.
Yes, 802.1AS is supported on both fiber optic and copper cables (technically the standard also supports WiFi but to my knowledge there are no products on the market for that yet).
It will require that the fiber converter or switch support the 802.1AS standard. Cisco IE4000 switches can be used. I'm not aware of copper to fiber converters that support 802.1AS.
We have looked at some off the shelf fiber converters which are not AS rated. If you are evaluating converters some things to be aware of:
Converters can introduce non-symmetric delays (ie where the TX takes longer than the RX). This will lead to timing errors.
802.1AS also has a peer delay threshold which will cause the system to identify a link as not AS capable if the delay is too big. The default for copper is 800nS. A transparent fiber converter could introduce latency (even long fiber optics can introduce a latency of more than 800nS). On cRIO (starting in 18.1) you can change this threshold but on cDAQ you can't change the default. This means the device may detect that the link is not AS capable and the software will stop accepting time from that port.
Does the Cisco IE4000 switches support the fiber（as the picture）? I noted that there are 4 SFP module slots,If the IE4000 support the fiber,how long does it support?
Now I have the last question，I noted that the distance IE4000 support is depend on the choise of the SFP module，Does the SFP slot on the IE4000 device support the TSN？If the SFP slot on IE4000 support the TSN，that would be great.
yes the IE4000 supports SFP modules of different distances. the datasheet for the IE4000 Cisco.com shows the support for different SFP types, and the distances ranges for each type.
scroll down to table 15.
the Cisco IE4000 requires Cisco certified SFP modules.
TSN will work on the SFP links.
Note that on interfaces G1/1 - 1/4 can operate in Fiber mode or copper mode. you cannot use these first 4 interfaces to have both fiber and copper. you must choose.
TSN is supported interfaces 1 - 16 regardless of copper or fiber.
Regarding fiber capabilities of NI products, Hokie is correct with respect to layer 2 copper-fiber conversion. We have recently been able to test layer 1 copper-fiber conversion and saw better results. Using a layer 1 copper-fiber converter (such as this one), we were able to maintain 802.1AS synchronization over a fiber connection. We saw a low offset between the slave and master clock (typically <10 ns), but we did see a high path delay (~500 ns) between nodes connected by fiber converters and 10m of fiber cable, so we expect the path delay could still become a problem for longer fiber connections. If the path delay becomes too long (over 800 ns by default), 802.1AS synchronization will be disabled.
On the CompactRIO platform, users can adjust the neighbor propagation delay property which would allow for longer path delay, and longer fiber connections. This property is not modifiable on cDAQ devices, so they may not be viable for an application that requires a fiber connection. We also expect that less hops may be possible in a daisy-chain with fiber connections than in a daisy-chain with copper connections due to the path delay. We expect that a star topology with CompactRIO nodes and suitable settings for neighbor propagation delay on each branch would be an ideal setup.
IEEE 1588-2008 could also be used, and may be preferable since it does not have a requirement for path delay.
So If I want to build the long distance synchronous system by the TSN network and NI TSN cDAQ,the IE4000 should be used（As the picture）?And I can use the DAQmx to achieve synchronization between cRIO and cDAQ？
Thank you for your response.
I wanted to update this thread with a correction to some inaccurate information. Longer path delays will not degrade the quality of synchronization, as long as the path delay is consistent and symmetrical. 802.1AS automatically compensates for path delay so the length of the path delay does not affect synchronization. I apologize for any confusion.
It is worth noting that path delay is a method by which the 802.1AS algorithm detects non-802.1AS capable devices on the network. The assumption is that if a device has path delay that's longer than the maximum specified path delay, it is not 802.1AS capable and it is excluded from the network. With CompactRIO targets, you can set this path delay as needed but with CompactDAQ targets, long path delay may still become an issue.