RE: CANOpen NMT Modes

Thanks Heikki,

In this case I built a list of node IDs and a mask in my main controller 
that identifies which are valid nodes and which have to be issuing 
Heartbeats in PRE-OPERATIONAL module before the master will change 
everyone to OPERATIONAL.

While I was walking the dog this evening, thinking about the problems, I 
realized that I should be able to look at any node and examine the Object 
Dictionary for key items like 1017h the producer heartbeat time.

I think I have a grasp of how it all fits together.

Thanks

John Dammeyer




"ELS! The Solution"
Automation Artisans Inc.
http://www.autoartisans.com/ELS/
Ph. 1 250 544 4950


-----Original Message-----
From: [email protected] 
[mailto:[email protected]] On Behalf Of 
[email protected]
Sent: Monday, December 17, 2012 9:57 PM
To: [email protected]
Subject: Re: [CANLIST] CANOpen NMT Modes



Hi John,

Typically, when you are designing your CANopen-system, you'll have a 
CANopen project describing
the structure of your system. If you have excellent devices, you can just 
download configuration device
by device from DCF-files to the devices. More common is, that for e.g. 
PLCs, you have to have a
generator reading through the CANopen project and producing an abstraction 
layer for the project as
IEC-code. Slave assignment is typically an important part of it, as long 
as the NMT-master is not
implemented in the PLC runtime. All mobile PLCs I have seen, need 
NMT-master implemented as
IEC-code.

According to CiA-301, it should be configurable if the NMT-master should 
issue a global restart or just
start the failed device. NMT-startup cannot be performed if "mandatory" 
devices are missing. "Optional"
devices are typically started for specified time. The principle is, that 
if an exception is met, a new NMT-
start will be issued (even with flying-master).

Everything in CANopen should be implemented so, that the actual executable 
code is stable and only
its behavior is adjusted by modifying parameter values through the object 
dictionary. Or, as I wrote before
from PLCs, sometimes something need to be performed via code generation. 
But the idea is, that the
CANopen-project is edited and then the changes are automatically 
transferred further.

Best regards,

-H





"John Dammeyer"


		From:        "John Dammeyer" <[email protected]>
To:        "'CANLIST'" <[email protected]>
Date:        18.12.2012 06:25
Subject:        [CANLIST] CANOpen NMT Modes
Sent by:        [email protected]


  _____




Hi everyone,

I'm trying to come up with an optimal solution for dealing with CANOpen 
devices that arrive on the network after the master has already told the 
existing nodes that they are to go from PRE-OPERATIONAL mode to 
OPERATIONAL mode.

To review for those who don't know much about CANOpen.  Each node starts 
in the BOOT mode.  Once it's done booting I believe it's supposed to 
automatically go into PRE-OPERATIONAL mode or state.

At this point the node will respond to SDO (Service Data Objects) from the 
master that could configure it with additional project specific value. 
However, the node remains dormant as far as broadcasting PDO type messages 
(Process Data Objects).  It may not even execute it's dedicated functions.

During the PRE-OPERATIONAL state the node sends out a periodic heartbeat 
with the PRE-OPERATIONAL state in the first byte of the message.  A system 
master will see this and decide what it needs to do with that node before 
issuing either a specific GO OPERATIONAL message or sending a global 
EVERYONE GO OPERATIONAL message.

So say everyone is OPERATIONAL and a new node shows up.  Or one that has 
been reset by a user.  Should the master recognize that a node out there 
is PRE-OPERATIONAL and if allowed send it OPERATIONAL or should the master 
periodically send out an EVERYONE GO OPERATIONAL as a matter of course.

From my perspective, I'd think the nodes shouldn't be allowed to go 
OPERATIONAL until told.  And the Master should note the arrival of a new 
(or previously OPERATIONAL) node and reconfigure it if needed before 
sending the OPERATIONAL message.

Or should the system go through a RESET if one node that was OPERATIONAL 
suddenly shows up as BOOT and then PRE-OPERATIONAL.

How are these issues being handled by integrators?  I realize it's 
somewhat project specific but I'm just looking for general operations.

Thanks

John Dammeyer




"ELS! The Solution"
Automation Artisans Inc.
 <http://www.autoartisans.com/ELS/> http://www.autoartisans.com/ELS/
Ph. 1 250 544 4950







This e-mail is confidential and it is intended only for the addressees. 
Any review, dissemination, distribution, or copying of this message by 
persons or entities other than the intended recipient is prohibited. If 
you have received this e-mail in error, kindly notify us immediately by 
telephone or e-mail and delete the message from your system. The sender 
does not accept liability for any errors or omissions in the contents of 
this message which may arise as a result of the e-mail transmission.