I have a cRIO-9024 with an NI 9853 and I'm trying to configure and control an Emerson Unidrive SP using CAN port 0. I have the Indsutrial Communication for CANOpen 1.0.1 driver installed (on PC and cRIO) and I've been able to successfully read certain registers on the drive using SDOs.
I'm still confused as to the configuration and use of SDOs and PDOs (learning a lot, though), but what I want to do at the moment is be able to write to the drive control word (parameter 1.42) and read the status word (parameter 10.40). I have been doing a LOT of digging through manuals and LV CANOpen examples, and I think that the addresses that I need to use for these two values are 0x2001, sub-index 2A for the control word and 0x200A, sub-index 28 for the status word.
I've had no luck in running the CANopencRIOPDODemo VI (from the cRIOCANopenbasic example project), it causes a CANopen module error and kicks the cRIO offline, I end up having to reboot it to restore communication between it and my laptop.
At any rate, any light anyone can shed on this particular issue, as well as configuring and using SDOs/PDOs in general would be GREATLY appreciated.
What error message do you get when you run the Demo VI? A screenshot could be really useful here.
The SM-CANopen manual has a number of flow charts and setup examples that will help you to get moving with the configuration. A lot will depend on the number of PDOs you wish to use for cyclic data. There are examples for all options.
If using SDO access you can use the 0x2000 + Menu, Sub Index (parameter); so in your example use for Pr 10.40 0x200A SI 0x28. The control word for the drive is 6.42 hence this should be 0x2006 SI 0x2A. This reflects the drive control word rather than any profile.
The Control Techniques Drive Centre network will be able to provide you with excellent support.If you Google "Control Techniques" then follow the contact us link this should get you in touch with the local Drive Centre for help with the drive setup and the SM-CANopen setup.
I will keep an eye on the postings if you need more input.
First of all the 9853 CAN module is not compatible with the IndCom 1.0.1 driver. Only the 9881 CANopen module is compatoible unfortunately. So I guess thats why you are experimenting with the examples from our Developer Zone.
Try the Reference example for cRIO and CANopen it should handle errors like timeouts better then the basic example does.
For your motion device CANopen offers two ways of writing the control word and reading the status, either by SDO or PDO. For SDO it should be sufficiant to bring the drive into operational srtate by using the NMT commands and then writing and reading to the index and sub index mentioned above. However this is very unefficient. Typically a CAMNopen device automatically maps these objects (control word and staus ) into PDO memory and you can use PDO communication to access these Objects much faster. Normaly a device maps the first 4 PDo IDs and for your device it might be TxPDO1 and Rx PDO. The manual shou;ld tell us that.
Hope that helps.
Yes the best way to manage control and status words is via the PDOs rather than individual SDO cycles. The PDOs being cyclic, rather than single wrtie cycle from an SDO (typically coded as a one off event or non-cyclic); you can use SDOs if the application doesn't demand high performance (it will work), but typically for 1ms updates (or there about) PDOs are used.
Typically a master sends a number of SDOs before the network is running (a startup list) that configures the node, this allows the cyclic data to be configured prior to the network reaching the operational state.
The SM-CANopen allows various methods to configure the PDOs, a single PDO can be set up (typically 4 x 16 bit parameters both in and out, or 2 x 32 bit parameters both in and out) using the fixed PDO 1 and drive parameters. For more advanced setup the drive can be configured to use up to 4 PDOs in each direction containing either 2x32bit parameters or 4 x 14 bit parameters. The PDO numbering is configured by specific SDOs during startup. Effectively this means the drive can use any of 4 PDO numbers for in data and the same or different PDOs for out data.
In my opinion using the startup list is usually easier to configure the PDOs than using the drive settings as all network configuration stays in the master (where it should be) , you'll need to set the PDO numbers, transmission types, COB IDs and mappings then you should be ready to go. Have a look at the flow charts in the getting started section of the SM-CANopen guide. You are already using the correct numbering system for parameters, just remember the COB IDs are typically 32 bit.
Once the PDOs are configured it is a very simple process to move data in and out of the drive.
I found out the hard way that the NI Industrial Communication for CANopen driver doesn't support the 9853, despite the fact that the driver's page explicitly states that it does.
I'm fighting two problems right now, one being the SDO/PDO specifics, and the other being the FPGA VI. When I duplicated the structure of the FPGA VI from the cRIO CANopen Basics project example, I was able to successfully execute SDO queries of several objects. The Software version number, Manufacturer's ID, etc. Seeing that these worked just fine, I added the FPGA I/O nodes for CAN1, the second port. Now no matter how I try to change the logic of the FGPA VI, those same SDO reads that had worked in the past now don't.
I'm using a slightly modified version of the cRIOCANopenSDODemo VI, along with an FPGA VI that's compiled for my target. I've changed the controls on the FPGA VI to have more descriptive names, plus I added controls for the first two U32 values (CAN Timestamp HI and LO) instead of the constants that were there. I know I won't need to write to these, but I added just to be consistent, and no, changing them back to constants doesn't make a difference.
I have a support request open with NI, it's starting to look like I can't use both ports, at least not from the same FPGA VI. I've attached the current version of the FPGA VI, the code from the example project is almost identical to what I'm using, with the exception of the changed control names and the fact that I'm using Node ID 1 instead of 0.
Getting very frustrated here, I can't even move on to the point of configuring and using the PDOs.
Ok let me try to help you on this.
1. Can you point me to the page that says the IndCom driver supports the 9853. That would clearly be a bad thing and we should fix it immediately.
2. The Fpga Vi should be able to use both ports of the module at the same time. One thing you need to know is that the second port needs external power in order to work. Only the first port is powered internally. The low power cRIO was not able to power both ports of the module internally. ;-(
3. I could not load your VI. It is somehow corrupted. Could you zip it and attach it again?
I can't find the page at the moment. I've been through so many of them it may just be that I'm thinking of the fact that a few places (this one, for instance: http://zone.ni.com/devzone/cda/epd/p/id/5474) state that the 9853 works with CANopen. Now, it indeed does work with CANopen, but it's not a CANopen module, it's a CAN module. The way it works (specifically with FPGA) is to simply use two FPGA I/O nodes (1 read, 1 write) with the default NI CAN frame array of 6 U32 controls. This leads one to the LabVIEW CANopen library, which doesn't work with my cRIO for some reason (confrmed by Richard Van De Graaf at NI). I then ended up attempting to use the Ind. Com. driver, which only supports true CANopen modules like the 9881.
At this point I've removed all the references to CAN1 from my FPGA VI and I'm having some degree of success. The engineers at NI I've spoken with (Larry Hawkins most recently, and someone named Julianne, through Larry) feel that somehow my network or node is seeing the presense of the two CAN ports as two masters. I've no idea how this is possible as I never once have called CAN1, only CAN0. I/O nodes connected to CAN1 existed in my FPGA VI existed, and that's it.
There's really no point in me uploading the latest version of my FPGA VI (sorry you couldn't view it, no idea what happened there), as I've changed it back to the same structure as that of the FPGA VI in the CANopen Basics for cRIO example project. I just gave the controls and indicators descriptive names.
I can now only successfully read index 0x1009, which is the manufacturer hardware version register. I was able to read 0x1008 and 0x100A, but now they just give me back ASCII gibberish. Not sure why, especially since 0x1009 works. I suspect that it's drive-specific.
The other issue I'm having now is that as soon as I powered the system up this morning, I tried to read 0x1009 and right after the WriteSDO VI wrote the frame to initiate the SDO upload protocol, the following SDO Read kept returning an ID value of 0x701, which is a response to a Node Guard status request. This puzzled me because I don't have any code that requests that status. I hacked in a couple of calls to the NMT VI to stop the node, reset it, the set it to the pre-operational state again. This has cleared the 0x701 response issue, but now only the first read I try to do (I'm just testing SDO reads and writes right now) returns any data to my top-level RT VI. If I stop it and read a different index, I'll get the expected response, but only that one, the others still won't return data.
I can post my code a bit later if you like, I'm going to go see if any of the default values in the drive have changed somehow.
from the drive side 0x1008 should return, "SM-CANopen" as an ASCII string. 0x100A should return the version number in the format VXXYYZZ (where xx, yy ,zz represent the firmware versions). The SM-CANopen module only supports heartbeat and not node guarding.
If you can post the PDO configurations (when you are at this stage), I will have a scan to ensure the drive will be happy with these. I'll keep monitoring the forum until you are running. Sorry I cant add much input from the master side though.
The CANopen reference library for the 9853 is located here, and I understand that the CANopen offerings for our different products can be confusing. I am currently working on a KnowledgeBase to clarify to difference between all these different libraries. The CANopen library is intended for Series 2 PXI/PCI devices which uses the legacy NI-CAN driver.
To clarify, we were not concerned that your bus was "seeing" two masters, but rather that you were trying to use two masters. Although multiple masters are supported by the CANopen standard, it can be more complicated and prone to bus conflicts. What would you like to use your second port for? I think it would be best to get basic CANopen communication up and running before implementing multiple ports.
Also, Larry mentioned that you were using the broadcast mode to transmit and receive SDOs. I was concerned that this method would cause bus conflicts. Essentially, if all nodes receive an SDO request, and all respond to it at the same time, you may have conflicts which may result in unexpected data. Do you also receive random data when your read and write from 0x1008 and 0x100A without using the broadcast mode?
Also, the response from 0x701 may be a heartbeat message. Check the manual for your slave devices to determine if they are configured to send heartbeat messages. If so, the slave will send a heartbeat message at a specified period, which the master can interpret to determine if the node is still "alive". If the slave was configured for node guarding, the master would need to poll the slave, and then the slave would respond to the master by sending a message. With the heartbeats method, the master does not need to request the message. Message ID 700h + Node ID can be used for either heartbeats or node guarding.