Fagor CANopen protocol (MCP-MCPi) Manual de usuario
- Tipo
- Manual de usuario
FAGOR AUTOMATION S.COOP.
MCP/MCPi
~ Protocolo CANopen ~
Ref.0612
2/40 - Protocolo CANopen MCP/MCPi - Ref.0612
Título MCP/MCPi. Protocolo CANopen.
Tipo de documentación Arquitectura, topología y comunicación en redes CANopen.
Denominación MAN_ MCP/MCPi_CANopen (cas.).
Referencia Ref.0612
Software V01.05 (MCP), V01.01 (MCPi)
WinDDSSetup A partir de la versión V0612
Documento electrónico MAN_MCP&MCPi_CANopen.pdf
Headquarters FAGOR AUTOMATION S.COOP.
Bº San Andrés 19, Apdo. 144
20500 ARRASATE- MONDRAGÓN
www.fagorautomation.com
info@fagorautomation.es
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.
MCP/MCPi - Ref.0612 Protocolo CANopen - 3/40
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.
4/40 - Protocolo CANopen MCP/MCPi - Ref.0612
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.
MCP/MCPi - Ref.0612 Protocolo CANopen - 5/40
Í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
6/40 - Protocolo CANopen MCP/MCPi - Ref.0612
PÁGINA EN BLANCO
MCP/MCPi - Ref.0612 Protocolo CANopen - 7/40
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.
En la red deberán ser conectadas entre sí todas las líneas CAN_H, CAN_L y
CAN_SHLD.
Recuérdese que el nodo 0 no existe como tal y queda reservado para ciertos
mensajes genéricos utilizados por el elemento maestro.
FIGURA 1.
Topología de una red CAN.
MAESTRO
CANopen
Conector
CANopen
del PC
5
4
3
2
1
120 Ω
Conector
CANopen
DRIVE 3
4
3
2
Conector
CANopen
DRIVE 2
4
3
2
Conector
CANopen
DRIVE 1
7
2
5
120 Ω
Blanco
Malla
Marrón
CAN_SHLD
CAN_H
CAN_L
CAN_H
CAN_SHLD
CAN_L
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 resist-
encia 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.
8/40 - Protocolo CANopen MCP/MCPi - Ref.0612
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.
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:
FIGURA 2.
Cables de conexión entre módulos conectados a una red CAN.
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
CAN H
SHIELD
CAN L
SHIELD
ISO GND
5
4
3
2
1
Pin
5
4
3
2
1
Pin
5
4
3
2
1
Pin
7
25
C
A
N
o
p
e
n
Vista frontal del conector Sub-D, F9 del extremo
del cable CAN
Cable CAN entre
PC y DRIVE1
Cable CAN entre
DRIVE1 y DRIVE2
Cable CAN entre
DRIVE2 y DRIVE3
5
4
3
2
1
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. ----
MCP/MCPi - Ref.0612 Protocolo CANopen - 9/40
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 men-
saje 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 CRC-
16.
<Acknowledge>: Reconocimiento de trama.
<End>: Bits de final de trama.
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.
FIGURA 3.
Trama CAN estándar.
1
12
6
0-8 bytes 16
27
Start bit
A
rbitration
Control bits
Data field
CRC
Acknowledge
End
Bit Length
10/40 - Protocolo CANopen MCP/MCPi - Ref.0612
COB ID
Identificador del mensaje puesto en la red implementado en los 11 bits del
identificador en la trama de CAN. Su estructura es:
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”
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.
FIGURA 4.
Estructura del COB ID.
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
10 9 8765 4 3 2 1 0
código de función nº de nodo: 0 - 127
MCP/MCPi - Ref.0612 Protocolo CANopen - 11/40
- Objetos “Per to Per”
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.
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:
TABLA 3. Objetos Per to Per.
Objeto Bits de código
de función
COB ID Parámetros de
mapeado del PDO
Parámetros de
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.
COB ID Byte 0
0x700 + ID de nodo 0
12/40 - Protocolo CANopen MCP/MCPi - Ref.0612
(Control del módulo) NMT- maestro Î NMT- esclavos.
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.
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.
NMT- maestro
Í NMT- esclavos.
COB ID Byte 0 Byte 1
0x000 CS ID de nodo
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 -
COB ID
0x700 + ID de nodo
COB ID Byte 0
0x700 + ID de nodo Bit 7 - Toggle bit - Bits 6-0 - Estado
MCP/MCPi - Ref.0612 Protocolo CANopen - 13/40
Estado.
Objetos relacionados.
Alternativamente, un nodo puede ser configurado con el fin de generar un mensaje
periódico denominado “Heartbeat”.
(Heartbeat) Productor
Î Consumidor / es.
Estado.
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.
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.
100Ch Guard Time
100Dh Life Time
100Eh Node Guarding Identifier ( por defecto: 700 + ID de nodo )
COB ID Byte 0
0x700 + ID de nodo Estado
TABLA 6. Heartbeat. Estados.
Estado Significado
0 Boot-up
4 Parado
5 En funcionamiento
127 En fase previa al funcionamiento normal
Atención: Un nodo no puede soportar “Heartbeat” y “Node Guarding” simultánea-
mente.
14/40 - Protocolo CANopen MCP/MCPi - Ref.0612
(Sync) Productor Î Consumidor / es.
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.
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 sobre-
cargarlo con información redundante.
En los mensajes PDO (en los bytes de datos) se transmiten única y exclusiva-
mente 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).
COB ID
0x080
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
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.
MCP/MCPi - Ref.0612 Protocolo CANopen - 15/40
Mapeo y tipo de comunicaciones
Supóngase que en el objeto de mapeo del segundo PDO de transmisión se dis-
pone de los siguientes valores:.
Valor Dword (32 bits)
Supóngase que en el objeto de comunicaciones del segundo PDO de transmisión
se dispone de los siguientes valores:
Valor del subíndice 1 (COB ID)
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.
TABLA 8. Descripción.
Bits 31-16 Bits 15-8 Bits 14-0
Indice Subíndice Nº de bits de datos del objeto
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.
20xBC
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.
TABLA 10. Valor del subíndice 1 (COB ID)
Bit 31 Bit 30 Bit 29 Bits 28-11 Bits 10-0
0
ÎPDO existe
1
ÎPDO no existe
0
ÎRTR permitido
1
ÎRTR no permitido
0
ÎCAN ID 11 bits
1
ÎCAN ID 29 bits
Parte alta
del COB ID
(si CAN ID
es de 29 bits)
.
Parte baja
del COB ID
(si CAN ID
es de 29 bits).
COB ID
(si CAN ID es
de 11 bits)
.
16/40 - Protocolo CANopen MCP/MCPi - Ref.0612
Valor del subíndice 2 ( Tipo de transmisión )
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 única-
mente si se produce un evento, y en este caso, el mensaje es enviado sincrónica-
mente con el siguiente mensaje de sincronismo.
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 trans-
misió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.
TABLA 11. Valor del subíndice 2 (tipo de transmisión).
Tipo de
transmisión
Condición de disparo del PDO
( B = se necesitan ambos, O = uno o ambos )
Transmisión del
PDO
SYNC
Objeto
SYNC
recibido
RTR
Recibida
solicitud de
transmisión
remota
Evento
Cambio de valor
de la interrupción
del temporizador
0 B B Síncrona (SYNC), acíclica
1-240 O Síncrona (SYNC), cíclica
241-251 Reservado
252 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.
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.
MCP/MCPi - Ref.0612 Protocolo CANopen - 17/40
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, ocu-
pando 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 mien-
tras 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:
La transmisión del PDO será cíclica y es suministrada al bus tras haber recibido 188
mensajes de sincronismo.
Objetos relacionados
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.
TABLA 12. Mensaje PDO.
COB ID Byte 0 Byte 1 Byte 2
0x280
+ ID del nodo
8 bits de datos del
objeto 0x6000
Parte baja de los 16 bits de
datos del objeto 0x6000
Parte alta de los 16 bits de
datos del objeto 0x6401
1004 h Nº de PDOs soportados
18/40 - Protocolo CANopen MCP/MCPi - Ref.0612
Estructuras básicas de un SDO
Las estructuras básicas de un SDO son:
Cliente Î Servidor / Servidor Î Cliente
ó también Cliente
Î Servidor / Servidor Î Cliente
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)
Indicadores de comando de SDO para los diferentes protocolos
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).
TABLA 13. Estructura SDO. Cliente Î Servidor / Servidor Î Cliente
Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7
Indicador del
comando
SDO
Índice
de
objetos
Subíndice
de
objetos
Hasta 4 Bytes de datos en transferencia
expeditada ó 4 Bytes del contador en
transferencia segmentada
TABLA 14. Estructura SDO. Cliente Î Servidor / Servidor Î Cliente
Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7
Indicador del
comando SDO
Hasta 7 Bytes de datos en transferencia
segmentada
Se entiende por descargar (download) a escribir en el diccionario de objetos y
cargar (upload) a leer del diccionario de objetos.
TABLA 15. Inicio de la descarga de dominio.
Comenzar la descarga de dominio
bit
76543210
Cliente
Î 001- n es
Servidor
Í 011- - - --
MCP/MCPi - Ref.0612 Protocolo CANopen - 19/40
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).
Un mensaje puede ser abortado tanto por el cliente como por el servidor. Debe
indicarse con el siguiente indicador de comando:
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.
TABLA 16. Descarga del segmento de dominio.
Descargar el segmento de dominio
bit 76543210
Cliente
Î 000t n c
Servidor
Í 000t - - - -
TABLA 17. Comienzo de la carga de dominio.
Comenzar la carga de dominio
bit 76543210
Cliente
Î 010- - - - -
Servidor
Í 010- n es
TABLA 18. Carga del segmento de dominio.
Cargar el segmento de dominio
bit 76543210
Cliente
Î 011t - - - -
Servidor
Í 000t n c
TABLA 19. Abortado de la transferencia de dominio.
Abortar la transferencia de dominio
bit 76543210
Cliente
Î / Í Servidor100- - - - -
20/40 - Protocolo CANopen MCP/MCPi - Ref.0612
Códigos que describen la posible razón de abortar SDO
Objeto de emergencia
Un mensaje de emergencia se compone de 8 bytes y dispone del siguiente formato:
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 03 00 00
El bit basculante no es basculante
05 04 00 00
TimeOut para el protocolo SDO
05 04 00 01
Comando Cliente/Servidor inválido o identificador
desconocido
05 04 00 02
Tamaño no reconocido de bloque (sólo modo bloque)
05 04 00 03 Número no reconocido de bloque (sólo modo bloque)
05 04 00 04
Error CRC (sólo modo bloque)
05 04 00 05
Memoria insuficiente
06 01 00 00
Acceso no soportado a este objeto
06 01 00 01
Se ha intentado leer un objeto de sólo escritura
06 01 00 02
Se ha intentado escribir un objeto de sólo lectura
06 02 00 00
El objeto no existe en el diccionario de objetos
06 04 00 41
El objeto no puede ser mapeado a un PDO
06 04 00 42
El tamaño y número de objetos mapeados sobrepasan la
longitud del PDO
06 04 00 43
Incompatibilidad general de parámetros
06 04 00 47
Incompatibilidad general de dispositivos
06 06 00 00
Acceso infringido causado por error de hardware
06 07 00 10
Tipo de dato incompatible, la longitud del parámetro de
servicio es incompatible
06 07 00 12
Tipo de dato incompatible, el parámetro de servicio es
demasiado largo
06 07 00 13
Tipo de dato incompatible, el parámetro de servicio es
demasiado corto
06 09 00 11
No existe el subíndice
06 09 00 30 Rango de valores externo (sólo para acceso de escritura)
06 09 00 31
Valor de parámetro demasiado alto
06 09 00 32
Valor de parámetro demasiado bajo
06 09 00 36 El valor máximo es inferior al valor mínimo
08 00 00 00
Error / fallo general
08 00 00 20
Los datos no pueden ser transmitidos ni guardados
08 00 00 21
Los datos no pueden ser transmitidos ni guardados porque
el dispositivo está bajo control local
08 00 00 22
Los datos no pueden ser transmitidos ni guardados debido
al estado del dispositivo
08 00 00 23
No es posible generar dinámicamente el diccionario de
objetos
TABLA 21. Mensaje de emergencia.
COB ID Byte 0 -1 Byte 2 Byte 3 -7
0x080
+ ID del nodo
Código de error de
emergencia
Registro de error
(objeto 0x1001)
Campo de error especificado
por el fabricante
MCP/MCPi - Ref.0612 Protocolo CANopen - 21/40
Códigos de error de emergencia
TABLA 22. Códigos de error de emergencia.
Código de error de emergencia Significado
00xx Error reset o no error
10xx Error genérico
20xx Corriente
21xx Corriente, lado de entrada del dispositivo
22xx Corriente dentro del dispositivo
23xx Corriente, lado de salida del dispositivo
30xx Tensión
31xx Tensión de red
32xx Tensión dentro del dispositivo
33xx Tensión de salida
40xx Temperatura
41xx Temperatura ambiente
42xx Temperatura del dispositivo
50xx Hardware del dispositivo
60xx Software del dispositivo
61xx Software interno
62xx Software de usuario
63xx Dato W
70xx Módulos adicionales
80xx Monitorización
81xx Comunicación
8110 CAN sobrepasado
8120 Error pasivo
8130 Error “ life guard” ó error “Heartbeat”
8140 Restaurado desde el bus-off
82xx Error de protocolo
8210 PDO no procesado por error de longitud
8220 Longitud superada
90xx Error externo
F0xx Funciones adicionales
FFxx
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.
22/40 - Protocolo CANopen MCP/MCPi - Ref.0612
Registro de error (objeto 0x1001)
Objetos relacionados
Descripción del diccionario de objetos
Objetos de comunicaciones (DS301)
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.
TABLA 23. Registro de error (OBJETO 0x1001).
Bit Tipo de error
0 Genérico
1 Corriente
2 Tensión
3 Temperatura
4 Comunicación
5 Específico del perfil de dispositivo
6 Reservado (=0)
7 Específico del fabricante
1001 h Registro de errores
1003 h Campo de errores predefinidos
1014 h COB ID para el mensaje de emergencia
TABLA 24. Objetos de comunicaciones (DS301).
Índice Descripción
1000h
Tipo de dispositivo
1001h
Registro de errores
1003h
Campo de errores predefinidos
1005h
COB ID de mensaje SYNC
1006h
Período de ciclo de comunicación
1007h
Longitud de la ventana de sincronismo
1008h
Nombre de dispositivo del fabricante
1009h
Versión de hardware del fabricante
100Ah Versión de software del fabricante
100Ch
Tiempo de vigilancia
100Dh
Factor de tiempo de vida
1014h
COB ID para mensaje de emergencia
1015h
Tiempo de inhibición para mensaje de emergencia
1018h
Objeto de identidad
1400h
Parámetro de comunicación de PDO recepción
1600h
Parámetro de mapeo de PDO recepción
1800h
Parámetro de comunicación de PDO transmisión
1A00h
Parámetro de mapeo de PDO transmisión
MCP/MCPi - Ref.0612 Protocolo CANopen - 23/40
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
0x80000000 a
0x7fffffff
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
24/40 - Protocolo CANopen MCP/MCPi - Ref.0612
Nombre Índice IdA Descripción Acc Tipo Rango
GP9 50CFh 643h DriveOfDelayTime R/W UINT 0 a 9999
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 string -32768 a 32767
GV11 42C4h 685h SoftReset R/W UINT 0 a 16
GV16 42CCh 686h MotorTableVersion R UINT 0 a 32767
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 INT -12000 a 12000
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
ID5 49C4h 1B85h BusCodeChecksum R UINT -32768 a 32767
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 R/W UINT 0 a 1
LV35 491Fh B89h BlockTravelDistance R INT
0x8000000
a 0x7fffffff
LV36 4920h B8Ah BlockCoveredDistance R INT
0x8000000
a 0x7fffffff
LV158 5102h B8Bh TargetPosition R INT
0x8000000
a 0x7fffffff
MCP/MCPi - Ref.0612 Protocolo CANopen - 25/40
Nombre Índice IdA Descripción Acc Tipo Rango
LV159 5103h B8Ch PositioningVelocity R UINT 0 a 0x7fffffff
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 UINT 0 a 0x7fffffff
PP49 5031h F44h PositivePositionLimit R/W INT
0x8000000
a 0x7fffffff
PP50 5032h F45h NegativePositionLimit R/W INT
0x8000000
a 0x7fffffff
PP52 5034h F46h ReferenceDistance1 R/W INT
0x8000000
a 0x7fffffff
PP54 5036h F47h ReferenceDistance2 R/W INT
0x8000000
a 0x7fffffff
PP55 5037h F48h PositionPolarityParameters R/W UINT 0 a 65535
PP57 5039h F49h PositionWindow R/W INT
0x8000000
a 0x7fffffff
PP76 504Ch F4Ah PositionDataScalingType R/W 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
26/40 - Protocolo CANopen MCP/MCPi - Ref.0612
Nombre Índice IdA Descripción Acc Tipo Rango
PV51 5033h F81h PositionFeedback1 R INT
0x8000000
a 0x7fffffff
PV53 5035h F82h PositionFeedback2 R INT
0x8000000
a 0x7fffffff
PV173 50ADh F83h MarkerPositionA R INT
0x8000000
a 0x7fffffff
PV189 50BDh F84h FollowingError R INT
0x8000000
a 0x7fffffff
PV200 5190h F85h HomeSwitch R 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 -500 a 500
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 -2000 a 2000
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
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·10
7
a 6·10
7
SV2 5028h 1282h VelocityFeedback R INT -6·10
7
a 6·10
7
SV6 4656h 1283h VelocityCommandAfterFilters R INT -6·10
7
a 6·10
7
SV7 464Ch 1284h VelocityCommandFinal R INT -6·10
7
a 6·10
7
MCP/MCPi - Ref.0612 Protocolo CANopen - 27/40
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
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.
Nombre Índice IdA Descripción Acc Tipo Rango
SV15 4657h 1285h DigitalVelocityCommand R/W INT -6·10
7
a 6·10
7
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
TABLA 26. AssemblyIn.
B7 B6 B5 B4 B3 B2 B1 B0
Byte 0 I_Fast Starting_Block
Byte 1
Drive_
Enable
Speed_
Enable
Home_
Switch
Lim - Lim +
Reset *
Stop
Start *
Jog- ** Jog+ **
Byte 2 Dir_Var Bits 0 -7
Byte 3
Command_
Toggle_Bit
Command Dir_Var Bits 8-12
Byte 4 Data_Byte 0
Byte 5 Data_Byte 1
Byte 6 Data_Byte 2
Byte 7 Data_Byte 3
* KernelOperationMode Î LV13 = 0, es decir, en modo automático.
** KernelOperationMode Î LV13 = 1, es decir, en modo manual.
28/40 - Protocolo CANopen MCP/MCPi - Ref.0612
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.
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.
0
Leer un parámetro / una variable.
1
Escribir un parámetro / una variable
2
Leer en la tabla de movimientos
3
Escribir en la tabla de movimientos
MCP/MCPi - Ref.0612 Protocolo CANopen - 29/40
AssemblyOut - Estado
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.
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 del 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.
TABLA 27. AssemblyOut.
B7 B6 B5 B4 B3 B2 B1 B0
Byte 0 Ref_Done Reg_Status Warning Error In_Position ---- Speed_Enable
Byte 1 ------------- Active_Block
Byte 2
Command_
Toggle_Bit_Resp
Command_
Resp
Command_
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
(----) Bits reservados.
0 Realizando el test interno de Start-Up.
1 Control establecido. A la espera de recibir potencia.
2 Power On. Potencia y control establecidos pero, sin par en el motor.
3 Torque On. Motor con par (habilitado).
30/40 - Protocolo CANopen MCP/MCPi - Ref.0612
Operation_Status: Bits que reflejan el “modo” y el “estado” en el que se encuentra
el secuenciador de movimientos del equipo.
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.
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.
FIGURA 5.
Modo de operación del regulador.
Estructura del Assembly. Ejemplos prácticos.
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.
STOP
5
MODO
AUTOMÁTICO
0
BLOQUE EN EJECUCIÓN
1
A la espera de
desactivar el
modo JOG
12
En espera de la
señal START
4
Reset
6
desde
0-1-2-3-4-5
Cambio a
KernelOperationMode
MODO
MANUAL
10
Modo JOG en
funcionamiento
11
KernelManMode
(INCREMENTAL)
& FIN DE
MOVIMIENTO
Desde todos
los estados
Alarma
Alarma
15
PAUSA DE
BLOQUE
3
En espera de que
la señal START
no esté activa
2
KernelStartSignal
& KernelStopSignal
& KernelResetSignal
BlockEnd
KernelResetSignal
KernelResetSignal
KernelStopSignal
Mnemónicos y símbolos
A
A
(A negada)
Señal A activa
X
Modo de operación
Estado
Señal A no activa
Ejemplo:
KernelStopSignal
KernelStopSignal
= KernelStopSignal no activa
= KernelStopSignal activa
desde
10-11-12
Cambio a
KernelOperationMode
KernelStopSignal
KernelStartSignal
JogPositiveSignal
& JogNegativeSignal
& KernelStopSignal
KernelStartSignal
KernelStopSignal
KernelStopSignal
JogPositiveSignal
OR JogNegativeSignal
& KernelStopSignal
& KernelResetSignal
JogPositiveSignal
& JogNegativeSignal
(CONTINUO)
& KernelManMode
OR KernelResetSignal
OR KernelStopSignal
Transiciones entre estados
MCP/MCPi - Ref.0612 Protocolo CANopen - 31/40
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.
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.
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).
Lectura de parámetro/variable
Escritura de parámetro/variable
Tabla de movimientos
32/40 - Protocolo CANopen MCP/MCPi - Ref.0612
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).
TABLA 28. Estructura del bloque de posicionamiento.
Descripción
del campo
Reserv. LOOP NEXT PROGOUT
EVENTO
TIPO TIEMPO
Valor 0000h
0000h
a
FFFFh
0001h a 0080h
“ OR ”
Cnt piezas
SC00h
END=xxFEh
(1
00000000h
a
000000FFh
InRpos (real) 0001h
0000h
a
FFFFh
InTpos (teórico) 0002h
InBand 0003h
ActSpeedReached 0004h
NextSpeedReached 0005h
“OR”
FastInput
(2
0100h
Nº WORD 15-12 11 10 9-8 7 6
Descripción
del campo
VELPOS
POSDEST
VALOR MODO
Valor
00000000h
a
FFFFFFFFh
00000000h
a
FFFFFFFFh
Absoluto
0000 0001 h
Incremental
0000 0002 h
+ Infinito
0000 0003 h
- Infinito
0000 0004 h
Stop
0000 0005 h
Nº WORD 5-4 3-2 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
MCP/MCPi - Ref.0612 Protocolo CANopen - 33/40
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.
Escritura de la tabla de movimientos
34/40 - Protocolo CANopen MCP/MCPi - Ref.0612
Puesta en marcha
Descripción de la tarjeta CAN
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 den-
tro del bus CAN de comunicaciones.
Conmutadores “x1” y “x10”
Î Conmutadores rotativos que permiten selec-
cionar 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.
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
FIGURA 6.
Descripción de la tarjeta CAN® de un módulo MCP ó MCPi. Protocolo CANopen.
Nota: Únicamente serán utilizados los valores 0 y 99 para ciertos casos
especiales documentados más adelante.
MCP/MCPi - Ref.0612 Protocolo CANopen - 35/40
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:
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.
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.
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 1000 kbit/s 6 100 kbit/s
2 800 kbit/s 7 50 kbit/s
3 500 kbit/s 8 20 kbit/s
4 250 kbit/s 9 10 kbit/s
5 125 kbit/s
TABLA 30. Selección de la velocidad de transmisión.
Posición del switch
rotativo “x1”
Velocidad de
transmisión
Posición del switch
rotativo “x1”
Velocidad de
transmisión
1 1000 kbit/s 6 100 kbit/s
2 800 kbit/s 7 50 kbit/s
3 500 kbit/s 8 20 kbit/s
4 250 kbit/s 9 10 kbit/s
5 125 kbit/s
36/40 - Protocolo CANopen MCP/MCPi - Ref.0612
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.
La determinación del nº de nodo del equipo se lleva a cabo mediante los dos
conmutadores rotativos x1 y x10.
Ejemplo.
Tras realizar un reset del regulador, éste será identificado en la red con el nº de nodo
que le ha sido asignado.
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.
IMPORTANTE: Queda bajo la responsabilidad del usuario evitar que dos
equipos distintos dispongan del mismo nº de nodo.
El rango de selección del nº de nodo en una red CANopen está comprendido en-
tre 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.
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.
MCP/MCPi - Ref.0612 Protocolo CANopen - 37/40
En un proceso inicial del equipo estos leds alcanzan los siguientes estados con el
fin de verificar el correcto estado del regulador.
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
Nota. MS y NS se iluminan de acuerdo al estado en el que se encuentran tanto
el bus como el equipo.
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”
NS
(green)
on
off
NS
(red)
on
off
MS
(green)
on
off
on
off
MS
(red)
250 ms
250 ms
250 ms
250 ms
38/40 - Protocolo CANopen MCP/MCPi - Ref.0612
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
Pre-
operacional
El equipo se encuentra en estado
pre-operacional
Un único parpadeo Detenido El equipo se encuentra en estado de parada.
FIGURA 7.
Denominación y tiempos de parpadeo del led indicador NS (Network Status).
triple flash
(green)
on
off
triple flash
(red)
on
off
doble flash
(red)
on
off
single flash
(green)
on
off
single flash
(red)
on
off
blincking
(green)
on
off
blincking
(red)
on
off
flickering
(green)
on
off
flickering
(red)
on
off
50 ms
200 ms
6 x 200 ms 1000 ms
MCP/MCPi - Ref.0612 Protocolo CANopen - 39/40
Notas de usuario.
40/40 - Protocolo CANopen MCP/MCPi - Ref.0612
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: info@fagorautomation.es
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: usurbil@fagorautomation.es
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: del.catalunya@barna.fagorautoma-
tion.es
FRANCE
FAGOR AUTOMATION FRANCE Sàrl
Parc Technologique de La Pardieu
16 Rue Patrick Depailler
63000 CLERMONT FERRAND
Tel.: 33-473277916
Fax: 33-473150289
fagorautomation@wanadoo.fr
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: automation@fagor.de
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: italy@fagorautomation.it
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: info@fagorautomation.co.uk
PORTUGAL
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: fagorauto[email protected]
USA
Chicago:
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: fagorusa@fagor-automation.com
California:
FAGOR AUTOMATION West Coast
3176 Pullman Ave., Unit 110
COSTA MESA, CA 92626
Tel: 1-714-9579885
Fax: 1-714-9579891
E-mail: caservice@fagor-automation.com
New Jersey:
FAGOR AUTOMATION East Coast
Tel: 1-973-7733525
Fax: 1-973-7733526
E-mail: wnelson@fagor-automation.com
South East:
FAGOR AUTOMATION SOUTH EAST
4234 Amber Ridge Ln- VALRICO, FL 33594
Tel: 813 654 4599
E-mail: jkas@fagor-automation.com
Ohio:
FAGOR AUTOMATION OHIO BRANCH
Westerville OH 43081
Tel: 1 614-855-5720
Fax: 1 614-855-5928
E-mail: tdrane@fagor-automation.com
CANADA
Ontario:
FAGOR AUTOMATION ONTARIO
Unit 3, 6380 Tomken Road
MISSISSAUGA L5T 1Y4
Tel: 1-905-6707448
Fax: 1-905-6707449
E-mail: sales@fagorautomation.on.ca
Montreal:
FAGOR AUTOMATION QUEBEC
Tel.: 1-450-2270588
Fax: 1-450-2276132
E-mail: montreal@fagorautomation.on.ca
Windsor:
FAGOR AUTOMATION WINDSOR
Tel.: 1-519 944-5674
Fax: 1-519 944-2369
BRAZIL
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: brazil@fagorautomation.com.br
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: sale@fagorautomation.com.cn
Nanjing:
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: fagor_nj@fagorautomation.com.cn
CHINA
Guangzhou:
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: fagor_gz@fagorautomation.com.cn
Shanghai:
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: fagor_sh@fagorautomation.com.cn
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: fagorhk@fagorautomation.com.hk
KOREA, Republic of
FAGOR AUTOMATION KOREA, LTD.
Room No. 707 Byucksan Digital Valley 2
nd
481-10 Gasan-dong. Geumcheon-gu
Seoul 153-803, Korea
Tel: 82 2 2113 0341
Fax: 82 2 2113 0343
E-mail: korea@fagorautomation.com.kr
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: singapore@fagorautomation.com.sg
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: malaysi[email protected]
-
1
-
2
-
3
-
4
-
5
-
6
-
7
-
8
-
9
-
10
-
11
-
12
-
13
-
14
-
15
-
16
-
17
-
18
-
19
-
20
-
21
-
22
-
23
-
24
-
25
-
26
-
27
-
28
-
29
-
30
-
31
-
32
-
33
-
34
-
35
-
36
-
37
-
38
-
39
-
40
Fagor CANopen protocol (MCP-MCPi) Manual de usuario
- Tipo
- Manual de usuario
Artículos relacionados
-
Fagor Profibus-DP Protocol (MCP-MCPi) Manual de usuario
-
-
-
-
-
Fagor CNC 8060 Manual de usuario
-
Fagor CNC 8058elite M El manual del propietario
Otros documentos
-
AVENTICS Bus Control CMS, B-Design, CANopen El manual del propietario
-
-
-
LXNAV FlarmLED Manual de usuario
-
ProMinent delta 986524 Supplementary Instructions Manual
-
SICK OLS10 Quickstart