RE: CANopen question

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: [email protected] [mailto:[email protected]] On
> Behalf Of Uwe Koppe
> Sent: February-14-16 8:46 AM
> To: [email protected]
> 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 <[email protected]>

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