PROTOCOLO CANopen

FAGOR AUTOMATION S.COOP.
MCP/MCPi
~ Protocolo CANopen ~
Ref.0612
Título
Tipo de documentación
Denominación
Referencia
Software
WinDDSSetup
Documento electrónico
Headquarters
MCP/MCPi. Protocolo CANopen.
Arquitectura, topología y comunicación en redes CANopen.
MAN_ MCP/MCPi_CANopen (cas.).
Ref.0612
V01.05 (MCP), V01.01 (MCPi)
A partir de la versión V0612
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]
Teléfono: 34-943-719200
Fax:
34-943-771118 (Servicio de Asistencia Técnica)
La información descrita en este manual puede estar sujeta a variaciones motivadas
por modificaciones técnicas. FAGOR AUTOMATION, S. Coop. se reserva el
derecho de modificar el contenido del manual, no estando obligada a notificar las
variaciones.
Se han contrastado los contenidos de este manual y sus coincidencias con el
producto descrito. Aún así, es posible el deslíz de algún error introducido de manera
involuntaria y, es por ello que, no se garantiza una coincidencia absoluta. No
obstante, es comprobada regularmente la información contenida en el documento,
procediéndose a realizar las correcciones oportunas que quedarán incluídas en
una posterior edición.
Todos los derechos reservados. No puede reproducirse ninguna parte de esta
documentación, transmitirse, transcribirse, almacenarse en un sistema de
recuperación de datos o traducirse a ningún idioma sin premiso expreso de Fagor
Automation S. Coop.
2/40 - Protocolo CANopen
MCP/MCPi - Ref.0612
GARANTÍA
GARANTÍA INICIAL:
Todo producto fabricado o comercializado por FAGOR tiene una garantía de 12 meses para
el usuario final.
Para que el tiempo que transcurre entre la salida de un producto desde nuestros almacenes
hasta la llegada al usuario final no juegue en contra de estos 12 meses de garantía, el fabricante
o intermediario debe comunicar a FAGOR el destino, identificación y fecha de instalación de
la máquina a través de la Hoja de Garantía que acompaña a cada producto.
La fecha de comienzo de la garantía para el usuario será la que figura como fecha de
instalación de la máquina en la Hoja de Garantía.
Este sistema nos permite asegurar los 12 meses de garantía al usuario.
FAGOR da un plazo de 12 meses al fabricante o intermediario para la instalación y venta del
producto, de forma que la fecha de comienzo de garantía puede ser hasta un año posterior
a la salida del producto de nuestros almacenes, siempre y cuando se nos haya remitido la hoja
de garantía. Esto supone en la práctica la extensión de la garantía a dos años desde la salida
del producto de los almacenes de Fagor. En caso de que no se haya enviado la citada hoja,
el período de garantía finalizará a los 15 meses desde la salida del producto de nuestros
almacenes.
FAGOR se compromete a la reparación o sustitución de un producto desde su lanzamiento,
y hasta 8 años después de la fecha de su desaparición de catálogo.
Compete exclusivamente a FAGOR determinar si la reparación entra dentro del marco definido
como garantía.
CLÁUSULAS EXCLUYENTES:
La reparación se realizará en nuestras dependencias. Por tanto, quedan fuera de garantía
todos los gastos de transporte o los ocasionados en el desplazamiento de su personal técnico
para realizar la reparación de un equipo, aún estando éste dentro del período de garantía antes
citado.
La citada garantía se aplicará siempre que los equipos hayan sido desinstalados de acuedo
con las instrucciones, no hayan sido maltratados o sufrido desperfectos por accidente o
negligencia y no hayan sido intervenidos por personal no autorizado por FAGOR.
Si, una vez realizada la asistencia o reparación, la causa de la avería no es imputable a nuestro
producto, el cliente está obligado a cubrir todos los gastos ocasionados ateniéndose a las
tarifas vigentes.
No están cubiertas otras garantías implícitas o explícitas y FAGOR AUTOMATION no se hace
responsable bajo ninguna circunstancia de otros daños o perjuicios que pudieran ocasionarse.
CONTRATOS DE ASISTENCIA:
Están a disposición del cliente Contratos de Asistencia y Mantenimiento tanto para el período
de garantía como fuera de él.
MCP/MCPi - Ref.0612
Protocolo CANopen - 3/40
DECLARACIÓN DE CONFORMIDAD
Fabricante:
Fagor Automation, S. Coop.
Bº San Andrés 19, C.P. 20500, Mondragón - Guipúzcoa - (SPAIN)
Declaramos bajo nuestra exclusiva responsabilidad la conformidad del producto:
Sistema de regulación AC Brushless Fagor
compuesto por los siguientes módulos y motores:
Módulos reguladores:
Series MCP y MCPi
Motores AC:
Series FXM, FKM, FSA y FSP
al que se refiere esta declaración,
con los requisitos básicos de las Directivas Europeas 73/23/CE de Baja Tensión
(Norma Básica de Seguridad; Equipo Eléctrico de las Máquinas EN60204-1:95) y
92/31/CE de Compatibilidad Electromagnética (EN 61800-3:1996, Norma
específica de Compatibilidad Electromagnética para Sistemas de Regulación).
En Mondragón a 15 de Septiembre de 2006
PRESENTACIÓN
Este manual ofrece una información descriptiva y detallada del protocolo CANopen
sobre la placa CAN de los reguladores MCP y MCPi, de la arquitectura, topología y
comunicación CANopen en la red y la puesta en marcha del equipo.
Si es la primera vez que se realiza la instalación, conviene leer este documento
completo.
Ante cualquier duda o necesidad no dude en consultar con nuestros técnicos en
cualquiera de las oficinas subsidiarias.
Gracias por elegir Fagor.
4/40 - Protocolo CANopen
MCP/MCPi - Ref.0612
ÍNDICE GENERAL
PROTOCOLO CANopen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Arquitectura de la red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Topología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Cable de conexión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
Longitud máxima . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
Comunicación en la red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Trama CAN estándar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Conexión predefinida CANopen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
NMT, Network Management. Proceso de arranque y control de red . . . . . . . . . .11
PDO, Objeto de Datos de Proceso. Canal rápido . . . . . . . . . . . . . . . . . . . . . . . . .14
SDO, Objeto de Datos de Servicio. Canal lento . . . . . . . . . . . . . . . . . . . . . . . . . .17
Objeto de emergencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
Descripción del diccionario de objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
Descripción de los PDOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
Puesta en marcha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
Descripción de la tarjeta CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
Selección de la velocidad de comunicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
Determinación del nº de nodo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
Indicadores de estado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
MCP/MCPi - Ref.0612
Protocolo CANopen - 5/40
PÁGINA EN BLANCO
6/40 - Protocolo CANopen
MCP/MCPi - Ref.0612
PROTOCOLO CANopen
Introducción
CANopen es un protocolo de comunicación de red basado en el sistema de Bus
CAN (desarrollado por BOSCH a mediados de los 80 y orientado al mundo de la
automoción). CANopen está definido como una capa de aplicación uniforme en la
especificación DS301 editada por la entidad que regula la especificación CIA (Can
In Automation).
CAN es un sistema de Bus Multimaster que contrasta con otros sistemas de Bus
en que los módulos conectados a él no son direccionados por los identificadores
de los mensajes. Así, los nodos podrán ir dejando mensajes en el Bus siempre que
éste se encuentre libre de tráfico. Los conflictos en el bus son resueltos en base a
cierta prioridad asignada a los mensajes, establecida en el propio COB ID
(Communication Object Identifier) y claramente asignada a los objetos de
comunicación. El COB ID que contenga el menor valor identifica el mensaje de
mayor prioridad. Esta característica proporciona una autorregulación de
prioridades en el Bus sin la gestión de ningún elemento maestro (master).
Arquitectura de la red
‡ Topología
Para construir una red CAN simple, donde la comunicación va a ser establecida con
protocolo CANopen, será necesario mínimamente un elemento esclavo, un
elemento maestro (p. ej. un PC con tarjeta de bus de campo CAN) y un cable de
conexión como el que se muestra en la FIGURA 1.
Podrán disponerse de hasta 127 elementos esclavos independientes. Éstos,
podrán adoptar números de nodo comprendidos entre 1 y 127.
Recuérdese que el nodo 0 no existe como tal y queda reservado para ciertos
mensajes genéricos utilizados por el elemento maestro.
En la red deberán ser conectadas entre sí todas las líneas CAN_H, CAN_L y
CAN_SHLD.
MAESTRO
CANopen
Conector
CANopen
del PC
DRIVE 1
DRIVE 2
DRIVE 3
Conector
CANopen
Conector
CANopen
Conector
CANopen
CAN_L
2
5
120 Ω
5
CAN_H
7
CAN_SHLD
4 Blanco
4 CAN_H
3 Malla
3 CAN_SHLD
2 Marrón
2 CAN_L
4
120 Ω
3
2
1
Nota: Una resistencia terminadora de 120 Ω será instalada por el instalador de la red en cada
módulo extremo del bus CANopen. En la red de la figura han sido instaladas en el PC y en el
DRIVE3 que son los módulos extremos del bus. Si p.ej. en lugar del PC se hubiese ubicado un
DRIVE en esa posición éste sería entonces un extremo del bus y habría que instalar la resistencia terminadora de 120 Ω en ese DRIVE y no en el PC. El resto de los módulos que forman
parte del bus no estarán ubicados en los extremos del mismo y, por tanto, no se instalará en
ellos ninguna resistencia. Véase figura.
FIGURA 1.
Topología de una red CAN.
MCP/MCPi - Ref.0612
Protocolo CANopen - 7/40
‡ Cable de conexión
Para realizar la conexión de la tarjeta CAN, dispuesta en un regulador, a una red
CANopen, será necesario disponer de un cable CAN formado por una manguera de
dos hilos con pantalla exterior. En uno de los extremos de la manguera se incorpora
un conector “Open Style” enchufable de 5 vías y paso 5 mm. La malla irá conectada
al pin 3 de este conector. Para más detalles, véase FIGURA 2.
Pin
Señal
Color del hilo
5
N.C.
----
4
CAN_H
Blanco
3
CAN_SHLD
Malla
2
CAN_L
Marrón
1
N.C.
----
CANopen
Cable CAN entre
PC y DRIVE1
Pin
2
7
4
5
Cable CAN entre
DRIVE2 y DRIVE3
Cable CAN entre
DRIVE1 y 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
Vista frontal del conector Sub-D, F9 del extremo
del cable CAN
FIGURA 2.
Cables de conexión entre módulos conectados a una red CAN.
Todas las líneas CAN_H, CAN_L y malla de cada uno de los módulos que conforman
la red deberán ser conectadas entre sí.
En los dos módulos extremos del bus de CAN (y sólo en éstos) deberán ser
instaladas externamente por el usuario (entre los pines 2 y 4 del conector Open
Style si el módulo extremo es un regulador ó 2 y 7 del conector Sub-D, M9 si es el
módulo extremo es el PC) una resistencia terminadora de línea de 120 Ω en cada
uno con la finalidad de evitar reflexiones (rebotes), es decir, problemas de
transmisión.
‡ Longitud máxima
En la siguiente tabla quedan reflejadas las longitudes máximas de la red en función
de las diferentes velocidades de transmisión:
TABLA 1.
Longitud máxima de una red CAN según la velocidad de transmisión
Velocidad de
transmisión
Longitud de red
Velocidad de
transmisión
Longitud de red
1000 kbit/s
30 metros
250 kbit/s
250 metros
800 kbit/s
50 metros
125 kbit/s
500 metros
500 kbit/s
100 metros
≤ 50 kbit/s
1000 metros
8/40 - Protocolo CANopen
MCP/MCPi - Ref.0612
Comunicación en la red
‡ Trama CAN estándar
Las tramas estándar de CAN contienen entre 44 y 108 bits útiles. Además, en función
de los datos enviados, pueden ser insertados en la trama por los drivers de CAN
hasta 23 bits “de relleno” de manera que el máximo nº de bits que se llega a alcanzar
en el envío de una trama es de 131.
La identificación de los campos de bits en la trama CAN es:
‡ <Start bit>: Inicio de la trama.
‡ <Arbitration>: Campo de arbitraje que contiene el identificador y el tipo de mensaje que va a ser enviado.
‡ <Control bits>: Campo de control que contiene el nº de bytes de datos.
‡ <Data field>: Bytes de datos (de 0 a 8 bytes).
‡ <CRC>: Caracteres de chequeo de redundancia cíclica según el algoritmo CRC16.
‡ <Acknowledge>: Reconocimiento de trama.
‡ <End>: Bits de final de trama.
Bit Length
1
12
6
0-8 bytes
16
2
7
Start bit
Arbitration
Control bits
Data field
CRC
Acknowledge
End
FIGURA 3.
Trama CAN estándar.
‡ Conexión predefinida CANopen
Con CANopen, la transmisión de datos, el disparo de eventos, la señalización de
estados de error, ... es realizada mediante objetos de comunicación. Con esta
finalidad, cada objeto de comunicación lleva asignado un COB ID en la red.
Los objetos más importantes en CANopen son:
‡ <NMT>: Objetos de tratamiento de la red.
‡ <SYNC>: Objetos de sincronización.
‡ <EMCY>: Objetos de mensajes de error.
‡ <PDO>: Objetos de proceso.
‡ <SDO>: Objetos de servicio.
Con el objetivo de facilitar la configuración de redes CAN simples, existe un set de
COB IDs ya predefinidos.
MCP/MCPi - Ref.0612
Protocolo CANopen - 9/40
COB ID
Identificador del mensaje puesto en la red implementado en los 11 bits del
identificador en la trama de CAN. Su estructura es:
10 9
8
7
6
código de función
5
4
3
2
1
0
nº de nodo: 0 - 127
FIGURA 4.
Estructura del COB ID.
Con el código de función 1 (objeto de emergencia) pueden generarse hasta 128
objetos diferentes dependiendo del nº de nodo dispuesto en el mensaje. Los objetos
con identificador desde 0x81 hasta 0xFF son objetos de emergencia emitidos por
el nodo cuyo número va implícito en el identificador. El 0x80 es un objeto diferente
emitido por el elemento maestro (sin nº de nodo asignado) de mayor prioridad que
los mensajes de emergencia y que sirve de sincronismo para el bus de
comunicaciones.
Dependiendo de que el nº de nodo aparezca o no en la cabecera del mensaje se
establecen los objetos Broadcast (nodo 0) y Per to Per (nodo>0). Los objetos
“Broadcast” son interpretados por todos los nodos del bus y los objetos “Per to Per”
permiten establecer conversaciones entre dos elementos de la red.
- Objetos “Broadcast”
TABLA 2.
Objetos Broadcast.
Objeto
Bits de código
de función
COB ID
Parámetros de
comunicación
NMT Module Control
0000
000h
---------
SYNC
0001
080h
1005h, 1006h, 1007h
TIME STAMP
0010
100h
1012h, 1013h
El COB ID de los objetos Broadcast es único al no llevar asignado ningún número
de nodo. Será interpretado por todos los nodos presentes en la red CANopen.
10/40 - Protocolo CANopen
MCP/MCPi - Ref.0612
- Objetos “Per to Per”
TABLA 3.
Objetos Per to Per.
Objeto
Bits de código COB ID
de función
Parámetros de
Parámetros de
mapeado del PDO comunicación
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
Nota. Entiéndase el concepto de los términos rx y tx desde un punto de vista del bus.
Los objetos Per to Per implican establecer una comunicación entre dos nodos
concretos. Esto obliga a los COB ID a incluir (según el objeto del que se trate) el nº
de nodo al que son dirigidos o el nº de nodo desde el que son emitidos (0-127 en
ambos casos). De ahí el rango especificado en la TABLA 3.
En “parámetros de comunicación” se encuentra el objeto de comunicaciones en
el que son configurados diferentes aspectos relativos a tal objeto.
En “parámetros de mapeado del PDO” se encuentra el objeto de mapeo en el que
son configurados los diferentes objetos mapeados para el correspondiente PDO.
‡ NMT, Network Management. Proceso de arranque y control de red
Una vez aplicada la tensión a un nodo CANopen se establece el proceso de
arranque (start-up) inicializando sus variables, realizando su auto-chequeo, ...
Realizada esta labor, cada nodo envía un mensaje de “Boot-Up” (arranque) a
través del bus para hacer saber al elemento maestro que un nuevo nodo ha
pasado a formar parte de la red CANopen.
(Boot-Up)
NMT - maestro Í NMT - esclavos.
COB ID
Byte 0
0x700 + ID de nodo
0
Tras haber sido realizada correctamente esta tarea, el nodo pasa automáticamente
a un estado preoperacional manteniéndose en él hasta que el elemento maestro,
mediante un mensaje de control de red (NMT), le solicita el paso a un estado
operacional:
MCP/MCPi - Ref.0612
Protocolo CANopen - 11/40
(Control del módulo)
NMT- maestro Î NMT- esclavos.
COB ID
Byte 0
Byte 1
0x000
CS
ID de nodo
Esta acción puede o no establecerse como “Broadcast” dependiendo del valor
indicado en el byte 1 del campo de datos. Así, si el valor del byte 1 es cero, la
acción se establece como “Broadcast”. Si es distinto de cero y menor de 128, su
valor indicará el nodo al que va dirigida la orden.
El valor indicado en el byte 0 del campo de datos del mensaje CAN establece la orden
a realizar. Véase la siguiente tabla.
CS.
TABLA 4.
Byte 0 del campo de datos del mensaje CAN. Orden a llevar a cabo.
Especificador de
comando (byte 0)
Servicio de NTM
(control del módulo)
1
Arrancar el nodo remoto - paso a operacional -
2
Detener el nodo remoto - paso a stop -
128
Introducir el estado preoperacional - paso a preoperacional -
129
Inicializar el nodo - reset del ó de los nodos seleccionados -
130
Inicializar la comunicación - reset del proceso de comunicación en
el nodo o los nodos indicados -
Dependiendo del valor especificado en estos bytes del campo de datos puede
modificarse el estado en el que se encuentran uno o todos los nodos presentes en
la red.
Tras un arranque satisfactorio de la red, el elemento maestro tiene la opción de
comprobar cíclicamente que todos los nodos permanecen activos dentro de ella.
Con - Node Guarding - el elemento maestro envía cíclicamente (bajo unos tiempos
previamente preestablecidos y comprobados) un mensaje “broadcast” sin dato
alguno y al cual responden todos los nodos y donde se incluye el estado en el que
se encuentra cada uno de ellos. Estos mensajes son:
(Node Guarding)
NMT- maestro Î NMT- esclavos.
COB ID
0x700 + ID de nodo
NMT- maestro Í NMT- esclavos.
COB ID
Byte 0
0x700 + ID de nodo
Bit 7 - Toggle bit -
12/40 - Protocolo CANopen
Bits 6-0 - Estado
MCP/MCPi - Ref.0612
Estado.
TABLA 5.
Node Guarding. Estados.
Valor
Estado
0
Inicializando
1
Desconectando *
2
Conectando *
3
Preparando *
4
Parado
5
En funcionamiento
127
En fase previa al funcionamiento normal
* Estos estados existen únicamente si el dispositivo soporta “extended boot-up”
Atención: La tarjeta CAN de los reguladores MCP y MCPi no soporta esta
característica.
Objetos relacionados.
100Ch
Guard Time
100Dh
Life Time
100Eh
Node Guarding Identifier ( por defecto: 700 + ID de nodo )
Alternativamente, un nodo puede ser configurado con el fin de generar un mensaje
periódico denominado “Heartbeat”.
(Heartbeat)
Productor Î Consumidor / es.
COB ID
Byte 0
0x700 + ID de nodo
Estado
Estado.
TABLA 6.
Heartbeat. Estados.
Estado
Significado
0
Boot-up
4
Parado
5
En funcionamiento
127
En fase previa al funcionamiento normal
El consumidor del “Heartbeat” normalmente es el elemento maestro que verifica el
envío por parte de cada uno de los nodos del mensaje de “Heartbeat” con una
periodicidad establecida dentro de unos determinados márgenes y que actuará en
consecuencia siempre que ésto no se cumpla en alguno de los nodos.
Atención: Un nodo no puede soportar “Heartbeat” y “Node Guarding” simultáneamente.
MCP/MCPi - Ref.0612
Protocolo CANopen - 13/40
(Sync)
Productor Î Consumidor / es.
COB ID
0x080
Objeto encargado de sincronizar el bus. Es cíclico, “Broadcast” y tiene máxima
prioridad en el bus después del NMT. Está directamente relacionado con el
tratamiento de PDOs.
Objetos relacionados.
1005 h
COB-ID del mensaje de sincronismo
1006 h
Período del ciclo de comunicación
1007 h
Longitud de la ventana síncrona
‡ PDO, Objeto de Datos de Proceso. Canal rápido
Los objetos de datos de procesos (PDOs) permiten llevar a cabo la transmisión de
datos en tiempo real y con identificadores de alta prioridad. Los telegramas de datos
pueden disponer de un máximo de 8 Bytes. El intercambio de datos puede realizarse
mediante eventos o de modo síncrono, según se requiera. El intercambio de
mensajes mediante eventos permite reducir drásticamente la carga en el bus con
respecto al modo síncrono.
Protocolo PDO
Este protocolo se utiliza para transmitir los datos al/desde el bus evitando sobrecargarlo con información redundante.
En los mensajes PDO (en los bytes de datos) se transmiten única y exclusivamente los valores de variables de distintos nodos eliminándose el envío de sus
identificadores. Para que esto pueda llevarse a cabo sin ningún tipo de error, los
elementos maestro y esclavo han concertado previamente qué variables van a ser
enviadas dentro de cada PDO (mapeo). Esta asignación se establece mediante los
objetos “PDO Mapping Parameter”. El tipo de comunicación que se establece
para cada PDO (sincronizada o por evento) será determinado por los objetos
“Communication Parameter”.
En función de quién emite el mensaje PDO se hablará de PDO de transmisión (del
elemento esclavo al maestro) ó de PDO de recepción (del elemento maestro al
esclavo).
Nota. El Standard DS301 establece cuatro PDOs de transmisión y otros 4 de
recepción por cada elemento esclavo. No es obligatorio implementar todos para
el cumplimiento de la norma.
14/40 - Protocolo CANopen
MCP/MCPi - Ref.0612
Mapeo y tipo de comunicaciones
Supóngase que en el objeto de mapeo del segundo PDO de transmisión se dispone de los siguientes valores:.
TABLA 7.
Mapeo y tipo de comunicaciones
Objeto 0x1A01
Subíndice
Valor
Significado
0
2
Se mapean dos objetos en este PDO
1
0x60000208
Objeto: 0x6000 (*)
Subíndice: 0x02
Dato: 8 bits
2
0x64010110
Objeto: 0x6401 (*)
Subíndice: 0x01
Dato: 16 bits
* Su descripción viene dada en la siguiente tabla.
Valor Dword (32 bits)
TABLA 8.
Descripción.
Bits 31-16
Bits 15-8
Bits 14-0
Indice
Subíndice
Nº de bits de datos del objeto
Supóngase que en el objeto de comunicaciones del segundo PDO de transmisión
se dispone de los siguientes valores:
TABLA 9.
Ej. de objeto del segundo PDO.
Objeto 0x1801
Subíndice
Valor
Significado
0
5
El objeto 0x1801 consta de 5 subíndices
1
0x00000280
PDO existe, RTR no permitido, 11 bits ID, COB ID=280h.
2
0xBC
La transmisión del PDO será cíclica y a través del bus tras
haber recibido 188 mensajes de sincronismo.
3
0x000A
El tiempo de “inhibit time” entre PDOs es de:
10 x 100 µs = 1 ms.
4
----------
Reservado.
5
0x0000
Intervalo del “event timer” 0.
Valor del subíndice 1 (COB ID)
TABLA 10. Valor del subíndice 1 (COB ID)
Bit 31
Bit 30
Bit 29
Bits 28-11
0ÎPDO existe
0ÎRTR permitido
0ÎCAN ID 11 bits Parte alta
1ÎPDO no existe 1ÎRTR no permitido 1ÎCAN ID 29 bits del COB ID
Bits 10-0
Parte baja
del COB ID
(si CAN ID
(si CAN ID
es de 29 bits). es de 29 bits).
COB ID
(si CAN ID es
de 11 bits).
MCP/MCPi - Ref.0612
Protocolo CANopen - 15/40
Valor del subíndice 2 ( Tipo de transmisión )
TABLA 11. Valor del subíndice 2 (tipo de transmisión).
Tipo de
transmisión
Condición de disparo del PDO
Transmisión del
( B = se necesitan ambos, O = uno o ambos ) PDO
SYNC
RTR
Evento
Objeto
SYNC
recibido
Recibida
solicitud de
transmisión
remota
Cambio de valor
de la interrupción
del temporizador
0
B
1-240
O
B
Síncrona (SYNC), cíclica
241-251
252
Síncrona (SYNC), acíclica
Reservado
B
B
Síncrona (SYNC) tras RTR
253
O
Asíncrona (ASYNC) tras RTR
254
O
O
Asíncrona (ASYNC), evento
específico de fabricante
255
O
O
Asíncrona (ASYNC), evento
específico del perfil de dispositivo.
donde:
‡ <SYNC> significa que la transmisión del PDO está relacionada con la recepción
del mensaje de sincronismo.
‡ <ASYNC> significa que la transmisión del PDO no tiene ninguna relación con
la recepción del mensaje de sincronismo.
Tipo de transmisión = 0. Síncrona y acíclica. Los mensajes son enviados únicamente si se produce un evento, y en este caso, el mensaje es enviado sincrónicamente con el siguiente mensaje de sincronismo.
Se entiende por evento a un cambio en el valor de la variable ó (si es soportado
por el equipo, objetos de comunicaciones con subíndice 5) un determinado tiempo
transcurrido.
Tipo de transmisión = 1 a 240. El PDO es transmitido tras haber recibido el nº de
mensajes de sincronismo especificados en el tipo de transmisión.
Tipo de transmisión = 252 a 253. Valores únicamente posibles en los PDOs de
transmisión. En ambos casos, el PDO es enviado como respuesta a una trama
RTR del elemento maestro. La diferencia radica en que el tipo de transmisión =
252 actualiza las variables con la llegada de los sincronismos y el tipo de transmisión = 253 actualiza las variables y las envía con la recepción de la trama RTR.
Tipo de transmisión = 254. El PDO se transmite cuando se produce algún evento
específico de fabricante.
Tipo de transmisión = 255. El PDO se transmite cuando se produce algún evento
específico del perfil de dispositivo.
16/40 - Protocolo CANopen
MCP/MCPi - Ref.0612
Valor del subíndice 3 (tiempo de inhibición ó deshabilitación)
Especifica el mínimo intervalo de tiempo (en incrementos de 100 µs) que transcurre
entre PDOs. Este intervalo de tiempo no puede ser modificado mientras el valor del
bit 31 del subíndice 1 (COB ID) sea 0 (el PDO existe).
Valor del subíndice 5 (temporizador de eventos)
Especifica el valor del temporizador de eventos (en incrementos de 1ms) cuando
el tipo de transmisión es 254 ó 255.
Ejemplo explicativo del sentido del “tiempo de inhibición” y del “temporizador de
eventos”.
Cuando se programa un PDO de transmisión de tipo 254 en el que se incluye una
variable de posición se presentan dos situaciones distintas. En tanto que el elemento
a emitir el PDO esté parado (sin variación en su posición) no será necesario ningún
envío. Si se programa un temporizador de eventos (event timer) de 10 ms, aunque
el elemento no varíe su posición (no se mueva) enviará PDOs cada 10 ms indicando
su posición. Al iniciar el movimiento tratará de enviar PDOs constantemente, ocupando así todo el bus con esta información. Con la finalidad de evitar esta situación
puede programarse un tiempo de inhibición (inhibit time) de 2 de manera que mientras se encuentre en movimiento únicamente envía PDOs cada 2 ms.
El mensaje
Atendiendo a la configuración expuesta en las tablas anteriormente señaladas, el
mensaje PDO (con los bytes que lo conforman) queda de la siguiente forma:
TABLA 12. Mensaje PDO.
COB ID
Byte 0
Byte 1
Byte 2
0x280
8 bits de datos del Parte baja de los 16 bits de Parte alta de los 16 bits de
+ ID del nodo objeto 0x6000
datos del objeto 0x6000
datos del objeto 0x6401
La transmisión del PDO será cíclica y es suministrada al bus tras haber recibido 188
mensajes de sincronismo.
Objetos relacionados
1004 h
Nº de PDOs soportados
‡ SDO, Objeto de Datos de Servicio. Canal lento
Los objetos de datos de servicio (SDOs) permiten llevar a cabo la lectura y escritura
de las entradas del diccionario de objetos (parámetros, variables, comandos, ...). Así,
haciendo uso de SDOs, cualquier nodo puede ser configurado por el elemento
maestro. El mensaje SDO, por defecto, lleva previamente asignado un identificador
de baja prioridad. Los datos transmitidos mayores de 4 Bytes pueden ser
fragmentados y debido a esto aparecen dos mecanismos de transferencia de un
SDO:
<Transferencia expeditada> utilizados para establecer una transferencia de
objetos de no más de 4 Bytes.
<Transferencia segmentada> utilizados para establecer una transferencia de
objetos de más de 4 Bytes.
MCP/MCPi - Ref.0612
Protocolo CANopen - 17/40
Estructuras básicas de un SDO
Las estructuras básicas de un SDO son:
Cliente
Servidor / Servidor Î Cliente
Î
TABLA 13. Estructura SDO. Cliente Î Servidor / Servidor Î Cliente
Byte 0
Byte 1
Indicador del
comando
SDO
Índice
de
objetos
ó también Cliente
Î
Byte 2
Byte 3
Byte 4
Byte 5
Byte 6
Byte 7
Subíndice
de
objetos
Hasta 4 Bytes de datos en transferencia
expeditada ó 4 Bytes del contador en
transferencia segmentada
Servidor / Servidor Î Cliente
TABLA 14. Estructura SDO. Cliente Î Servidor / Servidor Î Cliente
Byte 0
Byte 1
Byte 2
Byte 3
Byte 4
Byte 5
Indicador del
comando SDO
Hasta 7 Bytes de datos en transferencia
segmentada
Byte 6
Byte 7
Existen cinco protocolos de solicitud / respuesta implementados en los SDOs. Éstos
son:
‡ Comenzar la descarga de dominio (Initiate Domain Download)
‡ Descargar el segmento de dominio (Download Domain Segment)
‡ Comenzar la carga de dominio (Initiate Domain Upload)
‡ Cargar el segmento de dominio (Upload Domain Segment)
‡ Abortar la transferencia de dominio (Abort Domain Transfer)
Se entiende por descargar (download) a escribir en el diccionario de objetos y
cargar (upload) a leer del diccionario de objetos.
Indicadores de comando de SDO para los diferentes protocolos
TABLA 15. Inicio de la descarga de dominio.
Comenzar la descarga de dominio
bit
Cliente
Î
Servidor
Í
7
6
5
4
3
0
0
1
-
n
0
1
1
-
-
2
-
1
0
e
s
-
-
donde:
n Î Indicador del nº de bytes que no contienen datos y es válido si e=1 y s=1.
e Î Indicador de transferencia normal (e=0) ó transferencia expeditada (e=1).
s Î Indicación o no del tamaño de los datos. Si se indica (s=0) y si no se indica (s=1).
e = 0 y s = 0 Î Bytes de datos reservados por CiA para un futuro.
e = 0 y s = 1 Î El contador de Bytes se encuentra en los Bytes de datos (byte 4 LSB
a byte 7 MSB).
e = 1 Î Los Bytes de datos contienen los datos para descargar (download).
18/40 - Protocolo CANopen
MCP/MCPi - Ref.0612
TABLA 16. Descarga del segmento de dominio.
Descargar el segmento de dominio
bit
Cliente
Î
Servidor
Í
7
6
5
4
3
0
0
0
t
n
0
0
0
t
-
2
1
0
c
-
-
-
donde:
n Î Indicador del nº de bytes que no contienen datos y es cero si el tamaño del
segmento no se indica.
c Î Indicador de segmentos para descargar. Si hay más segmentos para descargar
(c=0) y si es el último segmento (c=1).
t Î Bit de toggle que debe alternar con cada segmento consecutivo. La primera vez
es (t=0).
TABLA 17. Comienzo de la carga de dominio.
Comenzar la carga de dominio
bit
Cliente
Î
Servidor
Í
7
6
5
4
3
2
1
0
0
1
0
-
-
-
-
-
0
1
0
-
n
e
s
TABLA 18. Carga del segmento de dominio.
Cargar el segmento de dominio
bit
Cliente
Î
Servidor
Í
7
6
5
4
3
2
1
0
0
1
1
t
-
-
-
-
0
0
0
t
n
c
Un mensaje puede ser abortado tanto por el cliente como por el servidor. Debe
indicarse con el siguiente indicador de comando:
TABLA 19. Abortado de la transferencia de dominio.
Abortar la transferencia de dominio
bit
Cliente
Î / Í Servidor
7
6
5
4
3
2
1
0
1
0
0
-
-
-
-
-
Al abortar la transferencia de dominio los bytes de datos 0 y 1 contienen el índice
del objeto, el byte 2, el subíndice del objeto y los bytes 4-7 contienen el código de
abortar (abort) que describe la causa.
MCP/MCPi - Ref.0612
Protocolo CANopen - 19/40
Códigos que describen la posible razón de abortar SDO
TABLA 20. Descripción de los posibles códigos de abortado del SDO.
Código de abortar
Descripción
byte 7 byte 6 byte 5 byte 4
05
05
03
04
00
00
00
00
05
04
00
01
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
06
07
00
12
06
07
00
13
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
08
00
00
23
El bit basculante no es basculante
TimeOut para el protocolo SDO
Comando Cliente/Servidor inválido o identificador
desconocido
Tamaño no reconocido de bloque (sólo modo bloque)
Número no reconocido de bloque (sólo modo bloque)
Error CRC (sólo modo bloque)
Memoria insuficiente
Acceso no soportado a este objeto
Se ha intentado leer un objeto de sólo escritura
Se ha intentado escribir un objeto de sólo lectura
El objeto no existe en el diccionario de objetos
El objeto no puede ser mapeado a un PDO
El tamaño y número de objetos mapeados sobrepasan la
longitud del PDO
Incompatibilidad general de parámetros
Incompatibilidad general de dispositivos
Acceso infringido causado por error de hardware
Tipo de dato incompatible, la longitud del parámetro de
servicio es incompatible
Tipo de dato incompatible, el parámetro de servicio es
demasiado largo
Tipo de dato incompatible, el parámetro de servicio es
demasiado corto
No existe el subíndice
Rango de valores externo (sólo para acceso de escritura)
Valor de parámetro demasiado alto
Valor de parámetro demasiado bajo
El valor máximo es inferior al valor mínimo
Error / fallo general
Los datos no pueden ser transmitidos ni guardados
Los datos no pueden ser transmitidos ni guardados porque
el dispositivo está bajo control local
Los datos no pueden ser transmitidos ni guardados debido
al estado del dispositivo
No es posible generar dinámicamente el diccionario de
objetos
‡ Objeto de emergencia
Un mensaje de emergencia se compone de 8 bytes y dispone del siguiente formato:
TABLA 21. Mensaje de emergencia.
COB ID
Byte 0 -1
Byte 2
0x080
Código de error de Registro de error
+ ID del nodo emergencia
(objeto 0x1001)
20/40 - Protocolo CANopen
Byte 3 -7
Campo de error especificado
por el fabricante
MCP/MCPi - Ref.0612
Códigos de error de emergencia
TABLA 22. Códigos de error de emergencia.
Código de error de emergencia
Significado
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 o no error
Error genérico
Corriente
Corriente, lado de entrada del dispositivo
Corriente dentro del dispositivo
Corriente, lado de salida del dispositivo
Tensión
Tensión de red
Tensión dentro del dispositivo
Tensión de salida
Temperatura
Temperatura ambiente
Temperatura del dispositivo
Hardware del dispositivo
Software del dispositivo
Software interno
Software de usuario
Dato W
Módulos adicionales
Monitorización
Comunicación
CAN sobrepasado
Error pasivo
Error “ life guard” ó error “Heartbeat”
Restaurado desde el bus-off
Error de protocolo
PDO no procesado por error de longitud
Longitud superada
Error externo
Funciones adicionales
Específico de dispositivo
Códigos de error de emergencia in hexadecimal. Nótese que “xx” es una parte que
depende del perfil de dispositivo.
MCP/MCPi - Ref.0612
Protocolo CANopen - 21/40
Registro de error (objeto 0x1001)
TABLA 23. Registro de error (OBJETO 0x1001).
Bit
0
1
2
3
4
5
6
7
Tipo de error
Genérico
Corriente
Tensión
Temperatura
Comunicación
Específico del perfil de dispositivo
Reservado (=0)
Específico del fabricante
Objetos relacionados
1001 h
Registro de errores
1003 h
Campo de errores predefinidos
1014 h
COB ID para el mensaje de emergencia
‡ Descripción del diccionario de objetos
Objetos de comunicaciones (DS301)
TABLA 24. Objetos de comunicaciones (DS301).
Índice
Descripción
1000h
1001h
1003h
1005h
1006h
1007h
1008h
1009h
100Ah
100Ch
100Dh
1014h
1015h
1018h
1400h
1600h
1800h
1A00h
Tipo de dispositivo
Registro de errores
Campo de errores predefinidos
COB ID de mensaje SYNC
Período de ciclo de comunicación
Longitud de la ventana de sincronismo
Nombre de dispositivo del fabricante
Versión de hardware del fabricante
Versión de software del fabricante
Tiempo de vigilancia
Factor de tiempo de vida
COB ID para mensaje de emergencia
Tiempo de inhibición para mensaje de emergencia
Objeto de identidad
Parámetro de comunicación de PDO recepción
Parámetro de mapeo de PDO recepción
Parámetro de comunicación de PDO transmisión
Parámetro de mapeo de PDO transmisión
Objetos de fabricante MCP/MCPi CANopen
Descripción de las cabeceras de las diferentes columnas que componen la tabla de
los objetos de fabricante.
Fn Î Nombre Fagor del objeto.
Índice Î Índice hexadecimal del objeto CANopen de fabricante.
IdA Î Identificador de la variable dentro de la estructura “Assembly” en los mensajes
rápidos PDO.
22/40 - Protocolo CANopen
MCP/MCPi - Ref.0612
Variable Î Parámetro, variable o comando asignable al objeto.
Acc Î Acceso del objeto. Sólo lectura (R), lectura y escritura (R/W).
Tipo Î Tipo de datos del objeto. Entero sin signo (UINT), entero con signo (INT),
texto (string).
Rango Î Rango de valores (mínimo ó máximo) aceptado por el objeto.
TABLA 25. Objetos de fabricante MCP/MCPi CANopen.
Nombre Índice
IdA
Descripción
Acc
Tipo
Rango
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 a 999
CP2
506Bh
242h
CurrentIntegralTime
R/W
UINT 0 a 999
CP10
413Bh
243h
VoltageAmpVolt
R/W
UINT 1000 a 9999
CP11
413Ch
244h
AmpAmpVolt
R/W
UINT 100 a 5000
CP20
4133h
245h
CurrentLimit
R/W
UINT 0 a 5000
CP30
4134h
246h
CurrentCommandFilter1Type
R/W
UINT 0 a 1
CP31
4138h
247h
CurrentCommandFilter1Frequency
R/W
UINT 0 a 4000
CP32
4139h
248h
CurrentCommandFilter1Dumping
R/W
UINT 0 a 1000
CP45
413Ah
249h
CurrentCommandSelector
R/W
UINT 0 a 3
CV1
4135h
281h
Current1Feedback
R
INT
-5000 a 5000
CV2
4136h
282h
Current2Feedback
R
INT
-5000 a 5000
CV3
4137h
283h
CurrentFeedback
R
INT
-5000 a 5000
CV10
4131h
284h
Current1Offset
R
INT
-2000 a 2000
CV11
4132h
285h
Current2Offset
R
INT
-2000 a 2000
CV15
413Dh
286h
DigitalCurrentCommand
R/W
INT
-5000 a 5000
DC1
5063h
301h
ResetClass1Diagnostics
R/W
UINT 0 a 15
DC2
4192h
302h
ClearHistoricOfErrorsCommand
R/W
UINT 0 a 15
DV17
419Ah
381h
HistoricOfErrors
R
String 0 a 999
DV31
5087h
382h
DriverStatusWord
R
UINT 0 a 65535
DV32
5086h
383h
MasterControlWord
R/W
UINT 0 a 65535
DV50
5FF8h
384h
ErrorBitArea
R
UINT
DV51
5FFDh
385h
WarningBitArea
R
UINT 0 a 65535
DV60
41CDh
386h
FastControlIn
R/W
UINT sin rango
DV61
41CEh
387h
FastControlOut
R
UINT sin rango
EP1
41F4h
441h
EncoderSimulatorPulsesPerTurn
R/W
UINT 1 a 4096
EP3
41F6h
442h
EncoderSimulatorDirection
R/W
UINT 0 a 1
GC1
5108h
601h
BackupWorkingMemoryCommand
R/W
UINT 0 a 15
GC3
42DAh
602h
AutophasingCommand
R/W
UINT 0 a 15
GC10
5106h
603h
LoadDefaultsCommand
R/W
UINT 0 a 15
GP3
42BEh
641h
StoppingTimeout
R/W
UINT 0 a 9999
GP5
42C0h
642h
ParameterVersion
R
UINT 0 a 9999
MCP/MCPi - Ref.0612
0x80000000 a
0x7fffffff
Protocolo CANopen - 23/40
Nombre Índice
IdA
Descripción
Acc
GP9
50CFh
643h
DriveOfDelayTime
R/W UINT 0 a 9999
Tipo
Rango
GP11
42D6h
645h
IOFunctionsTime
R/W UINT 0 a 9999
GP15
42D5h
646h
AutomaticInitialization
R/W UINT 0 a 1
GP16
42D7h
647h
MonoPhaseSelector
R/W UINT 0 a 1
GV2
501Eh
681h
ManufacturerVersion
R
string 0 a 9999
GV5
42C2h
682h
CodeChecksum
R
INT
-32768 a 32767
GV7
510Bh
683h
Password
R/W UINT 0 a 9999
GV9
508Ch
684h
DriveType
R
GV11
42C4h
685h
SoftReset
R/W UINT 0 a 16
GV16
42CCh
686h
MotorTableVersion
R
GV50
4725h
688h
SerialNumber
R
UINT -32768 a 32767
GV75
5177h
687h
ErrorList
R
string -32768 a 32767
HV5
4127h
781h
PLDVersion
R
UINT 0 a 65535
IP6
438Eh
841h
DigitalInputPolarity
R/W UINT 0 a 1
IP14
438Fh
842h
DigitalInputFunctionSelector
R/W UINT 0 a 4
IP17
4390h
843h
AnalogFunctionSelector
R/W UINT 0 a 2
IV1
4389h
881h
AnalogInput1
R
IV2
438Ah
882h
AnalogInput2
R
INT
-1200 a 1200
IV3
4391h
883h
CurrentCommandAfterScaling
R
INT
-9999 a 9999
IV10
438Bh
884h
DigitalInputs
R
UINT 0 a 1
IV11
438Ch
885h
DigitalInputsCh2
R
UINT -32768 a 32767
UINT -32768 a 32767
string -32768 a 32767
UINT 0 a 32767
INT
-12000 a 12000
ID5
49C4h
1B85h
BusCodeChecksum
R
KP3
445Ah
A41h
ExtBallastPower
R/W UINT 200 a 2000
KP4
445Ch
A42h
ExtBallastEnergyPulse
R/W UINT 200 a 2000
KV6
517Fh
A81h
MotorTemperature
R
UINT 0 a 200
KV10
444Eh
A82h
CoolingTemperature
R
UINT 0 a 200
KV32
4455h
A83h
I2tDrive
R
UINT 0 a 100
KV36
4457h
A84h
I2tMotor
R
UINT 0 a 100
KV40
445Bh
A85h
I2tCrowbar
R
UINT 0 a 100
KV41
445Dh
A86h
BallastSelect
R/W UINT 0 a 1
LP22
4912h
B41h
JogVelocity
R/W UINT 0 a 500000
LP23
4913h
B42h
JogIncrementalPosition
R/W UINT 0 a 0x7fffffff
LP48
4934h
B43h
PositionActionsSelect
R/W UINT -32768 a 32767
LP49
4935h
B44h
InBandPosition
R/W UINT 0 a 0x7fffffff
LP143
5189h
B45h
ModuleCommandMode
R/W UINT 0 a 2
LV13
4909h
B81h
KernelOperationMode
R/W UINT 0 a 1
LV14
490Ah
B82h
KernelAutoMode
R/W UINT 0 a 1
LV15
490Bh
B83h
KernelStartSignal
R/W UINT 0 a 1
LV16
490Ch
B84h
KernelStopSignal
R/W UINT 0 a 1
LV17
490Dh
B85h
KernelResetSignal
R/W UINT 0 a 1
LV19
490Fh
B86h
KernelManMode
R/W UINT 0 a 1
LV20
4910h
B87h
JogPositiveSignal
R/W UINT 0 a 1
LV21
4911h
B88h
JogNegativeSignal
LV35
491Fh
B89h
BlockTravelDistance
LV36
4920h
B8Ah
BlockCoveredDistance
LV158
5102h
B8Bh
TargetPosition
R/W UINT 0 a 1
0x8000000
R
INT
a 0x7fffffff
0x8000000
R
INT
a 0x7fffffff
0x8000000
R
INT
a 0x7fffffff
24/40 - Protocolo CANopen
MCP/MCPi - Ref.0612
Nombre Índice
IdA
LV159
B8Ch PositioningVelocity
5103h
Descripción
Acc
Tipo
R
UINT 0 a 0x7fffffff
Rango
LV160
5104h
B8Dh PositioningAcceleration
R/W
UINT 0 a 0x7fffffff
LV161
5105h
B8Eh PositioningAcceleration2
R/W
UINT 0 a 0x7fffffff
LV242
5156h
B8Fh TargetPositionAttained
R
UINT 0 a 1
MP1
508Dh
C41h MotorType
R/W
string -32768 a 32767
MP2
44B0h
C42h MotorTorqueConstant
R/W
UINT 0 a 1000
MP3
506Fh
C43h MotorContinuousStallCurrent
R/W
UINT 0 a 5000
NP117
5075h
D42h ResolutionOfFeedback2
R/W
UINT 0 a 65535
NP118
5076h
D43h ResolutionOfLinearFeedback
R/W
UINT 0 a 65535
NP121
5079h
D44h InputRevolutions
R/W
UINT 1 a 65535
NP122
507Ah
D45h OutputRevolutions
R/W
UINT 1 a 65535
NP123
507Bh
D46h FeedConstant
R/W
UINT 0 a 0x7fffffff
NP131
4082h
D47h InputRevolutions2
R/W
UINT 1 a 65535
NP132
4083h
D48h OutputRevolutions2
R/W
UINT 1 a 65535
NP133
4084h
D49h FeedConstant2
R/W
UINT 0 a 0x7fffffff
OP1
4578h
E41h DA1IDN
R/W
UINT 0 a 13
OP2
4579h
E42h DA2IDN
R/W
UINT 0 a 13
OP3
457Ah
E43h DA1ValuePer10Volt
R/W
UINT 0 a 9999
OP4
457Bh
E44h DA2ValuePer10Volt
R/W
UINT 0 a 9999
OP6
4588h
E45h DigitalOutputPolarity
R/W
UINT 0 a 1
OP14
4586h
E46h DigitalOutputFunctionSelector
R/W
UINT 0 a 7
OP15
4587h
E47h DigitalOutputWarningSelector
R/W
UINT 0 a 2
OV10
4582h
E81h DigitalOutputs
R
UINT 0 a 1
OV11
4585h
E82h DigitalOutputsCh2
R/W
UINT -32768 a 32767
PC148
5094h
F02h
DriveControlledHoming
R/W
UINT 0 a 15
PC150
4517h
F03h
ChangePosFB12
R/W
UINT 0 a 16
PP1
5028h
F41h
HomingVelocitySlow
R/W
UINT 0 a 1200
PP41
5029h
F42h
HomingVelocityFast
R/W
UINT 0 a 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 a 0x7fffffff
0x8000000
INT
a 0x7fffffff
0x8000000
INT
a 0x7fffffff
0x8000000
INT
a 0x7fffffff
0x8000000
INT
a 0x7fffffff
UINT 0 a 65535
0x8000000
INT
a 0x7fffffff
UINT 1 a 65535
PP103
5067h
F4Bh ModuleValue
R/W
UINT 0 a 0x7fffffff
PP104
5068h
F4Ch PositionKvGain
R/W
UINT 0 a 65535
PP105
5069h
F4Dh PositionKvGain2
R/W
UINT 0 a 65535
PP115
5073h
F4Eh PositionFeedback2Type
R/W
UINT 0 a 32
PP147
5093h
F4Fh HomingParameter
R/W
UINT 0 a 65535
PP159
509Fh
F50h
MonitoringWindow
R/W
UINT 0 a 0x7fffffff
PP216
5128h
F51h
VelocityFeedforwardPercentage
R/W
UINT 0 a 120
PP218
4526h
F52h
VelocityFeedforwardPercentage2
R/W
UINT 0 a 120
MCP/MCPi - Ref.0612
Protocolo CANopen - 25/40
Nombre Índice
IdA
Descripción
Acc
Tipo
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
Rango
0x8000000
INT
a 0x7fffffff
0x8000000
INT
a 0x7fffffff
0x8000000
INT
a 0x7fffffff
0x8000000
INT
a 0x7fffffff
UINT 0 a 1
PV208
5198h
F86h
ReferenceMarkerPulseRegistered
R
UINT 0 a 1
QP11
47D0h
1043h
CanBusSpeed
R/W
UINT 0 a 20
QP14
47DAh 1044h
ProtocolTypeSelector
R/W
UINT 2 a 4
QP16
47DCh 1045h
SerialSettings
R/W
UINT 0 a 65535
QV22
5016h
1081h
IDNListOfInvalidOperationData
R
string 0 a 65535
QV96
5060h
1083h
SlaveArrangement
R/W
UINT 0 a 127
RC1
45E9h
1101h
EncoderParameterStoreCommand
R/W
UINT 0 a 15
RG1
3801h
11C1h
PiecesCount
R/W
UINT 0 a 65535
RG2
3802h
11C2h
ActualPiecesCount
R/W
UINT 0 a 65535
RG3
3803h
11C3h
RunningBlock
R/W
UINT 0 a 127
RG4
3804h
11C4h
PositionBlockIni
R/W
UINT 0 a 127
RP1
45DCh 1141h
FeedbackSineGain
R/W
UINT 0 a 8192
RP2
45DDh 1142h
FeedbackCosineGain
R/W
UINT 0 a 8192
RP3
45DEh 1143h
FeedbackSineOffset
R/W
INT
-2000 a 2000
RP4
45DFh 1144h
FeedbackCosineOffset
R/W
INT
-2000 a 2000
RV1
45E2h
1181h
FeedbackSine
R
INT
-512 a 511
RV2
45E3h
1182h
FeedbackCosine
R
INT
-512 a 511
RV3
45E4h
1183h
FeedbackRhoCorrection
R
UINT 0 a 65535
SP1
5064h
1241h
VelocityProportionalGain
R/W
UINT 0 a 9999
SP2
5065h
1242h
VelocityIntegralTime
R/W
UINT 0 a 9999
SP3
5066h
1243h
VelocityDerivativeGain
R/W
UINT 0 a 9999
SP10
505Bh
1244h
VelocityLimit
R/W
UINT 0 a 9999
SP19
4653h
1245h
SymmetryCorrection
R/W
INT
SP20
4654h
1246h
VoltageRpmVolt
R/W
UINT 1000 a 9999
SP21
4655h
1247h
RpmRpmVolt
R/W
UINT 10 a 9999
SP30
4643h
1248h
VelocityOffset
R/W
INT
SP40
507Dh
1249h
VelocityThresholdNx
R/W
UINT 0 a 9999
SP41
509Dh
124Ah
VelocityWindow
R/W
UINT 0 a 9999
SP42
507Ch
124Bh
StandStillWindow
R/W
UINT 0 a 9999
SP43
502Bh
124Ch
VelocityPolarityParameters
R/W
UINT 0 a 1
SP45
4651h
124Dh
VelocityCommandSelector
R/W
UINT 0 a 2
SP60
508Ah
124Eh
AccelerationLimit
R/W
UINT 0 a 4000
-500 a 500
-2000 a 2000
SP65
4649h
124Fh
EmergencyAcceleration
R/W
UINT 0 a 4000
SP66
4652h
1250h
VelocityDecelerationTime
R/W
UINT 0 a 4000
SV1
5024h
1281h
VelocityCommand
R/W
INT
-6·107 a 6·107
SV2
5028h
1282h
VelocityFeedback
R
INT
-6·107 a 6·107
SV6
4656h
1283h
VelocityCommandAfterFilters
R
INT
-6·107 a 6·107
SV7
464Ch
1284h
VelocityCommandFinal
R
INT
-6·107 a 6·107
26/40 - Protocolo CANopen
MCP/MCPi - Ref.0612
Nombre Índice
IdA
Descripción
Acc
Tipo
Rango
SV15
4657h
1285h
DigitalVelocityCommand
R/W
INT
-6·107 a 6·107
TP1
507Eh
1341h
TorqueThresholdTx
R/W
UINT 0 a 100
TV1
5050h
1381h
TorqueCommand
R
INT
-9999 a 9999
TV2
5054h
1382h
TorqueFeedback
R
INT
-9999 a 9999
‡ Descripción de los PDOs
La tarjeta CAN de comunicaciones de los reguladores MCP y MCPi dispone de un
PDO de recepción y un PDO de transmisión (pudiendo incrementarse este número
en futuras versiones). El mapeo de los PDOs viene establecido desde fábrica y no
puede ser modificado por el usuario. Los parámetros de comunicación de los PDOs
quedan accesibles al usuario pudiendo éste seleccionar tanto el tipo de
comunicación a llevar a cabo como su habilitación.
El fin último de los PDOs es establecer el control de los módulos esclavos en tiempo
real por parte del módulo maestro. En los reguladores existen dos estructuras de
datos (directamente mapeadas a estos mensajes PDO) denominadas Assembly
pensadas para poder gobernar los accionamientos en tiempo real. Constan, cada
una de ellas, de 8 bytes y su objetivo es, entre otros, establecer el control sobre el
regulador desde el módulo maestro pudiendo modificar sus variables y parámetros
(AssemblyIn) y además poder informar desde el regulador, de su estado y al mismo
tiempo devolver las variables solicitadas por el módulo maestro (AssemblyOut).
AssemblyIn - Control
TABLA 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, es decir, en modo automático.
** KernelOperationMode Î LV13 = 1, es decir, en modo manual.
I_Fast: Bit que permite activar la entrada rápida (como evento de paso de bloque)
a través del bus de comunicaciones.
Starting_Block (7 bits): Especifica el nº de bloque a partir del cual será iniciada la
ejecución en la tabla de movimientos.
Drive_Enable: Bit que permite activar a través del bus de comunicaciones el Drive
Enable del equipo siempre y cuando la entrada hardware correspondiente esté
activada. La señal final interpretada por el equipo viene dada por un “AND” lógico
entre el valor de la entrada física Drive_Enable y el bit Drive_Enable del AssemblyIn.
Speed _Enable: Bit que permite activar a través del bus de comunicaciones el Speed
Enable del equipo siempre y cuando la entrada hardware correspondiente esté
activada.
MCP/MCPi - Ref.0612
Protocolo CANopen - 27/40
La señal final interpretada por el equipo viene dada por un “AND” lógico entre el valor
de la entrada física Speed_Enable y el bit del Speed_Enable del AssemblyIn.
Home_Switch: Bit que permite activar a través del bus de comunicaciones el final
de carrera del Home_Switch (micro de búsqueda de cero o referencia).
Lim + : Bit que permite activar a través del bus de comunicaciones el final de carrera
del límite positivo del recorrido.
Lim - : Bit que permite activar a través del bus de comunicaciones el final de carrera
del límite negativo del recorrido.
Reset : Control digital de la señal Reset. Si el regulador está en modo manual
(LV13 = 0), la activación de este bit implica actuar sobre la señal Jog-. Si está en
modo automático, la activación de esta señal efectúa un Reset en el secuenciador
de movimientos.
Stop : Bit que permite detener el movimiento en curso.
Start : Control digital de la señal Start. Si el regulador está en modo manual (LV13
= 0), la activación de este bit implica actuar sobre la señal Jog+. Si está en modo
automático, pueden establecerse dos posibles situaciones:
‡ Si se activa Start por primera vez o tras realizar un Reset de movimientos, el
secuenciador de posición comenzará la ejecución del bloque indicado en los bits
de Starting_Block.
‡ Si durante la ejecución de un bloque se activa una señal Stop, el equipo se
detiene. Si ahora se activa una señal de Start, el equipo continua con la ejecución
del bloque justamente donde se detuvo cuando fue activada la señal de Stop.
Command: Campo del AssemblyIn donde es indicada la acción a llevar a cabo por
el elemento maestro. Véanse los ejemplos prácticos documentados más adelante.
0
1
2
3
Leer un parámetro / una variable.
Escribir un parámetro / una variable
Leer en la tabla de movimientos
Escribir en la tabla de movimientos
Dir_Var: Campo de la estructura AssemblyIn que en función del comando solicitado
por el elemento maestro podrá indicar tanto el identificador IdA de una variable como
el bloque de posición a leer/escribir por el elemento maestro (véanse los ejemplos
prácticos documentados más adelante).
Command Toggle Bit: Bit cuyo fin es hacer efectivo por parte del módulo maestro
el comando solicitado en los bits Command del AssemblyIn. Esto se consigue
negando el estado actual de este bit.
28/40 - Protocolo CANopen
MCP/MCPi - Ref.0612
AssemblyOut - Estado
TABLA 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.
Ref_Done: Bit indicador (al módulo maestro) de que la acción de “búsqueda de
cero” ha sido realizada satisfactoriamente.
Reg_Status: Bits indicadores del estado en el que se encuentra el regulador.
0
1
2
3
Realizando el test interno de Start-Up.
Control establecido. A la espera de recibir potencia.
Power On. Potencia y control establecidos pero, sin par en el motor.
Torque On. Motor con par (habilitado).
Warning: Bit indicador de que el regulador se encuentra en un estado de warning
(aviso).
Error: Bit indicador de que se ha producido algún error en el regulador.
In_Position: Bit indicador de que ha sido alcanzada la posición de destino de un
bloque. Es activado cuando el posicionador se encuentra dentro de la banda
especificada en el parámetro PP57 - Position Window -.
Speed_Enable: Bit que refleja el estado interno de la señal Speed_Enable del
regulador. Se tiene en cuenta tanto la entrada física como el bit del AssemblyIn.
Active_Block: Bits indicadores del nº de bloque de la tabla de posicionamiento
actualmente en ejecución.
Command_Toggle_Bit_Resp: Tras recibir un nuevo comando mediante el cambio
de valor de Command_Toggle_Bit, el regulador inicia su ejecución. Finalizada la
ejecución, se hace una copia de l valor de Command_Toggle Bit en
Command_Toggle_Bit_Resp. Así, el módulo maestro queda informado de que el
comando se ha completado.
Command_Resp: Reflejo del comando especificado en los bits “Command” del
AssemblyIn.
Command_OK: Tras recibir un nuevo comando mediante el cambio de valor de
Command_Toggle_Bit, el bit “Command_OK” será activado cuando el comando
solicitado ha sido ejecutado satisfactoriamente. Se pondrá a cero siempre que se
generen errores en la ejecución del comando.
MCP/MCPi - Ref.0612
Protocolo CANopen - 29/40
Operation_Status: Bits que reflejan el “modo” y el “estado” en el que se encuentra
el secuenciador de movimientos del equipo.
STOP
5
KernelStopSignal
KernelResetSignal
KernelStopSignal
0
KernelOperationMode
desde
& KernelResetSignal
10-11-12
3
KernelStopSignal
PAUSA DE
BLOQUE
En espera de la
señal START
MODO
MANUAL
4
& JogNegativeSignal
& KernelManMode
(CONTINUO)
OR KernelResetSignal
OR KernelStopSignal
Modo JOG en
funcionamiento
JogPositiveSignal
OR JogNegativeSignal
& KernelResetSignal
& KernelStopSignal
11
Desde todos
los estados
KernelManMode
(INCREMENTAL)
& FIN DE
MOVIMIENTO
10
JogPositiveSignal
& JogNegativeSignal
A la espera de
desactivar el
modo JOG
12
Alarma
2
Cambio a
KernelOperationMode
1
JogPositiveSignal
KernelStartSignal & KernelStopSignal
En espera de que
la señal START
no esté activa
KernelStopSignal
KernelStartSignal
& KernelStopSignal
BLOQUE EN EJECUCIÓN
desde
0-1-2-3-4-5
Cambio a
KernelStartSignal
BlockEnd
KernelResetSignal
6
Reset
MODO
AUTOMÁTICO
Alarma
15
Mnemónicos y símbolos
A (A negada)
A
Señal A no activa
Ejemplo:
Señal A activa
KernelStopSignal = KernelStopSignal no activa
KernelStopSignal = KernelStopSignal activa
Transiciones entre estados
X
Estado
Modo de operación
FIGURA 5.
Modo de operación del regulador.
Data_Byte_Resp 0-3: Bytes de datos que contienen la información solicitada (valor
de variable, parámetro o valores de la tabla de posicionamiento) por el módulo
maestro. El Data_Byte_Resp 0 contiene el byte de menor peso de la variable
solicitada mientras que el Data_Byte_Resp 3 contiene el byte de mayor peso.
Estructura del Assembly. Ejemplos prácticos.
La estructura del Assembly facilita la labor a un elemento maestro externo a la hora
de realizar diferentes operaciones con el regulador utilizando un único tipo de
mensaje de comunicaciones. Un ejemplo de ello lo constituyen los PLC que realizan
cíclicamente, operaciones con los diferentes elementos esclavos, utilizando el
mismo tipo de mensaje rápido.
Véanse seguidamente algunos ejemplos prácticos en los que se detalla cómo debe
configurar el módulo maestro cada uno de los bits del AssemblyIn para llevar a cabo
las operaciones requeridas.
Se entenderá (en todos los ejemplos) que el bit de “Command_Toggle_Bit_Resp”
que devuelve el módulo esclavo antes de que el módulo maestro envíe el
AssemblyIn está a cero.
30/40 - Protocolo CANopen
MCP/MCPi - Ref.0612
Lectura de parámetro/variable
Para leer un parámetro ó una variable del regulador, asignar necesariamente al
campo “Command” un 0.
Seguidamente, introducir en los 13 bits del campo “Dir_Var” el identificador Id
Assembly correspondiente al parámetro o variable a leer. Este identificador es
suministrado en la tercera columna de las tablas de descripción de los objetos
CANopen específicos de fabricante. Así, p. ej. si se desea leer la variable SV2
(realimentación de velocidad), introducir el valor Id Assembly de SV2 en hexadecimal
Î1282h. Véase TABLA 25.
Finalmente, asignar al bit “Command_Toggle_Bit” un 1 cuando desee ejecutarse la
orden.
Escritura de parámetro/variable
Para escribir en un parámetro ó en una variable del regulador, asignar
necesariamente al campo “Command” un 1.
Seguidamente, introducir en los 13 bits del campo “Dir_Var” el identificador Id
Assembly correspondiente al parámetro o variable a leer. Este identificador es
suministrado en la tercera columna de las tablas de descripción de los objetos
CANopen específicos de fabricante. Así, p. ej. si se desea escribir en el parámetro
CP20 (límite de corriente), introducir el valor Id Assembly de CP20 en hexadecimal
Î245h. Véase TABLA 25.
El valor a escribir en el parámetro ó variable se introducirá en los cuatro primeros
bytes de datos (destinados al respecto) y en las unidades requeridas. Véanse las
unidades en el apartado de parámetros, variables y comandos del manual del
regulador MCP ó MCPi, según corresponda.
Así, p.ej. si se establece un límite de la corriente (según parámetro CP20) de 5 A,
se escribirá en los 4 bytes “Data_Byte” el valor de 500 cA (centiAmperios).
Finalmente, asignar al bit “Command_Toggle_Bit” un 1 cuando desee ejecutarse la
orden.
Una vez que el mensaje ha sido recibido por el módulo esclavo, éste comprueba la
existencia del parámetro y trata de escribir en él. Si tiene éxito se activa el bit
“Command_OK” del mensaje AssemblyOut.
Tabla de movimientos
Los equipos MCP/MCPi integran lazo de posición y posicionador. La secuencia de
movimientos a llevar a cabo por el posicionador es programada mediante una tabla
de 127 bloques. Cada bloque establece una posición y en él pueden programarse
diferentes parámetros (posición absoluta o incremental, velocidad máxima de
posicionamiento, activación de salidas tras la ejecución del bloque, ...) a los que el
posicionador obedece durante la ejecución del bloque.
Existe la posibilidad de lectura/escritura de todos los elementos que componen la
tabla de movimientos a través de los mensajes Assembly. La estructura del bloque
de posicionamiento que ofrece la TABLA 28. detalla los 16 words que componen el
bloque. El word más significativo (de mayor peso) es el situado más a la izquierda
(word 15) y el menos significativo (de menor peso) el situado más a la derecha (word
0).
MCP/MCPi - Ref.0612
Protocolo CANopen - 31/40
TABLA 28. Estructura del bloque de posicionamiento.
Descripción
Reserv.
del campo
LOOP
NEXT
PROGOUT
0001h a 0080h
Valor
“ OR ”
Cnt piezas
SC00h
0000h
a
FFFFh
0000h
00000000h
a
000000FFh
Descripción
del campo
Valor
Nº WORD
15-12
11
10
VELPOS
9-8
5-4
TIEMPO
0001h
InTpos (teórico)
0002h
InBand
0003h
ActSpeedReached
0004h
NextSpeedReached
0005h
FastInput (2
0100h
0000h
a
FFFFh
7
6
POSDEST
VALOR
00000000h
a
FFFFFFFFh
TIPO
InRpos (real)
“OR”
END=xxFEh (1
Nº WORD
EVENTO
00000000h
a
FFFFFFFFh
3-2
MODO
Absoluto
0000 0001 h
Incremental
0000 0002 h
+ Infinito
0000 0003 h
- Infinito
0000 0004 h
Stop
0000 0005 h
1-0
(1
El word nº10, < siguiente bloque > consta de dos bytes con diferentes funcionalidades.
Byte bajo: indica el nº del siguiente bloque a ejecutar (valores válidos entre 1 y 127 y además el 254).
Byte alto: SC (Salto Condicional). Si se desea que al final del bloque aumente el contador de piezas realizadas
(REG2), este byte deberá tomar un valor distinto de cero. Cuando el contador de piezas coincida con el nº de piezas
deseadas (REG1) el siguiente bloque a ejecutar será el indicado en este byte.
END (xxFEh): indistintamente del valor que posea el byte alto (xxh), si se introduce (FEh) en el byte bajo, supondrá
el bloque final del programa.
(2 Si se desea que la condición de paso de bloque sea "posición teórica alcanzada" o activación de la entrada rápida
"fast input", el valor a introducir será 0102h.
Lectura de la tabla de movimientos
Para la lectura de datos en la tabla de movimientos del regulador, asignar el valor
2 al campo “Command” del AssemblyIn. La selección de un elemento de la tabla
se establece desde el campo “Dir_Var”. En sus 8 bits menos significativos (de menor
peso) se indicará el número de bloque de posicionamiento y en los 5 bits más
significativos (de mayor peso) el número de “word” a leer dentro del bloque.
Los accesos a la tabla de parámetros son llevados a cabo de 4 en 4 bytes siendo
muy conveniente (imprescindible) acceder a números de “word” pares para evitar
así equívocos en la interpretación de datos.
Ejemplo.
Para leer el valor de la posición de destino (words 2 y 3, siendo el origen el más bajo,
es decir, 2) del número de bloque 19 se introduce el valor hexadecimal 213h en el
campo “Dir_Var” del AssemblyIn. Ahora, cuando vaya a ser ejecutada la orden,
poner a 1 el bit “Command_Toggle_Bit”.
Recibido el mensaje por el módulo esclavo, éste comprueba la existencia de la
información solicitada y en caso afirmativo activa el comando “Command_Ok” y
devuelve la posición de destino a través de los mensajes AssemblyOut hasta que
cambie nuevamente el bit “ Command_Toggle_Bit ” (cambio de comando o de dato
solicitado de la tabla).
32/40 - Protocolo CANopen
MCP/MCPi - Ref.0612
Escritura de la tabla de movimientos
Para la escritura de datos en la tabla de movimientos del regulador, asignar el valor
3 al campo “Command” del AssemblyIn. La selección de un elemento de la tabla se
establece desde el campo “Dir_Var”. En sus 8 bits menos significativos (de menor
peso) se indicará el número de bloque de posicionamiento y en los 5 bits más
significativos (de mayor peso) el número de “word” a escribir dentro del bloque.
Los accesos a la tabla de parámetros son llevados a cabo de 4 en 4 bytes siendo
muy conveniente (imprescindible) acceder a números de “word” pares para evitar
así equívocos en la interpretación de datos.
Ejemplo.
Para cambiar el tipo de evento (condición de paso de bloque del posicionador, word
7) hay que escribir simultáneamente los words 6 y 7. Así, si se pretende un cambio
de bloque del posicionador cuando el lazo de posición alcanza la posición teórica
final (evento del tipo 2), se escribirá el valor hexadecimal 20000h en los bytes de
datos “Data_Byte”. Ahora, cuando vaya a ser ejecutada la orden, poner a 1 el bit
“Command_Toggle_Bit”.
Recibido el mensaje por el módulo esclavo, éste comprueba la existencia de los
datos que van a ser escritos y, si consigue escribirlos con éxito, entonces activa el
comando “Command_Ok” del mensaje AssemblyOut.
MCP/MCPi - Ref.0612
Protocolo CANopen - 33/40
Puesta en marcha
‡ Descripción de la tarjeta CAN
FIGURA 6.
Descripción de la tarjeta CAN® de un módulo MCP ó MCPi. Protocolo CANopen.
‡ MS Led Î Module Status Led. Diodo emisor de luz bicolor (colores rojo y verde)
indicativo del estado del regulador.
‡ NS Led Î Network Status Led. Diodo emisor de luz bicolor (colores rojo y verde)
indicativo de los diferentes estados en los que el equipo puede encontrarse dentro del bus CAN de comunicaciones.
‡ Conmutadores “x1” y “x10” Î Conmutadores rotativos que permiten seleccionar un dígito entre 0 y 9 en cada uno de ellos y de cuya combinación se obtiene
un número que estará comprendido entre 0 (ambos señalan 0) y 99 (ambos
señalan 9). Cada nodo del bus se diferencia del resto de ellos en el nº de nodo
que le ha sido asignado desde estos conmutadores rotativos. Cualquier valor
entre 01 y 98 podrá ser asumido como nº de nodo por un equipo.
Nota: Únicamente serán utilizados los valores 0 y 99 para ciertos casos
especiales documentados más adelante.
‡ Selección de la velocidad de comunicación
La primera labor que debe realizarse siempre que se incorpora un nuevo equipo en
la red CANopen es adecuar su velocidad de comunicación a la velocidad de la red.
Se dispone de dos selectores rotativos (x10, x1) y dos indicadores MS (Module
Status) y NS (Network Status) que permiten llevar a cabo este proceso.
Las velocidades de transmisión que pueden ser seleccionadas en CANopen son 10,
20, 50, 100, 125, 250, 500, 800 y 1000 (en kbit/s) .
Proceso de selección
En el arranque de un equipo y siempre que los selectores rotativos estén
seleccionando 99 (es decir, cada uno señalando al 9), estará habilitado el modo
de selección de la velocidad de transmisión. Los leds MS y NS parpadearán
simultáneamente, en verde, con una periodicidad de 500 ms aprox., indicando que
34/40 - Protocolo CANopen
MCP/MCPi - Ref.0612
el modo de selección de la velocidad de comunicación está habilitado. Desde este
estado pueden llevarse a cabo las siguientes operaciones:
Verificar la velocidad de transmisión seleccionada
Para conocer cual es la velocidad de transmisión a la que se está realizando la
comunicación en la red, en ese mismo instante, se actuará sobre el selector rotativo
“x1” situándolo en la posición ”0”. El indicador MS realizará un nº de parapadeos (led
rojo parpadeante) y seguidamente permanecerá en estado no iluminado aprox.
durante 1 segundo. Tras ese tiempo inicia nuevamente esta misma secuencia.
El nº de parpadeos (en rojo) efectuados entre cada dos intervalos en los que el led
deja de estar iluminado indica la velocidad de comunicación (almacenada en
memoria) con la que el equipo tratará de conectarse a la red.
La tabla asociativa entre el nº de parpadeos del led MS en rojo y la velocidad de
transmisión de la red es:
TABLA 29. Verificación de la velocidad de transmisión.
nº de parpadeos
del led MS
Velocidad de
transmisión
nº de parpadeos
del led MS
Velocidad de
transmisión
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
Ejemplo.
Si el nº de parpadeos en rojo del led MS es de 3 (entre cada dos períodos en los
que no se ilumina) estará indicando según esta tabla que la velocidad de transmisión
de la red es 500 kbit/s.
Seleccionar la velocidad de transmisión
Para establecer una velocidad de transmisión igual a la de comunicación en la red
en el nuevo equipo que se incorpora, se actuará sobre su selector rotativo “x1”
situándolo entre las posiciones 1 y 9 para seleccionar alguna de las velocidades.
TABLA 30. Selección de la velocidad de transmisión.
Posición del switch
rotativo “x1”
1
2
3
4
5
Velocidad de
transmisión
1000 kbit/s
800 kbit/s
500 kbit/s
250 kbit/s
125 kbit/s
Posición del switch
rotativo “x1”
6
7
8
9
Velocidad de
transmisión
100 kbit/s
50 kbit/s
20 kbit/s
10 kbit/s
Ejemplo.
Si la velocidad de comunicación en la red es 500 kBd, el equipo que se incorpora
también deberá transmitir a esa velocidad, es decir, habrá que situar su switch
rotativo “x1” en la posición 3.
MCP/MCPi - Ref.0612
Protocolo CANopen - 35/40
Simultáneamente y con las mismas secuencias ya comentadas en párrafos
anteriores, el led MS parpadeará (en verde) identificando así la velocidad
seleccionada.
Seleccionada la posición en el switch “x1”, será necesario confirmar la selección.
Para ello, actúese sobre el switch “x10” ubicándolo en la posición 0. El led MS, ahora
destelleando en rojo, es indicativo de la velocidad seleccionada. Tras esta operación,
esta velocidad será almacenada permanentemente en la memoria no volátil del
equipo. Tras realizar un reset en el equipo, éste asumirá ya como velocidad de
transmisión la almacenada en memoria.
‡ Determinación del nº de nodo
Determinada la velocidad de transmisión del equipo en la red, será ahora necesario
identificarlo dentro de la misma. Habrá que asignar al nuevo equipo incorporado un
nº identificador único que le permita diferenciarse de cualquier otro equipo que
forme parte de la red y evitar así colisiones. Este nº identificador ID se conocerá como
nº de nodo y debe ser único para cada equipo.
IMPORTANTE: Queda bajo la responsabilidad del usuario evitar que dos
equipos distintos dispongan del mismo nº de nodo.
La determinación del nº de nodo del equipo se lleva a cabo mediante los dos
conmutadores rotativos x1 y x10.
Ejemplo.
Para asignar a un equipo el nº de nodo 57, habrá que situar
la flecha del conmutador rotativo “ x10 ” señalando la posición
5 y la del rotativo “ x1” la posición 7. Véase figura.
Se comprueba que 10 x 5 + 1 x 7 = 57.
Tras realizar un reset del regulador, éste será identificado en la red con el nº de nodo
que le ha sido asignado.
El rango de selección del nº de nodo en una red CANopen está comprendido entre 01 y 127. Ahora bien, cuando se trata de equipos MCP ó MCPi sólo será
posible una selección de nodo entre 01 y 98. Recuérdese que el nº de nodo 99
queda reservado en su uso al proceso de selección de velocidad y el 00 se trata
inmediatamente como 01 ya que el nodo 00 no existe en CANopen.
En cada arranque del equipo, éste asume como nº de nodo, el asignado en los
selectores rotativos “x1” y “x10”.
‡ Indicadores de estado
La tarjeta CAN del regulador dispondrá de dos indicadores o leds “bicolor”. Éstos
son, MS (Module Status) y NS (Network Status). El indicador MS visualiza el estado
del equipo y NS informa del estado del equipo dentro de la red CANopen.
36/40 - Protocolo CANopen
MCP/MCPi - Ref.0612
En un proceso inicial del equipo estos leds alcanzan los siguientes estados con el
fin de verificar el correcto estado del regulador.
on
MS
(red)
250 ms
off
on
MS
(green)
250 ms
off
on
NS
(red)
250 ms
off
on
250 ms
NS
(green)
off
Nota. MS y NS se iluminan de acuerdo al estado en el que se encuentran tanto
el bus como el equipo.
MS (Module Status)
Este indicador informa del estado del equipo, propiamente dicho. Los estados que
pueden alcanzarse, actualmente, son:
Operativo. El regulador se encuentra libre de errores. El led indicador se iluminará
en verde en modo intermitente con una cadencia de intermitencia de 200 ms (on/off).
En error. El regulador se encuentra en estado de error. El led indicador se iluminará
en modo intermitente más rápido que en el estado anterior y en rojo con una cadencia
de intermitencia de 50 ms (on/off).
NS (Network Status)
Este indicador informa del estado del equipo dentro de la red CANopen, es decir,
del estado del Bus CANopen. Véanse las tablas y la figura siguientes donde se
establecen los tiempos de intermitencia del led rojo y del verde así como su
denominación.
‡ Led rojo. Led indicador de error
TABLA 31. Led indicador de error. Color rojo.
Led de error (rojo)
Estado
Descripción
No iluminado
Sin error
Funcionamiento satisfactorio del equipo
Un único parpadeo
Alcanzado el
límite de
aviso
Al menos uno de los contadores de error del driver
de CAN ha alcanzado o excedido el nivel de aviso
(warning). Demasiadas tramas de error ó error
frames.
Doble parpadeo
Evento de
control de
error NMT
Se ha producido un evento de “guarding” (NMT
esclavo ó NMT maestro) o un evento de
“heartbeat” (consumidor de heartbeat).
Triple parpadeo
Bus off
El control de CAN se encuentra en “bus off”
MCP/MCPi - Ref.0612
Protocolo CANopen - 37/40
‡ Led verde. Led indicador de estado
TABLA 32. Led indicador de error. Color rojo.
Led de marcha (verde)
Estado
Descripción
Iluminado
Operacional El equipo se encuentra en estado operacional
Intermitente
Preoperacional
El equipo se encuentra en estado
pre-operacional
Un único parpadeo
Detenido
El equipo se encuentra en estado de parada.
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
FIGURA 7.
Denominación y tiempos de parpadeo del led indicador NS (Network Status).
38/40 - Protocolo CANopen
MCP/MCPi - Ref.0612
Notas de usuario.
MCP/MCPi - Ref.0612
Protocolo CANopen - 39/40
Oficinas subsidiarias de FAGOR:
SPAIN
Sede Central:
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 - Protocolo CANopen
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