I'm getting my feet wet with the deterministic data flow aspect of TSN, and have been trying to wrap my head around the TSN Toolkit Simple Talker and Listener Example (see here: https://forums.ni.com/t5/LabVIEW-Time-Sensitive/TSN-Toolkit-Simple-Talker-and-Listener-Example/gpm-p...)
My question is what protocol or method is being used in that example to transmit data from the talker to the listener in this example? I edited the network packet type-def in the example to include a few extra double-variables (see images), and they seem to arrive at the listener correctly, but I'm not sure if this is the best way to set up the actual deterministic flow in TSN.
1 - [Talker] Changed type def of network packet cluster to include 3 double variables
2 - [Talker] Values are written to the cluster before being transmitted to listener
3 - [Listener] Values are read out of the incoming network packet cluster
You are using this properly.
The TSN API is a low level interface. It is similar to the LabVIEW UDP API. The payload can be anything (UDP VIs use a string input and TSN uses a U8 array but you can convert one to the other). This allows a number of different higher level protocols to be built on top of the API. UDP uses network layer 3 mechanisms to specify the network settings for transporting the message from talker to listener. TSN uses layer 2 mechanisms to specify the network settings.
In the TSN API there are two options on how you want to send and receive. One is a "Chronos" option and one is a "Raw" option.
Chronos will add (and remove on listeners) some additional information to help with diagnostics and benchmarking. The key items are a counter value and a Tx timestamp. This can be used to detect if a packet was missed or was delayed by the network.
Raw will not add any additional information into the payload. If you were to inspect the actual packet you would see the L2 payload is exactly what was written from your TX.
I'd also recommend you take a look at these examples instead. We migrated away from some of the VIs you are using in the last version to a simpler and lower level API.
Related to the example you linked: in the talker and listener, there inputs for "Offset" and "Loop offset from TX/RX". The default values were working for me with a 1ms and 500us period set in the CNC, but when I tried a period of 250us I couldn't find what values the CNC flow scheduler corresponded to these inputs, and consequently I get no connection. Do you know what corresponded to these values in the CNC? Or is it that a period of 250us is too fast?
I'm going from memory since I don't have the code loaded in front of me but I think:
Loop offset from TX/RX is the amount of time it will take the LV code and the driver to shuttle data back and forth including timed loop overhead and OS jitter. It is used to calculate when the timed loop should start relative to the TX or RX time. These will vary somewhat on your code and you need to use the benchmark examples if you want to fine tune (basically tighten the times until you see missed packets when using the counter inserted from the LV diagram). In general the values in this example should not need to be changed unless you change what code is running in the timed loop.
The offset is the time that is given from the CNC for TX time or RX time. The CNC gives a range assuming that devices are a little sloppy on TX. In general NI has roughly 1uS of jitter on TX so you can move toward the middle of the window if you need to but in general I use the earliest time on TX and latest time on RX.
That said, even with these pulled in you should still get data but may also get missed packet errors. If you are not getting any data I suspect the packets may not be making it through the switch. There may be a limit on what cycle the Cisco switches support. I don't know if we have tried a 4kHz with the Cisco switches. It is also getting close to the limit for cRIO due to the above mentioned "loop offset from TX/RX" unless you start to do a 1 delay communication cycle.
I normally go to Wireshark running on a PC when I suspect these types of problems. You can disconnect and plug directly into the PC and see what packets are flowing (talker cRIO directly to PC, then Cisco switch egress port directly to PC).