implementing CANopen/MODbus on a micro controller

[Simon]

I work mainly with motors that are driven from some custom ECU I design. It seems that having analogue/PWM inputs/outputs to motor drives is going out of fashion ang everything uses CANopen or MODbus.

While I am no stranger to RS485 and have been around CAN these have always been custom protocols. CANopen and MODbus are of a much higher level themselves (to the point that I don't recognise CANopen as anything like the hardware implementation of CAN) and will require significant amounts of code to run the system.

Before I fall down a deep hole, any advice on doing this? I usually use a SAMC micro controller, but really I am interested in the process of getting it up and running on "a" micro controller.

[nctnico]

I have been dabbling a bit with Canopen recently. It looks complicated but it turns out that it is not the case.  The motor controller I had to talk with has a bunch of registers you can read / write to. The CAN ID space is divided into several blocks where the high bits are the function (read / write / response) and the lower 7 (IIRC) bits the device address. The register and data are inside the CAN data payload.

In the end my application ended up being much like regular CAN operation: repeatedly writing data to the motor controller.

[tszaboo]

I've some experience with modbus. It's a controller that has to connect to different type of actuators, systems, and set parameters. It's kinda like writing and reading memory locations remotely. But then comes the manufacturer dependent part, each device acts a bit differently, and restrictions come in (don't write here within 20 ms of writing here, and so on). It's a very complicated firmware.
Honestly, depending on how many systems you want to support, and how flexible you want to have it, I don't think you want to all program this in C. For me I think it was a mistake to go with a simple microcontroller. I would probably go now with a basic microprocessor with a single core, running small linux. So the script for modbus is in a script language, easy to modify, don't need to build it every time you want a small parameter change. And you can SSH into the system and dump all data.
But then again, if you have a fixed system, with small amount of components, and you only want to run a closed loop motor controller, probably a simple microcontroller would work.

[Simon]

From wikipedia:

The SDO protocol is used for setting and for reading values from the object dictionary of a remote device. The device whose object dictionary is accessed is the SDO server and the device accessing the remote device is the SDO client. The communication is always initiated by the SDO client. In CANopen terminology, communication is viewed from the SDO server, so that a read from an object dictionary results in an SDO upload and a write to a dictionary entry is an SDO download.

I guess that is the mess you get when some idiot decides we can't use master/slave terminology and conventions anymore.

[newbrain]

I guess that is the mess you get when some idiot decides we can't use master/slave terminology and conventions anymore.

Yes, and the CiA (CAN in Automation) group is extra 'woke', because they published the "rainbow" specifications.
What a load of
The client server abstraction exists since...well probably since forever.
DHCP, NETCONF, FTP, TLS just to mention the client/server protocols I worked with today on my job.

Client server language has been there for SDO at least since 2011, and can be found in 2003 drafts.

[Siwastaja]

I have been dabbling a bit with Canopen recently. It looks complicated but it turns out that it is not the case.  The motor controller I had to talk with has a bunch of registers you can read / write to. The CAN ID space is divided into several blocks where the high bits are the function (read / write / response) and the lower 7 (IIRC) bits the device address. The register and data are inside the CAN data payload.

This. The biggest hurdle will be getting over the initial shock. CANopen is loved by complexity-loving managers, and documentation of such systems is sometimes nonexistent "because it's a standard so everybody knows everything about it by heart for sure". All you would need is a simplified document (in less than 10-20 pages) which shows the exact CAN frames to be sent/expected without having to wonder if all these 5000 pdf documents totaling 500 000 pages on the CANOpen website are relevant or not.

[Simon]

This. The biggest hurdle will be getting over the initial shock. CANopen is loved by complexity-loving managers, and documentation of such systems is sometimes nonexistent "because it's a standard so everybody knows everything about it by heart for sure". All you would need is a simplified document (in less than 10-20 pages) which shows the exact CAN frames to be sent/expected without having to wonder if all these 5000 pdf documents totaling 500 000 pages on the CANOpen website are relevant or not.

Yea, this is my worry. The documentation for the motor seems more intent on trying to half tell me about CANopen rather than just say: this ID has this data or whatever, like good old J1936. The motor documentation uses the terms master slave, I beleive the master is the client, the slave is the server, I think there are about 3 interpretations as to how that came about but meh. I thought CAN was multimaster! it's just a case of who is the one with the smallest ID that wins, because size does not matter - or does

[nctnico]

This. The biggest hurdle will be getting over the initial shock. CANopen is loved by complexity-loving managers, and documentation of such systems is sometimes nonexistent "because it's a standard so everybody knows everything about it by heart for sure". All you would need is a simplified document (in less than 10-20 pages) which shows the exact CAN frames to be sent/expected without having to wonder if all these 5000 pdf documents totaling 500 000 pages on the CANOpen website are relevant or not.

Yea, this is my worry. The documentation for the motor seems more intent on trying to half tell me about CANopen rather than just say: this ID has this data or whatever, like good old J1936. The motor documentation uses the terms master slave, I beleive the master is the client, the slave is the server, I think there are about 3 interpretations as to how that came about but meh. I thought CAN was multimaster! it's just a case of who is the one with the smallest ID that wins, because size does not matter - or does

CANopen uses CAN as a point-to-point bus so you can send queries to a specific device on the bus. The device will then put a message on the bus with the response to the query. That is different compared to how CAN is typically used. For a 'real' implementation you'd send the queries at regular intervals which makes the device send data on the bus as regular intervals.

The motor controller I had to deal with also allows to set it up so it will send data by itself at regular intervals but for my application this was not so useful.

[Kjelt]

Motor control as in servo control with rapid movements? or in slow motor control as in spindlesettings?
First one modbus is out: too slow.
For the first one take a look at Ethercat and find out it is a large can of worms that will keep you busy for a year.

[nctnico]

Motor control as in servo control with rapid movements? or in slow motor control as in spindlesettings?

In my case it is only about 'spindle settings' as you call it.

[Simon]

I don't need fast communication, I am only telling a drive to do a certain speed and torque and getting the speed and torque back. Either would do, although once I crack CAN on my SAMC the CAN controller will do a lot of what I'd have to do in software for RS485.

Yes it seems pretty silly to use it as master/slave, that is not how CAN was conceived, doing that wastes bandwidth. The idea is that each device transmits, anyone interested in what the device has to say or more to the point the data in that message of a certain message ID gets the data. It sounds like they first abused CAN into RS485 and then went, "oh!" and put in a mode that allows it to work as intended.

Advice I was given was to not load a can bus to more than 70%, if you run it master/slave mode so achieve 100% load which you won't anyway you will see something like 50% of the actual bandwidth used, this is why CAN was designed as "multimaster" I guess.

[Dave]

I guess that is the mess you get when some idiot decides we can't use master/slave terminology and conventions anymore.

Is there any chance you could refrain from randomly shitting on people for making design decisions that you can't comprehend?

[Simon]

I guess that is the mess you get when some idiot decides we can't use master/slave terminology and conventions anymore.

Is there any chance you could refrain from randomly shitting on people for making design decisions that you can't comprehend?

same article has master/slave and client/server references, I guess they missed some when they decided to clean up. So what did I miss?

[newbrain]

same article has master/slave and client/server references, I guess they missed some when they decided to clean up. So what did I miss?

The specification text, for one thing.
It contains both C/S and M/S terminology, SINCE 2003 DRAFT. Last revision I can find is 2011, still both present.

Honestly, I'm glad we have a clear and reasonable guideline where I work, and one has to follow it.
M/S is frowned upon, in new material. If it's in an existing standard we use it (until it's updated).
Master on its own e.g. repo branch is OK.
Same thing with black and white.
Pure and simple decency, and avoiding making uncomfortable persons with a sensibility different from yours.

[nctnico]

Please stop the 'woke' stuff. I've had enough of that. Putting a different label on something or someone doesn't make a fundamental problem go away.

[Dave]

I don't see it as a "sensitive word" political correctness bullshit in this case. In my eyes, master and slave are simply unfit words in this context.

Master and slave are applicable in the context of SPI or I2C, for example. The master dictates when something is going to be read and which register it is going to be read from and also how the bits are going to be shifted onto the data lines (clock generation by master). The slave just spits out the data as commanded.

In the context of CANopen, you have request messages with OD indices and subindices coming from the client, the server processes them at its own pace, and spits out the result if it wants to. This is directly analogous to how the internet works. You request a website from the server and it replies to your query. Would you call your computer a master in this case, and CloudFlare's server a slave?
______________________________

Alright, let's get back to the thread at hand.

I have coded a limited-functionality CANopen server for a small project in the past. It allowed for reading from/writing to the OD, and using that you were able to configure what the PDOs would be spitting out on a regular basis. All of the NMT node control, sync, emergency messages (everything that wasn't 100% necessary) was simply left out. And even without all the spit and polish, it took quite some effort to make it happen.
Would I do it again? Probably not.

At work, we purchased a CANopen library from Port GmbH. The library was device-specific, as it interacted directly with the registers of the chosen microcontroller.
Several attempts were made to adapt the code to use our hardware abstraction library interfaces and make it portable. Every attempt eventually failed, because the code is horrendously convoluted, with files in the several thousand LOC territory, no naming convention whatsoever, etc.
Fair disclosure: We're using an old version of their CANopen library, so I don't know the state of what they're selling now. They might have restructured things and improved them in the meantime.

Your best route would probably be to buy something ready-made, but shop around and request some trials, as quality might vary.

[Simon]

At this point I am successfully confused as to why there are two existing conventions in the same document, is it about wanting to change it out of fear of upsetting people or are there two sub-standards / methods of operation?

this is why trying to change something like this is stupid. There is a reason why we still use the antiquated "feet" to measure altitude, yes even as a brit I will convert it to metres in my head, but there is a very good reason why we stick with feet, because what do you think will happen if in aviation we try to switch? accidents galore.

As for the terms, they are still normal words, they are not deemed swear words and the concep of slavery is alive and well, it's not a black persons thing etc, slave actually comes from the name of the slavic people, and way back in history most white cultures have enslaved other white cultures and there are still slaves to this day, yes, even in the UK, we call it modern slavery just to make it clear we are not talking about history, but right now, in the UK there are several thousand slaves! yes this is illegal, but it does not stop criminals, and I am sure those people would rather we don't eliminate from our language the word that describes their plight that I very much hope some of my tax money goes into to free them.

As an abstract concept I don't see the issue. The issue IU have is that knowing that this whitewashing of stuff is going on, I don't know if finding two pairs of terminology is down to the fact that someone has tried to "update" it, or that there are two sets of words to describe two modes of operation, thankfully no planes will fall out of the sky....

Black/White? what is the problem? one is the lightest colour one the darkest.

So now that it's clear that the waters will be even muddier, where do I start?

i am trying to drive based on this document: https://www.maxongroup.com/medias/sys_master/root/8884070252574/IDX-Communication-Guide-En.pdf

[Dave]

CiA 301 (page 19 onwards) describes three different relationships between CAN nodes: Master/Slave, Server/Client and Producer/Consumer. Seems reasonable enough.

What I was describing earlier with OD requests and responses does seem to agree with the explanation of Server/Client, but I did neglect the possibility of the other two relationships.

[Simon]

I see that as stated before they have made one hec of a mess here. This is CANbus. The natural working of CANbus is the push model, yes we are onto the forth pair of terminology for something that at an electrical level works in one way only, a device sends a message, whomever is interested uses the data received.

it looks like there a lot is going on within the poor little CAN protocol.

[Simon]

At work, we purchased a CANopen library from Port GmbH. The library was device-specific, as it interacted directly with the registers of the chosen microcontroller.
Several attempts were made to adapt the code to use our hardware abstraction library interfaces and make it portable. Every attempt eventually failed, because the code is horrendously convoluted, with files in the several thousand LOC territory, no naming convention whatsoever, etc.
Fair disclosure: We're using an old version of their CANopen library, so I don't know the state of what they're selling now. They might have restructured things and improved them in the meantime.

Your best route would probably be to buy something ready-made, but shop around and request some trials, as quality might vary.

It looks like they are now platform independent: https://www.port.de/en/products/canopen/software/ansi-c-canopen-library.html

[Dave]

I see that as stated before they have made one hec of a mess here. This is CANbus. The natural working of CANbus is the push model, yes we are onto the forth pair of terminology for something that at an electrical level works in one way only, a device sends a message, whomever is interested uses the data received.

it looks like there a lot is going on within the poor little CAN protocol.

You again go shitting on other engineers without understanding the fundamentals behind the things you're bashing. Will you stop it already?

Master/Slave, Server/Client, Publisher/Subscriber are all just abstract descriptions of how two entities interact with each other when communicating. They're descriptions that humans use to be able to more easily create a mental model of how some communication network works.
Read up on the OSI model. It's a common way of abstracting communication protocols into several layers for better understanding of a protocol. You will find that communication stacks are often written in a way that the code is split into logical blocks which cover one or more of the layers of abstraction in the OSI model. The data link layer of CAN may be inherently publisher/subscriber-based, but that does NOT mean that all of the protocols riding on top of it are like that.

To further drive this message home, here is an example of UDS, a diagnostic protocol that you will usually find in the automotive world.

The exact same protocol can be used on five different physical communication buses: CAN, FlexRay, Ethernet, K-line and LIN. As long as the transport layer can pack the data in a way that is suited to the limitations of the lower layers, it doesn't matter which protocol is riding on top and which relationship the respective protocol is using between two devices.

[Simon]

I see that as stated before they have made one hec of a mess here. This is CANbus. The natural working of CANbus is the push model, yes we are onto the forth pair of terminology for something that at an electrical level works in one way only, a device sends a message, whomever is interested uses the data received.

it looks like there a lot is going on within the poor little CAN protocol.

You again go shitting on other engineers without understanding the fundamentals behind the things you're bashing. Will you stop it already?

I'm just struggling to keep up, that is all. I look at this from the perspective of using just CAN and I wonder how much of a job this will be. Remember I need to do all this (potentially it's not decided yet) just to talk to 2 motors mere millimeters away from my control system so that I can set a speed and torque and so that I can read a speed and torque. Unfortunately the motor manufacturer only has an option to input speed and torque as analogue voltages but no return signals an that is a separate version of the motor that does just "I/O", CANopen and Ethercat are two other separate part numbers. I know that for more information a coms bus makes sense.

I can see that actual data throughput must be quite a low percentage. The hardware layer of CAN already has nearly 50 bits for a message before you get to put the 64 bits of data in. The CAN ID will address the device, 24 bits are used to address a single variable if I have understood correctly although that is as much as I have had time to go into.

what I am also saying is that this protocol is obviously used over CAN just because CAN was probably already prevalent and so on the one hand it just had to be made to work on the existing physical layer of choice but also that the physical layer could have lent more to the protocol if it was specifically designed for CANopen but it was not. Back in the day CAN 2.0 was devised for J1939 with the upgrade in ID numbers from 11 to 29, if it were not for J1939 CAN 2.0 would not exist. Bosch were obviously thinking ahead and when CAN 1.0 was created with some wiggle room. I am sure if you ask them they did not envision CAN being used to carry anything so complex. But someone has made it work.

At the moment I am trying to understand how much work this could be so that I can outline it to my boss in terms he will understand.

[Siwastaja]

Well, when you have to interface with devices made with bloated mindset and total misunderstanding what OSI model is and what it isn't*, you should allocate for at least half a man-year for the task. It's the cost of operating with such bullshit companies. If they make an exceptionally good motor controller, maybe it's worth it. Or maybe they offer some kind of simpler interface, or a good summary documentation/examples which manages to circumvent the complexity. Maybe the CANopen bullshit is just for managers, and there is a backdoor for engineers. But if not, I would recommend picking another motor controller with simple, less layered interface which comes with a protocol documentation where a few pages fully describe how to set torque, speed etc.

*) OSI is considered as some sort of generic ideology of "having layers", but it is not as such. OSI is an actual failed protocol stack which is not in use anywhere. It is especially poor fit as a generic layer model because the seven layers almost never fit cleanly any real-world protocol stack, only causing confusion. Protip: just explain the layers as layers, as many as you need for the stack you are discussing, without forcing them through the OSI layer naming scheme.

In the end, much of being competent is seeing through of all technomarketing bullshit and see if the core technology works out or not. Sometimes alarmingly complex interfaces are actually not that bad; or vice versa.

[nctnico]

Well, when you have to interface with devices made with bloated mindset and total misunderstanding what OSI model is and what it isn't*, you should allocate for at least half a man-year for the task. It's the cost of operating with such bullshit companies. If they make an exceptionally good motor controller, maybe it's worth it. Or maybe they offer some kind of simpler interface, or a good summary documentation/examples which manages to circumvent the complexity. Maybe the CANopen bullshit is just for managers, and there is a backdoor for engineers. But if not, I would recommend picking another motor controller with simple, less layered interface which comes with a protocol documentation where a few pages fully describe how to set torque, speed etc.

In the end it all comes down to sending a couple of relatively simple messages over the CAN bus to set the parameter and request the status from the motor controller. There should be a document for the motor controller which describes these registers as this is specific for the motor controller. It really shouldn't take more than a few days to get this going once the documentation has been gathered. I don't really see the need to resort to using libraries for just a few settings. Perhaps a few wrapper functions are nice the have but these can be super simple.

[Siwastaja]

In the end it all comes down to sending a couple of relatively simple messages over the CAN bus to set the parameter and request the status from the motor controller. There should be a document for the motor controller which describes these registers as this is specific for the motor controller. It really shouldn't take more than a few days to get this going once the documentation has been gathered.

But if you fail to find the good documentation and instead get referred to the CANopen website and start downloading thousands of PDFs trying to understand the motor controller profiles, or start installing large libraries, you have quickly spent weeks of work time without actually getting anything done, only to eventually find out the device just implemented a few custom messages over a fairly simple protocol.