This example creates a single deterministic data communication pathway between one talker and one listener using the TSN Toolkit API and returns useful statistics on that communication during execution. This example primarily differs from the shipping TSN example in two ways. First this example assumes that a CNC has already created and distributed a network schedule to the TSN switches. As a result, the example has a user type in the network schedule directly on the CNM such that those values overide any another values the CNM may calculate. T
his example also shows how to calculate and graph loop execution and network transmit and receive times. The talker sends packet numbers and transmission timestamps to the listener, which creates its own receive timestamps upon packet arrival and displays timing data on a graph.
There are three main VIs that are used in this program: The Simple Talker, the Simple Listener, and the Network Manager.
Again this example assumes that the user has already generated and distributed a schedule to any TSN switches. However the example can also execute on two cRIOs connected directly.
Step 1: Open the project. The project will have two unconfigured targets with the Simple Talker VI under one and the Simple Listener VI under the other. Right click one of the targets, go to Properties, and enter the IP Address of one of the targets you will be using. Repeat for the second target. Please note that this example will only function with sync capable devices. If using cRIOs, the products that support this are the 9035 (Sync) and the 9039 (Sync).
Step 2: Run both cRIO VIs. The State indicators should transition quickly from Initialization to Configuration.
Step 3: Open the Network Manager. Under Endstation IP Address, type in the IP addresses of each of the targets. Their order in the array does not matter.
Step 4: Input the following values. Values in bold are defined by the schedule generator (CNC) and can be found in the data for the flow schedule. Values not in bold are important to the application schedule but are automatically derived from the Period and Tx/Rx offsets.
The MAC address associated with the stream. Each time sensitive stream in a TSN domain is assigned a unique MAC address. This is a virtual address generated by the schedule and NOT the MAC address of the receiving cRIO’s NIC.
VLAN ID number. The VID is assigned by the CNC based on the route configured for the stream.
Priority Code Point. The PCP is a 3-bit value that indicates the priority of the stream. Set the PCP to 0 unless there is a 3rd party device being used that requires a specific PCP value.
The period is the network communication period for the talker and listener. This will also be defined as part of the network schedule.
The Tx Offset is the time since the start of the network communication cycle at which the transmission of the time sensitive stream begins. This value will be provided by the CNC. If provided with a window of potential transmission time, set this value to the lower number in the range ex. If the range is 150-170 usec, the Tx Offset should be 150 usec
The Rx Offset is the time since the start of the cycle at which the listener expects to receive the time sensitive stream. This value will be provided by the CNC. If provided with a window of potential receive time, set this value to the higher number in the range ex. If the range is 560-590 usec, the Rx Offset should be 590 usec.
Talker Sync Point
The Talker Sync Point is the time at which the function on the talker device will wake up and begin creating data, which will then be input into the Tx Buffer. The Talker Sync Point must be less than the Tx Offset minus the Tx Copy time, as the device needs time to write the data to be transmitted into its Tx Buffer.
Listener Sync Point
The Listener Sync Point is the time at which the function on the listener will wake up and begin reading data from the Rx Buffer. The Listener Sync Point must be greater than the Rx Offset plus the Rx Copy time, as the device needs time to write the data to be read into its Rx Buffer.
Step 5: Run the Network Manager. The Talker and Listener VIs should move from Configuration to Ready, Ready to Running, and Running to Start Event Received. At this point, the Listener VI will begin to display timing data on the graph. The values displayed should match the values that were set in the Network Manager. If matched, then the hardware is verified and TSN communication is functioning properly.
The graph on the UI of the listener program shows the measurements of the actual times for specific network events. The following values input into the CNM correspond to the values on the graph:
Input into CNM
Talker Sync Point
Tx Loop Start
Listener Sync Point
Rx Loop Start
The Rx Loop End is the time when the Listener function has completed execution.
From start to finish, the graph will show the times from when the talker loop woke up to when data was pulled out of the buffer on the receiver, and the times for most of the key steps in between.
When using a switch between the devices, the values on the graph should closely match those input into the CNM. If that isn't the case, common errors include inputting the incorrect MAC address for a flow or having the devices connected to the wrong ports of the switch. For example, if the talker is plugged into the port where the schedule expects the listener, and vice versa, then data likely won't make it between end devices.
Also note that when directly connecting the cRIOs without using a switch, the Tx and Rx timestamps will be nearly identical. In this case, the measured Rx offset would not match that of a system originally scheduled with a switch in the middle.
Where can one get the DMAC, VID and PCP values from when running this example with 2 cRIO's connected to each other? Do you have to have the shipping example running as well?
With TSN 17.5, a lot of VIs has been moved/renamed, is it possible that you can update the VIs for TSN 17.5?
Thanks and Kind regards
That is correct, this was a shipping example in 2016 with TSN 16.0. Since then the API has evolved and the most up to date examples are in C:\Program Files (x86)\National Instruments\LabVIEW 2017\examples\tsndriver after TSN 17.5 installation.
I'm planning to write up a quick documentation page to go over few talking points. But here is a quick overview.
Open the TSN Stream.lvproj project. In the project there are two cRIO targets representing endpoints. Under each cRIO(endpoint) there are two VIs, 'TSN Stream.vi' and 'TSN Stream - with JSON Configuration Import.vi'
Setup endpoint Stream Configuration and Run. Do it for each cRIO (endpoint) where one cRIO is a listener and another a talker.
TSN Stream - with JSON Configuration Import.vi
This VI is very similar to the above example VI except that a Stream Configuration is turned into a Json and then the Json is use to configure a stream. The idea there is to show how to start a stream with a preconfigured Json. The preconfigured Json can be made on the target or it can be send from some other 'centralized location' like a user host PC, control station etc.
Hi, I have already taken the operation as the video about using cnc tools,and I get the computed schedule (please refer to cnc schedule.PNG). Finishing this step,I tried to run the TSN Toolkit Simple Talker and Listener Example with some configurations provided by cnc schedule ,but the result is always unsuccessful. (please refer to the Simple talker and listener vi state.PNG) My cisco switch has been configurated according to official instruction yet. Would you help me find the possible reason lead to this problem.
From looking at your screen shot of the computed schedules in the CNC it looks like the last computed schedule version does not match the last distributed schedule version. I suspect the switch did not retrieve the configuration from the CNC.
The distribution window should look something like this:
After the schedule is distributed, the schedule version should match all around. You can also open console out window to your switch and see console out print out as the schedule is being distributed. (It may take around 30 seconds or more so be patient)
Also little bit of background which might help with debugging. The CNC technically does not push the schedule on to the switch, its actually the switch that pulls it from the CNC. The CNC just "notifies" the switch that a schedule has changed (this happens when you hit "distribute schedule to switches).
One thing to try is to restart the service responsible for handling communication between CNC and a switch.
In the switch CLI type:
no tsn cnc-server // this stops the service
tsn cnc-server <IP> // where <IP> is the IP number of the VM eth port connected to the switch. If you are using a preconfigured VM that IP is set to 10.1.1.1. Please confirm using 'ping'
What protocol is being used to transfer data between the talker and listener in this example? I have edited the network packet type-def on the talker to add a few extra variables that are successfully transmitted, but I'm curious if there is a better way of doing this.
Can you create a new post with your question? It is easier to follow a thread if it only contains one question. If you are talking about a specific example or topic just link it to your post.
Also can you elaborate what variables you changed? A screenshot would be useful.