reasonable max number of etherCAT slaves with cRIO

[MarkCG]

Hi all, I am designing the control system for what will be a fairly large machine and I considering the ways the overall system can be architected. I have created systems with a cRIO master and a single cRIO 9144 EtherCAT slave. However I have not tried using multiple EtherCAT cRIOs and/or 3rd party EtherCAT devices like servocontrollers. Has anyone used more than one EtherCAT slave with a cRIO? How many slaves can you realistically daisy chain off one of the newer "value" cRIOs like the 9068? I know this answer will depend on number of scanned variables and the scan engine period. At 10ms scan engine period, what can you expect?

 

[smithd]

Don't forget about the existance of the much much newer ethernet rio targets -- if you can handle slower loop rates (and shoving all high speed logic onto the FPGA) they're really a lot easier to deal with (at least in my experience).

 

Still, I think these benchmarks should give you a good idea:
http://www.ni.com/product-documentation/10596/en/
and http://www.ni.com/white-paper/52642/en/

If you grab the excel sheet off the first one you can guess how much data is transferred and it estimates latency and delays through each node. For a basic enough example the second page shows results for the 9068. In this case 4 slaves at 10 ms uses 13% of the CPU, similar to the 9024. 

[MarkCG]

Very good! Thank you for pointing me to this article, was not aware of it. The only thing I am wary about is running into a bug that will be complete show stopper, which a risk with hardware configuration that are theoretically possible but no one really uses. Especially when using third party devices. 

[ShaunR]

59 minutes ago, MarkCG said:

Very good! Thank you for pointing me to this article, was not aware of it. The only thing I am wary about is running into a bug that will be complete show stopper, which a risk with hardware configuration that are theoretically possible but no one really uses. Especially when using third party devices. 

The usual issue is finding out the processor you chose based on cost, isn't enough to run ethercat and your application at the same time (half way through your project ). If you are not using the FPGA then I highly recommend spending the extra effort and using that instead.

Edited June 20, 2016 by ShaunR

[Omar Mussa]

I've been using a mix of EtherCAT slaves (all third party, none are NI) for several years now connected to various NI cRIO controllers (9067, 9068, 9035) and I haven't had any major issues.  So far, whenever I've had an issue its been because the vendor had an error in their XML file and contacting the vendor I've been able to get fixes in each case without too much hassle.

 

I would warn that if you are using a 9068 you should be aware of this issue:  http://digital.ni.com/public.nsf/allkb/9038F4D0429DD7C686257BBB0062D3F3

In my case this issue was a showstopper so we switched to a 9035 which I would recommend looking at.

[smithd]

4 hours ago, MarkCG said:

Very good! Thank you for pointing me to this article, was not aware of it. The only thing I am wary about is running into a bug that will be complete show stopper, which a risk with hardware configuration that are theoretically possible but no one really uses. Especially when using third party devices. 

I guess I would say look for the module being compatible with a 9074 in FPGA mode. This excludes things like the XNet interface which is RT-only but includes things like the raw CAN card. You can also emulate it in the project -- if the FPGA compiles, it will likely work. The two big showstoppers I've seen with ecat are...

3 hours ago, ShaunR said:

The usual issue is finding out the processor you chose based on cost, isn't enough to run ethercat and your application at the same time (half way through your project ). If you are not using the FPGA then I highly recommend spending the extra effort and using that instead.

Yeah lots of small logic bits will save you with the ethercat...but theres also the risk you run out of space since the FPGA on those guys is so small.

The other concern is the number of user-defined variables. While you can have full chassis worth of IO, you can only have like 64 or 128 or something like that UDVs per chassis. 

[MarkCG]

On 6/20/2016 at 2:31 PM, ShaunR said:

The usual issue is finding out the processor you chose based on cost, isn't enough to run ethercat and your application at the same time (half way through your project ). If you are not using the FPGA then I highly recommend spending the extra effort and using that instead.

I don't think I will need to implement any custom logic in FPGA. Having worked with FPGA I only really want to use it if there is something I HAVE to do in it that I can't implement on real time side with a scan-engine synchronized loop. multi-kilohertz control loop rates, signal generation or digital logic. Motion control will be handled far better than what I can implement by purpose built, EtherCAT third party servo controllers. My experience implementing custom FPGA logic on the etherCAT slave is not really worth unless you really need it. That is, it's worth it if you have a physically distributed network and you need FPGA logic AT that physical etherCAT node. Otherwise, for master and slave colocated in same cabinet, I prefer to stick any FPGA code on the master, which can have big FPGA, and just use the slaves as expansion chassis for scanned IO. Thank you for pointing that out the CPU issue. I believe I will get a high performance cRIO then.

On 6/20/2016 at 2:59 PM, Omar Mussa said:

I've been using a mix of EtherCAT slaves (all third party, none are NI) for several years now connected to various NI cRIO controllers (9067, 9068, 9035) and I haven't had any major issues.  So far, whenever I've had an issue its been because the vendor had an error in their XML file and contacting the vendor I've been able to get fixes in each case without too much hassle.

 

I would warn that if you are using a 9068 you should be aware of this issue:  http://digital.ni.com/public.nsf/allkb/9038F4D0429DD7C686257BBB0062D3F3

In my case this issue was a showstopper so we switched to a 9035 which I would recommend looking at.

It's good to know it can be done with multiple third party slaves. I am going to have to analyze what happens during resets, thank your for bringing that KB to my attention. Behavior during reset can be odd for certain device-- the NI 9401 DIO module outputs go HIGH during reset for example.

 

On 6/20/2016 at 5:57 PM, smithd said:

I guess I would say look for the module being compatible with a 9074 in FPGA mode. This excludes things like the XNet interface which is RT-only but includes things like the raw CAN card. You can also emulate it in the project -- if the FPGA compiles, it will likely work. The two big showstoppers I've seen with ecat are...

Yeah lots of small logic bits will save you with the ethercat...but theres also the risk you run out of space since the FPGA on those guys is so small.

The other concern is the number of user-defined variables. While you can have full chassis worth of IO, you can only have like 64 or 128 or something like that UDVs per chassis. 

Oh yes, I have the compatibility chart KB bookmarked

http://www.ni.com/product-documentation/8136/en/

It's funny you mention UDVs because that is exactly what generated a nearly showstopping bug for me a year ago- CAR was issued

http://forums.ni.com/t5/Real-Time-Measurement-and/cRIO-application-works-in-interactive-mode-but-broken-VIs/td-p/3095135

I wonder what the UDV limitation comes from? Perhaps NI will do a refresh on the cRIO EtherCAT chassis soon and put a bigger FPGA on it.

Edited June 22, 2016 by MarkCG