There is a need for better CAN documentation
6 years 9 months ago #29532072
by maple
There is a need for better CAN documentation was created by maple
We've been using Roboteq controllers with central MCU for years, battling various communication problems like Roboteq switching to higher serial rate or micro controllers moving to 3.3V supply. Firmware v1.6 is finally mature enough so that we can port MCU code to microbasic and simplify the system enormously. However without central MCU we now need reliable communication between Roboteq nodes.
The NXTGEN user manual lists three CAN modes: RawCAN, MiniCAN and CANopen. Online microbasic manual also mentions RoboCAN.
My understanding is that in RawCAN mode setCommand/getValue are used with CF, CS and CAN to send/receive 8-byte frames with arbitrary data. This seems to be most flexible mode useful for custom protocols but not very useful for basic operations.
The documentation is confusing. For example it says ?CF copies next frame into read buffer from which ?CAN can read it. Having a dedicated "read buffer" means that ?CAN operation should be completely isolated from FIFO operation. However notes in documentation imply that using ?CAN affects what happens with incoming frames and also that read buffer can be "overwritten by a new arriving frame", which does not make sense at all. There is also no information on how to set up ListenNodeID from microbasic.
In MiniCAN mode firmware takes care of communication details by automatically sending/receiving up to 8 integer and 32 boolean values using predefined variables as data sources and targets. setCommand/getValue are used with B and VAR to read/write data variables. The exact meaning of the data is once again defined by the user. This mode is great for bi-directional communication between two nodes because it can be configured once. For more nodes the script has to re-configure ListenNodeID all the time even if each node uses its own TPDO. And again, there is no information on how to configure it from microbasic.
CANopen is great leap in complexity and requires deep knowledge of the protocol. On the other hand it only makes sense when integrating into true CANopen systems, which assumes developers are already familiar with protocol.
The documentation describes four TPDO/RPDO objects which are similar the functionality to MiniCAN and controlled in the same manner via 16 custom variables. I could not find any information on mapping other controller parameters to PDO or how to send SDO messages.
Finally RoboCAN is extremely simple extension to normal commands allowing control of remote devices. Basically, it is a way to execute exactly same commands as in "normal" microbasic script only on some other node in the network. Great idea!
Unfortunately the documentation is lacking here as well. The application note "Driving Mecanum Wheels Omnidirectional Robots" uses RoboCAN to send commands to remote controllers. However it also uses obscure "getvalue(_CL, 1) <> 273" which is not documented anywhere. There is IsCANNodeAlive function in microbasic reference. Why isn't it used here?
Also ScanCANValue looks like an attempt to provide RoboCAN alternative to MiniCAN/CANopen PDO operation. However it only supports one parameter at a time and seems rather inefficient.
Is all of the above correct summary of our CAN options? Is there any documentation that I missed with answers to these questions?
The NXTGEN user manual lists three CAN modes: RawCAN, MiniCAN and CANopen. Online microbasic manual also mentions RoboCAN.
My understanding is that in RawCAN mode setCommand/getValue are used with CF, CS and CAN to send/receive 8-byte frames with arbitrary data. This seems to be most flexible mode useful for custom protocols but not very useful for basic operations.
The documentation is confusing. For example it says ?CF copies next frame into read buffer from which ?CAN can read it. Having a dedicated "read buffer" means that ?CAN operation should be completely isolated from FIFO operation. However notes in documentation imply that using ?CAN affects what happens with incoming frames and also that read buffer can be "overwritten by a new arriving frame", which does not make sense at all. There is also no information on how to set up ListenNodeID from microbasic.
In MiniCAN mode firmware takes care of communication details by automatically sending/receiving up to 8 integer and 32 boolean values using predefined variables as data sources and targets. setCommand/getValue are used with B and VAR to read/write data variables. The exact meaning of the data is once again defined by the user. This mode is great for bi-directional communication between two nodes because it can be configured once. For more nodes the script has to re-configure ListenNodeID all the time even if each node uses its own TPDO. And again, there is no information on how to configure it from microbasic.
CANopen is great leap in complexity and requires deep knowledge of the protocol. On the other hand it only makes sense when integrating into true CANopen systems, which assumes developers are already familiar with protocol.
The documentation describes four TPDO/RPDO objects which are similar the functionality to MiniCAN and controlled in the same manner via 16 custom variables. I could not find any information on mapping other controller parameters to PDO or how to send SDO messages.
Finally RoboCAN is extremely simple extension to normal commands allowing control of remote devices. Basically, it is a way to execute exactly same commands as in "normal" microbasic script only on some other node in the network. Great idea!
Unfortunately the documentation is lacking here as well. The application note "Driving Mecanum Wheels Omnidirectional Robots" uses RoboCAN to send commands to remote controllers. However it also uses obscure "getvalue(_CL, 1) <> 273" which is not documented anywhere. There is IsCANNodeAlive function in microbasic reference. Why isn't it used here?
Also ScanCANValue looks like an attempt to provide RoboCAN alternative to MiniCAN/CANopen PDO operation. However it only supports one parameter at a time and seems rather inefficient.
Is all of the above correct summary of our CAN options? Is there any documentation that I missed with answers to these questions?
Please Log in or Create an account to join the conversation.
6 years 9 months ago #29532074
by niko
Replied by niko on topic There is a need for better CAN documentation
Hello,
First to mention that documentatio is out dated and we are working on releasing the new versions. So we need to apologise for that.
About RawCAN. As mentioned in documentation, Using RawCAN Mode, p.118 : "A FIFO buffer will capture up to 16 frames." So if frames are kept on coming the old data will be overwritten. The specific note you mention is talking about reading process and not execution of ?CAN query alone.
About ListenNodeID. You see no description about configuring listennodeid via microbasic because we consider that this should be a one time configuration in order not to mess nodes. For every configuration value you want to access via microbasic follow the following steps:
1. Go to configuration tab and load configuration.
2. Modify the configuration value you want to use and press save to controller (e.g. listen node id).
3. Go to run tab, where you will see in the bootom of console the respective command (e.g. ^CLSN 1).
4. Go to script tab and use setconfig/getconfig functions using the commands with a _ character in front (e.g. seconfig(_CLSN, 2)).
About CANOpen. CANopen is an open standard protocol and our implementation is mainly headed for applications where PLCs or other similar devices support this protocol. You cannot map other parameters to PDOs. But you can write a script which will get/set values from PDOs variables to/from the desired ones. SDOs can be found in TABLE 16 p.129-134 in user manual. Below are the errata of this table:
0x2000 01 Set Motor Command, ch1 CG CANGO
02 Set Motor Command, ch2
0x2121 00 Read Magsensor Gyroscope MGY MGYRO
0x2122 00 Read Motor Status Flags FM MOTFLAG
0x2123 01 Read Hall Sensor States, ch1 HS HSENSE
02 Read Hall Sensor States, ch2
About RoboCAN. getvalue(_CL, 1) is similar to ISCANNodeALive(1). We suggest you using the latter, since it is simpler. Did you see this article ?
In the above mentioned article it says about ScanCANValue that "the buffer can store up to 32 values.". So we think that it is more efficient than the TPDOs, since there is no need for scripting, too.
At your disposal for any other question, or if something is still unclear.
First to mention that documentatio is out dated and we are working on releasing the new versions. So we need to apologise for that.
About RawCAN. As mentioned in documentation, Using RawCAN Mode, p.118 : "A FIFO buffer will capture up to 16 frames." So if frames are kept on coming the old data will be overwritten. The specific note you mention is talking about reading process and not execution of ?CAN query alone.
About ListenNodeID. You see no description about configuring listennodeid via microbasic because we consider that this should be a one time configuration in order not to mess nodes. For every configuration value you want to access via microbasic follow the following steps:
1. Go to configuration tab and load configuration.
2. Modify the configuration value you want to use and press save to controller (e.g. listen node id).
3. Go to run tab, where you will see in the bootom of console the respective command (e.g. ^CLSN 1).
4. Go to script tab and use setconfig/getconfig functions using the commands with a _ character in front (e.g. seconfig(_CLSN, 2)).
About CANOpen. CANopen is an open standard protocol and our implementation is mainly headed for applications where PLCs or other similar devices support this protocol. You cannot map other parameters to PDOs. But you can write a script which will get/set values from PDOs variables to/from the desired ones. SDOs can be found in TABLE 16 p.129-134 in user manual. Below are the errata of this table:
0x2000 01 Set Motor Command, ch1 CG CANGO
02 Set Motor Command, ch2
0x2121 00 Read Magsensor Gyroscope MGY MGYRO
0x2122 00 Read Motor Status Flags FM MOTFLAG
0x2123 01 Read Hall Sensor States, ch1 HS HSENSE
02 Read Hall Sensor States, ch2
About RoboCAN. getvalue(_CL, 1) is similar to ISCANNodeALive(1). We suggest you using the latter, since it is simpler. Did you see this article ?
In the above mentioned article it says about ScanCANValue that "the buffer can store up to 32 values.". So we think that it is more efficient than the TPDOs, since there is no need for scripting, too.
At your disposal for any other question, or if something is still unclear.
Please Log in or Create an account to join the conversation.
6 years 9 months ago - 6 years 9 months ago #29532076
by maple
Replied by maple on topic There is a need for better CAN documentation
Thanks a lot for prompt reply. Yes, I somehow missed that document on RoboCAN, otherwise the choice would be clear for me. RoboCAN covers all our needs for the moment. And that documentation is quite clear and extensive. Great job!
I think I now have all I need to proceed with implementation. Not sure if all our business logic will fit into one controller, but that is the beauty of having a network - we can do distributed processing by splitting computational load between nodes. Something we could not do with central MCU before.
However I do have couple more questions, just to make sure I got your answers right and not ask again later.
RawCAN - so, when new frame arrives and FIFO is full, will it a) push out oldest frame from FIFO, b) override the most recent frame in FIFO or c) be ignored and lost?
The statement "New CAN frames will not be received by the controller until a ?CAN query is sent to read the header or any other element" seems to imply option (c).
On the other hand the description of ?CF query says "copy the oldest frame into the read buffer, from which it can then be accessed" and "After a frame has been moved to the read buffer, the header, bytecount and data can be read with the ?CAN query". To me this sounds like ?CAN should not have any effect on FIFO, since it works with "read buffer" only, and ?CF is the only command that moves data from FIFO (thus freeing space for next frame) to read buffer.
ListenNodeID - if this is one time configuration then one controller can only receive messages from one other controller. Is this correct? We often have 3 to 4 controllers in one device. Assuming one of them will be master this won't work for us. Nice trick on peeking the configuration command in console output, btw.
CANopen - I've seen Object Dictionary table. But how do I use SDO from microbasic?
RoboCAN - You say it is more efficient than TPDOs. Does it mean that RoboCAN is not a layer built on top of other, more standard protocols (like CANopen) but completely different proprietary protocol? Or did you simply mean that using it is easier than TPDOs?
Thanks again!
I think I now have all I need to proceed with implementation. Not sure if all our business logic will fit into one controller, but that is the beauty of having a network - we can do distributed processing by splitting computational load between nodes. Something we could not do with central MCU before.
However I do have couple more questions, just to make sure I got your answers right and not ask again later.
RawCAN - so, when new frame arrives and FIFO is full, will it a) push out oldest frame from FIFO, b) override the most recent frame in FIFO or c) be ignored and lost?
The statement "New CAN frames will not be received by the controller until a ?CAN query is sent to read the header or any other element" seems to imply option (c).
On the other hand the description of ?CF query says "copy the oldest frame into the read buffer, from which it can then be accessed" and "After a frame has been moved to the read buffer, the header, bytecount and data can be read with the ?CAN query". To me this sounds like ?CAN should not have any effect on FIFO, since it works with "read buffer" only, and ?CF is the only command that moves data from FIFO (thus freeing space for next frame) to read buffer.
ListenNodeID - if this is one time configuration then one controller can only receive messages from one other controller. Is this correct? We often have 3 to 4 controllers in one device. Assuming one of them will be master this won't work for us. Nice trick on peeking the configuration command in console output, btw.
CANopen - I've seen Object Dictionary table. But how do I use SDO from microbasic?
RoboCAN - You say it is more efficient than TPDOs. Does it mean that RoboCAN is not a layer built on top of other, more standard protocols (like CANopen) but completely different proprietary protocol? Or did you simply mean that using it is easier than TPDOs?
Thanks again!
Please Log in or Create an account to join the conversation.
6 years 9 months ago #29532083
by niko
Replied by niko on topic There is a need for better CAN documentation
RawCAN: You are right data are ignored.
ListenNodeId: It is up to you to do whatever you want. Usually in MiniCAN/RawCAN networks there is one master and many slaves.
CANOpen: You cannot use SDOs with microbasic.
RoboCAN: It is a proprietary protocol. In previous post you asked how to map other values in TPDOs. With RoboCAN you can head exactly to the value you want.
ListenNodeId: It is up to you to do whatever you want. Usually in MiniCAN/RawCAN networks there is one master and many slaves.
CANOpen: You cannot use SDOs with microbasic.
RoboCAN: It is a proprietary protocol. In previous post you asked how to map other values in TPDOs. With RoboCAN you can head exactly to the value you want.
The following user(s) said Thank You: maple
Please Log in or Create an account to join the conversation.
4 months 1 week ago #29536175
by DblS
Replied by DblS on topic There is a need for better CAN documentation
I know this post is a few years old. Niko, you stated "RoboCAN: It is a proprietary protocol. In previous post you asked how to map other values in TPDOs. With RoboCAN you can head exactly to the value you want.
How exactly do you map and use the data from TPDO's using RoboCAN? I've managed to do it with miniCAN as TPDO's are automatically mapped to _VAR's.
How would I read the data from say, Node 5 TPDO at index 0x185 using RoboCAN and MicroBasic Scripting?
Dbls
How exactly do you map and use the data from TPDO's using RoboCAN? I've managed to do it with miniCAN as TPDO's are automatically mapped to _VAR's.
How would I read the data from say, Node 5 TPDO at index 0x185 using RoboCAN and MicroBasic Scripting?
Dbls
Please Log in or Create an account to join the conversation.
Time to create page: 0.090 seconds
