FAGOR AUTOMATION S.COOP MCP/MCPi · MCP/MCPi - Ref.0612 Protocolo CANopen - 7/40 PROTOCOLO CANopen...

40
FAGOR AUTOMATION S.COOP . MCP/MCPi ~ Protocolo CANopen ~ Ref.0612

Transcript of FAGOR AUTOMATION S.COOP MCP/MCPi · MCP/MCPi - Ref.0612 Protocolo CANopen - 7/40 PROTOCOLO CANopen...

Page 1: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

FAGOR AUTOMATION S.COOP.

MCP/MCPi

~ Protocolo CANopen ~

Ref.0612

Page 2: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

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. 14420500 ARRASATE- MONDRAGÓ[email protected]

Teléfono: 34-943-719200Fax: 34-943-771118 (Servicio de Asistencia Técnica)

La información descrita en este manual puede estar sujeta a variaciones motivadaspor modificaciones técnicas. FAGOR AUTOMATION, S. Coop. se reserva elderecho de modificar el contenido del manual, no estando obligada a notificar lasvariaciones.

Se han contrastado los contenidos de este manual y sus coincidencias con elproducto descrito. Aún así, es posible el deslíz de algún error introducido de manerainvoluntaria y, es por ello que, no se garantiza una coincidencia absoluta. Noobstante, es comprobada regularmente la información contenida en el documento,procediéndose a realizar las correcciones oportunas que quedarán incluídas enuna posterior edición.

Todos los derechos reservados. No puede reproducirse ninguna parte de estadocumentación, transmitirse, transcribirse, almacenarse en un sistema derecuperación de datos o traducirse a ningún idioma sin premiso expreso de FagorAutomation S. Coop.

2/40 - Protocolo CANopen MCP/MCPi - Ref.0612

Page 3: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

GARANTÍA

GARANTÍA INICIAL:

Todo producto fabricado o comercializado por FAGOR tiene una garantía de 12 meses parael usuario final.

Para que el tiempo que transcurre entre la salida de un producto desde nuestros almaceneshasta la llegada al usuario final no juegue en contra de estos 12 meses de garantía, el fabricanteo intermediario debe comunicar a FAGOR el destino, identificación y fecha de instalación dela 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 deinstalació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 delproducto, de forma que la fecha de comienzo de garantía puede ser hasta un año posteriora la salida del producto de nuestros almacenes, siempre y cuando se nos haya remitido la hojade garantía. Esto supone en la práctica la extensión de la garantía a dos años desde la salidadel 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 nuestrosalmacenes.

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 definidocomo garantía.

CLÁUSULAS EXCLUYENTES:

La reparación se realizará en nuestras dependencias. Por tanto, quedan fuera de garantíatodos los gastos de transporte o los ocasionados en el desplazamiento de su personal técnicopara realizar la reparación de un equipo, aún estando éste dentro del período de garantía antescitado.

La citada garantía se aplicará siempre que los equipos hayan sido desinstalados de acuedocon las instrucciones, no hayan sido maltratados o sufrido desperfectos por accidente onegligencia 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 nuestroproducto, el cliente está obligado a cubrir todos los gastos ocasionados ateniéndose a lastarifas vigentes.

No están cubiertas otras garantías implícitas o explícitas y FAGOR AUTOMATION no se haceresponsable 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íodode garantía como fuera de él.

MCP/MCPi - Ref.0612 Protocolo CANopen - 3/40

Page 4: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

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 Fagorcompuesto 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, Normaespecí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 CANopensobre la placa CAN de los reguladores MCP y MCPi, de la arquitectura, topología ycomunicació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 documentocompleto.

Ante cualquier duda o necesidad no dude en consultar con nuestros técnicos encualquiera de las oficinas subsidiarias.Gracias por elegir Fagor.

4/40 - Protocolo CANopen MCP/MCPi - Ref.0612

Page 5: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

ÍNDICE GENERAL

PROTOCOLO CANopen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7Arquitectura de la red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7Topología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7Cable de conexión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8Longitud máxima . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8Comunicación en la red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9Trama CAN estándar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9Conexión predefinida CANopen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9NMT, Network Management. Proceso de arranque y control de red . . . . . . . . . .11PDO, Objeto de Datos de Proceso. Canal rápido . . . . . . . . . . . . . . . . . . . . . . . . .14SDO, Objeto de Datos de Servicio. Canal lento . . . . . . . . . . . . . . . . . . . . . . . . . .17Objeto de emergencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20Descripción del diccionario de objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22Descripción de los PDOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27Puesta en marcha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34Descripción de la tarjeta CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34Selección de la velocidad de comunicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34Determinación del nº de nodo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36Indicadores de estado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36

MCP/MCPi - Ref.0612 Protocolo CANopen - 5/40

Page 6: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

PÁGINA EN BLANCO

6/40 - Protocolo CANopen MCP/MCPi - Ref.0612

Page 7: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

PROTOCOLO CANopen IntroducciónCANopen es un protocolo de comunicación de red basado en el sistema de BusCAN (desarrollado por BOSCH a mediados de los 80 y orientado al mundo de laautomoción). CANopen está definido como una capa de aplicación uniforme en laespecificación DS301 editada por la entidad que regula la especificación CIA (CanIn Automation).CAN es un sistema de Bus Multimaster que contrasta con otros sistemas de Busen que los módulos conectados a él no son direccionados por los identificadoresde 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 acierta prioridad asignada a los mensajes, establecida en el propio COB ID(Communication Object Identifier) y claramente asignada a los objetos decomunicación. El COB ID que contenga el menor valor identifica el mensaje demayor prioridad. Esta característica proporciona una autorregulación deprioridades en el Bus sin la gestión de ningún elemento maestro (master).

Arquitectura de la redTopología

Para construir una red CAN simple, donde la comunicación va a ser establecida conprotocolo CANopen, será necesario mínimamente un elemento esclavo, unelemento maestro (p. ej. un PC con tarjeta de bus de campo CAN) y un cable deconexió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 yCAN_SHLD.

Recuérdese que el nodo 0 no existe como tal y queda reservado para ciertosmensajes genéricos utilizados por el elemento maestro.

FIGURA 1.Topología de una red CAN.

MAESTROCANopen

ConectorCANopendel PC

54

3

21

120 Ω

ConectorCANopen

DRIVE 3

4

3

2

ConectorCANopen

DRIVE 2

4

3

2

ConectorCANopen

DRIVE 1

7

25

120 Ω

Blanco

Malla

MarrónCAN_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 cadamódulo extremo del bus CANopen. En la red de la figura han sido instaladas en el PC y en elDRIVE3 que son los módulos extremos del bus. Si p.ej. en lugar del PC se hubiese ubicado unDRIVE 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 formanparte del bus no estarán ubicados en los extremos del mismo y, por tanto, no se instalará enellos ninguna resistencia. Véase figura.

MCP/MCPi - Ref.0612 Protocolo CANopen - 7/40

Page 8: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

Cable de conexión Para realizar la conexión de la tarjeta CAN, dispuesta en un regulador, a una redCANopen, será necesario disponer de un cable CAN formado por una manguera dedos hilos con pantalla exterior. En uno de los extremos de la manguera se incorporaun conector “Open Style” enchufable de 5 vías y paso 5 mm. La malla irá conectadaal 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 conformanla red deberán ser conectadas entre sí.En los dos módulos extremos del bus de CAN (y sólo en éstos) deberán serinstaladas externamente por el usuario (entre los pines 2 y 4 del conector OpenStyle si el módulo extremo es un regulador ó 2 y 7 del conector Sub-D, M9 si es elmódulo extremo es el PC) una resistencia terminadora de línea de 120 Ω en cadauno con la finalidad de evitar reflexiones (rebotes), es decir, problemas detransmisión.

Longitud máximaEn la siguiente tabla quedan reflejadas las longitudes máximas de la red en funciónde 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 HSHIELDCAN L

SHIELD

ISO GND

54321

Pin

54321

Pin

54321

Pin

7

25

CAN

open

Vista frontal del conector Sub-D, F9 del extremodel cable CAN

Cable CAN entre PC y DRIVE1

Cable CAN entre DRIVE1 y DRIVE2

Cable CAN entre DRIVE2 y DRIVE3

54321

Pin Señal Color del hilo5 N.C. ----4 CAN_H Blanco3 CAN_SHLD Malla2 CAN_L Marrón1 N.C. ----

8/40 - Protocolo CANopen MCP/MCPi - Ref.0612

Page 9: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

Comunicación en la red

Trama CAN estándarLas tramas estándar de CAN contienen entre 44 y 108 bits útiles. Además, en funciónde los datos enviados, pueden ser insertados en la trama por los drivers de CANhasta 23 bits “de relleno” de manera que el máximo nº de bits que se llega a alcanzaren 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 CANopenCon CANopen, la transmisión de datos, el disparo de eventos, la señalización deestados de error, ... es realizada mediante objetos de comunicación. Con estafinalidad, 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 deCOB IDs ya predefinidos.

FIGURA 3.Trama CAN estándar.

1 12 6 0-8 bytes 16 2 7Start bitArbitrationControl bitsData fieldCRCAcknowledgeEnd

Bit Length

MCP/MCPi - Ref.0612 Protocolo CANopen - 9/40

Page 10: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

COB IDIdentificador del mensaje puesto en la red implementado en los 11 bits delidentificador en la trama de CAN. Su estructura es:

Con el código de función 1 (objeto de emergencia) pueden generarse hasta 128objetos diferentes dependiendo del nº de nodo dispuesto en el mensaje. Los objetoscon identificador desde 0x81 hasta 0xFF son objetos de emergencia emitidos porel nodo cuyo número va implícito en el identificador. El 0x80 es un objeto diferenteemitido por el elemento maestro (sin nº de nodo asignado) de mayor prioridad quelos mensajes de emergencia y que sirve de sincronismo para el bus decomunicaciones.Dependiendo de que el nº de nodo aparezca o no en la cabecera del mensaje seestablecen 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úmerode 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 8 7 6 5 4 3 2 1 0

código de función nº de nodo: 0 - 127

10/40 - Protocolo CANopen MCP/MCPi - Ref.0612

Page 11: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

- Objetos “Per to Per”

Los objetos Per to Per implican establecer una comunicación entre dos nodosconcretos. 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 enambos casos). De ahí el rango especificado en la TABLA 3.En “parámetros de comunicación” se encuentra el objeto de comunicaciones enel que son configurados diferentes aspectos relativos a tal objeto.En “parámetros de mapeado del PDO” se encuentra el objeto de mapeo en el queson configurados los diferentes objetos mapeados para el correspondiente PDO.

NMT, Network Management. Proceso de arranque y control de redUna vez aplicada la tensión a un nodo CANopen se establece el proceso dearranque (start-up) inicializando sus variables, realizando su auto-chequeo, ...Realizada esta labor, cada nodo envía un mensaje de “Boot-Up” (arranque) através del bus para hacer saber al elemento maestro que un nuevo nodo hapasado a formar parte de la red CANopen.(Boot-Up) NMT - maestro NMT - esclavos.

Tras haber sido realizada correctamente esta tarea, el nodo pasa automáticamentea 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 estadooperacional:

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 00x700 + ID de nodo 0

MCP/MCPi - Ref.0612 Protocolo CANopen - 11/40

Page 12: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

(Control del módulo) NMT- maestro NMT- esclavos.

Esta acción puede o no establecerse como “Broadcast” dependiendo del valorindicado en el byte 1 del campo de datos. Así, si el valor del byte 1 es cero, laacción se establece como “Broadcast”. Si es distinto de cero y menor de 128, suvalor 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 ordena realizar. Véase la siguiente tabla.CS.

Dependiendo del valor especificado en estos bytes del campo de datos puedemodificarse el estado en el que se encuentran uno o todos los nodos presentes enla red.Tras un arranque satisfactorio de la red, el elemento maestro tiene la opción decomprobar cíclicamente que todos los nodos permanecen activos dentro de ella.Con - Node Guarding - el elemento maestro envía cíclicamente (bajo unos tiempospreviamente preestablecidos y comprobados) un mensaje “broadcast” sin datoalguno y al cual responden todos los nodos y donde se incluye el estado en el quese encuentra cada uno de ellos. Estos mensajes son:(Node Guarding) NMT- maestro NMT- esclavos.

NMT- maestro NMT- esclavos.

COB ID Byte 0 Byte 10x000 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 ID0x700 + ID de nodo

COB ID Byte 00x700 + ID de nodo Bit 7 - Toggle bit - Bits 6-0 - Estado

12/40 - Protocolo CANopen MCP/MCPi - Ref.0612

Page 13: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

Estado.

Objetos relacionados.

Alternativamente, un nodo puede ser configurado con el fin de generar un mensajeperiódico denominado “Heartbeat”.(Heartbeat) Productor Consumidor / es.

Estado.

El consumidor del “Heartbeat” normalmente es el elemento maestro que verifica elenvío por parte de cada uno de los nodos del mensaje de “Heartbeat” con unaperiodicidad establecida dentro de unos determinados márgenes y que actuará enconsecuencia siempre que ésto no se cumpla en alguno de los nodos.

TABLA 5. Node Guarding. Estados.

Valor Estado0 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 estacaracterística.

100Ch Guard Time

100Dh Life Time

100Eh Node Guarding Identifier ( por defecto: 700 + ID de nodo )

COB ID Byte 00x700 + 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.

MCP/MCPi - Ref.0612 Protocolo CANopen - 13/40

Page 14: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

(Sync) Productor Consumidor / es.

Objeto encargado de sincronizar el bus. Es cíclico, “Broadcast” y tiene máximaprioridad en el bus después del NMT. Está directamente relacionado con eltratamiento de PDOs.

Objetos relacionados.

PDO, Objeto de Datos de Proceso. Canal rápidoLos objetos de datos de procesos (PDOs) permiten llevar a cabo la transmisión dedatos en tiempo real y con identificadores de alta prioridad. Los telegramas de datospueden disponer de un máximo de 8 Bytes. El intercambio de datos puede realizarsemediante eventos o de modo síncrono, según se requiera. El intercambio demensajes mediante eventos permite reducir drásticamente la carga en el bus conrespecto al modo síncrono.

Protocolo PDOEste 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 susidentificadores. Para que esto pueda llevarse a cabo sin ningún tipo de error, loselementos maestro y esclavo han concertado previamente qué variables van a serenviadas dentro de cada PDO (mapeo). Esta asignación se establece mediante losobjetos “PDO Mapping Parameter”. El tipo de comunicación que se establecepara 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 (delelemento esclavo al maestro) ó de PDO de recepción (del elemento maestro alesclavo).

COB ID0x080

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 derecepción por cada elemento esclavo. No es obligatorio implementar todos parael cumplimiento de la norma.

14/40 - Protocolo CANopen MCP/MCPi - Ref.0612

Page 15: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

Mapeo y tipo de comunicacionesSupó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ónse dispone de los siguientes valores:

Valor del subíndice 1 (COB ID)

TABLA 7. Mapeo y tipo de comunicaciones

Objeto 0x1A01Subíndice Valor Significado0 2 Se mapean dos objetos en este PDO

1 0x60000208 Objeto: 0x6000 (*)Subíndice: 0x02Dato: 8 bits

2 0x64010110 Objeto: 0x6401 (*)Subíndice: 0x01Dato: 16 bits

* Su descripción viene dada en la siguiente tabla.

TABLA 8. Descripción.

Bits 31-16 Bits 15-8 Bits 14-0Indice Subíndice Nº de bits de datos del objeto

TABLA 9. Ej. de objeto del segundo PDO.

Objeto 0x1801Subíndice Valor Significado0 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.

TABLA 10. Valor del subíndice 1 (COB ID)

Bit 31 Bit 30 Bit 29 Bits 28-11 Bits 10-00 PDO existe1 PDO no existe

0 RTR permitido1 RTR no permitido

0 CAN ID 11 bits1 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).

MCP/MCPi - Ref.0612 Protocolo CANopen - 15/40

Page 16: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

Valor del subíndice 2 ( Tipo de transmisión )

donde:<SYNC> significa que la transmisión del PDO está relacionada con la recepcióndel mensaje de sincronismo.<ASYNC> significa que la transmisión del PDO no tiene ninguna relación conla 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º demensajes de sincronismo especificados en el tipo de transmisión.Tipo de transmisión = 252 a 253. Valores únicamente posibles en los PDOs detransmisión. En ambos casos, el PDO es enviado como respuesta a una tramaRTR 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 eventoespecífico de fabricante.Tipo de transmisión = 255. El PDO se transmite cuando se produce algún eventoespecífico del perfil de dispositivo.

TABLA 11. Valor del subíndice 2 (tipo de transmisión).

Tipo detransmisión

Condición de disparo del PDO( B = se necesitan ambos, O = uno o ambos )

Transmisión delPDO

SYNCObjeto SYNC recibido

RTRRecibida solicitud de transmisión remota

EventoCambio 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 soportadopor el equipo, objetos de comunicaciones con subíndice 5) un determinado tiempotranscurrido.

16/40 - Protocolo CANopen MCP/MCPi - Ref.0612

Page 17: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

Valor del subíndice 3 (tiempo de inhibición ó deshabilitación)Especifica el mínimo intervalo de tiempo (en incrementos de 100 µs) que transcurreentre PDOs. Este intervalo de tiempo no puede ser modificado mientras el valor delbit 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) cuandoel tipo de transmisión es 254 ó 255.

Ejemplo explicativo del sentido del “tiempo de inhibición” y del “temporizador deeventos”.Cuando se programa un PDO de transmisión de tipo 254 en el que se incluye unavariable de posición se presentan dos situaciones distintas. En tanto que el elementoa emitir el PDO esté parado (sin variación en su posición) no será necesario ningúnenvío. Si se programa un temporizador de eventos (event timer) de 10 ms, aunqueel elemento no varíe su posición (no se mueva) enviará PDOs cada 10 ms indicandosu 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ónpuede 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 mensajeAtendiendo a la configuración expuesta en las tablas anteriormente señaladas, elmensaje 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 188mensajes de sincronismo.

Objetos relacionados

SDO, Objeto de Datos de Servicio. Canal lentoLos objetos de datos de servicio (SDOs) permiten llevar a cabo la lectura y escriturade las entradas del diccionario de objetos (parámetros, variables, comandos, ...). Así,haciendo uso de SDOs, cualquier nodo puede ser configurado por el elementomaestro. El mensaje SDO, por defecto, lleva previamente asignado un identificadorde baja prioridad. Los datos transmitidos mayores de 4 Bytes pueden serfragmentados y debido a esto aparecen dos mecanismos de transferencia de unSDO:<Transferencia expeditada> utilizados para establecer una transferencia deobjetos de no más de 4 Bytes.<Transferencia segmentada> utilizados para establecer una transferencia deobjetos de más de 4 Bytes.

TABLA 12. Mensaje PDO.

COB ID Byte 0 Byte 1 Byte 20x280 + 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

MCP/MCPi - Ref.0612 Protocolo CANopen - 17/40

Page 18: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

Estructuras básicas de un SDOLas 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. Éstosson:

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 LSBa 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 7Indicador del comando SDO

Hasta 7 Bytes de datos en transferencia segmentada

Se entiende por descargar (download) a escribir en el diccionario de objetos ycargar (upload) a leer del diccionario de objetos.

TABLA 15. Inicio de la descarga de dominio.

Comenzar la descarga de dominio bit 7 6 5 4 3 2 1 0Cliente 0 0 1 - n e s

Servidor 0 1 1 - - - - -

18/40 - Protocolo CANopen MCP/MCPi - Ref.0612

Page 19: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

donde:n Indicador del nº de bytes que no contienen datos y es cero si el tamaño delsegmento 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 vezes (t=0).

Un mensaje puede ser abortado tanto por el cliente como por el servidor. Debeindicarse con el siguiente indicador de comando:

Al abortar la transferencia de dominio los bytes de datos 0 y 1 contienen el índicedel objeto, el byte 2, el subíndice del objeto y los bytes 4-7 contienen el código deabortar (abort) que describe la causa.

TABLA 16. Descarga del segmento de dominio.

Descargar el segmento de dominio bit 7 6 5 4 3 2 1 0Cliente 0 0 0 t n c

Servidor 0 0 0 t - - - -

TABLA 17. Comienzo de la carga de dominio.

Comenzar la carga de dominio

bit 7 6 5 4 3 2 1 0Cliente 0 1 0 - - - - -

Servidor 0 1 0 - n e s

TABLA 18. Carga del segmento de dominio.

Cargar el segmento de dominio

bit 7 6 5 4 3 2 1 0Cliente 0 1 1 t - - - -

Servidor 0 0 0 t n c

TABLA 19. Abortado de la transferencia de dominio.

Abortar la transferencia de dominio

bit 7 6 5 4 3 2 1 0Cliente / Servidor 1 0 0 - - - - -

MCP/MCPi - Ref.0612 Protocolo CANopen - 19/40

Page 20: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

Códigos que describen la posible razón de abortar SDO

Objeto de emergenciaUn 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ónbyte 7 byte 6 byte 5 byte 405 03 00 00 El bit basculante no es basculante05 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 insuficiente06 01 00 00 Acceso no soportado a este objeto06 01 00 01 Se ha intentado leer un objeto de sólo escritura06 01 00 02 Se ha intentado escribir un objeto de sólo lectura06 02 00 00 El objeto no existe en el diccionario de objetos06 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ámetros06 04 00 47 Incompatibilidad general de dispositivos06 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índice06 09 00 30 Rango de valores externo (sólo para acceso de escritura)06 09 00 31 Valor de parámetro demasiado alto06 09 00 32 Valor de parámetro demasiado bajo06 09 00 36 El valor máximo es inferior al valor mínimo08 00 00 00 Error / fallo general08 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 -70x080 + ID del nodo

Código de error de emergencia

Registro de error(objeto 0x1001)

Campo de error especificado por el fabricante

20/40 - Protocolo CANopen MCP/MCPi - Ref.0612

Page 21: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

Códigos de error de emergencia

TABLA 22. Códigos de error de emergencia.

Código de error de emergencia Significado00xx Error reset o no error10xx Error genérico20xx Corriente21xx Corriente, lado de entrada del dispositivo22xx Corriente dentro del dispositivo23xx Corriente, lado de salida del dispositivo30xx Tensión31xx Tensión de red32xx Tensión dentro del dispositivo33xx Tensión de salida40xx Temperatura41xx Temperatura ambiente42xx Temperatura del dispositivo50xx Hardware del dispositivo60xx Software del dispositivo61xx Software interno62xx Software de usuario63xx Dato W70xx Módulos adicionales80xx Monitorización81xx Comunicación8110 CAN sobrepasado8120 Error pasivo8130 Error “ life guard” ó error “Heartbeat”8140 Restaurado desde el bus-off82xx Error de protocolo8210 PDO no procesado por error de longitud8220 Longitud superada90xx Error externoF0xx Funciones adicionalesFFxx Específico de dispositivo

Códigos de error de emergencia in hexadecimal. Nótese que “xx” es una parte quedepende del perfil de dispositivo.

MCP/MCPi - Ref.0612 Protocolo CANopen - 21/40

Page 22: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

Registro de error (objeto 0x1001)

Objetos relacionados

Descripción del diccionario de objetosObjetos de comunicaciones (DS301)

Objetos de fabricante MCP/MCPi CANopenDescripción de las cabeceras de las diferentes columnas que componen la tabla delos 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 mensajesrápidos PDO.

TABLA 23. Registro de error (OBJETO 0x1001).

Bit Tipo de error0 Genérico1 Corriente2 Tensión3 Temperatura4 Comunicación5 Específico del perfil de dispositivo6 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ón1000h Tipo de dispositivo1001h Registro de errores1003h Campo de errores predefinidos1005h COB ID de mensaje SYNC1006h Período de ciclo de comunicación1007h Longitud de la ventana de sincronismo1008h Nombre de dispositivo del fabricante1009h Versión de hardware del fabricante100Ah Versión de software del fabricante100Ch Tiempo de vigilancia100Dh Factor de tiempo de vida1014h COB ID para mensaje de emergencia1015h Tiempo de inhibición para mensaje de emergencia1018h Objeto de identidad1400h Parámetro de comunicación de PDO recepción1600h Parámetro de mapeo de PDO recepción1800h Parámetro de comunicación de PDO transmisión1A00h Parámetro de mapeo de PDO transmisión

22/40 - Protocolo CANopen MCP/MCPi - Ref.0612

Page 23: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

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 RangoAP1 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 9999GP5 42C0h 642h ParameterVersion R UINT 0 a 9999

MCP/MCPi - Ref.0612 Protocolo CANopen - 23/40

Page 24: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

Nombre Índice IdA Descripción Acc Tipo RangoGP9 50CFh 643h DriveOfDelayTime R/W UINT 0 a 9999GP11 42D6h 645h IOFunctionsTime R/W UINT 0 a 9999GP15 42D5h 646h AutomaticInitialization R/W UINT 0 a 1GP16 42D7h 647h MonoPhaseSelector R/W UINT 0 a 1GV2 501Eh 681h ManufacturerVersion R string 0 a 9999GV5 42C2h 682h CodeChecksum R INT -32768 a 32767GV7 510Bh 683h Password R/W UINT 0 a 9999GV9 508Ch 684h DriveType R string -32768 a 32767GV11 42C4h 685h SoftReset R/W UINT 0 a 16GV16 42CCh 686h MotorTableVersion R UINT 0 a 32767GV50 4725h 688h SerialNumber R UINT -32768 a 32767GV75 5177h 687h ErrorList R string -32768 a 32767HV5 4127h 781h PLDVersion R UINT 0 a 65535IP6 438Eh 841h DigitalInputPolarity R/W UINT 0 a 1IP14 438Fh 842h DigitalInputFunctionSelector R/W UINT 0 a 4IP17 4390h 843h AnalogFunctionSelector R/W UINT 0 a 2IV1 4389h 881h AnalogInput1 R INT -12000 a 12000IV2 438Ah 882h AnalogInput2 R INT -1200 a 1200IV3 4391h 883h CurrentCommandAfterScaling R INT -9999 a 9999IV10 438Bh 884h DigitalInputs R UINT 0 a 1IV11 438Ch 885h DigitalInputsCh2 R UINT -32768 a 32767ID5 49C4h 1B85h BusCodeChecksum R UINT -32768 a 32767KP3 445Ah A41h ExtBallastPower R/W UINT 200 a 2000KP4 445Ch A42h ExtBallastEnergyPulse R/W UINT 200 a 2000KV6 517Fh A81h MotorTemperature R UINT 0 a 200KV10 444Eh A82h CoolingTemperature R UINT 0 a 200KV32 4455h A83h I2tDrive R UINT 0 a 100KV36 4457h A84h I2tMotor R UINT 0 a 100KV40 445Bh A85h I2tCrowbar R UINT 0 a 100KV41 445Dh A86h BallastSelect R/W UINT 0 a 1LP22 4912h B41h JogVelocity R/W UINT 0 a 500000LP23 4913h B42h JogIncrementalPosition R/W UINT 0 a 0x7fffffffLP48 4934h B43h PositionActionsSelect R/W UINT -32768 a 32767LP49 4935h B44h InBandPosition R/W UINT 0 a 0x7fffffffLP143 5189h B45h ModuleCommandMode R/W UINT 0 a 2LV13 4909h B81h KernelOperationMode R/W UINT 0 a 1LV14 490Ah B82h KernelAutoMode R/W UINT 0 a 1LV15 490Bh B83h KernelStartSignal R/W UINT 0 a 1LV16 490Ch B84h KernelStopSignal R/W UINT 0 a 1LV17 490Dh B85h KernelResetSignal R/W UINT 0 a 1LV19 490Fh B86h KernelManMode R/W UINT 0 a 1LV20 4910h B87h JogPositiveSignal R/W UINT 0 a 1LV21 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

24/40 - Protocolo CANopen MCP/MCPi - Ref.0612

Page 25: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

Nombre Índice IdA Descripción Acc Tipo RangoLV159 5103h B8Ch PositioningVelocity R UINT 0 a 0x7fffffffLV160 5104h B8Dh PositioningAcceleration R/W UINT 0 a 0x7fffffffLV161 5105h B8Eh PositioningAcceleration2 R/W UINT 0 a 0x7fffffffLV242 5156h B8Fh TargetPositionAttained R UINT 0 a 1MP1 508Dh C41h MotorType R/W string -32768 a 32767MP2 44B0h C42h MotorTorqueConstant R/W UINT 0 a 1000MP3 506Fh C43h MotorContinuousStallCurrent R/W UINT 0 a 5000NP117 5075h D42h ResolutionOfFeedback2 R/W UINT 0 a 65535NP118 5076h D43h ResolutionOfLinearFeedback R/W UINT 0 a 65535NP121 5079h D44h InputRevolutions R/W UINT 1 a 65535NP122 507Ah D45h OutputRevolutions R/W UINT 1 a 65535NP123 507Bh D46h FeedConstant R/W UINT 0 a 0x7fffffffNP131 4082h D47h InputRevolutions2 R/W UINT 1 a 65535NP132 4083h D48h OutputRevolutions2 R/W UINT 1 a 65535NP133 4084h D49h FeedConstant2 R/W UINT 0 a 0x7fffffffOP1 4578h E41h DA1IDN R/W UINT 0 a 13OP2 4579h E42h DA2IDN R/W UINT 0 a 13OP3 457Ah E43h DA1ValuePer10Volt R/W UINT 0 a 9999OP4 457Bh E44h DA2ValuePer10Volt R/W UINT 0 a 9999OP6 4588h E45h DigitalOutputPolarity R/W UINT 0 a 1OP14 4586h E46h DigitalOutputFunctionSelector R/W UINT 0 a 7OP15 4587h E47h DigitalOutputWarningSelector R/W UINT 0 a 2OV10 4582h E81h DigitalOutputs R UINT 0 a 1OV11 4585h E82h DigitalOutputsCh2 R/W UINT -32768 a 32767PC148 5094h F02h DriveControlledHoming R/W UINT 0 a 15PC150 4517h F03h ChangePosFB12 R/W UINT 0 a 16PP1 5028h F41h HomingVelocitySlow R/W UINT 0 a 1200PP41 5029h F42h HomingVelocityFast R/W UINT 0 a 6000PP42 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

MCP/MCPi - Ref.0612 Protocolo CANopen - 25/40

Page 26: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

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 1PV208 5198h F86h ReferenceMarkerPulseRegistered R UINT 0 a 1QP11 47D0h 1043h CanBusSpeed R/W UINT 0 a 20QP14 47DAh 1044h ProtocolTypeSelector R/W UINT 2 a 4QP16 47DCh 1045h SerialSettings R/W UINT 0 a 65535QV22 5016h 1081h IDNListOfInvalidOperationData R string 0 a 65535QV96 5060h 1083h SlaveArrangement R/W UINT 0 a 127RC1 45E9h 1101h EncoderParameterStoreCommand R/W UINT 0 a 15RG1 3801h 11C1h PiecesCount R/W UINT 0 a 65535RG2 3802h 11C2h ActualPiecesCount R/W UINT 0 a 65535RG3 3803h 11C3h RunningBlock R/W UINT 0 a 127RG4 3804h 11C4h PositionBlockIni R/W UINT 0 a 127RP1 45DCh 1141h FeedbackSineGain R/W UINT 0 a 8192RP2 45DDh 1142h FeedbackCosineGain R/W UINT 0 a 8192RP3 45DEh 1143h FeedbackSineOffset R/W INT -2000 a 2000RP4 45DFh 1144h FeedbackCosineOffset R/W INT -2000 a 2000RV1 45E2h 1181h FeedbackSine R INT -512 a 511RV2 45E3h 1182h FeedbackCosine R INT -512 a 511RV3 45E4h 1183h FeedbackRhoCorrection R UINT 0 a 65535SP1 5064h 1241h VelocityProportionalGain R/W UINT 0 a 9999SP2 5065h 1242h VelocityIntegralTime R/W UINT 0 a 9999SP3 5066h 1243h VelocityDerivativeGain R/W UINT 0 a 9999SP10 505Bh 1244h VelocityLimit R/W UINT 0 a 9999SP19 4653h 1245h SymmetryCorrection R/W INT -500 a 500SP20 4654h 1246h VoltageRpmVolt R/W UINT 1000 a 9999SP21 4655h 1247h RpmRpmVolt R/W UINT 10 a 9999SP30 4643h 1248h VelocityOffset R/W INT -2000 a 2000SP40 507Dh 1249h VelocityThresholdNx R/W UINT 0 a 9999SP41 509Dh 124Ah VelocityWindow R/W UINT 0 a 9999SP42 507Ch 124Bh StandStillWindow R/W UINT 0 a 9999SP43 502Bh 124Ch VelocityPolarityParameters R/W UINT 0 a 1SP45 4651h 124Dh VelocityCommandSelector R/W UINT 0 a 2SP60 508Ah 124Eh AccelerationLimit R/W UINT 0 a 4000SP65 4649h 124Fh EmergencyAcceleration R/W UINT 0 a 4000SP66 4652h 1250h VelocityDecelerationTime R/W UINT 0 a 4000SV1 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

Page 27: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

Descripción de los PDOsLa tarjeta CAN de comunicaciones de los reguladores MCP y MCPi dispone de unPDO de recepción y un PDO de transmisión (pudiendo incrementarse este númeroen futuras versiones). El mapeo de los PDOs viene establecido desde fábrica y nopuede ser modificado por el usuario. Los parámetros de comunicación de los PDOsquedan accesibles al usuario pudiendo éste seleccionar tanto el tipo decomunicació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 tiemporeal por parte del módulo maestro. En los reguladores existen dos estructuras dedatos (directamente mapeadas a estos mensajes PDO) denominadas Assemblypensadas para poder gobernar los accionamientos en tiempo real. Constan, cadauna de ellas, de 8 bytes y su objetivo es, entre otros, establecer el control sobre elregulador 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 mismotiempo 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 laejecución en la tabla de movimientos.Drive_Enable: Bit que permite activar a través del bus de comunicaciones el DriveEnable 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ógicoentre 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 SpeedEnable del equipo siempre y cuando la entrada hardware correspondiente estéactivada.

Nombre Índice IdA Descripción Acc Tipo RangoSV15 4657h 1285h DigitalVelocityCommand R/W INT -6·107 a 6·107

TP1 507Eh 1341h TorqueThresholdTx R/W UINT 0 a 100TV1 5050h 1381h TorqueCommand R INT -9999 a 9999TV2 5054h 1382h TorqueFeedback R INT -9999 a 9999

TABLA 26. AssemblyIn.

B7 B6 B5 B4 B3 B2 B1 B0Byte 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 3Command_Toggle_Bit Command Dir_Var Bits 8-12

Byte 4 Data_Byte 0Byte 5 Data_Byte 1Byte 6 Data_Byte 2Byte 7 Data_Byte 3

* KernelOperationMode LV13 = 0, es decir, en modo automático.** KernelOperationMode LV13 = 1, es decir, en modo manual.

MCP/MCPi - Ref.0612 Protocolo CANopen - 27/40

Page 28: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

La señal final interpretada por el equipo viene dada por un “AND” lógico entre el valorde 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 finalde 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 carreradel límite positivo del recorrido.Lim - : Bit que permite activar a través del bus de comunicaciones el final de carreradel 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á enmodo automático, la activación de esta señal efectúa un Reset en el secuenciadorde 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 modoautomático, pueden establecerse dos posibles situaciones:

Si se activa Start por primera vez o tras realizar un Reset de movimientos, elsecuenciador de posición comenzará la ejecución del bloque indicado en los bitsde Starting_Block.Si durante la ejecución de un bloque se activa una señal Stop, el equipo sedetiene. Si ahora se activa una señal de Start, el equipo continua con la ejecucióndel 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 porel 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 solicitadopor el elemento maestro podrá indicar tanto el identificador IdA de una variable comoel bloque de posición a leer/escribir por el elemento maestro (véanse los ejemplosprácticos documentados más adelante).Command Toggle Bit: Bit cuyo fin es hacer efectivo por parte del módulo maestroel comando solicitado en los bits Command del AssemblyIn. Esto se consiguenegando el estado actual de este bit.

0 Leer un parámetro / una variable.1 Escribir un parámetro / una variable2 Leer en la tabla de movimientos3 Escribir en la tabla de movimientos

28/40 - Protocolo CANopen MCP/MCPi - Ref.0612

Page 29: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

AssemblyOut - Estado

Ref_Done: Bit indicador (al módulo maestro) de que la acción de “búsqueda decero” 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 unbloque. Es activado cuando el posicionador se encuentra dentro de la bandaespecificada en el parámetro PP57 - Position Window -.Speed_Enable: Bit que refleja el estado interno de la señal Speed_Enable delregulador. 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 posicionamientoactualmente en ejecución.Command_Toggle_Bit_Resp: Tras recibir un nuevo comando mediante el cambiode valor de Command_Toggle_Bit, el regulador inicia su ejecución. Finalizada laejecución, se hace una copia del valor de Command_Toggle Bi t enCommand_Toggle_Bit_Resp. Así, el módulo maestro queda informado de que elcomando se ha completado.Command_Resp: Reflejo del comando especificado en los bits “Command” delAssemblyIn.Command_OK: Tras recibir un nuevo comando mediante el cambio de valor deCommand_Toggle_Bit, el bit “Command_OK” será activado cuando el comandosolicitado ha sido ejecutado satisfactoriamente. Se pondrá a cero siempre que segeneren 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).

MCP/MCPi - Ref.0612 Protocolo CANopen - 29/40

Page 30: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

Operation_Status: Bits que reflejan el “modo” y el “estado” en el que se encuentrael secuenciador de movimientos del equipo.

Data_Byte_Resp 0-3: Bytes de datos que contienen la información solicitada (valorde variable, parámetro o valores de la tabla de posicionamiento) por el módulomaestro. El Data_Byte_Resp 0 contiene el byte de menor peso de la variablesolicitada 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 horade realizar diferentes operaciones con el regulador utilizando un único tipo demensaje de comunicaciones. Un ejemplo de ello lo constituyen los PLC que realizancíclicamente, operaciones con los diferentes elementos esclavos, utilizando elmismo tipo de mensaje rápido.Véanse seguidamente algunos ejemplos prácticos en los que se detalla cómo debeconfigurar el módulo maestro cada uno de los bits del AssemblyIn para llevar a cabolas 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 elAssemblyIn está a cero.

STOP 5 MODOAUTOMÁTICO 0

BLOQUE EN EJECUCIÓN 1

A la espera dedesactivar elmodo JOG 12

En espera de laseñal START 4

Reset 6 desde0-1-2-3-4-5

Cambio aKernelOperationMode

MODOMANUAL 10

Modo JOG enfuncionamiento 11 KernelManMode

(INCREMENTAL)& FIN DE

MOVIMIENTODesde todoslos estados

Ala

rma

Alarma 15

PAUSA DEBLOQUE 3

En espera de quela señal STARTno esté activa 2

KernelStartSignal& KernelStopSignal& KernelResetSignal

BlockEnd

KernelResetSignal KernelResetSignal

Ker

nelS

topS

igna

l

Mnemónicos y símbolos

AA

(A negada)

Señal A activa XModo de operación

Estado

Señal A no activa Ejemplo:

KernelStopSignal

KernelStopSignal = KernelStopSignal no activa= KernelStopSignal activa

desde10-11-12

Cambio aKernelOperationMode

Ker

nelS

topS

igna

l

Ker

nelS

tart

Sign

al

JogPositiveSignal& JogNegativeSignal

& K

erne

lSto

pSig

nal

Ker

nelS

tart

Sign

al

KernelStopSignal

KernelStopSignal

JogPositiveSignalOR JogNegativeSignal

& KernelStopSignal& KernelResetSignal

JogPositiveSignal& JogNegativeSignal

(CONTINUO)& KernelManMode

OR KernelResetSignalOR KernelStopSignal

Transiciones entre estados

30/40 - Protocolo CANopen MCP/MCPi - Ref.0612

Page 31: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

Para leer un parámetro ó una variable del regulador, asignar necesariamente alcampo “Command” un 0. Seguidamente, introducir en los 13 bits del campo “Dir_Var” el identificador IdAssembly correspondiente al parámetro o variable a leer. Este identificador essuministrado en la tercera columna de las tablas de descripción de los objetosCANopen 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 laorden.

Para escribir en un parámetro ó en una variable del regulador, asignarnecesariamente al campo “Command” un 1. Seguidamente, introducir en los 13 bits del campo “Dir_Var” el identificador IdAssembly correspondiente al parámetro o variable a leer. Este identificador essuministrado en la tercera columna de las tablas de descripción de los objetosCANopen específicos de fabricante. Así, p. ej. si se desea escribir en el parámetroCP20 (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 primerosbytes de datos (destinados al respecto) y en las unidades requeridas. Véanse lasunidades en el apartado de parámetros, variables y comandos del manual delregulador 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 laorden.Una vez que el mensaje ha sido recibido por el módulo esclavo, éste comprueba laexistencia 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 demovimientos a llevar a cabo por el posicionador es programada mediante una tablade 127 bloques. Cada bloque establece una posición y en él pueden programarsediferentes parámetros (posición absoluta o incremental, velocidad máxima deposicionamiento, activación de salidas tras la ejecución del bloque, ...) a los que elposicionador obedece durante la ejecución del bloque.Existe la posibilidad de lectura/escritura de todos los elementos que componen latabla de movimientos a través de los mensajes Assembly. La estructura del bloquede posicionamiento que ofrece la TABLA 28. detalla los 16 words que componen elbloque. 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 (word0).

Lectura de parámetro/variable

Escritura de parámetro/variable

Tabla de movimientos

MCP/MCPi - Ref.0612 Protocolo CANopen - 31/40

Page 32: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

Para la lectura de datos en la tabla de movimientos del regulador, asignar el valor2 al campo “Command” del AssemblyIn. La selección de un elemento de la tablase establece desde el campo “Dir_Var”. En sus 8 bits menos significativos (de menorpeso) se indicará el número de bloque de posicionamiento y en los 5 bits mássignificativos (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 siendomuy conveniente (imprescindible) acceder a números de “word” pares para evitarasí 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 elcampo “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 lainformación solicitada y en caso afirmativo activa el comando “Command_Ok” ydevuelve la posición de destino a través de los mensajes AssemblyOut hasta quecambie nuevamente el bit “ Command_Toggle_Bit ” (cambio de comando o de datosolicitado de la tabla).

TABLA 28. Estructura del bloque de posicionamiento.

Descripcióndel campo Reserv. LOOP NEXT PROGOUT

EVENTO

TIPO TIEMPO

Valor 0000h0000h

aFFFFh

0001h a 0080h

“ OR ”Cnt piezas

SC00h

END=xxFEh (1

00000000h a

000000FFh

InRpos (real) 0001h

0000h a

FFFFh

InTpos (teórico) 0002hInBand 0003hActSpeedReached 0004hNextSpeedReached 0005h

“OR”FastInput (2 0100h

Nº WORD 15-12 11 10 9-8 7 6

Descripción del campo VELPOS

POSDEST

VALOR MODO

Valor

00000000haFFFFFFFFh

00000000haFFFFFFFFh

Absoluto 0000 0001 hIncremental 0000 0002 h+ Infinito 0000 0003 h- Infinito 0000 0004 hStop 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 piezasdeseadas (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

32/40 - Protocolo CANopen MCP/MCPi - Ref.0612

Page 33: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

Para la escritura de datos en la tabla de movimientos del regulador, asignar el valor3 al campo “Command” del AssemblyIn. La selección de un elemento de la tabla seestablece desde el campo “Dir_Var”. En sus 8 bits menos significativos (de menorpeso) se indicará el número de bloque de posicionamiento y en los 5 bits mássignificativos (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 siendomuy conveniente (imprescindible) acceder a números de “word” pares para evitarasí equívocos en la interpretación de datos.

Ejemplo.

Para cambiar el tipo de evento (condición de paso de bloque del posicionador, word7) hay que escribir simultáneamente los words 6 y 7. Así, si se pretende un cambiode bloque del posicionador cuando el lazo de posición alcanza la posición teóricafinal (evento del tipo 2), se escribirá el valor hexadecimal 20000h en los bytes dedatos “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 losdatos que van a ser escritos y, si consigue escribirlos con éxito, entonces activa elcomando “Command_Ok” del mensaje AssemblyOut.

Escritura de la tabla de movimientos

MCP/MCPi - Ref.0612 Protocolo CANopen - 33/40

Page 34: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

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 obtieneun número que estará comprendido entre 0 (ambos señalan 0) y 99 (ambosseñalan 9). Cada nodo del bus se diferencia del resto de ellos en el nº de nodoque le ha sido asignado desde estos conmutadores rotativos. Cualquier valorentre 01 y 98 podrá ser asumido como nº de nodo por un equipo.

Selección de la velocidad de comunicaciónLa primera labor que debe realizarse siempre que se incorpora un nuevo equipo enla 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 (ModuleStatus) 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ónEn el arranque de un equipo y siempre que los selectores rotativos esténseleccionando 99 (es decir, cada uno señalando al 9), estará habilitado el modode selección de la velocidad de transmisión. Los leds MS y NS parpadearánsimultá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 casosespeciales documentados más adelante.

34/40 - Protocolo CANopen MCP/MCPi - Ref.0612

Page 35: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

el modo de selección de la velocidad de comunicación está habilitado. Desde esteestado pueden llevarse a cabo las siguientes operaciones:

Verificar la velocidad de transmisión seleccionadaPara conocer cual es la velocidad de transmisión a la que se está realizando lacomunicació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 (ledrojo 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 leddeja de estar iluminado indica la velocidad de comunicación (almacenada enmemoria) 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 detransmisió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 losque no se ilumina) estará indicando según esta tabla que la velocidad de transmisiónde la red es 500 kbit/s.

Seleccionar la velocidad de transmisiónPara establecer una velocidad de transmisión igual a la de comunicación en la reden 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 incorporatambién deberá transmitir a esa velocidad, es decir, habrá que situar su switchrotativo “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/s4 250 kbit/s 9 10 kbit/s5 125 kbit/s

TABLA 30. Selección de la velocidad de transmisión.Posición del switch rotativo “x1”

Velocidad detransmisión

Posición del switch rotativo “x1”

Velocidad detransmisión

1 1000 kbit/s 6 100 kbit/s2 800 kbit/s 7 50 kbit/s3 500 kbit/s 8 20 kbit/s4 250 kbit/s 9 10 kbit/s5 125 kbit/s

MCP/MCPi - Ref.0612 Protocolo CANopen - 35/40

Page 36: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

Simultáneamente y con las mismas secuencias ya comentadas en párrafosanteriores, el led MS parpadeará (en verde) identificando así la velocidadseleccionada.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, ahoradestelleando en rojo, es indicativo de la velocidad seleccionada. Tras esta operación,esta velocidad será almacenada permanentemente en la memoria no volátil delequipo. Tras realizar un reset en el equipo, éste asumirá ya como velocidad detransmisión la almacenada en memoria.

Determinación del nº de nodoDeterminada la velocidad de transmisión del equipo en la red, será ahora necesarioidentificarlo dentro de la misma. Habrá que asignar al nuevo equipo incorporado unnº identificador único que le permita diferenciarse de cualquier otro equipo queforme parte de la red y evitar así colisiones. Este nº identificador ID se conocerá comonº de nodo y debe ser único para cada equipo.

La determinación del nº de nodo del equipo se lleva a cabo mediante los dosconmutadores rotativos x1 y x10. Ejemplo.

Tras realizar un reset del regulador, éste será identificado en la red con el nº de nodoque le ha sido asignado.

En cada arranque del equipo, éste asume como nº de nodo, el asignado en losselectores rotativos “x1” y “x10”.

Indicadores de estadoLa tarjeta CAN del regulador dispondrá de dos indicadores o leds “bicolor”. Éstosson, MS (Module Status) y NS (Network Status). El indicador MS visualiza el estadodel equipo y NS informa del estado del equipo dentro de la red CANopen.

IMPORTANTE: Queda bajo la responsabilidad del usuario evitar que dosequipos 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 99queda reservado en su uso al proceso de selección de velocidad y el 00 se tratainmediatamente como 01 ya que el nodo 00 no existe en CANopen.

Para asignar a un equipo el nº de nodo 57, habrá que situarla flecha del conmutador rotativo “ x10 ” señalando la posición5 y la del rotativo “ x1” la posición 7. Véase figura. Se comprueba que 10 x 5 + 1 x 7 = 57.

36/40 - Protocolo CANopen MCP/MCPi - Ref.0612

Page 37: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

En un proceso inicial del equipo estos leds alcanzan los siguientes estados con elfin de verificar el correcto estado del regulador.

MS (Module Status)Este indicador informa del estado del equipo, propiamente dicho. Los estados quepueden 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 cadenciade 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 seestablecen los tiempos de intermitencia del led rojo y del verde así como sudenominación.

Led rojo. Led indicador de error

Nota. MS y NS se iluminan de acuerdo al estado en el que se encuentran tantoel bus como el equipo.

TABLA 31. Led indicador de error. Color rojo.

Led de error (rojo) Estado DescripciónNo iluminado Sin error Funcionamiento satisfactorio del equipo

Un único parpadeoAlcanzado el límite de aviso

Al menos uno de los contadores de error del driverde CAN ha alcanzado o excedido el nivel de aviso(warning). Demasiadas tramas de error ó errorframes.

Doble parpadeoEvento de control de error NMT

Se ha producido un evento de “guarding” (NMTesclavo ó 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

MCP/MCPi - Ref.0612 Protocolo CANopen - 37/40

Page 38: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

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 ms6 x 200 ms 1000 ms

38/40 - Protocolo CANopen MCP/MCPi - Ref.0612

Page 39: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

Notas de usuario.

MCP/MCPi - Ref.0612 Protocolo CANopen - 39/40

Page 40: FAGOR AUTOMATION S.COOP MCP/MCPi · 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

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. 144E-20500 ARRASATE-MONDRAGONwww.fagorautomation.comE-mail: [email protected]: 34-943-719200 / 34-943-039800Fax: 34-943-791712 34-943-771118 (Service Dept.)

Usurbil:FAGOR AUTOMATION S.COOP.Planta de UsurbilSan Esteban s/n Txoko-AldeE-20170 USURBILTel: 34-943-000690Fax: 34-943-360527E-mail: [email protected]

Eskoriatza:FAGOR AUTOMATION S.COOP.Planta de EskoriatzaTorrebaso Pasealekua, 4, Apdo. 50E-20540 ESKORIATZATel: 34-943-719200Fax: 34-943-039783

Barcelona:FAGOR AUTOMATION, CatalunyaParc Tecnològic del Vallès,Tecnoparc IIEdificio I Módulo AbC/Argenters, 508290 Cerdanyola del VallèsTel.: 34-93-4744375Fax: 34-93-4744327E-mail: [email protected]

FRANCEFAGOR AUTOMATION FRANCE SàrlParc Technologique de La Pardieu16 Rue Patrick Depailler63000 CLERMONT FERRANDTel.: 33-473277916Fax: [email protected]

GERMANYFAGOR AUTOMATION GmbHPostfach 604 D-73006 GÖPPINGENNördliche Ringstrasse, 100Tel.: 49-7161 15685-0Fax: 49-7161 1568579E-mail: [email protected]

ITALYFAGOR ITALIA S.R.L.Pal. CD3 P.T. - Via Roma, 10820060 CASSINA DE PECCHI (MI)Tel.: 39-0295301290Fax: 39-0295301298E-mail: [email protected]

UNITED KINGDOMFAGOR AUTOMATION UK Ltd.2 A Brunel CloseDrayton Field Industrial EstateDaventry NorthamptonshireNN11 5RBTel: 44-1327 300067Fax: 44-1327 300880E-mail: [email protected]

PORTUGALFAGOR AUTOMATION LTDA.Sucursal PortuguesaRua Gonçalves Zarco nº 1129-B-2ºSalas 210/2124450 LEÇA DA PALMEIRATel: 351 22 996 88 65Fax: 351 22 996 07 19E-mail: [email protected]

USAChicago:FAGOR AUTOMATION CORP.2250 Estes AvenueELK GROVE VILLAGE, IL 60007Tel: 1-847-9811500

1-847-9811595 (Service)Fax:1-847-9811311E-mail: [email protected]

California:FAGOR AUTOMATION West Coast3176 Pullman Ave., Unit 110COSTA MESA, CA 92626Tel: 1-714-9579885Fax: 1-714-9579891E-mail: [email protected]

New Jersey:FAGOR AUTOMATION East CoastTel: 1-973-7733525Fax: 1-973-7733526E-mail: [email protected]

South East:FAGOR AUTOMATION SOUTH EAST4234 Amber Ridge Ln- VALRICO, FL 33594Tel: 813 654 4599E-mail: [email protected]

Ohio:FAGOR AUTOMATION OHIO BRANCHWesterville OH 43081Tel: 1 614-855-5720Fax: 1 614-855-5928E-mail: [email protected]

CANADAOntario:FAGOR AUTOMATION ONTARIOUnit 3, 6380 Tomken RoadMISSISSAUGA L5T 1Y4Tel: 1-905-6707448Fax: 1-905-6707449 E-mail: [email protected]

Montreal:FAGOR AUTOMATION QUEBECTel.: 1-450-2270588Fax: 1-450-2276132E-mail: [email protected]

Windsor:FAGOR AUTOMATION WINDSORTel.: 1-519 944-5674Fax: 1-519 944-2369

BRAZILFAGOR AUTOMATION DO BRASILCOM.IMP. E EXPORTAÇAO LTDA.Rua Homero Baz do Amaral, 331CEP 04774-030 SAO PAULO-SPTel.: 55-11-56940822Fax: 55-11-56816271E-mail: [email protected]

CHINA, P.R.Beijing:BEIJIN FAGOR AUTOMATION EQUIPMENT Co.,LTD.C-1 Yandong Building, No.2 Wanhong Xijie, XibajianfangChaoyang DistrictBEIJING, Zip Code: 100015Tel: 86-10-84505858Fax: 86-10-84505860E-mail: [email protected]

Nanjing:FAGOR AUTOMATION EQUIPMENT LTD. NANJING OFFICERoom 803, Holiday Inn (Nanjing) 45 Zhongshan Beilu, Nanjing 210008Jiangsu ProvenceTel: 86-25-3328259Fax: 86-25-3328260E-mail: [email protected]

CHINAGuangzhou:Beijin FAGOR AUTOMATION Equipment Co.Ltd., Guangzhou Rep.OfficeRoom 915 Lihao Plaza No. 18 Jichanglu Baiyun District - GUANGZHOU 510405Tel: 86-20-86553124Fax: 86-20-86553125E-mail: [email protected]

Shanghai:Beijing FAGOR AUTOMATION equipment Co., Ltd - SHANGHAI Representative OfficeRoom No.1906 LianTong International BuildingNo. 547 Tianmu XiluSHANGHAI, P.C. 20070Tel: 86-21-63539007Fax: 86-21-63538840E-mail: [email protected]

HONG KONGFAGOR AUTOMATION (ASIA) LTD.Room 628. Tower II, Grand Central Plaza138 Shatin Rural Committee RoadShatin, HONG KONGTel: 852-23891663Fax: 852-23895086 E-mail: [email protected]

KOREA, Republic ofFAGOR AUTOMATION KOREA, LTD.Room No. 707 Byucksan Digital Valley 2nd

481-10 Gasan-dong. Geumcheon-guSeoul 153-803, KoreaTel: 82 2 2113 0341Fax: 82 2 2113 0343E-mail: [email protected]

TAIWAN, R.C.O.FAGOR AUTOMATION TAIWAN CO., LTD.Nº 24 Ta-Kuang St. Nan-Tun Dist. 408Taichung, TAIWAN R.O.C.Tel: 886-4-2 3271282Fax: 886-4-2 3271283

SINGAPOREFAGOR AUTOMATION (S) PTE.LTD.240 MacPherson Road06-05 Pines Industrial BuildingSINGAPORE 348574Tel: 65-68417345 / 68417346Fax: 65-86417348E-mail: [email protected]

MALAYSIAFAGOR AUTOMATION (M) SDN.BHD. (638038-H)No.39, Jalan Utama 1/7Taman Perindustrian Puchong Utama47100 Puchong, Selangor Darul EhsanTel: +60 3 8062 2858Fax: +60 3 8062 3858E-mail: [email protected]