CANopen question

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

CANopen question

John Dammeyer

Suppose a technician accidentally installs two CANOpen motor drives with the same nodeID.  Or two pressure transducers or Inclinometers.  Anything that requires an external terminal and dongle to program the target ID. 

 

Is there a standardized way to ask nodes to report their NodeID when there may be two on the bus with the same ID?

 

Thanks

John Dammeyer

 

"ELS! Nothing else works as well for your Lathe"

Automation Artisans Inc.

http://www.autoartisans.com/ELS/

Ph. 1 250 544 4950

 

 

Reply | Threaded
Open this post in threaded view
|

Re: CANopen question

Torsten Gedenk
>Suppose a technician accidentally installs two CANOpen motor drives with the same nodeID.  
>Or two pressure transducers or Inclinometers.  Anything that requires an external
>terminal and dongle to program the target ID.  
According to the CANopen specification this situation shall not happen and the technician shall take care that it does not happen.
Having 2 or more CANopen devices with the same node-ID is not allowed.

If you compare it to office Ethernet it is the same as 2 computers with the same fixed IP address.
If a network administrator configures 2 computers with the same IP address, he has done something wrong.
Well, in your office you maybe use DHCP to dynamically assign IP addresses and CANopen offers Layer Setting Services (LSS) as defined in CiA 305.

LSS may be used to configure CANopen node-IDs dynamically if both the master and the slaves support it.
So in modern installations it is recommended to use LSS in order to avoid scenarios as mentioned above.
 
>Is there a standardized way to ask nodes to report their NodeID when there may be two on the bus with the same ID?
LSS also offers a service to query the node ID from devices but you need to know the vendor ID, product code, revision number and serial number (all in object 0x1018) to query it.

Besides LSS there is no standardized way to handle this situation.

A device that receives a CAN-ID that it usually should send - a scenario that might be caused by the same node id - may send the Emergency Messages with the Error Code 0x8150 "CAN-ID collision", but this behaviour is not mandatory and so only very little devices support it.

Best Regards
   Torsten Gedenk

-------------------------------------------------------------------------
emtas - your embedded solution partner
-------------------------------------------------------------------------

--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

FW: [CANLIST] CANopen question

Corey, Richard-2
In reply to this post by John Dammeyer

I don’t know “the CANopen Way”, but years ago I set up a command that told every node to reply once with its node ID, after waiting a time dependent on the ID plus a random extra delay.  I  “hoped” that any duplicate nodes would start transmitting more than a fraction of a bit-time apart.  It might have been smart to turn retries off for that transmission, but I did not bother with that. 

 

It wasn’t a robust method and took some seconds to run, but we used it during development to confirm that people had set all the ID switches correctly. 

 

For the real machine, the “chorus reply” was not needed.  It was sufficient to detect the absence of any expected node.  If one node was missing, we only had to look at the physical location of the “missing” node to find the incorrect ID switch setting (or a dead node or bad connector).

 

The real machine had a fixed list of nodes that were expected and needed – we didn’t have to support a variable number of “drop-in” nodes.

 

We also had an LED on each node, that toggled each time a message was received.  If some unexpected node answered and I wasn’t sure what-all was SUPPOSED to be installed on that particular day during development, I would set up a repeating command to the unexpected node ID, so I could walk around and look for the toggling LED.

 

Primitive stuff.  The opposite of a standardized approach.

 

 

Rick Corey  | Software Engineer | Crane Aerospace & Electronics, Lynnwood WA 98046

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of John Dammeyer
Sent: Friday, February 12, 2016 10:00 AM
To: [hidden email]
Subject: [CANLIST] CANopen question

 

Suppose a technician accidentally installs two CANOpen motor drives with the same nodeID.  Or two pressure transducers or Inclinometers.  Anything that requires an external terminal and dongle to program the target ID. 

 

Is there a standardized way to ask nodes to report their NodeID when there may be two on the bus with the same ID?

 

Thanks

John Dammeyer

 

"ELS! Nothing else works as well for your Lathe"

Automation Artisans Inc.

http://www.autoartisans.com/ELS/

Ph. 1 250 544 4950

 

 

 


Connect with us on LinkedIn!

We value your opinion! Please click the survey link to tell us how satisfied you are: http://www.craneae.com/VOC

Crane Aerospace & Electronics Confidentiality Statement:
The information contained in this email message may be privileged and is confidential information intended only for the use of the recipient, or any employee or agent responsible to deliver it to the intended recipient. Any unauthorized use, distribution or copying of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify the sender immediately and destroy the original message and all attachments from your electronic files.


Reply | Threaded
Open this post in threaded view
|

RE: CANopen question

Bram Kerkhof
In reply to this post by John Dammeyer

In SAE J1939 you have the address claim message specifically for this purpose, but as it is an optional part there are a lot of manufacturers who just don’t bother to implement the specification making it effectively useless in a lot of cases.

 

The simplest implementation would be that the node receiving a message from a source address that it considers to be its own goes in some kind of error state.

Signaling that over the CAN network itself is hard, due to the limitation that no CAN id should be shared between nodes.

 

cheers,

Bram

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of John Dammeyer
Sent: vrijdag 12 februari 2016 19:00
To: [hidden email]
Subject: [CANLIST] CANopen question

 

Suppose a technician accidentally installs two CANOpen motor drives with the same nodeID.  Or two pressure transducers or Inclinometers.  Anything that requires an external terminal and dongle to program the target ID. 

 

Is there a standardized way to ask nodes to report their NodeID when there may be two on the bus with the same ID?

 

Thanks

John Dammeyer

 

"ELS! Nothing else works as well for your Lathe"

Automation Artisans Inc.

http://www.autoartisans.com/ELS/

Ph. 1 250 544 4950

 

 

Reply | Threaded
Open this post in threaded view
|

Re: CANopen question

koppe
In reply to this post by John Dammeyer
Hello John,

there is no standard way in CANopen (similar to J1939 Address Claiming)
for resolving node-ID collisions.

However, there is the possibility to send an EMCY message with code
8150h which denotes a CAN identifier collision. We use this EMCY
code in our CANopen protocol stack in order to signalize collision
of Tx PDOs, SDOs, etc. It does not automatically solve the conflict,
but it helps to investigate the source of the problem (which is the
system integrator).




Greetings,
Uwe



---------------------------------------------------------------------
MicroControl GmbH & Co. KG
Junkersring 23, 53844 Troisdorf, Germany

Homepage: www.microcontrol.net
Facebook: www.facebook.com/MicroControl.net
Twitter : http://twitter.com/_microcontrol_
---------------------------------------------------------------------
--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

RE: CANopen question

John Dammeyer
Thanks everyone.  
It's as I suspected.  

My modules do have a unique serial # in the DS1822 temperature/serial_number
device.  Back in 2009 I used that to good advantage when I accidentally set
50 nodes to ID #78.  However, that protocol had a global address message
type along with a command that told a lamp to change its node ID to N if the
serial # matched.  Fortunately we had a list of serial #'s.

Some thinking out loud here.

My NMT master doesn't change the system from PRE-OPERATIONAL until it's
received a heat beat from each node that has to be installed.  Some nodes
are optional or non-critical so they don't factor into this.    When and if
they do show up and the system is OPERATIONAL they are told to go
OPERATIONAL.

Both modules have identical firmware.  They both boot at the same speed so
odds are they'd send the their 0x7nn state messages at the same time.  I
could delay this but the NMT messages don't contain anything that lets the
master know they are different nodes so that's pointless.

Your idea to use the EMCY 8150 is a good one although ideally I'd like to
get this before there is a collision and 8150 identifies a COB ID collision.
I could use 8101 for example.

Since there is the OD Entry  EMCY Inhibit time I could use the serial # as
the inhibit time and force each node to send the
EMCY+NodeID 8  81, 50, ErrorReg, 00, nn, nn, nn, nn  
on the request to GO OPERATIONAL.

For a healthy network without node duplication the system starts up as
normal without any additional delay and broadcasts serial #'s

For an unhealthy network, both nodes might still send a 0x720 heart beat but
the master's NMT go OP-MODE will also trigger a time skewed EMCY message
holding the Serial #.   Or maybe once the nodes just get the first 0x701 NMT
message from the master since that tells them it's awake.

On start-up my nodes should report their serial # with no chance of
collision.  The problem is the timer value has to be large enough to not
result in the two messages being armed for transmission while waiting for
access to the bus.  Then I have a collision again.

Imagine a serial # 23FA05 and 23FB05.  They are different by 256 which at
1uS resolution is less than one message at 250kbps.  Use a longer time
period and it could take a long time before the messages show up since the
DS1822 numbers go randomly from 1xxxxx to 45xxxx
I could do some sort of hash on the serial # down to 1 byte and use that as
a 1mS time delay.  There's still the chance of a collision but it's lower.

Now if the system master gets two EMCY messages from what appears to be the
same node but with different serial #'s it can flag an error.  It can't
assign a different ID automatically since it doesn't know which physical
node is which.  

At this point the technician will be required to physically assess which
node serial # is in which location before re-assigning node IDs.  But at
least I'd know, and an EMCY 8150 message from the system master with a node
ID (non-zero) preceding the serial # could force the node with that serial #
to change its node ID to the new NodeID.

A bit clumsy but would probably work.

John Dammeyer



> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Uwe Koppe
> Sent: February-14-16 8:46 AM
> To: [hidden email]
> Subject: Re: [CANLIST] CANopen question
>
>
> Hello John,
>
> there is no standard way in CANopen (similar to J1939 Address Claiming)
> for resolving node-ID collisions.
>
> However, there is the possibility to send an EMCY message with code
> 8150h which denotes a CAN identifier collision. We use this EMCY
> code in our CANopen protocol stack in order to signalize collision
> of Tx PDOs, SDOs, etc. It does not automatically solve the conflict,
> but it helps to investigate the source of the problem (which is the
> system integrator).
>
>
>
>
> Greetings,
> Uwe
>
>
>
> ---------------------------------------------------------------------
> MicroControl GmbH & Co. KG
> Junkersring 23, 53844 Troisdorf, Germany
>
> Homepage: www.microcontrol.net
> Facebook: www.facebook.com/MicroControl.net
> Twitter : http://twitter.com/_microcontrol_
> ---------------------------------------------------------------------
> --
> Archives and useful links: http://groups.yahoo.com/group/CANbus
> Subscribe and unsubscribe at www.vector.com/canlist/
> Report any problems to <[hidden email]>

--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[hidden email]>