Can't get EtherCAT (9144) to recognize CAN (9853) module

[BobbyO]

I have a cRIO system which consists of a 9024 RT controller in a 4-slot chassis, and a separate, remote 9144 EtherCAT 8-slot chassis.  The 9144 has the usual assortment of AI, AO, etc. modules, and it also includes a 9853 2-port CAN module.  When I try to use the "Add Targets and Devices on FPGA Target", the 9853 shows up as a NI 37670, with the comment "This C Series module is not supported by the current versions of LabVIEW and NI-RIO."  For reference, I'm using LV2009 SP1, and NI-RIO 3.4.  Even more confusing: if I move the 9853 from the 9144 to the 4-slot (non EtherCAT) chassis, and try to add it to that chassis' FPGA target, it works without any problem.  Is there some issue with CAN through EtherCAT?  This thread seems to imply that it can be done, although that poster had different issues.

Any suggestions as to what I or NI might be doing wrong?

[DirkW]

Yes, unfortunately thats a known issue and we hope to fix it with the next version of the driver for the 9144 chassis. As a work around you can add the module as an offline module for the slot it is in and if you deploy that configuration it should work just fine.

DirkW

[BobbyO]

Hi Dirk,

Thanks for the quick reply.  I was able to add the device offline as you suggested, and it now shows up -- sort of -- in the project under the FPGA.  There are still three issues that perhaps you could resolve:

1.  I've never done CAN on cRIO (or serial for that matter; there's also an 9871 RS-485 module installed in this 9144) and have been studying the various examples for hints on how to proceed.  All of them appear to use either interrupts or DMA's to synchronize operations and communicate data between the FPGA and RT applications. This DevZone article about EtherCAT flatly states that "user-defined I/O variables are... the only means for transferring data between the controller’s real-time program and the expansion chassis’ FPGA program."  I see that DMA's aren't supported on the 9144 -- what about interrupts?  Are there other approaches for CAN and serial that don't need either of these functions?  Bottom line: can you do CAN and/or serial from the 9144 in any straightforward manner?

2. The 9853 shows up as a single, unexpandable device.  Unlike the 9871, which can be expanded to show its four distinct ports, the two CAN busses on the 9853 cannot be viewed.  Maybe this is correct, maybe not.

3. I used the Add Targets on the 9144 to see all of the installed modules, not just those to be targeted by the FPGA.  Both the 9853 (which still shows up as the fictitious 37670) and the 9871 have the commentary "This C Series module is not supported by the current version of NI-Industrial Communications for EtherCAT."  Again, I have to ask: can you do CAN and/or serial from the 9144 in any straightforward manner?  Has anyone actually put together a system which demonstrates this functionality?  I'm really getting a bad feeling about this particular system topology.

Thanks again for your help.

- Bob Hamburger

[DirkW]

1. Well as long as you stay on FPGA only you can use the FPGA only examples that you can find here:

C:\Program Files\National Instruments\LabVIEW 2010\examples\CompactRIO\Module Specific\NI 985x

if you need to interact between RT and FPGA it becomes a little tricky because you are right DMA is not supported because there is a ECAT Bus between the module and your RT controller that doesn't know what DMA is.

So you have to create User defined Variables under your 9144 chassis. These UDVs are either FPGA to RT or RT to FPGA. Keep that in mind.

So for writing a CAN frame from RT you would need 6 U32 UDVs in direction RT to FPGA to transfer the frame.

For reading a frame you need another 6 UDVs in the other direction. Have a look to the ECAT examples of how to handle the timing for the ECAT bus.

2. You can reach the can modules port properties by right clicking the module and choosing properties. If you change anything here you will have to recompile the bitfile for your 9144 chassis.

3. Yes , it is possible as long as you add the can module manually.

If I find some time today I will post an example that shows how to use the module. You are not the first one asking. 😉

This is really hardcore LV FPGA programming so you might need some time to figure it out. But if you understand you will see that performance is unbelievable.

DirkW

[DirkW]

Here is a basic example that shows how to use the ECAT bus between a 9144 that has a 9853 CAN module and a RT controller ECAT master. Instead of using I/O variables  directly in your RT code you could use the programmatic API to discover the variables and read and write them via handle.

DirkW

[BobbyO]

Hi Dirk,

I've integrated your code into my application and it all compiled and deployed without issue, but I haven't yet hooked it up to an actual piece of CAN hardware to test it yet.  In looking at the code, however, I noticed that only four out of the six possible U32's are being used in the write portion of the code example.  Any particular reason for doing this?

Thanks,

Bob H.

[DirkW]

Hi

Well I do not write the timestamp because it is not part of the frame. You can transmit a valid one if you need it on FPGA for some other purpose.

DirkW

[BobbyO]

Well, I set up the top loop (receive) to listen on CAN1, and the bottom loop (transmit) to talk on CAN0.  I hooked up a loopback cable, terminated on both ends, to the ports. With some translation code in the RT host to go back and forth between the CAN cluster format and the array-of-bytes, I can send messages to and receive data back from the FPGA app through user variables, as your example code demonstrates.  Compiled and running,  I get nothing.  I added some additional user variables to send the error codes back to the RT host app, from the respective read and write nodes; both are producing 65538 -- cRIO timeout codes.  Any further suggestions on how to proceed?  I'm really in the dark here...

[DirkW · Accepted solution]

Hope you saw that the second port CAN1 needs external power?

DirkW

[BobbyO]

Doh.

Everything's working now   I made one slight modification: instead of just waiting until WriteCmd goes true, and then writing a frame (usually more than one frame, actually), I added a shift register and AND'ed the current value of WriteCmd and the negated previous value.  The writing code then goes in a case structure whose selector is the result of the AND operation.  In this manner, we only write once per assertion of WriteCmd, on the rising edge.