CAN Open - on a mission to commission
14 June 2022 by Chris Woodhams
Introduction
We thought it would be good to share some details of a recent experience with some commissioning we did relating to some devices controlled using CAN. There are a number of different CAN protocols, this isn’t a post to describe them all, there is plenty of resources out there on this. The devices we were communicating with used the CANOpen protocol, a really well defined and established communication protocol. It was developed in the 90s, initially by Bosch, and then handed over to the CAN in Automation (CiA) association.
So that is a brief background into what we were working with, now to get them working as we need them to!
Hardware Manual
First things first, RFM (Read the F**King Manual!), which in this case, and I think not uncommon when communicating with devices, was not as easily said than done. The manual was very good, gave great overviews of all the different aspects of the protocol and how to setup the device. What it didn’t do, and in all fairness probably couldn’t, was explain how to resolve some of the detailed challenges we needed to resolve.
For example, we needed to change the method used to receive and transmit message and you would think that you could just change the relevant parameter to achieve this. What wasn’t included in the manual was that you needed to change bit 8 on one parameter, then update the relevant parameter, then change bit 8 of the other parameter back.
Software Setup
The software needed to be setup to read the relevant messages (frames) from the devices, which we did using a DBC file and the NI-XNET drivers. Setting up the DBC file was a case of interpreting the bits and bytes of the messages we needed access to from the manual and setting them up using the NI-XNET Database Editor, which is a really intuitive tool.
So we needed to setup each frame with the signals relative to that frame and we aligned the frames with the a PDOs (Process Data Object) for the device. This then needed accessing in LabVIEW, which was a case of utilising the NI-XNET drivers to, in its simplest form, initialise the frame, read\write from\to it and make sure you close it when you are done. One thing to be aware of, which sounds obvious, is to align the data you write to a frame with the bit order of it in your DBC file.
Help along the way
There are some great resources out there to learn all about CAN, one that I would highly recommend that was recommended to me is Brian Hoovah’s blog series, definitely one to check out.
Another invaluable asset is your network, we have always put the community high up in our priorities. It was awesome to be able to call on them (thanks Steve Watts!) in our moment of need. Community isn’t just about these moments when you need support, it’s about giving something back (what we do with our user group) and having a bit of a geek out occasionally, GDevCon 3 is coming!!
One of the supporting tools we used for debugging the CAN messages was a Picoscope, which was a great asset to integrate the signals. There are loads of resources on this with a little googling, but here is a starter.
Finally, we were lucky that the manufacturer of the devices, Nanotech, had really fantastic support. Fast to respond with really good practical advice, even offering to do Teams sessions to provide support.
So, if you are embarking on a mission with a CAN device, hopefully this might give you some help, but please share your experiences!
Back to Blog listings