Fagor CANopen protocol (MCP-MCPi) Manual

FAGOR AUTOMATION S.COOP.
MCP/MCPi
~ CANopen protocol ~
Ref. 0612
Title
Type of documentation
Name
Reference
Software
WinDDSSetup
Electronic document
Headquarters
MCP/MCPi. CANopen protocol.
Architecture, structure and communication in CANopen networks.
MAN_ MCP/MCPi_CANopen (in.)
Ref. 0612
V01.05 (MCP), V01.01 (MCPi)
From version V0612 on
MAN_MCP&MCPi_CANopen.pdf
FAGOR AUTOMATION S. COOP.
Bº San Andrés 19, Apdo. 144
20500 ARRASATE- MONDRAGÓN
www.fagorautomation.com
[email protected]
Telephone:34-943-719200
Fax:
34-943-771118 (Technical Service Department)
The information described in this manual may be subject to changes due to
technical modifications. FAGOR AUTOMATION, S. Coop. reserves the right to
change the contents of this manual without prior notice.
The contents of this manual have been verified and matched with the product
described here. Even so, it may contain involuntary errors that make it impossible
to ensure an absolute match. However, the contents of this document are regularly
checked and updated implementing the pertinent corrections in a later edition.
All rights reserved. No part of this documentation may be copied, transmitted,
transcribed, stored in a backup device or translated into another language without
Fagor Automation’s permission.
2/40 - CANopen protocol
MCP/MCPi - Ref. 0612
WARRANTY
INITIAL WARRANTY:
All products manufactured or marketed by FAGOR carry a 12-month warranty for the end
user.
In order to prevent the possibility of having the time period from the time a product leaves our
warehouse until the end user actually receives it run against this 12-month warranty, the OEM
or distributor must communicate to FAGOR the destination, identification and installation date
of the machine by filling out the Warranty Form that comes with each product.
The starting date of the warranty for the user will be the one appearing as the installation
date of the machine on the Warranty Form.
This system ensures the 12-month warranty period for the user.
FAGOR offers a 12-month period for the OEM or distributor for selling and installing the product.
This means that the warranty starting date may be up to one year after the product has left our
warehouse so long as the warranty control sheet has been sent back to us. This translates into
the extension of warranty period to two years since the product left our warehouse. If this sheet
has not been sent to us, the warranty period ends 15 months from when the product left our
warehouse.
FAGOR is committed to repairing or replacing its products from the time when the first such
product was launched up to 8 years after such product has disappeared from the product
catalog.
It is entirely up to FAGOR to determine whether a repair is to be considered under warranty.
EXCLUDING CLAUSES:
The repair will take place at our facilities. Therefore, all shipping expenses as well as travelling
expenses incurred by technical personnel are NOT under warranty even when the unit is under
warranty.
The warranty will be applied so long as the equipment has been installed according to the
instructions, it has not been mistreated or damaged by accident or negligence and has been
handled by personnel authorized by FAGOR.
If once the service call or repair has been completed, the cause of the failure is not to be blamed
on the FAGOR product, the customer must cover all generated expenses according to current
fees.
No other implicit or explicit warranty is covered and FAGOR AUTOMATION shall not be held
responsible, under any circumstances, of the damage which could be originated.
SERVICE CONTRACTS:
Service and Maintenance Contracts are available for the customer within the warranty period
as well as outside of it.
MCP/MCPi - Ref. 0612
CANopen protocol - 3/40
DECLARATION OF CONFORMITY
Manufacturer: Fagor Automation, S. Coop.
Bº San Andrés 19, C.P. 20500, Mondragón -Guipúzcoa- (SPAIN)
We hereby declare, under our responsibility that the product:
Fagor AC Brushless Servo Drive System
consisting of the following modules and motors:
Drives modules::
MCP and MCPi series
AC Motors
FXM, FKM, FSA and FSP series
mentioned on this declaration,
with the basic requirements of the European Directives 73/23/CE on Low Voltage
(Basic Safety Regulation; Electrical Equipment on Machines EN60204-1:95) and
92/31/CEon Electromagnetic Compatibility (EN 61800-3:1996, Specific Regulation
on Electromagnetic Compatibility for Servo Drive systems).
In Mondragón, 15.09.06
INTRODUCTION
This manual offers detailed description of the CANopen protocol on the CAN board of
the MCP and MCPi drives, of the CANopen architecture, structure and
communication in the network and on how to start up the unit.
When installed for the first time, it is a good idea to read the whole document.
Should you have any doubts or questions, please do not hesitate to contact our
technicians at any of our subsidiaries worldwide.
Thank you for choosing Fagor.
4/40 - CANopen protocol
MCP/MCPi - Ref. 0612
GENERAL INDEX
CANopen PROTOCOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Network architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Connection cable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
Maximum length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
Network communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Standard CAN frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Predetermined CANopen connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
NMT, Network Management. Network start-up and control process . . . . . . . . . .11
PDO, Process Data Object. Fast channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
SDO, Service Data Object. Slow channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
Emergency object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
Description of the object dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
Description of the PDO's. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
CAN card description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
Communication speed selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
Setting the node number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
Status indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
MCP/MCPi - Ref.0612
CANopen protocol - 5/40
BLANK PAGE
6/40 - CANopen protocol
MCP/MCPi - Ref.0612
CANopen PROTOCOL
Introduction
CANopen is a network communication protocol based on the CAN bus system
(developed by BOSCH in the mid 80's and oriented to the automotive world).
CANopen has been defined as a uniform application layer in the DS301 standard
edited by the entity that regulates the CIA (Can In Automation) standard.
CAN is a Multi-master Bus system that differs from other Bus systems where the
modules connected to it are not addressed by the message identifiers. Thus, the
nodes can leave messages at the Bus as long as it is free of traffic. Conflicts at the
Bus are solved based on a certain priority assigned to the messages, established
at the COB ID (Communication Object Identifier) itself and clearly assigned to the
communication objects. The COB ID having the lowest value identifies the
message of highest priority. This characteristic provides an automatic regulation of
priorities at the Bus without the management of any master element.
Network architecture
‡ Structure
Building a simple CAN network where communication will be established with
CANopen protocol will require at least a slave element, a master element (e.g. a PC
with a CAN field bus board) and a connection cable like the one shown in FIGURE 1.
Up to 127 independent slave elements may be used. Their node numbers may be
between 1 and 127.
Remember that node 0 does not exist as such and it is reserved for certain
generic messages used by the master element.
All the CAN_H, CAN_L and CAN_SHLD lines and shields must be connected to
each other on the network.
CANopen
MASTER
CANopen
connector
of the PC
DRIVE 1
DRIVE 2
DRIVE 3
CANopen
connector
CANopen
connector
CANopen
connector
CAN_L
2
5
120 Ω
5
CAN_H
7
CAN_SHLD
4 White
4 CAN_H
3 Shield
3 CAN_SHLD
2 Brown
2 CAN_L
4
120 Ω
3
2
1
Note:A 120 Ω terminating resistor must be installed by the network installer at the module of
each end the CANopen bus. The network of the figure has them installed at the PC and at the
DRIVE3 modules which are the modules at the ends. If, for example, instead of PC, a DRIVE
unit were placed in that position, it will then be one end of the bus and the 120 Ω terminating
resistor would have to be installed at that DRIVE, not at the PC. No resistor must be mounted at
the rest of the modules that make up the bus and are not at the ends. See figure.
FIGURE 1.
Structure of a CAN network.
MCP/MCPi - Ref.0612
CANopen protocol - 7/40
‡ Connection cable
Connecting the CAN card of a drive to a CANopen network requires a CAN cable
that has 2 wires and an external shield. One of the ends of the cable has a 5 prong
"Open Style" plugging connector with a 5 mm pitch. The shield must be connected
to pin 3 of this connector. For further detail, see FIGURE 2.
Pin
Signal
Wire color
5
N.C.
----
4
CAN_H
White
3
CAN_SHLD
Shield
2
CAN_L
Brown
1
N.C.
----
CANopen
CAN cable between
PC and DRIVE1
Pin
2
7
4
5
CAN cable between
DRIVE2 and DRIVE3
CAN cable between
DRIVE1 and DRIVE2
5
2
1
3
Pin
Pin
5
5
5
SHIELD
4
4
4
CAN H
3
3
3
SHIELD
2
2
2
CAN L
1
1
1
ISO GND
Front view of the Sub-D connector, F9 at the end of
the CAN cable
FIGURE 2.
Connection cables for the modules connected to a CAN network.
All the CAN_H, CAN_L lines and the shield of each one of the module that make up
the network must be connected to each other.
The user must install an external 120 W terminating resistor at the elements of both
ends of the CAN bus (and only at them)between pins 2 and 4 of the module's Open
Style connector if the end module is a drive or pins 2 and 7 of the Sub-D M9 connector
if the end module is the PC) in order to prevent rebounds and transmission problems.
‡ Maximum length
The following table shows the maximum length of the network depending on the
different transmission speeds:
TABLE 1.
Maximum length of a CAN network depending on the transmission speed
Transmission
speed
Network length
Transmission
speed
Network length
1000 kbit/s
30 meters
250 kbit/s
250 meters
800 kbit/s
50 meters
125 kbit/s
500 meters
500 kbit/s
100 meters
≤ 50 kbit/s
1000 meters
8/40 - CANopen protocol
MCP/MCPi - Ref.0612
Network communication
‡ Standard CAN frame
The standard CAN frames have between 44 and 108 useful bits. Also, depending
on the data sent, up to 23 filling bits may be inserted by the CAN drivers so the
maximum number of bits that may be reached when sending a frame is 131.
The identification of the bit fields in the CAN frame:
‡ <Start bit>: Beginning of the frame.
‡ <Arbitration>: Arbitration field that contains the identifier and the type of message
to be sent.
‡ <Control bits>: Control field that contains the number of data bytes.
‡ <Data field>: Data bits (from 0 to 8 bytes).
‡ <CRC>: Cyclic redundancy check characters according to the algorithm CRC-16.
‡ <Acknowledge>: Acknowledgment of the frame.
‡ <End>: End-of-frame bits.
Bit Length
1
12
6
0-8 bytes
16
2
7
Start bit
Arbitration
Control bits
Data field
CRC
Acknowledge
End
FIGURE 3.
Standard CAN frame.
‡ Predetermined CANopen connection
With CANopen, transmitting data, triggering events, signaling error states, etc, are
done using communication objects. That's why each communication object has a
COB ID assigned to it on the network.
The most important objects in CANopen are:
‡ <NMT>: Network treatment objects.
‡ <SYNC>: Objects for synchronization.
‡ <EMCY>: Object for error messages.
‡ <PDO>: Objects for processing.
‡ <SDO>: Objects for service.
There is a set of pre-defined COB ID's to make it easier to set up simple CAN
networks.
MCP/MCPi - Ref.0612
CANopen protocol - 9/40
COB ID
Identifier of the message placed on the network implemented in the 11 bits of the
CAN frame identifier. Its structure is:
10 9
8
7
6
Function Code
5
4
3
2
1
0
Node number: 0 - 127
FIGURE 4.
Structure of the COB ID.
Function code 1 (emergency object) may be used to generate up to 128 different
objects depending on the node number indicated in the message. Objects whose
identifier is between 0x81 and 0xFF are emergency objects sent by the node whose
number is implicit in the identifier. The 0x80 is a different object sent by the master
element (without node number assigned to it) that has higher priority than the
emergency messages and serves to synchronize the communication bus.
The Broadcast objects (node 0) and Per-to-Per objects (node>0) are set depending
on the node number appearing or not on the message header. Broadcast objects
are interpreted by all the nodes of the bus and the Per-to-Per objects may be used
to establish conversations between to elements of the net.
- "Broadcast" objects
TABLE 2.
"Broadcast" objects.
Object
Function code
bits
COB ID
Communication
parameters
NMT Module Control
0000
000h
---------
SYNC
0001
080h
1005h, 1006h, 1007h
TIME STAMP
0010
100h
1012h, 1013h
The COB ID of the "Broadcast" object is unique because it has no node number
assigned to it. It will be interpreted by all the nodes present on the CANopen network.
10/40 - CANopen protocol
MCP/MCPi - Ref.0612
- “Per-to-Per” objects
TABLE 3.
“Per-to-Per” objects.
Object
Function
code bits
COB ID
PDO mapping
parameters
Communication
parameters
EMERGENCY
0001
081h-0FFh
1024h, 1015h
PDO1 tx
0011
181h-1FFh
1A00h
1800h
PDO1 rx
0100
201h-27Fh
1600h
1400h
PDO2 tx
0101
281h-2FFh
1A01h
1801h
PDO2 rx
0110
301h-37Fh
1601h
1401h
PDO3 tx
0111
381h-3FFh
1A02h
1802h
PDO3 rx
1000
401h-47Fh
1602h
1402h
PDO4 tx
1001
481h-4FFh
1A03h
1803h
PDO4 rx
1010
501h-57Fh
1603h
1403h
SDO tx
1011
581h-5FFh
1200h
SDO rx
1100
601h-67Fh
1200h
NMT Error Control
1110
701h-77Fh
1016h-1017h
Note. The concepts of the terms rx and tx must be understood from the bus' point
of view.
"Per-to-Per" objects involve establishing communication between two particular
nodes. This forces the COB ID's to include (depending on the object) the target node
number or the source node number (0-127 in both cases). Hence the range indicated
in TABLE 3.
"Communications parameters" contains the communication object where the
various aspects related to that object are configured.
"PDO mapping parameters" contains the mapping object where the various
mapped objects are configured for the corresponding PDO.
‡ NMT, Network Management. Network start-up and control process
Once voltage is applied to a CANopen node, a startup process begins initialing its
variables, doing an auto-test, etc. When done, each node sends a "Boot-up"
message through the bus to let the master element know that a new node is now
part of the CANopen network.
(Boot-Up)
NMT - master Í NMT - slaves.
COB ID
Byte 0
0x700 + node ID
0
When this task is successfully finished, the node automatically goes into a preoperational state and stays there until the master element, with network control
message (NMT), requests it to switch to an operational state:
(module control)
NMT- master Î NMT- slaves.
COB ID
Byte 0
Byte 1
0x000
CS
node ID
MCP/MCPi - Ref.0612
CANopen protocol - 11/40
This action may or may not be set as "Broadcast" depending on the value indicated
in byte 1 of the data field. Thus, if the value of byte 1 is zero, the action is set as
"Broadcast". If other than zero and less than 128, its value will indicate the
destination node for the command.
The value indicated in byte 0 of the data field of the CAN message sets the command
to be carried out. See the following table.
CS.
TABLE 4.
Byte 0 of the data field of the CAN message. Command to carry out.
Command
specifier (byte 0)
NTM service
(module control)
1
Start the remote node - switch to operational state -
2
Stop the remote node - switch to stop state -
128
Enter the pre-operational state - switch to pre-operational state -
129
Initialize the node - reset the selected node or nodes -
130
Initialize the communication - reset the communication process at
the indicated node or nodes -
Depending on the value specified in these bytes of the data field, it is possible to
change the state of one or all the nodes of the network.
After the network has started up successfully, the master element has the option to
cyclically check that all the nodes remain active on it.
With - Node Guarding - the master element cyclically sends (under some previously
set and checked times) a broadcast message without any data; this message includes
the state of each of them and all the nodes respond to it. These messages are:
(Node Guarding)
NMT- master Î NMT- slaves.
COB ID
0x700 + node ID
NMT- master Í NMT- slaves.
COB ID
Byte 0
0x700 + node ID
Bit 7 - Toggle bit -
Bits 6-0 - Status
Status.
TABLE 5.
Node Guarding. States.
Value
Status
0
Initializing
1
Disconnecting *
2
Connecting *
3
Preparing *
4
Stopped
5
Running
127
In a stage prior to normal operation
* These states only exist if the device supports the “extended boot-up”.
12/40 - CANopen protocol
MCP/MCPi - Ref.0612
Warning. The CAN board of the MCP and MCPi drives does not support this
characteristic.
Related objects.
100Ch
Guard Time
100Dh
Life Time
100Eh
Node Guarding Identifier ( by default: 700 + node ID )
Alternately, a node may be configured for generating a period message called
"Heartbeat".
(Heartbeat)
Producer Î Consumer / s.
COB ID
Byte 0
0x700 + node ID
Status
Status.
Heartbeat. States.
TABLE 6.
Status
Meaning
0
Boot-up
4
Stopped
5
Running
127
In a stage prior to normal operation
The consumer of the "Heartbeat" is usually the master element that verifies that each
node sends the "Heartbeat" message with a set period within certain margins and
will act accordingly whenever this is not true in any of the nodes.
Warning:A node cannot support "Heartbeat" and "Node Guarding" at the same
time.
(Sync)
Producer Î Consumer / s.
COB ID
0x080
Object in charge of synchronizing the bus. It is cyclic, "Broadcast" and has maximum
priority in the bus after the NMT. It is directly related with the treatment of PDO's
Related objects.
1005 h
COB-ID of the synchronism message
1006 h
Period of the communication cycle
1007 h
Length of the synchronous window
‡ PDO, Process Data Object. Fast channel
The process data objects (PDO's) may be used to transmit data in real time and with
high priority identifiers. The data telegrams may have a maximum of 8 Bytes. The
data may be exchanged using events or synchronously as wished. Exchanging
messages using events can drastically reduce the load in the bus in comparison with
using the synchronous mode.
MCP/MCPi - Ref.0612
CANopen protocol - 13/40
PDO protocol
This protocol is used to transmit the data to/from the bus avoiding to overload it with
redundant information.
In PDO messages (in the data bytes), only and exclusively the values of variables
of different nodes are transmitted without sending their identifiers. In order for this
to be done without errors, the master and slave elements have previously agreed
on which variables will be sent within each PDO (mapping). This assignment is set
using “PDO Mapping Parameter” objects. The type of communication established
for each PDO (synchro nized or by event) will be determined by the
“Communication Parameter” objects.
Depending on who sends the PDO message, we'll refer to transmission PDO (from
the slave element to the master) or reception PDO (from the master element to the
slave).
Note. The DS301 standard sets four transmission PDO's and 4 reception PDO's
for each slave. All of them need not be implemented to meet the standard.
Mapping and type of communication
Let us suppose that the mapping object of the second transmission PDO has the
following values:.
TABLE 7.
Mapping and type of communication
Object 0x1A01
Subindex
Value
Meaning
0
2
Two objects are mapped in this PDO
1
0x60000208
Object: 0x6000 (*)
Subindex: 0x02
Data: 8 bits
2
0x64010110
Object: 0x6401 (*)
Subindex: 0x01
Data: 16 bits
* It is described in the following table.
Value Dword (32 bits)
TABLE 8.
Description.
Bits 31-16
Bits 15-8
Bits 14-0
Index
Subindex
Number of data bits of the object
14/40 - CANopen protocol
MCP/MCPi - Ref.0612
Let us suppose that the communication object of the second transmission PDO has
the following values:
TABLE 9.
Example of object of the second PDO.
Object 0x1801
Subindex
Value
Meaning
0
5
The object 0x1801 has 5 subindexes
1
0x00000280
PDO exists, RTR not allowed, 11 bits id, COB ID=280h.
2
0xBC
The PDO transmission will be cyclic and through the bus
after receiving 188 synchronism messages.
3
0x000A
The "inhibit time" between PDO's is:
10 x 100 µs = 1 ms.
4
----------
Reserved.
5
0x0000
Interval of the "event timer" 0.
Value of subindex 1 (COB ID)
TABLE 10. Value of subindex 1 (COB ID)
Bit 31
Bit 30
Bit 29
0ÎPDO exists
0ÎRTR allowed
0ÎCAN ID 11 bits
1ÎPDO does not 1ÎRTR not allowed 1ÎCAN ID 29 bits
exist
Bits 28-11
Bits 10-0
Low portion
High portion
of the COB ID of the COB ID
(if CAN ID
(if CAN ID
has 29 bits). has 29 bits).
COB ID
(if CAN ID has
11 bits).
Value of subindex 2 ( Type of transmission )
TABLE 11. Value of subindex 2 (type of transmission).
Type of
Trigger condition of the PDO
transmission ( B = both required, 0 = one or both)
SYNC
RTR
SYNC
object
received
Received
Value change
request for
of the interruption
remote
of the timer
transmission
0
B
1-240
O
Event
B
Synchronous (SYNC), non-cyclic
Synchronous (SYNC), cyclic
241-251
252
PDO transmission
Reserved
B
B
Synchronous (SYNC) after RTR
Asynchronous (ASYNC) after
253
O
254
O
O
Asynchronous (ASYNC), OEMspecific event
255
O
O
Asynchronous (ASYNC), deviceprofile-specific event
MCP/MCPi - Ref.0612
CANopen protocol - 15/40
where:
‡ <SYNC> means that the transmission of the PDO has to do with the reception
of the synchronism message.
‡ <ASYNC> means that the transmission of the PDO has nothing to do with the
reception of the synchronism message.
Type of transmission = 0.Synchronous and non-cyclic. The messages are only sent
when an event takes place and, in that case, the message is sent in synchronism
with the next synchronism message.
An event is a change of value of the variable or (if it is supported by the equipment,
communication objects with subindex 5).
Type of transmission = 1 to 240.The PDO is transmitted after receiving the
number of synchronism messages specified in the type of transmission.
Type of transmission = 252 to 253. Values only possible in transmission PDO's.
In either case, the PDO is sent as response to an RTR frame of the master element.
The difference is that in the type of transmission = 252 it updates the variables
when receiving the synchronism and the transmission = 253 updates the variables
and sends them when receiving the RTR frame.
Type of transmission = 254.The PDO is transmitted when some OEM-specific
event occurs.
Type of transmission = 255. The PDO is transmitted when some device-profilespecific event occurs.
Value of subindex 3 ( inhibit time or disable time)
It indicates the minimum time interval (in 100 µs increments ) elapsed between
PDO's. This time interval cannot be changed while the value of bit 31 of subindex
1 (COB ID) is 0 (the PDO exists).
Value of subindex 5 (event timer)
It indicates the value of the event timer (in 1 ms increments) when the transmission
type is 254 or 255.
Example to explain the meaning of the "time inhibit" and the "event timer".
When programming a type-254 transmission PDO that includes a position variable,
two different scenarios occur. As long as the element to send the PDO is stopped
(its position has not changed), it will not have to be sent. When programming a 10
ms event timer, even if the element does not change its position (it does not move),
it will send PDO's every 10 ms indicating its position. When starting the movement,
it will try sending PDO's constantly, thus taking up the whole bus with this information.
In order to avoid this situation, an inhibit time of 2 may be programmed so it only sends
PDO's every 2 ms while it is moving.
16/40 - CANopen protocol
MCP/MCPi - Ref.0612
The message
According to the configuration shown in the tables mentioned earlier, the PDO
message (with the bytes that make it up) is as follows:
TABLE 12. PDO message.
COB ID
Byte 0
Byte 1
Byte 2
0x280
+ node ID
8 data bits of the
object 0x6000
Low portion of the 16 data High portion of the 16 data
bits of the object 0x6000 bits of the object 0x6401
The PDO transmission will be cyclic and is provided to the bus after receiving 188
synchronism messages.
Related objects
1004 h
Number of PDO's supported
‡ SDO, Service Data Object. Slow channel
The service data objects (SDO's) may be used to read and write the entries of the
object dictionary (parameters, variables, commands, etc.). Thus, using SDO's, any
node may be configured by the master element. The SDO message, by default, has
a low priority identifier previously assigned to it. The transmitted data larger than 4
Bytes may be fragmented and that's why there are two ways to transfer an SDO:
<Expedited transfer> used to transfer of objects of less than 4 bytes
<Segmented transfer> used to transfer of objects of more than 4 bytes
Basic structures of an SDO
The basic structures of an SDO are:
Cliente
Î
Server / Server Î Client
TABLE 13. SDO structure. Cliente Î Server / Server Î Client
Byte 0
Byte 1
Indicator of
command
SDO
Index
rule
objects
or also Client
Î
Byte 2
Byte 3
Byte 4
Byte 5
Byte 6
Byte 7
Subindex
rule
objects
Up to 4 data Bytes in expedited
transfer or 4 counter Bytes in
segmented transfer
Server / Server Î Client
TABLE 14. SDO structure. Client Î Server / Server Î Client
Byte 0
Byte 1
Byte 2
Byte 3
Byte 4
Byte 5
Byte 6
Byte 7
Indicator of SDO Up to 7 data Bytes in segmented
command
transfer
There are five request / response protocols implemented in the SDO's. They are:
‡ Initiate Domain Download
‡ Download Domain Segment
‡ Initiate Domain Upload
‡ Upload Domain Segment
MCP/MCPi - Ref.0612
CANopen protocol - 17/40
‡ Abort Domain Transfer
Download means writing into the object dictionary and upload reading from the
object dictionary.
SDO command indicators for the different protocols
TABLE 15. Initiate domain download.
Begin the domain download
bit
Client
Î
Server
Í
7
6
5
4
3
0
0
1
-
n
0
1
1
-
-
2
-
1
0
e
s
-
-
where:
n Î Indicator of the number of bytes that do not contain data and it is valid if e=1 and
s=1.
e Î Indicator of a normal transfer (e=0) or expedited transfer (e=1).
s Î Indication or not of data size. If indicated (s=0) and if not indicated (s=1).
e = 0 y s = 0 Î Data bytes reserved for the future by CiA.
e = 0 y s = 1 Î The bytes counter is in the data bytes (byte 4 LSB to byte 7 MSB).
e = 1 Î The data bytes contain the data to be downloaded.
TABLE 16. Domain segment download.
Download the domain segment.
bit
Client
Î
Server
Í
7
6
5
4
3
0
0
0
t
n
0
0
0
t
-
2
1
0
c
-
-
-
where:
n Î Indicator of the number of bytes that do not contain data and it is zero if the size
of the segment is not indicated.
c Î Indicator of segments to download. (c=0) if there are more segments to download
and (c=1) if it is the last segment.
t Î Toggle bit that must toggle with each consecutive segment. The first time is (t=0).
TABLE 17. Initiate domain upload.
Begin the domain upload
bit
Client
Î
Server
Í
18/40 - CANopen protocol
7
6
5
4
3
2
1
0
0
1
0
-
-
-
-
-
0
1
0
-
n
e
s
MCP/MCPi - Ref.0612
TABLE 18. Domain segment upload.
Upload the domain segment
bit
Client
Î
Server
Í
7
6
5
4
3
2
1
0
0
1
1
t
-
-
-
-
0
0
0
t
n
c
A message may be aborted either by the client or by the server. It must be indicated
with the following command indicator:
TABLE 19. Aborting the domain transfer.
Abort the domain transfer
bit
Client
Î / Í Server
7
6
5
4
3
2
1
0
1
0
0
-
-
-
-
-
When aborting the domain transfer, data bytes 0 and 1 contain the object index; byte
2, the object subindex and bytes 4-7 contain the abort code that describes the cause.
MCP/MCPi - Ref.0612
CANopen protocol - 19/40
Codes describing the possible reason to abort an SDO
TABLE 20. Description of the possible SDO aborting codes.
Abort code
Description
byte 7 byte 6 byte 5 byte 4
05
05
03
04
00
00
00
00
The toggle bit does not toggle
TimeOut for the SDO protocol
05
04
00
01
Wrong client/server command or unknown identifier
05
05
05
05
06
06
06
06
06
04
04
04
04
01
01
01
02
04
00
00
00
00
00
00
00
00
00
02
03
04
05
00
01
02
00
41
06
04
00
42
06
06
06
04
04
06
00
00
00
43
47
00
06
07
00
10
Block size unrecognized (only block mode)
Block number unrecognized (only block mode)
CRC error (only block mode)
Insufficient memory
Access to this object not supported
An attempt has been made to read a write-only object
An attempt has been made to write a read-only object
The object does not exist in the object dictionary
The object cannot be mapped to a PDO.
The size and number of mapped objects exceed the length
of the PDO
Overall parameter incompatibility
Overall device incompatibility
Access violation caused by hardware error
Incompatible data type, the length of the service parameter
is incompatible
06
07
00
12
Incompatible data type, the service parameter is too long
06
07
00
13
Incompatible data type, the service parameter is too short
06
06
06
06
06
08
08
09
09
09
09
09
00
00
00
00
00
00
00
00
00
11
30
31
32
36
00
20
08
00
00
21
08
00
00
22
The subindex does not exist
External range of values (only for writing access)
Parameter value too high
Parameter value too low
The maximum value is lower than the minimum value
Overall error / failure
The data cannot be transmitted or saved
The data cannot be transmitted or saved because the
device is under local control
The data cannot be transmitted or saved because of the
device's status
08
00
00
23
The object dictionary cannot be generated dynamically
‡ Emergency object
An emergency message has 8 bytes and has the following format:
TABLE 21. Emergency message.
COB ID
Byte 0 -1
Byte 2
Byte 3 -7
0x080
+ node ID
Emergency error
code
Error register
(object 0x1001)
Error field specified by the
OEM
20/40 - CANopen protocol
MCP/MCPi - Ref.0612
Emergency error codes
TABLE 22. Emergency error codes.
Emergency error code
Meaning
00xx
10xx
20xx
21xx
22xx
23xx
30xx
31xx
32xx
33xx
40xx
41xx
42xx
50xx
60xx
61xx
62xx
63xx
70xx
80xx
81xx
8110
8120
8130
8140
82xx
8210
8220
90xx
F0xx
FFxx
Error reset or no error
Generic error
Peak
Current, input side of the device
Current inside the device
Current, output side of the device
Voltage
Mains voltage
Voltage inside the device
Output voltage
Temperature
Operating ambient
Device temperature
Device hardware
Device software
Internal software
User software
W data
Additional modules
Monitoring
Communication
CAN exceeded
Passive error
“ Life guard” error or “Heartbeat” error
Restored from bus-off
Protocol error
PDO not processed due to length error
Length exceeded
External error
Additional features
Device specific
Emergency error codes in hexadecimal. Observe that “xx” is a part that depends
on the device profile.
MCP/MCPi - Ref.0612
CANopen protocol - 21/40
Error register (object 0x1001)
TABLE 23. Error register (OBJECT 0x1001).
Bit
0
1
2
3
4
5
6
7
Type of error
Generic
Peak
Voltage
Temperature
Communication
Device-profile specific
Reserved (=0)
OEM specific
Related objects
1001 h
Error register
1003 h
Field of predefined errors
1014 h
COB ID for the emergency message
‡ Description of the object dictionary
Communication objects (DS301)
TABLE 24. Communication objects (DS301).
Index
Description
1000h
1001h
1003h
1005h
1006h
1007h
1008h
1009h
100Ah
100Ch
100Dh
1014h
1015h
1018h
1400h
1600h
1800h
1A00h
Device type
Error register
Field of predefined errors
COB ID of SYNC message
Communication cycle period
Length of the synchronism window
Name of the OEM device
OEM hardware version
OEM software version
Monitoring time
Lifetime factor
COB ID for the emergency message
Inhibit time for the emergency message
Identity object
Communication parameter for "PDO receive"
Mapping parameter for "PDO receive"
Communication parameter for "PDO send"
Mapping parameter for "PDO send"
OEM objects MCP/MCPi CANopen
Description of the headers of the columns of the table of OEM objects.
Fn Î Fagor name of the object.
Índice Î Hexadecimal index of the OEM's CANopen.
IdA Î Identifier of the variable in the "Assembly" structure of fast PDO messages.
22/40 - CANopen protocol
MCP/MCPi - Ref.0612
Variable Î Parameter, variable or command that may be assigned to the object.
Acc Î Object access. Read only (R), read and write (R/W).
Tipo Î Object data type. Unsigned integer, signed integer (INT), text (string).
Range Î Value range (minimum or maximum) accepted by the object.
TABLE 25. OEM objects MCP/MCPi CANopen.
Name
Index
IdA
Description
Acc
Type Range
AP1
5020h
41h
PrimaryOperationMode
R/W
UINT 2 a 5
BV14
40CCh
181h
NotProgrammableIOs
R
UINT 0 a 65535
CP1
506Ah
241h
CurrentProportionalGain
R/W
UINT 0 to 999
CP2
506Bh
242h
CurrentIntegralTime
R/W
UINT 0 to 999
CP10
413Bh
243h
VoltageAmpVolt
R/W
UINT 1000 to 9999
CP11
413Ch
244h
AmpAmpVolt
R/W
UINT 100 to 5000
CP20
4133h
245h
CurrentLimit
R/W
UINT 0 to 5000
CP30
4134h
246h
CurrentCommandFilter1Type
R/W
UINT 0 to 1
CP31
4138h
247h
CurrentCommandFilter1Frequency
R/W
UINT 0 to 4000
CP32
4139h
248h
CurrentCommandFilter1Dumping
R/W
UINT 0 to 1000
CP45
413Ah
249h
CurrentCommandSelector
R/W
UINT 0 to 3
CV1
4135h
281h
Current1Feedback
R
INT
-5000 to 5000
CV2
4136h
282h
Current2Feedback
R
INT
-5000 to 5000
CV3
4137h
283h
CurrentFeedback
R
INT
-5000 to 5000
CV10
4131h
284h
Current1Offset
R
INT
-2000 to 2000
CV11
4132h
285h
Current2Offset
R
INT
-2000 to 2000
CV15
413Dh
286h
DigitalCurrentCommand
R/W
INT
-5000 to 5000
DC1
5063h
301h
ResetClass1Diagnostics
R/W
UINT 0 to 15
DC2
4192h
302h
ClearHistoricOfErrorsCommand
R/W
UINT 0 to 15
DV17
419Ah
381h
HistoricOfErrors
R
String 0 to 999
DV31
5087h
382h
DriverStatusWord
R
UINT 0 to 65535
DV32
5086h
383h
MasterControlWord
R/W
UINT 0 to 65535
DV50
5FF8h
384h
ErrorBitArea
R
UINT
DV51
5FFDh
385h
WarningBitArea
R
UINT 0 to 65535
DV60
41CDh
386h
FastControlIn
R/W
UINT Without range
DV61
41CEh
387h
FastControlOut
R
UINT Without range
EP1
41F4h
441h
EncoderSimulatorPulsesPerTurn
R/W
UINT 1 to 4096
EP3
41F6h
442h
EncoderSimulatorDirection
R/W
UINT 0 to 1
GC1
5108h
601h
BackupWorkingMemoryCommand
R/W
UINT 0 to 15
GC3
42DAh
602h
AutoPhasingCommand
R/W
UINT 0 to 15
GC10
5106h
603h
LoadDefaultsCommand
R/W
UINT 0 to 15
GP3
42BEh
641h
StoppingTimeout
R/W
UINT 0 to 9999
GP5
42C0h
642h
ParameterVersion
R
UINT 0 to 9999
MCP/MCPi - Ref.0612
0x80000000
to 0x7fffffff
CANopen protocol - 23/40
Name
Index
IdA
Description
Acc
GP9
50CFh
643h
DriveOfDelayTime
R/W UINT 0 to 9999
Type Range
GP11
42D6h
645h
IOFunctionsTime
R/W UINT 0 to 9999
GP15
42D5h
646h
AutomaticInitialization
R/W UINT 0 to 1
GP16
42D7h
647h
MonoPhaseSelector
R/W UINT 0 to 1
GV2
501Eh
681h
ManufacturerVersion
R
string 0 to 9999
GV5
42C2h
682h
CodeChecksum
R
INT
GV7
510Bh
683h
Password
R/W UINT 0 to 9999
GV9
508Ch
684h
DriveType
R
-32768 a 32767
string -32768 a 32767
GV11
42C4h
685h
SoftReset
R/W UINT 0 to 16
GV16
42CCh
686h
MotorTableVersion
R
UINT 0 to 32767
GV50
4725h
688h
SerialNumber
R
UINT -32768 to 32767
GV75
5177h
687h
ErrorList
R
string -32768 to 32767
HV5
4127h
781h
PLDVersion
R
UINT 0 to 65535
IP6
438Eh
841h
DigitalInputPolarity
R/W UINT 0 to 1
IP14
438Fh
842h
DigitalInputFunctionSelector
R/W UINT 0 to 4
IP17
4390h
843h
AnalogFunctionSelector
R/W UINT 0 to 2
IV1
4389h
881h
AnalogInput1
R
IV2
438Ah
882h
AnalogInput2
R
INT
-1200 to 1200
IV3
4391h
883h
CurrentCommandAfterScaling
R
INT
-9999 to 9999
IV10
438Bh
884h
DigitalInputs
R
UINT 0 to 1
IV11
438Ch
885h
DigitalInputsCh2
R
UINT -32768 to 32767
UINT -32768 to 32767
INT
-12000 to 12000
ID5
49C4h
1B85h
BusCodeChecksum
R
KP3
445Ah
A41h
ExtBallastPower
R/W UINT 200 to 2000
KP4
445Ch
A42h
ExtBallastEnergyPulse
R/W UINT 200 to 2000
KV6
517Fh
A81h
MotorTemperature
R
UINT 0 to 200
KV10
444Eh
A82h
CoolingTemperature
R
UINT 0 to 200
KV32
4455h
A83h
I2tDrive
R
UINT 0 to 100
KV36
4457h
A84h
I2tMotor
R
UINT 0 to 100
KV40
445Bh
A85h
I2tCrowbar
R
UINT 0 to 100
KV41
445Dh
A86h
BallastSelect
R/W UINT 0 to 1
LP22
4912h
B41h
JogVelocity
R/W UINT 0 to 500000
LP23
4913h
B42h
JogIncrementalPosition
R/W UINT 0 to 0x7fffffff
LP48
4934h
B43h
PositionActionsSelect
R/W UINT -32768 to 32767
LP49
4935h
B44h
InBandPosition
R/W UINT 0 to 0x7fffffff
LP143
5189h
B45h
ModuleCommandMode
R/W UINT 0 to 2
LV13
4909h
B81h
KernelOperationMode
R/W UINT 0 to 1
LV14
490Ah
B82h
KernelAutoMode
R/W UINT 0 to 1
LV15
490Bh
B83h
KernelStartSignal
R/W UINT 0 to 1
LV16
490Ch
B84h
KernelStopSignal
R/W UINT 0 to 1
LV17
490Dh
B85h
KernelResetSignal
R/W UINT 0 to 1
LV19
490Fh
B86h
KernelManMode
R/W UINT 0 to 1
LV20
4910h
B87h
JogPositiveSignal
R/W UINT 0 to 1
LV21
4911h
B88h
JogNegativeSignal
LV35
491Fh
B89h
BlockTravelDistance
LV36
4920h
B8Ah
BlockCoveredDistance
LV158
5102h
B8Bh
TargetPosition
R/W UINT 0 to 1
0x8000000
R
INT
to 0x7fffffff
0x8000000
R
INT
a 0x7fffffff
0x8000000
R
INT
a 0x7fffffff
24/40 - CANopen protocol
MCP/MCPi - Ref.0612
Name
Index
IdA
LV159
5103h
B8Ch PositioningVelocity
Description
Acc
Type Range
R
UINT 0 to 0x7fffffff
LV160
5104h
B8Dh PositioningAcceleration
R/W
UINT 0 to 0x7fffffff
LV161
5105h
B8Eh PositioningAcceleration2
R/W
UINT 0 to 0x7fffffff
LV242
5156h
B8Fh TargetPositionAttained
R
UINT 0 to 1
MP1
508Dh
C41h MotorType
R/W
string -32768 to 32767
MP2
44B0h
C42h MotorTorqueConstant
R/W
UINT 0 to 1000
MP3
506Fh
C43h MotorContinuousStallCurrent
R/W
UINT 0 to 5000
NP117
5075h
D42h ResolutionOfFeedback2
R/W
UINT 0 to 65535
NP118
5076h
D43h ResolutionOfLinearFeedback
R/W
UINT 0 to 65535
NP121
5079h
D44h InputRevolutions
R/W
UINT 1 to 65535
NP122
507Ah
D45h OutputRevolutions
R/W
UINT 1 to 65535
NP123
507Bh
D46h FeedConstant
R/W
UINT 0 to 0x7fffffff
NP131
4082h
D47h InputRevolutions2
R/W
UINT 1 to 65535
NP132
4083h
D48h OutputRevolutions2
R/W
UINT 1 to 65535
NP133
4084h
D49h FeedConstant2
R/W
UINT 0 to 0x7fffffff
OP1
4578h
E41h DA1IDN
R/W
UINT 0 to 13
OP2
4579h
E42h DA2IDN
R/W
UINT 0 to 13
OP3
457Ah
E43h DA1ValuePer10Volt
R/W
UINT 0 to 9999
OP4
457Bh
E44h DA2ValuePer10Volt
R/W
UINT 0 to 9999
OP6
4588h
E45h DigitalOutputPolarity
R/W
UINT 0 to 1
OP14
4586h
E46h DigitalOutputFunctionSelector
R/W
UINT 0 to 7
OP15
4587h
E47h DigitalOutputWarningSelector
R/W
UINT 0 to 2
OV10
4582h
E81h DigitalOutputs
R
UINT 0 to 1
OV11
4585h
E82h DigitalOutputsCh2
R/W
UINT -32768 to 32767
PC148
5094h
F02h
R/W
UINT 0 to 15
DriveControlledHoming
PC150
4517h
F03h
ChangePosFB12
R/W
UINT 0 to 16
PP1
5028h
F41h
HomingVelocitySlow
R/W
UINT 0 to 1200
PP41
5029h
F42h
HomingVelocityFast
R/W
UINT 0 to 6000
PP42
502Ah
F43h
HomingAcceleration
R/W
PP49
5031h
F44h
PositivePositionLimit
R/W
PP50
5032h
F45h
NegativePositionLimit
R/W
PP52
5034h
F46h
ReferenceDistance1
R/W
PP54
5036h
F47h
ReferenceDistance2
R/W
PP55
5037h
F48h
PositionPolarityParameters
R/W
PP57
5039h
F49h
PositionWindow
R/W
PP76
504Ch
F4Ah PositionDataScalingType
R/W
UINT 0 to 0x7fffffff
0x8000000
INT
a 0x7fffffff
0x8000000
INT
a 0x7fffffff
0x8000000
INT
a 0x7fffffff
0x8000000
INT
a 0x7fffffff
UINT 0 to 65535
0x8000000
INT
a 0x7fffffff
UINT 1 to 65535
PP103
5067h
F4Bh ModuleValue
R/W
UINT 0 to 0x7fffffff
PP104
5068h
F4Ch PositionKvGain
R/W
UINT 0 to 65535
PP105
5069h
F4Dh PositionKvGain2
R/W
UINT 0 to 65535
PP115
5073h
F4Eh PositionFeedback2Type
R/W
UINT 0 to 32
PP147
5093h
F4Fh HomingParameter
R/W
UINT 0 to 65535
PP159
509Fh
F50h
MonitoringWindow
R/W
UINT 0 to 0x7fffffff
PP216
5128h
F51h
VelocityFeedforwardPercentage
R/W
UINT 0 to 120
PP218
4526h
F52h
VelocityFeedforwardPercentage2
R/W
UINT 0 to 120
MCP/MCPi - Ref.0612
CANopen protocol - 25/40
Name
Index
IdA
Description
Acc
PV51
5033h
F81h
PositionFeedback1
R
PV53
5035h
F82h
PositionFeedback2
R
PV173
50ADh F83h
MarkerPositionA
R
PV189
50BDh F84h
FollowingError
R
PV200
5190h
F85h
HomeSwitch
R
Type Range
0x8000000
INT
to 0x7fffffff
0x8000000
INT
a 0x7fffffff
0x8000000
INT
to 0x7fffffff
0x8000000
INT
to 0x7fffffff
UINT 0 to 1
PV208
5198h
F86h
ReferenceMarkerPulseRegistered
R
UINT 0 to 1
QP11
47D0h
1043h
CanBusSpeed
R/W
UINT 0 to 20
QP14
47DAh 1044h
ProtocolTypeSelector
R/W
UINT 2 to 4
QP16
47DCh 1045h
SerialSettings
R/W
UINT 0 to 65535
QV22
5016h
1081h
IDNListOfInvalidOperationData
R
string 0 to 65535
QV96
5060h
1083h
SlaveArrangement
R/W
UINT 0 to 127
RC1
45E9h
1101h
EncoderParameterStoreCommand
R/W
UINT 0 to 15
RG1
3801h
11C1h
PiecesCount
R/W
UINT 0 to 65535
RG2
3802h
11C2h
ActualPiecesCount
R/W
UINT 0 to 65535
RG3
3803h
11C3h
RunningBlock
R/W
UINT 0 to 127
RG4
3804h
11C4h
PositionBlockIni
R/W
UINT 0 to 127
RP1
45DCh 1141h
FeedbackSineGain
R/W
UINT 0 to 8192
RP2
45DDh 1142h
FeedbackCosineGain
R/W
UINT 0 to 8192
RP3
45DEh 1143h
FeedbackSineOffset
R/W
INT
-2000 to 2000
RP4
45DFh 1144h
FeedbackCosineOffset
R/W
INT
-2000 to 2000
RV1
45E2h
1181h
FeedbackSine
R
INT
-512 to 511
RV2
45E3h
1182h
FeedbackCosine
R
INT
-512 to 511
RV3
45E4h
1183h
FeedbackRhoCorrection
R
UINT 0 to 65535
SP1
5064h
1241h
VelocityProportionalGain
R/W
UINT 0 to 9999
SP2
5065h
1242h
VelocityIntegralTime
R/W
UINT 0 to 9999
SP3
5066h
1243h
VelocityDerivativeGain
R/W
UINT 0 to 9999
SP10
505Bh
1244h
VelocityLimit
R/W
UINT 0 to 9999
SP19
4653h
1245h
SymmetryCorrection
R/W
INT
SP20
4654h
1246h
VoltageRpmVolt
R/W
UINT 1000 to 9999
SP21
4655h
1247h
RpmRpmVolt
R/W
UINT 10 to 9999
SP30
4643h
1248h
VelocityOffset
R/W
INT
SP40
507Dh
1249h
VelocityThresholdNx
R/W
UINT 0 to 9999
SP41
509Dh
124Ah
VelocityWindow
R/W
UINT 0 to 9999
SP42
507Ch
124Bh
StandStillWindow
R/W
UINT 0 to 9999
SP43
502Bh
124Ch
VelocityPolarityParameters
R/W
UINT 0 to 1
SP45
4651h
124Dh
VelocityCommandSelector
R/W
UINT 0 to 2
SP60
508Ah
124Eh
AccelerationLimit
R/W
UINT 0 to 4000
-500 to 500
-2000 to 2000
SP65
4649h
124Fh
EmergencyAcceleration
R/W
UINT 0 to 4000
SP66
4652h
1250h
VelocityDecelerationTime
R/W
UINT 0 to 4000
SV1
5024h
1281h
VelocityCommand
R/W
INT
-6·107 to 6·107
SV2
5028h
1282h
VelocityFeedback
R
INT
-6·107 to 6·107
SV6
4656h
1283h
VelocityCommandAfterFilters
R
INT
-6·107 to 6·107
SV7
464Ch
1284h
VelocityCommandFinal
R
INT
-6·107 to 6·107
26/40 - CANopen protocol
MCP/MCPi - Ref.0612
Name
Index
IdA
Description
Acc
Type Range
SV15
4657h
1285h
DigitalVelocityCommand
R/W
INT
TP1
507Eh
1341h
TorqueThresholdTx
R/W
UINT 0 to 100
TV1
5050h
1381h
TorqueCommand
R
INT
-9999 to 9999
TV2
5054h
1382h
TorqueFeedback
R
INT
-9999 to 9999
-6·107 to 6·107
‡ Description of the PDO's.
The CAN communications card of the MCP and MCPi drives has one reception PDO
and one transmission PDO (this number may be higher in future versions). The PDO's
are factory mapped and cannot be changed by the user. The user may access the
communication parameters of the PDO's and can select both the type of
communication and their enabling.
The ultimate purpose of the PDO's is to set the control of the slave modules by the
master module. The drives have two data structures (mapped directly to these PDO
messages) called Assembly; they are meant to be used to govern servo drives in real
time. They have 8 bytes each and their purpose (among others) is to allow the master
module control the drive; It is possible to change its variables and parameters
(AssemblyIn) and also inform of its status from the drive and, at same time, return
the variables requested by the master module (AssemblyOut).
AssemblyIn - Control
TABLE 26. AssemblyIn.
B7
B6
Byte 0
I_Fast
Starting_Block
Byte 1
Drive_
Enable
Speed_
Enable
Byte 2
Dir_Var Bits 0 -7
Byte 3
Command_
Toggle_Bit
Byte 4
Data_Byte 0
Byte 5
Data_Byte 1
Byte 6
Data_Byte 2
Byte 7
Data_Byte 3
Command
B5
Home_
Switch
B4
B3
B2
B1
B0
Lim -
Lim +
Reset *
Jog- **
Stop
Start *
Jog+ **
Dir_Var Bits 8-12
* KernelOperationMode Î LV13 = 0, i.e. in automatic mode.
** KernelOperationMode Î LV13 = 1, i.e. in automatic mode.
I_Fast:Bit to activate the fast input (as next-block event) through the communications
bus.
Starting_Block (7 bits):Indicates the block number from which it will begin executing
in the movements table.
Drive_Enable:Bit to activate the Drive Enable of the unit through the
communications bus as long the relevant hardware input is activated. The final signal
interpreted by the unit is given by a logic "AND" between the value of the physical
Drive_Enable input and the Drive_Enable bit of the AssemblyIn.
Speed _Enable:Bit to activate the Speed Enable of the unit through the
communications bus as long the relevant hardware input is activated.
MCP/MCPi - Ref.0612
CANopen protocol - 27/40
The final signal interpreted by the unit is given by a logic "AND" between the value
of the physical Speed_Enable input and the Speed_Enable bit of the AssemblyIn.
Home_Switch:Bit to activate the Home_Switch (home search or reference switch)
through the communications bus.
Lim + :Bit to activate the positive travel limit switch through the communications bus.
Lim - :Bit to activate the negative travel limit switch through the communications bus.
Reset :Digital control of the Reset signal. If the drive is in manual mode (LV13 = 0),
activating this bit implies acting upon the Jog- signal. If it is in automatic mode,
activating this signal resets the movement sequencer.
Stop : Bit to interrupt the movement in progress.
Start :Digital control of the Start signal. If the drive is in manual mode (LV13 = 0),
activating this bit implies acting upon the Jog+ signal. If it is in automatic mode, there
could be two possible situtations:
‡ When activating Start for the first time or after resetting movements, the position
sequencer will start executing the block indicated in the bits of Starting_Block.
‡ If a Stop signal is activated while executing a block, the unit stops. If a Start signal
is then activated, the unit resumes the execution of the block right where it stopped
when the Stop signal was activated.
Command :Field of the AssemblyIn that indicates the action to carry out by the
master element. Refer to the practical examples documented later on.
0
1
2
3
The value of a parameter / variable.
Write a parameter / variable
Reading in the movements table.
Writing in the movements table
Dir_Var: Field of the AssemblyIn structure that depending on the command
requested by the master element can indicate either the IdA identifier of a variable
or the position block to be read/written by the master element (see the practical
examples described later one).
Command Toggle Bit:Bit for the master module to validate the command requested
in the Command bits of the AssemblyIn. This is done negating the current status of
this bit.
AssemblyOut - Status
TABLE 27. AssemblyOut.
B7
B6
B5
Byte 0
Ref_Done
Reg_Status Warning
Byte 1
-------------
Active_Block
Byte 2
Command_
Command_ Command_
Toggle_Bit_Resp Resp
ok
Operation_
Status
Byte 3
-------------
------
Byte 4
Data_Byte_Resp 0
Byte 5
Data_Byte_Resp 1
Byte 6
Data_Byte_Resp 2
Byte 7
Data_Byte_Resp 3
------ ------
B4
------
B3
B2
Error
In_Position ---- Speed_Enable
------
B1 B0
---- ------
(----) Bits reservados.
28/40 - CANopen protocol
MCP/MCPi - Ref.0612
Ref_Done:Bit that indicates to the master element that the "home search" action
has been carried out successfully.
Reg_Status: Bits that indicate the current drive status.
0
1
2
3
Running the internal Start-up test.
Control established. Waiting for power.
Power On. Power and control set, but without torque at the motor.
Torque On. Motor with torque (enabled).
Warning:Bit that indicates that the drive is in a warning state.
ErrorBit that indicates that an error has occurred at the drive.
In_Position: Bit that indicates that the target position of a block has been reached.
The positioning drive is within the in-position zone indicated in parameter PP57 Position Window -.
Speed_Enable:Bit that shows the internal status of the drive's Speed_Enable signal.
It takes into account both the physical input and the bit of the AssemblyIn.
Active_Block: Bits that indicate the number of the block of the positioning table
currently in execution.
Command_Toggle_Bit_Resp: After receiving a new command by changing the
value of Command_Toggle_Bit, the drive starts executing it. When the execution is
over, it makes a copy of the value of Command_Toggle Bit in
Command_Toggle_Bit_Resp. Thus, the master module is informed that the
command has been completed.
Command_Resp: Reflection of the command indicated in the "Command" bits of
the AssemblyIn.
Command_OK: After receiving a new command by changing the value of
Command_Toggle_Bit; the bit "Command_OK" will be executed when the requested
command has been executed successfully. It will be set to zero whenever the
execution of the command generates errors.
MCP/MCPi - Ref.0612
CANopen protocol - 29/40
Operation_Status: Bits that show the "mode" and the "status" of the unit's movement
sequencer.
STOP
5
KernelStopSignal
KernelResetSignal
0
KernelOperationMode
BLOCK IN EXECUTION
2
3
KernelStopSignal
BLOCK
PAUSE
Waiting for the
START signal
JOG
MODE
1
JogPositiveSignal
KernelStartSignal & KernelStopSignal
Waiting for the
START signal not
to be active
4
Change to
KernelOperationMode
from
10-11-12
& JogNegativeSignal
& KernelManMode
(CONTINUOUS)
OR KernelResetSignal
OR KernelStopSignal
JOG mode
working
JogPositiveSignal
OR JogNegativeSignal
& KernelResetSignal
& KernelStopSignal
11
From all the
states
KernelManMode
(INCREMENTAL)
& END OF
MOVEMENT
10
JogPositiveSignal
& JogNegativeSignal
Waiting for JOG
mode to be
deactivated
12
Alarm
BlockEnd
KernelStopSignal
KernelStartSignal
& KernelResetSignal
from
0-1-2-3-4-5
Change to
KernelStartSignal
& KernelStopSignal
KernelResetSignal
6
Reset
AUTOMATIC
MODE
KernelStopSignal
Alarm
15
Mnemonics & simbols
A (A negated)
A
“A” signal not active
Example:
“A” signal active
KernelStopSignal = KernelStopSignal not active
KernelStopSignal = KernelStopSignal active
Transitions between states
X
State
Operation Mode
FIGURE 5.
Operating mode of the drive.
Data_Byte_Resp 0-3:Data bytes that contain the data (value of the variable,
parameter or values of the positioning table) requested by the master module. The
Data_Byte_Resp 0 contains the least significant byte of the requested variable
whereas Data_Byte_Resp 3 contains the most significant byte.
Structure of the assembly. Practical examples.
The structure of the Assembly makes it easier for a master element to carry out
various operations with the drive using a single type of communication message. As
an example, the PLC's carry out operations cyclically with the different slave elements
using the same type of quick message.
See some practical examples that show how the master module must configure each
bit of the AssemblyIN to carry out the required operations.
It is assumed (in all the examples) that, in all of them, the
"Command_Toggle_Bit_Resp" bit returned by the slave element before the master
module sends the AssemblyIN is at zero.
30/40 - CANopen protocol
MCP/MCPi - Ref.0612
Reading a parameter/variable
To read a parameter or a variable of the drive, set the "Command" field to 0.
Then, enter in the 13 bits of the "Dir_Var" field the Id Assembly for the parameter or
variable to be read. This identifier is provided in the third column of the description
tables of the OEM-specific CANopen objects. Thus, for example, to read the SV2
variable (velocity feedback), enter the Id Assembly value of SV2 in hexadecimal
format Î1282h. See TABLE 25.
Finally, set "Command_Toggle_Bit" bit to 1 to execute the command.
Writing a parameter/variable
To write in a parameter or variable of the drive, set the "Command" field to 1.
Then, enter in the 13 bits of the "Dir_Var" field the Id Assembly for the parameter or
variable to be read. This identifier is provided in the third column of the description
tables of the OEM-specific CANopen objects. Thus, for example, to write in the
parameter CP20 (current limit), enter the Id Assembly value of CP20 in hexadecimal
format Î245h. See TABLE 25.
The value to be written in the parameter or variable must be entered in the first four
data bytes and in the required units. See the units in the section on parameters,
variables and commands of the manual of the corresponding MCP or MCIPi drive.
Thus, for example, for a current limit (according to parameter CP20) of 5 A, write a
value of 500 cA (hundredths of an Amp)in the 4 "Data_Bytes"
Finally, set "Command_Toggle_Bit" bit to 1 to execute the command.
Once the slave module has received the message, it checks that the parameter exists
and tries to write in it. If it is successful, the "Command_OK" bit of the message
AssemblyOut is activated.
Movements table
The MCP/MCPi integrate a positioning loop and a positioning feature. The sequence
of movements to be carried out by the positioning feature is programmed using a table
of 127 blocks. Each block indicates a position and it may contain the various
parameters (absolute or incremental position, maximum positioning feedrate,
activation of outputs after executing the block, etc.) that the positioning drive complies
with during the execution of the block.
It is possible to read/write all the elements that make up the movements table using
the Assembly messages. The structure of the positioning block shown in TABLE 28.
describes the 16 words that make up the block. The most significant word is the first
one from the left (word 15) and the least significant one is the first one from the right
(word 0).
MCP/MCPi - Ref.0612
CANopen protocol - 31/40
TABLE 28. Structure of the positioning block.
Description
of the field
Reserved
LOOP
NEXT
PROGOUT
EVENT
TYPE
TIME
InRpos (real)
0001h to 0080h
Value
0000h
0000h
to
FFFFh
“ OR ”
Parts counter
SC00h
00000000h
to
000000FFh
Description
of the field
Value
WORD Nr
15-12
11
VELPOS
10
5-4
0002h
InBand
0003h
ActSpeedReached
0004h
NextSpeedReached
0005h
FastInput (2
0100h
0000h
to
FFFFh
9-8
7
6
POSDEST
VALUE
00000000h
a
FFFFFFFFh
InTpos (theoretical)
“ OR ”
END=xxFEh (1
WORD Nr
0001h
00000000h
to
FFFFFFFFh
3-2
MODE
Absolute
0000 0001 h
Incremental
0000 0002 h
+ Infinite
0000 0003 h
- Infinite
0000 0004 h
Stop
0000 0005 h
1-0
(1
Word Nr 10, <next block> has two bytes with different functions.
Low Byte: indicates the number of the next block to execute (valid values between 1 and 127 and also 254).
High Byte: SC (Conditional jump). To increment the "parts made" counter at the block (REG2), this byte must
take a value other than zero. When the parts counter matches the desired number of parts (REG1), the next block
to be executed will be the one indicated in this byte.
END (xxFEh): Regardless of the value of the high byte (xxh), entering FEh in the low byte will mean the last block
of the program.
(2 If you wish the "next block" condition to be "theoretical position reached" or the activation of the fast input, the value
to enter will be 0102h
Reading the movements table
To read data in the movements table of the drive, set the "Command" field of the
AssemblyIn to 2. The element of the table is selected from the field "Dir_Var". Its 8
least significant bits will indicate the number of the positioning block and the 5 most
significant bits will indicate the "word" to read within the block.
The parameter table is accessed in sets of 4 bytes and it is a must to access even
"word" numbers to avoid interpreting data incorrectly.
Example.
To read the value of the target position (words 2 and 3, where the origin is the lowest
one, i.e. 2) of block number 19, enter the hexadecimal value 213h in the "Dir_Var"
field of the AssemblyIn. Now, when the command is going to be executed, set the
"Command_Toggle_Bit" to 1.
Once the slave module has received the message, it checks that the requested
information exists and, if so, it activates the command "Commmand_OK" and returns
the target position through the AssemblyOut messages until the
Command_Toggle_Bit changes again (change of command or table data
requested).
32/40 - CANopen protocol
MCP/MCPi - Ref.0612
Writing the movements table
To write data in the movements table of the drive, set the "Command" field of the
AssemblyIn to 3. The element of the table is selected from the field "Dir_Var". Its 8
least significant bits will indicate the number of the positioning block and the 5 most
significant bits will indicate the "word" to write within the block.
The parameter table is accessed in sets of 4 bytes and it is a must to access even
"word" numbers to avoid interpreting data incorrectly.
Example.
To change the type of event (next-block condition of the positioning feature, word
7) write words 6 and 7 at the same time. Thus, wen changing a block of the positioning
feature when the position loop reaches the final theoretical position (type 2 event),
write the hexadecimal value 20000h in the Data_Byte". Now, when the command is
going to be executed, set the "Command_Toggle_Bit" to 1.
Once the slave module has received the message, it checks that the data to be written
exists and, if they are written successfully, activates the command "Command_OK"
of the AssemblyOut message.
MCP/MCPi - Ref.0612
CANopen protocol - 33/40
Startup
‡ CAN card description
FIGURE 6.
Description of the CAN® card of an MCP or MCPi module. CANopen protocol.
‡ MS Led Î Module Status Led. Two-color light emitting diode (red and green)
to indicate the status of the drive.
‡ NS Led Î Network Status Led. Two-color light emitting diode (red and green)
to indicate the status of the unit within the communications CAN bus.
‡ "x1" and "x10" switches Î Rotary switches for selecting a digit between 0 and
9 on each one and whose combination gives a number between 0 (when both
are set to 0) and 99 (when both are set to 9). Each node of the bus differs from
the rest in the node number assigned to it using these rotary switches. A unit
may assume any node number between 01 and 98.
Note. 0 and 99 can only be used in special cases that are described later on.
‡ Communication speed selection
When incorporating a new unit in a CANopen network, the first thing to do is to adapt
the communication speed to the speed of the network. There are two rotary selector
switches (x10, x1) and two indicators MS (Module Status) and NS (Network Status)
to make the selection.
The transmission speeds (baudrate) that may be selected in CANopen are 10, 20,
50, 100, 125, 250, 500, 800 and 1000 (in kbits/s).
Selecting procedure
The transmission speed selection mode is enabled when powering the unit up
as long as the rotary selector switches are selecting the number 99 (that is when
both switches are set to 9). The MS and NS LED's blink a green light at the same
time with a period of about 500 ms indicating that the communication baudrate
selection mode is enabled. The following operations are possible in this state:
Verify the selected transmission speed
34/40 - CANopen protocol
MCP/MCPi - Ref.0612
To know the communication speed on the network at that very instant, turn the rotary
selector "x1" to the "0" position. The MS indicator blinks a red light a number of times
and it then turns off for about 1 second. After that time, it starts this same sequence
again.
The number of red blinks between two intervals where the LED is off indicates the
communication baudrate (saved in memory) used to connect the unit to the
network.
The table shows the relationship between the number of red blinks of the MS LED
and the network's baudrate:
TABLE 29. Baudrate verification.
nr of blinks
of MS LED..
Transmission
speed
nr of blinks
of MS LED..
Transmission
speed
1
2
3
4
5
1000 kbit/s
800 kbit/s
500 kbit/s
250 kbit/s
125 kbit/s
6
7
8
9
100 kbit/s
50 kbit/s
20 kbit/s
10 kbit/s
Example.
If the red MS LED blinks 3 times (between the periods when it's off), it will indicate,
according to this table, that the transmission speed (baudrate) is 500 kbits/s.
Selecting the transmission speed
To set the same baudrate at the new unit as that of the communication on the network,
turn its rotary selector "x1" to a position between 1 and 9 to select one of the
baudrates.
TABLE 30. Baudrate selection.
Position of the rotary
switch "x1"
1
2
3
4
5
Transmission
speed
1000 kbit/s
800 kbit/s
500 kbit/s
250 kbit/s
125 kbit/s
Position of the rotary
switch "x1"
6
7
8
9
Transmission
speed
100 kbit/s
50 kbit/s
20 kbit/s
10 kbit/s
Example.
If the network communication baudrate is 500 kBd, the unit being connected must
also transmit at that speed; i. e. its rotary switch "x1" must be set to position 3.
MCP/MCPi - Ref.0612
CANopen protocol - 35/40
At the same time and with the same sequences mentioned earlier, the green light
of the MS LED will blink identifying the selected baudrate.
Once the position has been selected at the "x1" switch, it is necessary to confirm
the selection. To do this, rotate the "x10" switch to position 0. The red blinking light
of the MS LED will indicate the selected baudrate. After this operation, this baudrate
will be saved permanently in the non-volatile memory of the unit. After resetting the
unit, it will assume the baudrate saved in memory as the transmission speed.
‡ Setting the node number
Once the transmission speed of the unit in the network has been set, it must then
be identified within the network. A unique identifier must be assigned to the new
unit to differentiate it from any other unit of the network, thus avoiding collisions. This
identifying number ID will be referred to as node number and must be different for
each unit.
IMPORTANT :It is up to the user to prevent two units from having the same node
number.
The unit's node number is set using the two rotary switches x1 and X10.
Example.
To assign node number 57 to a unit, turn the rotary switch "x10"
to position 5 and rotary switch "x1" to position 7. See figure.
Verify that 10 x 5 + 1 x 7 = 57.
After resetting the drive, it will be identified in the network with the node number
assigned to it.
The node number selection range on a CANopen network is between 01 and 127.
However, for MCP or MCPi units, it can only be selected between 01 and 98.
Remember that node number 99 is reserved for the baudrate selection process
and 00 is treated as 01 since there is no node 00 in CANopen.
On each power-up, the unit assumes as node number the one assigned at rotary
switches "x1" and "x10".
‡ Status indicators
The CAN card of the drive only has two two-color indicator LED's. They are, MS
(Module Status) and NS (Network Status). The MS indicator shows the unit status
and the NS the status of the unit within the CANopen network.
36/40 - CANopen protocol
MCP/MCPi - Ref.0612
In an initial process of the unit, these LED's reach the following states in order to verify
the proper state of the drive.
on
MS
(red)
250 ms
off
on
MS
(green)
250 ms
off
on
NS
(red)
250 ms
off
on
250 ms
NS
(green)
off
Note.MS and NS turn on according to the current status of the bus and of the unit.
MS (Module Status)
This indicator informs about the unit status as such. The states that may be reached,
at this time, are:
Running. The drive is error free. The indicator LED will blink green with a 200 ms
on/off period.
In error. The drive is in an error state. The indicator LED will blink red and faster than
in the previous state with a 50 ms on/off period.
NS (Network Status)
This indicator informs of the unit status within the CANopen network; i.e. of the
CANopen Bus status. See the following tables and figures that set the intermittent
frequencies of the red and green LED's and their names.
‡ Red LED. Error indicator LED
TABLE 31. Error indicator LED. Red.
Error LED (red)
Status
Description
OFF
No errors
Unit running properly
A single blink
Warning limit
reached
At least one of the error counters of the CAN driver
has reached or exceeded the warning level. Too
many error frames.
Double blinking
NMT error
control
event
Either a "guarding" event (slave NMT or master
NMT) or a "heartbeat" event (heartbeat
consumer) has occurred.
Triple blinking
Bus off
The CAN control is in "bus off" mode
MCP/MCPi - Ref.0612
CANopen protocol - 37/40
‡ Green LED. Status indicator LED
TABLE 32. Error indicator LED. Red.
Running LED (green)
Status
Description
ON
Operational
The drive is in an operational state
blinking
Preoperational
The unit is in pre-operational
state
A single blink
Stopped
The unit is in a stop state.
50 ms
on
flickering
(red)
off
on
flickering
(green)
off
on
blincking
(red)
off
on
blincking
(green)
off
on
single flash
(red)
off
on
single flash
(green)
off
on
doble flash
(red)
off
on
triple flash
(red)
off
on
triple flash
(green)
off
200 ms
6 x 200 ms
1000 ms
FIGURE 7.
Names and blinking times of the NS (Network Status) indicator LED.
38/40 - CANopen protocol
MCP/MCPi - Ref.0612
User notes.
MCP/MCPi - Ref.0612
CANopen protocol - 39/40
Fagor subsidiaries:
SPAIN
Headquarters:
FAGOR AUTOMATION S. COOP.
Bº San Andrés 19, Apdo. 144
E-20500 ARRASATE-MONDRAGON
www.fagorautomation.com
E-mail: [email protected]
Tel:
34-943-719200 / 34-943-039800
Fax: 34-943-791712
34-943-771118 (Service Dept.)
Usurbil:
FAGOR AUTOMATION S.COOP.
Planta de Usurbil
San Esteban s/n Txoko-Alde
E-20170 USURBIL
Tel:
34-943-000690
Fax: 34-943-360527
E-mail: [email protected]
Eskoriatza:
FAGOR AUTOMATION S.COOP.
Planta de Eskoriatza
Torrebaso Pasealekua, 4, Apdo. 50
E-20540 ESKORIATZA
Tel:
34-943-719200
Fax: 34-943-039783
Barcelona:
FAGOR AUTOMATION, Catalunya
Parc Tecnològic del Vallès,
Tecnoparc II
Edificio I Módulo Ab
C/Argenters, 5
08290 Cerdanyola del Vallès
Tel.: 34-93-4744375
Fax: 34-93-4744327
E-mail:
[email protected]
FRANCE
FAGOR AUTOMATION FRANCE Sàrl
Parc Technologique de La Pardieu
16 Rue Patrick Depailler
63000 CLERMONT FERRAND
Tel.:
33-473277916
Fax: 33-473150289
[email protected]
GERMANY
FAGOR AUTOMATION GmbH
Postfach 604 D-73006 GÖPPINGEN
Nördliche Ringstrasse, 100
Tel.:
49-7161 15685-0
Fax: 49-7161 1568579
E-mail: [email protected]
PORTUGAL
Nanjing:
FAGOR AUTOMATION LTDA.
Sucursal Portuguesa
Rua Gonçalves Zarco nº 1129-B-2º
Salas 210/212
4450 LEÇA DA PALMEIRA
Tel:
351 22 996 88 65
Fax: 351 22 996 07 19
E-mail: [email protected]
FAGOR AUTOMATION EQUIPMENT LTD.
NANJING OFFICE
Room 803, Holiday Inn (Nanjing)
45 Zhongshan Beilu, Nanjing 210008
Jiangsu Provence
Tel: 86-25-3328259
Fax: 86-25-3328260
E-mail: [email protected]
USA
Chicago:
CHINA
Guangzhou:
FAGOR AUTOMATION CORP.
2250 Estes Avenue
ELK GROVE VILLAGE, IL 60007
Tel: 1-847-9811500
1-847-9811595 (Service)
Fax:1-847-9811311
E-mail: [email protected]
Beijin FAGOR AUTOMATION Equipment
Co.Ltd., Guangzhou Rep.Office
Room 915 Lihao Plaza No. 18 Jichanglu
Baiyun District - GUANGZHOU 510405
Tel: 86-20-86553124
Fax: 86-20-86553125
E-mail: [email protected]
California:
Shanghai:
FAGOR AUTOMATION West Coast
3176 Pullman Ave., Unit 110
COSTA MESA, CA 92626
Tel: 1-714-9579885
Fax: 1-714-9579891
E-mail: [email protected]
New Jersey:
FAGOR AUTOMATION East Coast
Tel:
1-973-7733525
Fax: 1-973-7733526
E-mail: [email protected]
South East:
FAGOR AUTOMATION SOUTH EAST
4234 Amber Ridge Ln- VALRICO, FL 33594
Tel:
813 654 4599
E-mail: [email protected]
Ohio:
FAGOR AUTOMATION OHIO BRANCH
Westerville OH 43081
Tel:
1 614-855-5720
Fax: 1 614-855-5928
E-mail: [email protected]
CANADA
Ontario:
FAGOR AUTOMATION ONTARIO
Unit 3, 6380 Tomken Road
MISSISSAUGA L5T 1Y4
Tel:
1-905-6707448
Fax: 1-905-6707449
E-mail: [email protected]
Montreal:
FAGOR AUTOMATION QUEBEC
Tel.:
1-450-2270588
Fax: 1-450-2276132
E-mail: [email protected]
Windsor:
FAGOR AUTOMATION WINDSOR
Tel.:
1-519 944-5674
Fax: 1-519 944-2369
BRAZIL
ITALY
FAGOR ITALIA S.R.L.
Pal. CD3 P.T. - Via Roma, 108
20060 CASSINA DE PECCHI (MI)
Tel.:
39-0295301290
Fax: 39-0295301298
E-mail: [email protected]
UNITED KINGDOM
FAGOR AUTOMATION UK Ltd.
2 A Brunel Close
Drayton Field Industrial Estate
Daventry Northamptonshire
NN11 5RB
Tel:
44-1327 300067
Fax: 44-1327 300880
E-mail: [email protected]
40/40 - CANopen protocol
FAGOR AUTOMATION DO BRASIL
COM.IMP. E EXPORTAÇAO LTDA.
Rua Homero Baz do Amaral, 331
CEP 04774-030 SAO PAULO-SP
Tel.:
55-11-56940822
Fax: 55-11-56816271
E-mail: [email protected]
CHINA, P.R.
Beijing:
BEIJIN FAGOR AUTOMATION EQUIPMENT
Co.,LTD.
C-1 Yandong Building,
No.2 Wanhong Xijie, Xibajianfang
Chaoyang District
BEIJING, Zip Code: 100015
Tel: 86-10-84505858
Fax: 86-10-84505860
E-mail: [email protected]
Beijing FAGOR AUTOMATION equipment
Co., Ltd - SHANGHAI Representative Office
Room No.1906
LianTong International Building
No. 547 Tianmu Xilu
SHANGHAI, P.C. 20070
Tel: 86-21-63539007
Fax: 86-21-63538840
E-mail: [email protected]
HONG KONG
FAGOR AUTOMATION (ASIA) LTD.
Room 628. Tower II, Grand Central Plaza
138 Shatin Rural Committee Road
Shatin, HONG KONG
Tel: 852-23891663
Fax: 852-23895086
E-mail: [email protected]
KOREA, Republic of
FAGOR AUTOMATION KOREA, LTD.
Room No. 707 Byucksan Digital Valley 2nd
481-10 Gasan-dong. Geumcheon-gu
Seoul 153-803, Korea
Tel: 82 2 2113 0341
Fax: 82 2 2113 0343
E-mail: [email protected]
TAIWAN, R.C.O.
FAGOR AUTOMATION TAIWAN CO., LTD.
Nº 24 Ta-Kuang St. Nan-Tun Dist. 408
Taichung, TAIWAN R.O.C.
Tel: 886-4-2 3271282
Fax: 886-4-2 3271283
SINGAPORE
FAGOR AUTOMATION (S) PTE.LTD.
240 MacPherson Road
06-05 Pines Industrial Building
SINGAPORE 348574
Tel: 65-68417345 / 68417346
Fax: 65-86417348
E-mail: [email protected]
MALAYSIA
FAGOR AUTOMATION (M) SDN.BHD.
(638038-H)
No.39, Jalan Utama 1/7
Taman Perindustrian Puchong Utama
47100 Puchong, Selangor Darul Ehsan
Tel: +60 3 8062 2858
Fax: +60 3 8062 3858
E-mail: [email protected]
MCP/MCPi - Ref.0612