Image Processing Reference
In-Depth Information
Despite it is assigned a rather high priority, the SYNC object may be nevertheless delayed by other
messages (blocking time, because CAN is not preemptive). Hence, the resulting synchronization
might not be as accurate as several applications demand (although jitters are much lower than for
asynchronous exchanges, they are not usually negligible).
In the initial CANopen specification (as well as in most real devices), the SYNC object was mapped
onto an empty data frame: in fact, as it provides a sort of “network clock” to applications, only the time
instants when it is received are really meaningful. he most recent specification, however, defines an
additional format for the SYNC message that can now include a -byte payload. In this case, the data
field encodes a counter that is set initially to and then is increased by on every SYNC transmission.
When the counter reaches its maximum value (synchronous counter overflow), it is reset back to .
This permits devices that send synchronous PDOs whose period is greater than the communication
cycle to arrange their transmissions (through the SYNC start parameter), so that the overall traffic is
evenly spread over different cycles. In turn, this helps reducing jitters and latencies.
15.6.5.2 Emergency Object
The EMCY object is sent asynchronously by devices as a consequence of internal error conditions. It
can be considered as a sort of interrupt, which is raised to notify urgent alarms. Its implementation
is not mandatory.
The EMCY object is made up of three fields: an error code, encoded on bytes, a -byte error
register (that specifies errors that are still pending) and a manufacturer specific error field. A number
of standardized error code classes are defined in the CANopen communication profile, and others
canbeaddedbydeviceproiles.
Only one EMCY object shall be sent for each error event. A state machine is then defined that
describes the current error condition of the device. As soon as all errors have been repaired, the
device returns to the error-free state.
15.6.6 Network Management
NMT in CANopen relies on a master/slave approach, where one NMT master controls a number of
NMT slave devices. Each NMT slave is uniquely identified on the CANopen network by means of
a node-ID, encoded as an integer in the range from to . NMT requires that one device in the
network fulfils the function of the NMT master.
Two kinds of functions concern NMT, namely node control and error control. Node control ser-
vices, as the name suggests, are used to control the operation of nodes. For example, they can be
used to start/stop nodes, to reset them to a predefined state or to put a node in configuration (pre-
operational) mode. Error control services, instead, are aimed at verifying if every device is alive and
operating properly.
15.6.6.1 Node Control Services
At any time, each CANopen (slave) device can be in one of the following four NMT states, which
describe its current behavior and the allowed operations:
•
Initialization
: his state is actually made up of three substates. he first one (initializing),
entered autonomously after either power-on or hardware reset, is where basic initial-
ization activities are carried out. Parameters of both the manufacturer-specific and the
standardized device-profile areas are set to power-on values in the reset application state,
whereas in the reset communication state parameters of the communication profile area
are set. If a nonvolatile storage area is provided on the device, such power-on values are
