Image Processing Reference
In-Depth Information
compliant devices are usually used for assembling automated production lines in factory automation
systems.
Other profiles have been defined as well, that are aimed at fulfilling specific requirements concern-
ing either the functions or the installation environment of a particular application domain. his is the
case, for example, of the CiA application profile defined for the automotive domain that specifies
interfaces for add-on devices to be used in special-purpose cars. Devices for police cars (e.g., in the
roof bar and for digital radio), for taxi/cabs (e.g., taximeter) and for disabled drivers are included in
this profile.
In the following, the CANopen device-profile CiA for generic I/O modules will be described
in detail, to provide an insight of what a device profile in CANopen actually is and how it can help
designers to build up networked embedded systems.
15.7.1 Device Definition
The device profile for generic I/O modules [DS] is certainly one of the most popular device profiles
defined in CANopen. Generic input/output modules provide digital/analog inputs and/or outputs;
this means, they are not bound to application-specific functions, such as, for example, measuring the
enginetemperatureorswitchingtheturnlightson/of.
Many optional configuration parameters are specified by this profile, as well as a number of
PDOs to be either sent or received. For instance, it is possible to define the polarity of each digi-
talinput/outputportortoapplyailteringmasktoselectedchannels.Foranalogdevices,eitherraw
or converted (after a scaling factor and an offset have been applied) values can be used. In the same
way, triggering conditions can be defined when specific thresholds are exceeded. The generic I/O
modules profile supports different access granularities for digital I/Os and several resolutions (and
formats) for analog I/Os.
Input values (from sensors) are sent on the CAN network as TPDOs, whose transmission defaults
to the asynchronous (i.e., event-driven) triggering. However, also the synchronous or remotely
requested triggering schemes can be optionally enabled, if supported by the device. In the same way,
output values are provided (to actuators) via asynchronous RPDOs.
I/O values may be accessed by remote applications through SDOs as well, even though this is not
recommended as it leads to a reduced efficiency and generally higher delays.
15.7.1.1 Profile Predefinitions
Several entries of the OD are standardized by this profile. One of the most significant objects in
the communication profile area is, perhaps, object
h
that defines both the device type and its
functionality, each one of them encoded in bytes. In particular, the type is specified through
thedevice-proilenumber(inthiscasesettothevalue),whereasthefunctionalityieldtells
what kind of channels (e.g., input vs. output, digital vs. analog) are effectively included in the
device.
Moreover, I/O modules, which comply with this profile, define (part of) the entries of the OD in
thestandardizedproileareaintherangefrom
h
to FF
h
. For digital modules, different objects
are foreseen, which provide access to (exactly the same) process data stored in the OD on either , ,
, or bits. However, only the -bit access scheme is mandatory, whereas the others are optional.
Objects
h
and
h
are used for -bit access to digital input and output modules, respectively.
Each subentry encodes eight adjacent digital channels.
Concerning analog modules, values encoded as integers on , , and bits are available. In addi-
tion, floating-point and manufacturer-specific formats can be used. Only bit data are mandatory,
whereas the others are optional. Objects
h
and
h
areusedforaccessingbitsanaloginput
and output values, respectively. Each subentry encodes one analog channel.
