cRIOs in Ring topology :is it possible ?

[CyGa]

Hi,

I'd like to link several cRIOs in a ring topology. Is it possible ? If yes, how can I do this ?

My cRIOs references are 9082, 9030, 9035, 9039.

A ring could be composed from 2 to 5 cRIOs, references would be mixed.

The idea is to maximise the performance of 1588 synchronisation using a 1588 transparent DLR switch.

[vipillai]

Could you post a rough diagram showing how you would have this ring topology set up with the switch?

[Miro_T]

The current topology will the the transparent switch will help. But generally, I don’t think cRIOs can support a ring topology since you can only have one instance of 1588 on one of the two Ethernet ports. This might be possible on IC-317x controllers since ICs are able to have multiple instances of 1588 time reference on different eth ports. However I dont think it was ever tested. 

Also, I’m not sure how are you looking to maximize performance with the ring topology. Even if the ring topology was doable you will only increase reliability of the system, synchronization will be the same.  

[even-And]

To enable IEEE 1588 synchronization on your CompactRIO systems you will need to install NI-TimeSync on each CompactRIO

CompactRIO IEEE 1588 Synchronization:

http://www.ni.com/white-paper/52962/en/#toc5

For more information on IEEE 1588 Network Topologies:

http://www.ni.com/tutorial/2822/en/#toc4

[CyGa]

Hi !

Sorry for the late answer.

I have a switch which is 1588 transport only on 2 ports when used in ring topology. We have a problem with several cRIOs which are 'fighting' to become Master when set with the same priority. The priority is set to the same value because each cRIO is part of an 'acquisition station' (VeriStand) and they can be interchanged/removed/added.

We also found out that when a cRIO becomes Master, the slaves align to its 'master time' (which is the desired behaviour). When it happens, VeriStand PCL stops...

So we're trying to have a topology ensuring that the Master-Slave exchange won't happen when code is running.

[Miro_T]

Setting all cRIOs to same priority number basically “eliminates” decision making based on the priority1 which means BMC algorithm just goes to next deciding property (a class).

Can you elaborate on the “fighting”….. does this happen only during initial setup or does it also occur when running?

Is it possible to have only one cRIO to be dedicated “master” by assigning one cRIO a lower priority1 number and leaving others with higher priority1 numbers?

PCL stopping when a new master is introduced to the network makes sense a little since the timed loop “snaps” forward or backwards in time.  

How often do you need to remove/add cRIO to the network? Is it possible to have some “service state” on your acquisition station?

[CyGa]

Each CompactRIO is part of my System Definition and creates a versatile acquisition system.

So, in order to ease the configuration of the system, each cRIO avec the same 1588 priority (default 128). And we expect the master to be determined quickly when the targets turn on. When the targets are turned on the network topology do not vary (no device addition / removal). targets are connected to the network through a router.

We've observed that sometimes the 1588 master changes from one target to another, forcing the clocks to resynchronise on all targets. When that happens, we have an error from VeriStand saying that the PCL has stopped. And indeed our custom devices do not run anymore.

IMO, PCL should not stop. We should have a warning saying that loops have been missed according to the delta t.

It reminds me of some problems we faced in the past when running cRIOs RTEXE and changing the clock of the system by a few seconds : RT OS completely freezed.

[Miro_T]

Zyl7

Thank you for the further details about your system. BMCA is fairly quick and network should have the best master determined before you start your system. Furthermore, if there are no disruption to the network then there should not be no flip flopping between master selection. The initial master (device) should remain the master.

There are many reasons why this might be happening but most common is some problem on the 1588 network where Sync Receipts packets do not arrive on time (time outs). Is the router that you are using 1588 capable? Is it the one you mentioned in your original post?
Are there any other 1588 master-capable devices besides cRIOs on this network?

[CyGa]

Hi Miro_T,

The router used when we noticed the problem is not 1588 capable.

That is why we wanted try with a 1588-capable switch. And the one we have is 1588 transparent only on a ring topology. That is why I was trying to link my cRIOs in a ring.

[Miro_T]

Thanks, I think I see the full picture now...... Unfortunately I dont think ring topology will be possible with cRIOs due to single 1588 instance per controller. 

Using non 1588 switch is probably why the controllers are flip-flopping between masters because regular switches tend to buffer packets which might look like a "timeout" to a 1588 device(cRIO).