I have a question about changing "neighbor propagation delay" in NI-Sync property.
The picture gives rise to an error of -1074118578 on cRIO 9040.
Is there any good example vi or way to change the vi?
Also, is there any limitation or range for the value of "neighbor propagation delay"?
Solved! Go to Solution.
I have found the property nodes to be a little confusing to use. I'm not sure if there is a white paper or app note anywhere that describes the theory of operation. Maybe someone else on the forum can point to one.
In either case I think the issue is that you are not providing an input for the active item. There are multiple time references on the device and I think the node needs an input for active item to define what you are trying to change.
It's been a while since I worked with this but so I'm a little fuzzy on the details but I have previously created my own pallet and utility so I could monitor the performance of TSN devices on the network and could change settings. You probably don't need all the code in the example (it does discovery, etc) but it shows how to read the settings and how to change parameters including the neighbor delay threshold. I think most of this code will run either on a host PC talking to devices remotely or directly on a TSN RT target.
I attached a zip file. It may still have some bugs which is why I have not made into a package and posted before now. Hopefully this give you a good starting point.
Thank you for your early and kind correspondence. For me, your vi is very good example of using the property nodes to change TSN settings. I will check the vi in more detail with my customer next week.
Now my understanding is that the configurations of the proprerties on cRIO targets can define when and how a cRIO will send a packet.
Can we import the configuration of switch configuration software to the program on cRIO targets?
We would like to find an application or a sample vi by which we can configure whole communication under 802.1 Qbv standard.
The intention long-term is that the full network set-up can be automated and there is a CUC and a CNC. However the APIs to talk automatically to a CNC are not yet standardized. Instead today the Cisco CNC is designed to be use interactively (it has a GUI) and really is a mix of a CNC and a CUC.
This works well for small to medium systems that do not change very frequently. There are Cisco specific APIs and we have done joint proof of concepts and examples to automate the parameter set-up. (We have done similar work with Belden who showed automated network set-up of cRIO devices and their switches at the SPS show this year). We have never shared those externally, partly because they need cleanup and more testing but mostly because the APIs will change as the industry standardizes on an API.
Thank you for your kind advices. Now we can change the neighbor propagation delay. Is there any specific number for the maximum or minimum of the neighbor propagation delay?
You should not normally need to change this value. Default of 800nS is the spec for copper connections (<100m).
You might need to change if the device you are connected to is misbehaving (likely due to it being a prototype device). In this case the settings would depend on the device behavior.
The other potential reason would be if you have decided to try to connect to a non compliant network. An example would be connecting with a non-managed switch which does not support 802.1AS. The protocol is designed to detect this and to disable sync by looking at the neighbor prop delay. If you wanted to override you could set this value higher (you would need to do this on the devices on both sides). This may technically allow sync to occur but performance may be badly impacted. The only time I've changed the value was when I was using a non-compliant copper to fiber extender. This added some jitter to the time sync and added a few uS of prop delay. In this application I could deal with both items so I increased the delay threshold to get communications to work.