Trouble interfacing with CANopen Device using NI9881 on cRIO-9067

[simenfu]

Hello,

I'm currently struggling to interface over CANopen with a sensor-simulator. I have already verified (using a closed source program) that the simulator is indeed communicating. It should further be noted that I'm only briefly familiar with the CANopen protocol, so there might of course be something trivial that I have missed out.

The problem, in general, is that I appear to be unable to communicate with the simulator. I have attempted to read/write any of the SDOs listed in the Object Dictionary, but I keep getting the error code indicating "SDO Protocol timed out". Naturally I increased the timeout variable, though it made no difference. I have also noticed that when attempting to use the Online Test Panel (located in the Project Explorer under cRIO -> CANopen Utilities) I appear to be unable to locate the device. Still, when looking in MAX I can clearly see that my NI9881 module is present with a CANopen01 interface.

I have also tried the Online Validation tool with the Batch SDO. The only way this does not return a timeout is if I don't add any items to the Batch (pointlessly sending nothing). 

I'm currently using LabVIEW 2014 SP1 and the NI-Industrial Communications for CANopen 15.0 to program a cRIO-9067. My module is manufactured before April 4th, 2015, so I updated the firmware of my NI9881 according to the Example Project in LabVIEW. 

According to this link the cRIOs in the series 903x and 906x should not require a blank FPGA bitfile assuming that LabVIEW 2015 and Compact RIO 15.0 is used. Since I'm using 2014SP1 I decided to give the bitfile a shot as well, but that didn't work either. 

If desired I could upload my code. Although it primarily consists of inspiration from the LabVIEW CANopen example (which I've also tried, yet without luck). Let me know if there is any more information I can provide.

I would greatly appreciate any help on the matter (whether it be direct solutions or things I could try). 

[Miro_T]

Simenfu,

If you are not using LabVIEW 2015 then you should be deploying a blank FPGA bitfile. You have probably done this already but check out NI CANopen for cRIO.lvproj example. In the example go to the FPGA vi and read  instructions on the front panel. The way you can confirm the cRIO is aware of the module is if the module appears under Devices and Interfaces under cRIO in NI-MAX. Remote Systems>>your cRIO>>Devices and Interfaces>> it will say something like NI 9881 "CANopen 1" for example. This will only apper while you are running a blank FPGA bitfile.

In case of LabVIEW 2015 and RIO 15.0, module will appear under Devices and Interfaces wihtout running any FPGA code. 

Also since we are dealing with a CAN network, make sure the CAN network is properly powered and terminated. Check out page 6 of the NI 9881 Getting Started Document.

Make sure you are running CANopen Read SDO or any other CANopen vi while the project for that VI is open. 

Are two LED on the module doing anything? If yes can you observe their behavior and compare it to LED behavior describtion in the CANopen manual? In Windows click Start>> search for Ni-Industrial Communications for CANopen Help>> In Contents tab >>CANopen hardware>> Overview . You can also check out cabling section which would be a same thing i linked above. 

Hope this helps

Let us know what you find out

Miro T.

National Instruments

[simenfu]

Hi Miro_T,

I had indeed attempted to create a bitfile according to the instructions of that example, though it didn't make it work. However, I tried doing this again to cover all bases in case there was something I did wrong. I tried adding the module under the Chassis, create a bitfile, and run this file. Then I tried adding the module under the FPGA target, create a bitfile, and run this one. In neither of the cases were I able to locate the module in MAX. And I even got an error stating that the hardware was missing (-2147136892). As I did state in my previous post, though, the modules appeared in MAX when using Scanmode (I could see "CANopen01" interface under Devices and Interfaces"). 

I also tried to view the console terminal output using PuTTY, both by interfacing via SSH and Serial. In neither of the cases did I see the "DECoM RMT: Initializing..." text which the example states should appear in the console terminal. Is there possibly a command I need to type to get this to appear?

While in Scanmode (the only mode I've managed to get the hardware to show), I did try changing the terminating resistor value by enabling it in the Initialize VI. This made no difference. Also, another piece of information is that I'm using an NI CAN Breakout Box between the Simulator and the cRIO. Furthermore, my cable length does not exceed 10m, so I'm not sure if the terminating resistance will matter too much. 

As for the CANopen VIs I have tried virtually all of them in order to get some sort of feedback from the Simulator.

While running the program in Scanmode the left LED (1) is solid green while the right LED (2) is off (no activity at all). According to the info this should indicate "Open session on hardware, port is properly powered, and hardware is not communicating". This makes sense, although I'm not quite sure how to fix it yet. 

While running the program using a bitfile neither of the LEDs are lit. 

Are you sure that I need to use a blank bitfile? And if so, how can I verify this console output that the example speak of? 

[simenfu]

Upon trying once more I found that I would achieve the exact same result if I used scanmode or placed the modules under the Chassis and created a bitfile that I ran. The CANopen timeouts are the same, hardware discovery/interfaces in MAX are the same, and so are the LED indicators on the module. 

[Miro_T]

Yes the proper way to setup CANopen LabVIEW project is to have the module under the chassis and chassis is in the FPGA mode (as seen in the CANopen for cRIO project).

One thing I do if I need to run a blank bitfile is to crate a VI that just simply keeps FPGA reference open(call it "connection" vi or something similar). I keep this VI running on the side while I build new VI or use example VIs.

While this "connection" VI is running I'm able to see module in MAX and no LEDs are on. Once I attempt to run CANopen code thats when the module LEDs start flashing. 

Example of  the "connection" vi I use: 

Since you are using CAN breakout box I'm assuming you are powering your CAN network via the box, correct? Is the termination box LED ON? indicating power..

Also check termination switch on the box, make sure proper termination resistance is selected. 

If all that is good then post your code and location where the error gets generated.

[simenfu]

I attempted to use your method, but the SDO read still timeouts and I see no activity in the LED (apart from solid green LED1 like before). 

And yes, I power it with 24V through the Breakout Box and the LED is lit indicating that it is powered. The simulator also has a LED which is lit, so I know that the CAN network is powered. I have pretty much tried all the terminating resistor combinations I can. One more piece of information is that the program I use to verify the Simulator functionality is coupled to the CAN Breakout Box via an NI USB 8472 module. This program works fine regardless of which terminating resistor I'm using (even if there's none).

Below is a test-code I put together which gives me the "SDO protocol timed out" via the SDO Read Completion Code. The index I'm attempting to read is available upon bootup and should say whether I'm in boot or application mode. I have tried numerous different indices, without much luck with any of them. 

ass

[Miro_T]

Hmm that is interesting. Based on the information provided everything should be working fine. Code looks good as well.

One thing, I see you specified 50kbits/s baud rate. Is this really a baud rate needed for your sensor? Can you doublecheck with the manual? Also, it looks like baud rate is a type def. Make sure its not being overwritten from somwhere else, like top level VI for example. 

Sometimes its simple things like this 🙂

[simenfu]

From the information I've been presented, it should be 50kbps, yes. For the sake of it, I tried all the available baudrates, but all of them timed out. 

[Miro_T]

Very weird....

You mentioned using USB 8472 for testing which means you are probably doing low-speed CAN fault tolerant network. One advantage of fault tolerant network is that if there is a problem with one of the CAN wires device is able to automatically switch to single wire transmission. Since 9881 is build on top of high-speed CAN such functionality does not exists. I know this is a long shot but check it out. I'm running out of ideas why we can communicate with this sensor 

By any chance, do you have any other CANopen sensor to test?

Also, can you post user manual of the sensor you are training to communicate to?

[simenfu]

I have two simulators, each with two nodes, so in total 4 nodes. I tried reading from a different sensor, but the result remained the same. Sadly I'm not at liberty to disclose of the manual for the sensors (at least not at this point in time), but I could provide the standards that the sensor is based on. Perhaps that could give some insight that I've overlooked. CiA 301 Ver. 4, CiA 302, CiA 305, CiA 306 and CiA 443. Is it possible that the sensor just isn't compatible with the NI9881 module?