CanOpen and the things that creep up on you
So after a lengthy wait, I finally got the go-ahead to execute my long awaited CanOpen rebuild project in November. I can't go into the details of the machine itself, but I wanted to share a few critical learnings from contending with it during the installation and commissioning.
1. AC Tech Servo Drives - worked like champions, but I ran into an issue with the OEM limit switches. These were two-wire proxes, and leakage current wrought havoc on my sensitive new drives. This was addressed by installing relays on the switches, which provided a load to prevent false triggering. I also took it a step further and fully isolated the 24VDC circuit of the drives, to protect them from welding noise.
2. Wago CanOpen - When first powered up, the nodes were throwing an error onto the bus, then working fine thereafter. It turns out the node remembers the IO configuration that was connected to it the first time it was powered on, and if it sees different, generates this error before going to Operational state. Can be corrected by writing "save" to the appropriate register via SDO and CanOpen configuration software.
3. Numatics CanOpen - After powering up, the nodes would not respond to or generate any PDOs. I could see them in PCAN (software) and everything was right - operational, PDO length reflecting the physical IO attached, and no errors on communication, but also no action from them in response to input being tripped, or output being commanded.
I grabbed my original test unit and checked it, and made a suprising discovery - the test unit had all 8 bytes of it's PDOs configured. This, regardless of the fact it only had two bytes each worth of IO. I used PCAN to manually configure the PDO on the nodes of the machine, and it all came to life.
It seems that despite the Numatics node automatically detecting the IO attached, and automatically configuring it's PDO in response, it will not recognize or generate a PDO of any kind if it is, in fact, less than 8 bytes in length.
Also of note, while the corrected setup is retained, if you get a bus-off error, it will force the node to reconfigure its PDO back to defaults, ie automatic detection again. It has to be corrected manually again to correct.
4. Motoman - ah, motoman. The CanOpen cards I ordered were bad from the box. Turns out that batch had known firmware issues. After several phone calls and some frantic rushing around, converted the robots to my fallback position of Modbus TCP.
Lesson - if you are trying to do CanOpen with Motoman, at least in the US, don't. There's zero support for those cards and the cards themselves are questionable at best. Unitronics supports several protocols, just pick a different one for your robots.
5. IPD Dalsa vision system - nothing but kudos for these guys. I've using the VA31, and it runs terrific. One word of advice, use the hardware trigger input, it's just so much simpler than trying to trigger the image aquisition from modbus. Leave the data to modbus and trip the camera with a relay.
6. Unitronics - I replaced a Pentium 3 PC running Entivity Steeplechase. It included $16k worth of proprietary hardware, including a Sherlock vision card, two Motion control cards, and a devicenet card, all obsolete, all nearly impossible to obtain.
I replaced that mess with a Vision 570 PLC, and a combination of CanOpen and Modbus TCP. The PLC cost less than any single component of the original PC based system - if you could even find them anymore.
That's all for now. Thanks for reading!