Para poder conectar equipos slave EtherCAT a un master EtherCAT, cada slave EtherCAT deberá dis- poner de su archivo de descripción correspondiente. El archivo de descripción es equiparable a los archivos EDS para el sistema de bus de campo CANopen o a los archivos GSD de Profibus. A diferencia de estos archivos, la descripción de EtherCAT tiene el formato XML, utilizado con frecuencia en aplicac- iones web e Internet, y contiene la información relativa a las características siguientes del slave EtherCAT:
– Datos del fabricante del equipo. – Nombre, tipo y versión del equipo.
– Tipo y número de versión del protocolo que se debe utilizar para este equipo (p. ej., CANopen over Ethernet, etc.).
– Parametrización del equipo y configuración de los datos de proceso.
Este archivo contiene la parametrización completa del slave, con la parametrización del Sync Manager y de los objetos de datos de proceso incluidos. Por esta razón, la configuración del slave puede modificarse con este archivo.
El archivo XML está incluido en un CD-ROM suministrado con el controlador del motor.
Archivo XML Descripción
Festo_CMMP-AS_V3p0.xml Controlador del motor CMMP-AS-...-M3 Tab. 7.9 Archivo XML
Hallará la versión más actual en www.festo.com
Seguidamente explicamos el contenido de este archivo con más detalle para que el usuario pueda adaptarlo a su aplicación.
En los archivos disponibles de descripción de equipos se admite el uso tanto del perfil CiA 402 como del perfil FHPP mediante módulos seleccionables por separado.
7.5.1 Estructura básica del archivo de descripción de equipos XML
El archivo de descripción de equipos EtherCAT está en formato XML. Este formato tiene la ventaja de que puede leerse y editarse con un editor de textos estándar. Un archivo XML describe siempre una estructura de árbol. Las ramificaciones se definen con nodos. Estos nodos disponen de una marca de inicio y otra de fin. Dentro de un nodo puede haber un número ilimitado de subnodos.
<EtherCATInfo Version=“0.2“> <Vendor> <Id>#x1D</Id> <Name>Festo AG</Name> <ImageData16x14>424DD60200...</ImageData16x14> </Vendor> <Descriptions> <Groups> <Group SortOrder=“1“> <Type>Festo Electric-Drives</Type>
<Name LcId=“1033“>Festo Electric-Drive</Name> </Group> </Groups> <Devices> <Device Physics=“YY“> </Device> </Devices> </Descriptions> </EtherCATInfo>
Para estructurar un archivo XML se deben observar las reglas breves siguientes: – Cada nodo tiene un nombre inequívoco.
– Cada nodo se abre con <nombre de nodo> y se cierra con </nombre de nodo>.
El archivo de descripción de equipos para el controlador de motor CMMP-AS-...-M3 con CoE EtherCAT se estructura en los puntos siguientes:
Nombre del nodo Significado Adaptable
Vendor Este nodo contiene el nombre y el ID del fabricante del equipo al que pertenece el mismo archivo de descripción. Además, incluye el código binario de un mapa de bits con el logograma del fabricante.
No
Description Este punto incluye la descripción del equipo propiamente dicha con su configuración e inicialización.
Parcialmente Group Este nodo incluye la asignación del equipo a un grupo de eq-
uipos. Estos grupos son fijos y el usuario no debe modificarlos. No
Devices Este punto incluye la descripción del equipo. Parcialmente Tab. 7.10 Nodos de los archivos de descripción de equipos
En la tabla siguiente se describen exclusivamente los subnodos del nodo “Descriptions” necesarios para parametrizar el controlador de motor CMMP-AS-...-M3 con CoE. El resto de los nodos son fijos y el usuario no debe modificarlos.
Nombre del nodo Significado Adaptable RxPDO Fixed=... Este nodo incluye la asignación de PDO y la asignación del PDO
al Sync Manager para PDO de recepción.
Sí TxPDO Fixed=... Este nodo incluye la asignación de PDO y la asignación del PDO
al Sync Manager para PDO de transmisión.
Sí Mailbox Bajo este nodo se pueden definir órdenes que el master
transmite al slave durante la transición de las fases “Pre- Operational” a “Operational” mediante la transferencia de SDO.
Sí
Tab. 7.11 Subnodos del nodo “Descriptions”
Como para el usuario solo son importantes los nodos de la tabla anterior para adaptar el archivo de descripción de equipos, los nodos se describen con detalle en los capítulos siguientes. El contenido restante del archivo de descripción de equipos es fijo y el usuario no debe modificarlo.
Importante:
Si en el archivo de descripción de equipos se modifican otros nodos y contenidos diferen- tes a RxPDO, TxPDO y Mailbox, no se garantiza el funcionamiento correcto del equipo.
7.5.2 Configuración de PDO de recepción en el nodo RxPDO
El nodo RxPDO sirve para determinar la asignación de los PDO de recepción y su asignación a un canal del Sync Manager. Ejemplo de una entrada típica en el archivo de descripción de equipos para el con- trolador de motor CMMP-AS-...-M3:
<RxPDO Fixed=”1” Sm=”2”> <Index>#x1600</Index> <Name>Outputs</Name> <Entry> <Index>#x6040</Index> <SubIndex>0</SubIndex> <BitLen>16</BitLen> <Name>Controlword</Name> <DataType>UINT</DataType> </Entry> <Entry> <Index>#x6060</Index> <SubIndex>0</SubIndex> <BitLen>8</BitLen> <Name>Mode_Of_Operation</Name>
Como se advierte en el ejemplo anterior, en una entrada de ese tipo la asignación total de los PDO de recepción se describe de modo detallado. El primer bloque grande indica el número de objeto del PDO y su tipo. A continuación, le sigue una lista con todos los objetos CANopen que deben mapearse en el objeto de datos de proceso.
En la tabla siguiente se describe con más detalle cada una de las entradas:
Nombre del nodo Significado Adaptable
RxPDO Fixed=“1” Sm=“2”
Este nodo describe directamente la estructura del PDO de recepción y su asignación al Sync Manager. La entrada Fixed=“1” indica que el mapeado del objeto no se puede modificar. La entrada Sm=“2” indica que el PDO se debe asignar al canal Sync 2 del Sync Manager.
No
Index Esta entrada incluye el número de objeto del PDO. Aquí se con- figura el primer PDO de recepción en el número de objeto 0x1600.
Sí Name El nombre indica si el PDO es de recepción (Outputs) o de
transmisión (Inputs).
Para un Receive PDO, este valor siempre debe estar en “Output”. No
Entry El nodo Entry incluye un objeto CANopen que debe mapearse en el objeto de datos de proceso. Un nodo Entry incluye el índice y el subíndice del objeto CANopen que debe mapearse, además de su nombre y tipo de dato.
Sí
Tab. 7.12 Elementos del nodo “RxPDO”
El orden y el mapeado de cada uno de los objetos CANopen para el PDO coincide con el orden en que han sido introducidos en el archivo de descripción de equipos mediante las entradas “Entry”. En la tabla siguiente se indican todos los subpuntos de un nodo “Entry”:
Nombre del nodo Significado Adaptable
Index Esta entrada indica el índice del objeto CANopen que debe mapearse en el objeto de datos de proceso.
Sí Subindex Esta entrada indica el subíndice del objeto CANopen que se debe
mapear.
Sí BitLen Esta entrada indica en bits el tamaño del objeto que debe
mapearse. Esta entrada debe coincidir siempre con el tipo de objeto que debe mapearse.
Permitidos: 8 bits / 16 bits / 32 bits.
Sí
Name Esta entrada indica el nombre, en forma de cadena de caracteres, del objeto que debe mapearse.
Sí Data Type Esta entrada indica el tipo de datos del objeto que debe mapearse.
Se puede consultar para cada objeto CANopen en la descripción Sí
7.5.3 Configuración del PDO de transmisión en el nodo TxPDO
El nodo TxPDO sirve para determinar la asignación de los PDO de transmisión y su asignación a un canal del Sync Manager. La configuración coincide con la de los Receive PDO descrita en la sección 7.5.2 “Configuración de los Receive PDO en el nodo RxPDO” a diferencia de que el nodo “Name” del PDO se debe ajustar al valor “Inputs” en vez de “Outputs”.
7.5.4 Órdenes de inicialización a través del nodo “Mailbox”
El nodo “Mailbox” del archivo de descripción de equipos sirve para describir objetos CANopen a través del master en el slave durante la fase de inicialización. Las órdenes y los objetos que deban describirse aquí se determinan mediante entradas especiales. En dichas entradas se determina la transición de fase en la que debe describirse este valor. Además, esta entrada incluye el número de objeto (índice y subíndice), el valor de datos que se debe escribir y un comentario.
Formato de una entrada típica: <InitCmd> <Transition>PS</Transition> <Index#x6060</Index> <SubIndex>0</SubIndex> <Data>03</Data> <Comment>velocity mode</Comment> </InitCmd>
En el ejemplo anterior, el modo de funcionamiento en el objeto “modes_of_operation” se ajusta a “regulación de la velocidad” durante la transición de estado PS de “Pre-Operational” a “Safe Operat- ional”. Significado de los subnodos:
Nombre del nodo Significado Adaptable
Transition Nombre de la transición de estado en cuya aparición se debe ejecutar esta orden ( capítulo 7.7
“Máquina de estado de comunicación”)
Sí
Index Índice del objeto CANopen que debe escribirse. Sí Subindex Subíndice del objeto CANopen que debe escribirse. Sí Data Valor de datos que debe escribirse en forma de valor he-
xadecimal.
Sí Comment Comentario relativo a la orden. Sí Tab. 7.14 Elementos del nodo “InitCmd”
Importante:
En un archivo de descripción de equipos para el controlador de motor CMMP-AS-...-M3 ya existen algunas entradas en esta sección. Es obligatorio mantener estas entradas y el