DeviceNet

Este documento presenta una descripción operativa de DeviceNet ™, un protocolo de bajo nivel de aplicación industrial para aplicaciones de automatización industrial. DeviceNet conecta dispositivos industriales simples (sensores y actuadores) con dispositivos de nivel superior, como los controladores programables. Basado en el estándar de comunicaciones físicas CAN (Controller Area Network), DeviceNet utiliza el hardware CAN para definir un protocolo de capa de aplicación que estructura la tarea de configuración, acceso y control de dispositivos de automatización industrial.

Este documento está destinado al usuario de DeviceNet que desea una comprensión más profunda de DeviceNet. Está pensado para proporcionar mucha más información de la que se encuentra normalmente en una visión general de la red de DeviceNet, pero mucho menos que la especificación de varios cientos de páginas de DeviceNet. Este documento también puede proporcionar un punto de partida para los desarrolladores que están considerando agregar las comunicaciones de DeviceNet a su producto.

Tenga en cuenta que un resumen de una especificación de más de 200 páginas es incompleto por definición. Se admite que algunos aspectos de la tecnología solo están ligeramente cubiertos, mientras que otros no están cubiertos en absoluto. Los temas que se consideran que proporcionan la mayor información sobre el funcionamiento de DeviceNet o que aclaran las ideas erróneas comunes reciben prioridad.

DeviceNet – UNA VISIÓN RÁPIDA

DeviceNet es un protocolo de capa de aplicación. Qué significa eso? Una forma de verlo es que el término “capa de aplicación” implica que DeviceNet trata más con los datos de la aplicación que con un protocolo de nivel inferior o de capa sin aplicación. Por ejemplo, un protocolo de capa de enlace está diseñado simplemente para mover algunos bytes del punto A al punto B. No tiene ningún interés y no transmite información inherente con respecto al contenido del mensaje. Debido a que DeviceNet es un protocolo de capa de aplicación, sus mensajes transmiten información. Un mensaje explícito de DeviceNet tiene información específica en bytes específicos de un mensaje. Hay un byte para un número de clase, un byte para un código de servicio y así sucesivamente.

Ahora, si DeviceNet es un protocolo de capa de aplicación, ¿cuáles son las capas de protocolo inferiores que transportan sus mensajes? Ese es el contenido de la siguiente sección.

DEVICENET Y CAN

Controller Area Networking o CAN es un estándar de comunicaciones con un conjunto bastante prolífico de descendientes que incluye DeviceNet, Can Open, Can Kingdom y varios cientos de otros descendientes en todo el mundo.

Controller Area Networking es un estándar de comunicaciones en serie para que los dispositivos inteligentes se comuniquen entre sí. A diferencia de muchos otros estándares de comunicación que proporcionan velocidades de datos rápidas con miles o millones de bytes de datos en una sola trama, CAN tiene una velocidad de bits máxima de 1 mega baudios. La mayoría de las aplicaciones industriales ni siquiera necesitan esa velocidad. La mayoría utiliza el humilde 125Kbaud. Y donde otros estándares mueven miles de bytes en un solo cuadro, CAN solo mueve 8 bytes de datos.

Pero donde la velocidad y la capacidad son fortalezas para muchos de los otros estándares, la fortaleza de CAN es su baja sobrecarga y su sencilla interfaz física. Con su tamaño de paquete pequeño, incluso a 500 Kbaudios, una trama con ocho bytes de datos solo está en el cable de red durante un cuarto de milisegundo. Para muchas aplicaciones de control esto es bastante rápido.

Además, el microcontrolador, sí, un micro de 8 bits con poca potencia puede hacer el trabajo, necesita tan solo 4K de memoria de programa y 256 bytes de RAM para admitir una aplicación CAN.

CAN fue creada por Bosch en Alemania en marzo de 1985. La compañía Bosch la diseñó para reemplazar el cableado automotriz. En los primeros días de la especificación versión 1.2, los mensajes CAN contenían un identificador de once bits que proporciona la capacidad de direccionar los identificadores 2047. En 1992, CAN Specification 2.0 amplió el tamaño del identificador a 29 bits, proporcionando hasta 56 millones de identificadores únicos. Como ambas especificaciones aún están en uso (a veces en el mismo cable), la especificación 1.2 original se llama Parte A y la nueva especificación 2.0 se denomina parte B. Un atributo único de CAN es que solo dos de las capas del Modelo de Referencia OSI están definidas ( Figura 1), la capa de enlace de datos y la capa física. El enlazador de datos CAN normalmente se divide en dos subcapas, la subcapa de señalización física y la subcapa de control de acceso a los medios (MAC).

Allen-Bradley (Rockwell Automation) creó DeviceNet como un protocolo de capa de aplicación encima de CAN en la década de 1990. AB seleccionó CAN como la Capa Física de DeviceNet por varias razones, entre ellas:

Una capa física extremadamente robusta.
Tecnología abierta.
Pequeña huella de procesador (RAM, requisitos de ROM).
Componentes físicos económicos con múltiples fuentes.

Una de las características más extraordinarias de CAN (y DeviceNet) es el arbitraje a nivel de bits. El Arbitraje de Bitwise es el proceso que CAN utiliza para priorizar los mensajes sin perder el ancho de banda de la red. En una red CAN, los bits “cero” dominan los bits “uno”. Cuando un dispositivo transmite un mensaje, escucha los bits en la red. Si un dispositivo transmite uno y escucha un cero, sabe que se está transmitiendo un mensaje de mayor prioridad y deja de transmitir. El nodo con el mensaje de prioridad más alta oye los bits que está transmitiendo y nunca sabe que entró en conflicto con un mensaje de prioridad más baja. La secuencia de mensajes en la red se conserva.

DEVICENET & CIP

El Protocolo de Comunicaciones e Información (CIP) es un protocolo de comunicaciones para transferir datos de automatización entre dos dispositivos. DeviceNet es una combinación del protocolo CIP y la capa física CAN. En el Protocolo CIP, cada dispositivo de red se representa a sí mismo como una serie de objetos. Cada objeto es simplemente una agrupación de los valores de datos relacionados en un dispositivo. Por ejemplo, se requiere que cada dispositivo CIP haga que un objeto de Identidad esté disponible para la red. El objeto de identidad contiene valores de datos de identidad relacionados llamados atributos. Los atributos para el objeto de identidad incluyen la ID del proveedor, la fecha de fabricación, el número de serie del dispositivo y otros datos de identidad. CIP no especifica en absoluto cómo se implementan los datos de este objeto, solo deben admitirse qué valores de datos, generalmente llamados atributos, y que estos atributos deben estar disponibles para otros dispositivos CIP. El objeto de identidad es un ejemplo de un objeto requerido. Hay tres tipos de objetos definidos por el protocolo CIP:

OBJETOS REQUERIDOS

La especificación requiere que los objetos requeridos se incluyan en cada dispositivo CIP. Estos objetos incluyen el objeto de identidad, un objeto de enrutador de mensajes y un objeto de red.

Objeto de identidad

El objeto de identidad contiene atributos que identifican al dispositivo DeviceNet. Los atributos para el objeto de identidad incluyen la ID del proveedor, la fecha del fabricante, el número de serie del dispositivo y otros datos de identidad.

OBJETO DEL ENRUTADOR DE MENSAJES

El enrutador de mensajes es un objeto que existe para enrutar mensajes explícitos y respuestas explícitas hacia y desde el objeto de conexión. Por ejemplo, el objeto de conexión recibe una solicitud de mensaje explícito y la pasa al objeto enrutador. El enrutador abre el paquete DeviceNet (CIP) e identifica el objeto de destino. El mensaje se pasa al objeto de destino para su procesamiento. La respuesta del objeto objetivo sigue el curso idéntico a la inversa. Recuerde que esto es solo el comportamiento operativo externo del objeto Router de mensajes. La implementación de este objeto puede y sigue un mecanismo mucho más conciso y eficiente.

OBJETO DEVICENET

El objeto DeviceNet contiene atributos que identifican el puerto, la velocidad en baudios, la identificación de Mac (dirección de DeviceNet), la identificación del proveedor y otros parámetros físicos de operación.

OBJETO DE CONEXION

El objeto Connection contiene los atributos que controlan el procesamiento de mensajes explícitos y de E / S. Lo más importante es que los atributos para la ruta de E / S y el tipo de conexión controlan la frecuencia con la que los dispositivos DeviceNet producen datos y la ruta donde el objeto de conexión “encuentra” los datos para producir.

Otro objeto requerido es el objeto de enrutador de mensajes. La especificación de DeviceNet describe estos objetos con un detalle insoportable.

OBJETOS DE APLICACIÓN

Los objetos de aplicación son los objetos que definen los datos encapsulados por el dispositivo. Estos objetos son específicos para el tipo de dispositivo y la función. Por ejemplo, un objeto Motor en un sistema de accionamiento tiene atributos que describen la frecuencia, la clasificación de corriente y el tamaño del motor. Un objeto de entrada analógica en un dispositivo de E / S tiene atributos que definen el tipo, la resolución y el valor actual de la entrada analógica.

Estos objetos de la capa de aplicación están predefinidos para una gran cantidad de tipos de dispositivos comunes. Todos los dispositivos CIP con el mismo tipo de dispositivo (sistemas de control, control de movimiento, transductor de válvula, etc.) deben contener la misma serie de objetos de aplicación. La serie de objetos de aplicación para un tipo de dispositivo en particular se conoce como el perfil del dispositivo. Se ha definido un gran número de perfiles para muchos tipos de dispositivos. La compatibilidad con un perfil de dispositivo permite a un usuario comprender y cambiar fácilmente de un proveedor de un tipo de dispositivo a otro proveedor con el mismo tipo de dispositivo.

Un proveedor de dispositivos también puede agrupar objetos de capa de aplicación en objetos de ensamblaje. Estos súper objetos contienen atributos de uno o más objetos de la capa de aplicación. Los objetos de ensamblaje forman un paquete conveniente para el transporte de datos entre dispositivos. Por ejemplo, un proveedor de un controlador de temperatura con múltiples bucles de temperatura puede definir ensamblajes para cada uno de los bucles de temperatura y un ensamblaje con datos de ambos bucles de temperatura. El usuario puede elegir el ensamblaje más adecuado para la aplicación y con qué frecuencia acceder a cada ensamblaje. Por ejemplo, un conjunto de temperatura puede configurarse para informar cada vez que cambia de estado, mientras que el segundo puede configurarse para informar cada segundo sin importar un cambio de estado.

Los ensamblajes generalmente son predefinidos por el proveedor, pero el CIP también define un mecanismo en el cual el usuario puede crear dinámicamente un ensamblado a partir de atributos de objeto de capa de aplicación. Los ensamblajes dinámicos son bastante raros, ya que la mayoría de los usuarios finales no querrían molestarse en definir sus propios ensamblajes.

OBJETOS ESPECÍFICOS DEL VENDEDOR

Los objetos que no se encuentran en el perfil para una clase de dispositivo se denominan específicos del proveedor. El proveedor incluye estos objetos como características adicionales del dispositivo. El protocolo CIP proporciona acceso a estos objetos de extensión de proveedor en exactamente el mismo método que la aplicación o los objetos requeridos. Estos datos son estrictamente de la elección de los proveedores y están organizados en cualquier método que tenga sentido para el proveedor del dispositivo.

Además de especificar cómo se representan los datos del dispositivo en la red, el protocolo CIP especifica una serie de formas diferentes en las que se puede acceder a esos datos, como cíclicos, sondeados y cambio de estado.

CONEXIONES Y IDENTIFICACIONES DE CONEXIÓN

DeviceNet es una red basada en conexión similar a TCP / IP de Ethernet. Cuando dos dispositivos establecen una conexión, intercambian números de identificación de conexión. Para la mayoría de los mensajes de DeviceNet, la mensajería entre un dispositivo maestro y un dispositivo esclavo, las ID de conexión están predefinidas, lo que permite que los dispositivos de bajos recursos optimicen el procesamiento de estos mensajes. Usando los filtros provistos en una gran cantidad de controladores CAN, estos mensajes se identifican y procesan fácilmente, mientras que todos los demás mensajes se descartan rápidamente.

Para todos menos unos pocos tipos de conexiones, se asignan dos ID de conexión. Uno, el ID de conexión producido se asigna para el mensaje transmitido por el dispositivo. El segundo es el ID de conexión consumido, el ID de conexión utilizado en el mensaje consumido por el dispositivo.

Los ID de conexión son una parte integral de la mensajería de DeviceNet y son parte del esquema de priorización de mensajes. El identificador CAN en cada mensaje de DeviceNet se compone de parte de la dirección de DeviceNet y la ID de conexión del mensaje. Cuanto menor sea la combinación de la ID de conexión y la dirección de DeviceNet, mayor será la prioridad del mensaje en la red. En algunas redes con ciertos tipos de esquemas de mensajería, el uso de direcciones de ID de Mac más bajas para dispositivos de mayor prioridad es una estrategia de optimización válida.

CONEXIONES DE MENSAJE NO CONECTADOS

Cada dispositivo DeviceNet contiene un puerto de acceso virtual especial llamado Puerto de mensaje no conectado. Este puerto virtual proporciona una forma para que un dispositivo envíe algunos mensajes predefinidos a un dispositivo DeviceNet sin hacer una conexión primero. Los mensajes predefinidos se limitan a crear y eliminar otras conexiones.

El puerto de mensaje no conectado es parte del conjunto de conexiones del grupo 2, el conjunto de conexiones utilizadas por los dispositivos esclavos DeviceNet. Esta conexión está diseñada para dispositivos poco sofisticados y de bajos recursos. De hecho, este conjunto de conexión es exactamente cómo un maestro DeviceNet asigna un esclavo DeviceNet, mediante el envío de mensajes en el puerto de mensajes no conectado del grupo 2.

Los dispositivos más sofisticados también implementan el Puerto de Mensajes Desconectados. Para estos dispositivos, este puerto se puede usar para crear conexiones explícitas en los grupos de conexión 1 o 3, grupos de conexión que se usan para transferir solicitudes de mensajes explícitos.

CONEXIONES DE MENSAJES CONECTADOS

Los mensajes conectados son mensajes producidos y consumidos a través de una conexión entre dos dispositivos. Los mensajes conectados pueden ser mensajes de tipo Respuesta / Solicitud explícita o mensajes de E/S que contienen datos con formato. Los mensajes conectados también pueden ser mensajes transferidos a una determinada tasa de datos (mensajes cíclicos), en respuesta a una encuesta (mensajes de respuesta de encuesta) o en un cambio de estado (mensajes COS). Los datos pueden ser públicos, conjuntos de datos predefinidos o datos propietarios específicos de un proveedor en particular (mensaje homólogo propietario). El hecho de que dos dispositivos estén conectados no implica nada acerca de los datos que se transfieren a través de la conexión.

EL MAESTRO ESCLAVO CONECTADO MENSAJERÍA

Los dispositivos DeviceNet se pueden clasificar como dispositivos maestros o esclavos. Los dispositivos maestros son dispositivos que recopilan datos de entrada de varios dispositivos esclavos y distribuyen datos de salida a los dispositivos esclavos. Los dispositivos maestros también se conocen como escáneres y dispositivos cliente, mientras que los esclavos pueden denominarse servidores. Los dispositivos Maestro y Esclavo usan un conjunto de conexiones y secuencias de mensajes que se denominan Conjunto de “Conexión Maestro Esclavo”. Este conjunto de conexiones y mensajes proporciona una forma conveniente para que el dispositivo DeviceNet Master asigne, configure y transfiera datos de E / S a un esclavo DeviceNet no sofisticado.

El Conjunto de conexión de esclavo maestro predefinido se describe con gran detalle más adelante en este documento.

MENSAJERÍA DE CONEXIÓN E/S

Las conexiones de E / S son conexiones que distribuyen datos de salida a los esclavos DeviceNet y recopilan datos de entrada de los esclavos DeviceNet. La dirección de la transferencia de datos siempre se discute en términos de la red DeviceNet. Los datos que se mueven de la red a un dispositivo son datos de salida. Los datos que se mueven de un dispositivo a la red DeviceNet son datos de entrada.

Las conexiones de E / S para el conjunto de conexiones maestro / esclavo predefinidas se describen en detalle más adelante en este documento.

MENSAJERÍA DE CONEXIÓN OFFLINE

DeviceNet ahora incluye un conjunto de conexión para dispositivos en el estado de fallo de comunicación. Un dispositivo DeviceNet tiene un fallo de comunicación si, al encenderlo, detecta otro dispositivo con la misma ID MAC (Dirección DeviceNet). Un dispositivo en el estado de Fallo de comunicación no puede transferir ningún dato ni realizar ninguna operación de la aplicación hasta que se resuelva el fallo. La falla generalmente se resuelve al redireccionar manualmente la red para que no existan dispositivos con direcciones duplicadas.

Si muchos dispositivos tienen la dirección idéntica, redirigir manualmente la red requiere mucho tiempo y es difícil. O bien los interruptores en el dispositivo se deben cambiar individual y manualmente o todos los dispositivos deben eliminarse de la red. Una vez que se eliminan todos los dispositivos, cada dispositivo direccionable por software puede agregarse a la red y redirigirse uno por uno mediante una herramienta de configuración.

Este tedioso y tedioso procedimiento es para lo que se diseñó la mensajería del conjunto de conexión sin conexión. Usando el conjunto de conexión Desconectado, una herramienta de configuración puede conectarse a un dispositivo con Falla de Comunicación, cambiar su dirección y luego restablecerla. Dado que muchos dispositivos de comunicación con falla pueden compartir una dirección, la herramienta de configuración utiliza el número de serie del proveedor para identificar un dispositivo específico en la red. Al destellar los LED de ese dispositivo en un patrón específico, la herramienta puede identificar el dispositivo defectuoso para el usuario que luego puede asignar una dirección a ese dispositivo.

Desafortunadamente, solo una minoría de dispositivos admite el conjunto de conexión sin conexión.

MENSAJERÍA DE DEVICENET

Hay tres tipos de mensajes que pueden transmitirse entre los nodos de DeviceNet. Los mensajes de pares son mensajes sin formato entre dos nodos cualquiera. Los mensajes explícitos son mensajes de tipo Solicitud / Respuesta de un Maestro de DeviceNet a un esclavo de DeviceNet que obtienen o establecen un atributo en un Objeto de DeviceNet. Los mensajes de E / S son mensajes que transfieren datos de E / S predefinidos entre un maestro DeviceNet y un esclavo DeviceNet.

MENSAJERÍA

La mensajería entre pares en DeviceNet es un concepto ampliamente mal entendido. Aunque se admite la mensajería entre pares, no existe una forma práctica para que los dispositivos fabricados por diferentes proveedores se comuniquen a través de canales de comunicación entre iguales.

La mensajería entre pares es simplemente el intercambio de mensajes de un dispositivo DeviceNet a otro a través de cualquier conexión que no sea Master Slave. Si dos dispositivos admiten la mensajería no conectada y uno de los dispositivos puede emitir un mensaje no conectado, se puede crear un canal de comunicación entre los dos dispositivos.

Desafortunadamente, la creación del canal de comunicación entre pares no implica que los dos dispositivos puedan intercambiar datos significativos. A diferencia del grupo de comunicación Solo Grupo 2 (Maestro / Esclavo), no hay una regla u organización bien definida para los datos intercambiados en el canal de Comunicación de igual a igual. Si un controlador de temperatura DeviceNet envía una temperatura a través de una conexión entre pares a una pantalla, no hay forma de que la pantalla descifre los datos. La temperatura puede estar en grados Celsius o Fahrenheit. Puede ser de 16 o 32 bits, a escala o sin escala. A diferencia de un mensaje de E / S entre un Maestro DeviceNet y un Esclavo, no hay una estructura o significado implícito para los bytes enviados en un canal de comunicación de igual a igual.

La mayoría de las implementaciones de comunicaciones entre pares son utilizadas por dispositivos fabricados por el mismo proveedor. El proveedor define el formato y el contenido del mensaje para que cada dispositivo pueda comprender el contenido del mensaje. Los proveedores de códigos de barras a veces usan mensajes entre pares para crear lo que se denomina un “escáner universal para hombres pobres”. Usando 2 o más escáneres situados alrededor de un objetivo, el dispositivo de código de barras que lee el código de barras envía un mensaje a los otros escáneres indicando que tiene el código de barras y que pueden interrumpir el escaneo.

MENSAJERÍA EXPLÍCITA

Los mensajes explícitos son mensajes de solicitud / respuesta emitidos por un maestro de DeviceNet para solicitar un servicio de un esclavo de DeviceNet a través de una conexión de mensajes explícitos. El campo Código de servicio en el mensaje explícito identifica el servicio solicitado con el resto del mensaje que contiene los datos necesarios para ejecutar el servicio. El código de servicio GET_ATTRIBUTE es una solicitud típica transmitida en un mensaje explícito. GET_ATTRIBUTE devuelve el valor de un atributo al dispositivo que emite el mensaje explícito. Todos los dispositivos utilizan los mensajes explícitos, incluidas las herramientas de configuración.

DEVICENET SINOPSIS

Los códigos de servicio de atributos GET y SET son los mensajes más comunes transmitidos por los mensajes explícitos. Los datos del código de servicio asociados con estos mensajes incluyen:

Clase de objeto: el número de clase de objeto del objeto en el dispositivo de destino
Número de instancia: la aparición específica de la clase de objeto en el dispositivo de destino. Por ejemplo, un dispositivo con 16 puntos de entrada puede implementarse con un objeto de entrada con 16 instancias, uno para cada punto de entrada.
Id. De atributo: el índice del valor específico en el objeto al que se dirige el servicio Obtener o establecer
atributo Valor de atributo (solo configuración): el nuevo valor para el atributo

Una solicitud de obtención de servicio para obtener el número de serie del dispositivo se ve así:

Todos los mensajes explícitos se enrutan a través del Enrutador de mensajes explícitos dentro del dispositivo DeviceNet. El router valida la clase de objeto. Si el mensaje explícito contiene una clase no válida, el enrutador rechaza el mensaje y devuelve un código de error al solicitante. Si el enrutador valida la clase de objeto, lo pasa al objeto de destino para su procesamiento. La respuesta del objeto de destino se devuelve al solicitante a través del enrutador. Tenga en cuenta que esta es solo la vista de red del funcionamiento del dispositivo y puede o no ser la forma en que se implementa el dispositivo.

Una aplicación interesante de los mensajes explícitos es que se pueden utilizar para leer datos de E / S. Se puede formar un mensaje explícito para obtener los datos de atributo que contienen los datos de E / S. Los datos de E / S se pueden recuperar del objeto de origen que genera los datos o del objeto de ensamblaje que contiene los datos listos para transferir al Maestro.

Una conexión de mensaje explícito puede admitir un mecanismo de fragmentación para mensajes de más de 8 bytes. Los mensajes explícitos fragmentados contienen solo seis bytes de datos. Se agregan dos bytes de encabezado para administrar la fragmentación a cada mensaje. Un byte de encabezado indica la posición del mensaje fragmentado (Primero, Último, Medio) en la secuencia del mensaje, mientras que el segundo byte contiene un número de secuencia.

A diferencia de la fragmentación de mensajes de E / S, los mensajes explícitos deben ser reconocidos. El receptor (dispositivo maestro o esclavo) debe transmitir un mensaje que indique la aceptación del mensaje fragmentado antes de que se transmita el siguiente mensaje en la secuencia.

No se requiere que los dispositivos DeviceNet admitan la fragmentación de mensajes explícitos. De hecho, la mayoría de los dispositivos no lo hacen como fragmentación de mensajes explícitos y el manejo de acuse de recibo requerido requiere una enorme cantidad de recursos del dispositivo. Un hecho poco conocido es que la mayoría de los nombres de dispositivos DeviceNet (una cadena ASCII) tienen ocho bytes o menos de longitud para evitar el soporte de la fragmentación explícita de mensajes, ya que los nombres de productos más largos se transferirían al Maestro como una secuencia de mensajes fragmentada.

MENSAJERÍA DE E / S

Los mensajes de E / S transfieren datos de E / S predefinidos entre un escáner DeviceNet y un dispositivo de E / S. Tradicionalmente, las entradas y las salidas están referenciadas desde el punto de vista de la red. Una entrada es un punto de datos producido por un dispositivo de E / S y transferido a un escáner a través de la red. Una salida es un punto de datos consumido por un dispositivo de E / S y transferido desde un escáner a un dispositivo a través de la red DeviceNet.

Los datos de E / S están contenidos en un dispositivo en uno o más conjuntos de dispositivos. El objeto de ensamblaje de entrada identifica los datos producidos por el dispositivo. El atributo tres de cada objeto de ensamblaje de entrada es el atributo que contiene los datos que se deben producir. El atributo tres suele ser una recopilación de datos de uno o más objetos de aplicación. La Figura 2 es un ejemplo de los Conjuntos que puede encontrar en un medidor de flujo simple.

Los objetos del conjunto de salida identifican los datos consumidos por el dispositivo. El atributo tres de cada conjunto de salida identifica los datos específicos consumidos por el dispositivo. El atributo tres de cada conjunto de salida suele ser una recopilación de datos consumidos por el dispositivo. Los datos consumidos están destinados a uno o más objetos de la aplicación a medida que se reciben.

Un dispositivo puede tener múltiples ensamblajes de entrada y salida. Por ejemplo, un dispositivo lector de código de barras puede tener algún conjunto de entradas y salidas discretas. Los objetos del conjunto para el dispositivo de código de barras pueden incluir un conjunto con solo datos de código de barras, un conjunto con solo datos de E / S o un conjunto que contiene tanto código de barras como datos de E / S. Esto proporciona la máxima flexibilidad para el usuario final. Un usuario final que no usa la E / S en el lector de códigos de barras selecciona el primer ensamblaje. Un usuario que utiliza el lector de código de barras como un dispositivo de E / S discreto puede seleccionar el segundo conjunto, mientras que el usuario que usa ambos puede seleccionar el último conjunto.

La Figura 2 es un ejemplo de un dispositivo con más de un conjunto. En este ejemplo, el usuario puede elegir entre dos conjuntos para un medidor de flujo simple. El conjunto 1 contiene el flujo y la temperatura, mientras que el conjunto 2 contiene los datos de E / S discretas.

En estos casos, la conexión de E / S debe configurarse para hacer referencia a un conjunto que no sea el conjunto predeterminado. En el objeto Conexión hay un mínimo de dos instancias de conexión. Una instancia es para la conexión explícita y una instancia para la conexión de E / S. La conexión explícita describe cómo se transfieren los mensajes explícitos. La conexión de E / S describe cómo se gestionan los mensajes.

El atributo Ruta de conexión en la conexión de E / S es el objeto de ensamblaje que contiene los datos para consumir y producir. Hay varias formas diferentes de especificar la ruta de conexión, la mayoría de las cuales requieren más explicación de la que se puede proporcionar en este documento.

Para cambiar la ruta de conexión, un usuario puede usar un mensaje explícito para establecer esta ruta directamente o, en muchos casos, el proveedor del dispositivo proporciona un atributo de selección en uno de los objetos de la aplicación para establecer la ruta más fácilmente. Si un dispositivo solo admite la administración directa del atributo de ruta de conexión, el usuario puede tener que consultar la documentación del dispositivo o la especificación de DeviceNet para especificar correctamente la ruta.

Los mensajes de E / S vienen en varios sabores:

POLLED: los mensajes sondeados son mensajes de solicitud / respuesta que se envían a la conexión sondeada. Los mensajes sondeados son enviados por el escáner a la velocidad de su elección.
CÍCLICO – Los mensajes cíclicos son mensajes programados. En este modo, el dispositivo esclavo DeviceNet emite periódicamente mensajes al maestro a una velocidad programada.
Cambio de estado (COS): los mensajes COS son mensajes que se producen en la conexión de E / S en un evento. Además, el dispositivo esclavo DeviceNet también emite un mensaje de latido. El latido del corazón le permite al escáner saber que el dispositivo esclavo aún está vivo.

Todos los mensajes transfieren un conjunto de E / S entre el escáner y el adaptador. Escáner y Adaptador son términos alternativos utilizados por algunas personas de DeviceNet para referirse al Maestro de DeviceNet (escáner) y al Esclavo (Adaptador). Los mensajes de E / S también implementan un esquema de fragmentación para datos de E / S mayores que los bytes de datos estándar CAN 8. A diferencia del protocolo de fragmentación utilizado para los mensajes explícitos, la fragmentación de los mensajes de E / S no se reconoce y no se secuencia. Los múltiples mensajes se transmiten sin codificación especial o número de secuencia. El receptor simplemente reconstruye los datos de E / S en el orden en que se reciben los mensajes.

ESTABLECIMIENTO DE CONEXIÓN MENSAJERÍA

Solo hay dos requisitos para colocar con éxito un nuevo dispositivo en una red. Uno, la velocidad en baudios del dispositivo coincide con la velocidad en baudios de todos los demás dispositivos en la red y dos, la dirección del dispositivo no debe entrar en conflicto con la dirección de otro dispositivo.

TASA DE BAUDO

Hay tres velocidades en baudios para las redes DeviceNet; 125K, 250K y 500K. La velocidad en baudios limita la longitud de la red. Muy simple, las redes CAN requieren que cada dispositivo escuche sus propios bits a medida que se transmiten y establezca el bit de reconocimiento en todos y cada uno de los mensajes transmitidos en la red. La implementación de este último requisito determina la longitud máxima de la red para cada velocidad de transmisión:

Identificar la velocidad en baudios actual de un dispositivo puede ser un desafío. A menos que un dispositivo esté configurado con interruptores DIP y la velocidad de transmisión pueda distinguirse de los interruptores, no hay forma de saber cuál puede ser la velocidad de transmisión. Una de las razones por las que un dispositivo puede no conectarse es una velocidad en baudios diferente a la velocidad en baudios de la red. Si no conoce la velocidad en baudios de un dispositivo DeviceNet, el único método seguro para averiguarlo es tratar de conectarse a cada velocidad en baudios.

DIRECCIÓN DeviceNet

Se asigna una dirección entera a cada dispositivo DeviceNet en una red. Este entero es la dirección del dispositivo o MacID. MacID es la abreviatura de Media Access Identifier. Hay un máximo de 64 nodos en una red DeviceNet. Estos nodos ocupan MacID (direcciones) de 0 a 63 y se pueden configurar utilizando conmutadores o utilizando una herramienta de configuración DeviceNet. No hay dos dispositivos que puedan ocupar la misma dirección DeviceNet.

Al encender cada dispositivo DeviceNet, se envía un mensaje solicitando acceso a la red. Parte de este mensaje es el número de serie exclusivo del dispositivo. Si más de un devic del mismo proveedor, todos con el mismo ID de proveedor, se encienden e intentan acceder a la red en el mismo instante en que el dispositivo con el número de serie más bajo de DeviceNet tenga éxito. Todos los demás dispositivos fallan. Esta secuencia se explica con más detalle en la siguiente sección.

DUPLICADO SECUENCIA DE ID MAC

El protocolo DeviceNet requiere que los dispositivos que pasan de un estado sin conexión a otro en línea sigan una secuencia de mensajes muy específica con un tiempo específico. Esta secuencia se basa en el mensaje de solicitud de MacID duplicado. Este mensaje consta de la identificación del proveedor y el número de serie del dispositivo. El ID de proveedor es el ID de entero asignado al proveedor por ODVA, mientras que el número de serie es un entero largo único asignado por el proveedor. Dado que se requiere que el proveedor asigne un número de serie único a cada dispositivo, no hay dos dispositivos DeviceNet en ningún lugar del planeta que puedan tener la misma combinación de proveedor / número de secuencia. Esto garantiza que no haya dos mensajes de solicitud de MacID duplicados que puedan tener el mismo contenido.

La secuencia de Duplicate MacID consiste en enviar dos mensajes de solicitud de Duplicate MacID consecutivos con un retraso de un segundo entre mensajes. Durante la demora, cualquier dispositivo en línea con el mismo MacID debe emitir un mensaje de respuesta de MacID duplicado. Si el dispositivo que se une a la red recibe un mensaje de respuesta de MacID duplicado, pasa al estado de fallo de comunicación. Si no se recibe respuesta después de la segunda demora de un segundo, el dispositivo puede realizar la transición oficial al estado en línea.

Hay otros requisitos más sutiles para dispositivos DeviceNet. Por ejemplo, si un dispositivo en el estado en línea recibe alguna vez un mensaje de respuesta de MacID duplicado, debe pasar inmediatamente al estado fuera de línea. Recibir una respuesta MacID duplicada indica que hay otro dispositivo en la red en el estado en línea con la misma MacID.

MENSAJES VARIOS

Un mensaje que está directamente enfrente del mensaje de solicitud de Duplicate MacID es el mensaje de apagado del dispositivo. Este mensaje transmite el hecho de que un dispositivo está en transición desde el estado en línea al estado fuera de línea o no existente. Este es un mensaje opcional que puede ser usado por un dispositivo para indicar una condición de falla, comando remoto o alguna otra razón para desconectarse de la red.

Otro mensaje que se usa con poca frecuencia es el mensaje de latido del dispositivo. Los dispositivos que admiten la operación de cambio de estado (COS) utilizan el mensaje de latido del dispositivo (DHC) para comunicar al maestro que están operativos. Si no se produce ningún mensaje de COS que contenga datos nuevos para una duración determinada, el dispositivo produce el mensaje de DHB.

Estados de error

Los dispositivos DeviceNet pueden asumir cualquiera de los siguientes estados:

TIPOS DE DISPOSITIVOS DE DeviceNet

Hay tres tipos básicos de dispositivos DeviceNet; Dispositivos maestros, dispositivos esclavos y dispositivos pares. Un dispositivo puede admitir uno o todos los tipos de dispositivos simultáneamente.

DISPOSITIVOS MAESTROS (escáneres)

Los dispositivos maestros, a veces conocidos como escáneres, pero no usualmente como dispositivos cliente, son dispositivos que “poseen” dispositivos esclavos DeviceNet. Un maestro puede poseer muchos o todos los dispositivos esclavos, pero un esclavo solo puede ser “propiedad” de un maestro DeviceNeta la vez.

Un dispositivo maestro debe primero “asignar” un dispositivo esclavo DeviceNet para obtener la propiedad. El proceso de asignación, descrito más adelante en este documento, es un conjunto de mensajes de intercambio en el que el dispositivo Maestro solicita el control del esclavo y luego configura el esclavo para transferir un conjunto particular de datos a una velocidad de datos especificada por el Maestro. El conjunto típico de mensajes que solicitan la propiedad se conoce como el “Conjunto de conexión esclavo maestro predefinido”.

El proceso de asignación es simplemente un mensaje de solicitud explícita abierta emitido en el puerto de mensaje no conectado que solicita la propiedad del dispositivo esclavo. Si el esclavo acepta la propiedad, responde afirmativamente y crea las conexiones solicitadas por el dispositivo maestro en el mensaje de solicitud. Por lo general, el Maestro solicita una conexión explícita y una de E / S.

Un esclavo puede denegar la solicitud de asignación del dispositivo maestro. Los esclavos pueden denegar una solicitud si ya están asignados a otro maestro o si el dispositivo maestro solicita un tipo de conexión no compatible. Por ejemplo, si el maestro solicita una conexión cíclica y el esclavo DeviceNet solo admite conexiones de sondeo, se deniega la solicitud de asignación.

Una vez que el Esclavo acepta la solicitud de conexión, el Maestro utiliza la conexión de Mensaje Explícito para configurar la conexión de E / S. La configuración incluye la configuración de los dos atributos más importantes de la conexión de E / S; la tasa de paquetes esperada y las rutas de conexión producidas y consumidas. La tasa de paquetes esperada es la velocidad a la que el maestro espera escanear el dispositivo esclavo DeviceNet. Si el maestro no escanea a esta velocidad, el dispositivo esclavo entra en un estado de tiempo de espera agotado y debe ser reactivado explícitamente por el dispositivo maestro. Las rutas de conexión Producidas y Consumidas son las rutas a los objetos de la aplicación donde los datos se generan o almacenan respectivamente. En general, estas rutas se refieren a uno de los ensamblajes admitidos por el dispositivo esclavo.

El escaneo puede comenzar una vez que el dispositivo esclavo esté completamente configurado. Durante el escaneo, el dispositivo maestro produce y consume datos de esclavos. El maestro produce datos para el ensamblaje de salida del esclavo que se identifica mediante la ruta de conexión consumida en el esclavo. El maestro consume datos generados a partir del ensamblaje de entrada del esclavo que se identifica por la ruta de conexión producida en el ensamblaje de salida del esclavo.

DISPOSITIVOS ESCLAVO (Adaptadores)

Los dispositivos esclavos, a veces conocidos como servidores, son dispositivos que reciben y transmiten datos específicos de la aplicación hacia y desde un dispositivo maestro. Los dispositivos esclavos por definición implementan el conjunto de conexiones de esclavo maestro predefinido descrito en la sección anterior.

Los dispositivos esclavos deben admitir al menos uno o más de los siguientes tipos de transporte de mensajes de E / S:

POLLING : en este modo de operación, el dispositivo maestro transmite datos de E / S al dispositivo esclavo a cierta velocidad. Esta tasa debe ser mayor que la tasa especificada por la tasa de paquetes esperada cuando se configuró la conexión. El dispositivo esclavo responde a un mensaje de sondeo al producir los datos en su conjunto de entrada.

CÍCLICO : en la mensajería cíclica, el dispositivo maestro transmite datos de E / S al dispositivo esclavo a cierta velocidad. Esta tasa debe ser mayor que la tasa especificada por la tasa de paquetes esperada cuando se configuró la conexión. El dispositivo esclavo puede o no estar configurado para responder de inmediato. En la situación típica, el dispositivo esclavo produce sus datos de E / S a una frecuencia configurada por el dispositivo maestro.

CAMBIO DE ESTADO (COS) : en la mensajería COS, el dispositivo maestro transmite los datos de E / S al dispositivo esclavo a una tasa de escaneo superior a la especificada en la tasa de paquetes esperada. El dispositivo esclavo puede o no estar configurado para responder de inmediato. En la situación típica, el dispositivo esclavo produce sus datos de E / S SOLAMENTE cuando la capa de la aplicación indica que los datos han cambiado o al expirar algún temporizador de transmisión, también conocido como temporizador de latido.

Un dispositivo maestro transmite implícitamente su modo de operación actual con cada exploración de E / S. Si el dispositivo maestro (generalmente un controlador programable) se encuentra en un modo sin ejecución, el maestro produce un mensaje de E / S con cero bytes de datos conocido como mensaje de modo IDLE. El dispositivo esclavo puede implementar la funcionalidad requerida del dispositivo cuando su maestro no está en modo de ejecución. Los mensajes recibidos con al menos un solo byte de datos de E / S indican al dispositivo Esclavo que el Maestro ahora está en modo Ejecutar. DeviceNet no requiere que un dispositivo esclavo implemente ningún comportamiento específico cuando un dispositivo maestro está en modo IDLE.

Los dispositivos maestros, como las herramientas de configuración, a menudo asignan el conjunto de conexiones predefinidas de un dispositivo esclavo que solicita solo la conexión de solicitud de mensaje explícito. Estos dispositivos generalmente asignan la conexión EM, obtienen o establecen un atributo particular y luego liberan el conjunto de conexiones. Si estos dispositivos están asignados actualmente por otro dispositivo maestro, el maestro que posee el esclavo DeviceNet imita los mensajes de un dispositivo esclavo desconectado pero solo acepta la conexión de mensaje explícito. Los mensajes para el esclavo de propiedad son recibidos por este Maestro y enviados al esclavo. La respuesta del esclavo se recibe y se transmite al solicitante original, como si el dispositivo maestro original se comunicara directamente con el esclavo. De esta manera un dispositivo, como una herramienta de configuración,

SECUENCIA DE ASIGNACIÓN MAESTRA

Un dispositivo Master DeviceNet hace una conexión con un dispositivo esclavo usando la siguiente secuencia:

1. El maestro emite un mensaje de solicitud abierta no conectada al esclavo de DeviceNet. Un dispositivo esclavo DeviceNet que admite mensajes desconectados asigna una conexión de mensaje explícita y responde al mensaje maestro. El esclavo devuelve un ID de conexión y describe el tipo de mensajes que el esclavo puede admitir. Estos esclavos luego continúan con el paso 6 de la secuencia de conexión del mensaje.
2. Si un esclavo no responde a la solicitud de mensaje no conectado dentro de un segundo, el Maestro emite un segundo Mensaje de solicitud de apertura no conectado. Los esclavos que no admiten la mensajería desconectada ignorarán el mensaje de solicitud de apertura desconectada.
3. Un esclavo puede responder a la segunda solicitud, asignar una conexión de mensaje explícita y devolver el ID de conexión al maestro. Estos esclavos continúan con el paso 6 de la secuencia de conexión del mensaje.
4. Si un dispositivo esclavo no responde a las dos solicitudes de mensajes no conectados, el maestro espera otro segundo y emite una solicitud de conexión de solo grupo 2. Este mensaje intenta una asignación de una conexión explícita y / o IO utilizando el puerto de solo Grupo 2. Este es un puerto especial diseñado solo para admitir la asignación simple de dispositivos esclavos.
5. Los esclavos que no responden a la solicitud de conexión solo del grupo 2 están marcados como fallidos. Algunos maestros pueden reintentar la secuencia de asignación periódicamente, pero no están obligados a hacerlo.
6. Usando la conexión explícita hecha en el paso anterior, el Maestro usa la conexión para configurar la conexión de E / S. El maestro establece el tiempo de espera de E / S, las rutas de conexión y otros atributos necesarios para operar la conexión de E / S.
7. Una vez que se complete la conexión de E / S, el Maestro eliminará explícitamente la conexión explícita, ya que ya no es necesaria.

CUESTIONES DE MEDIOS FISICOS

Indicadores e interruptores

Los dispositivos DeviceNet se configuran utilizando herramientas externas de configuración de hardware o software. El hardware externo puede incluir interruptores rotativos, ruedecillas, interruptores DIP y otros dispositivos de entrada fijos. Las herramientas de configuración de software acceden a la configuración interna del dispositivo a través de la red DeviceNet u otro puerto de comunicación. Las herramientas genéricas que pueden configurar cualquier dispositivo DeviceNet utilizan la red DeviceNet. Las herramientas específicas del proveedor que configuran solo los dispositivos de ese proveedor pueden usar la red DeviceNet o algún otro puerto de comunicación en un dispositivo.

Algunos usuarios finales prefieren la configuración utilizando interruptores. Su filosofía es que un dispositivo se puede reemplazar fácilmente si todo lo que necesita es configurar los interruptores y conectar los dispositivos de reemplazo. Otros usuarios finales prefieren la configuración de software. Estos usuarios ven los interruptores como una posible fuente de falla del dispositivo.

Terminación

DeviceNet requiere resistencias de terminación en cada extremo de una línea troncal de DeviceNet. Se debe colocar una resistencia de ¼ vatio, 120 ohmios en cada extremo de la línea troncal entre las señales CAN-H y CAN-L. La especificación de DeviceNet recomienda expresamente que estas resistencias de terminación no se incluyan dentro de un dispositivo.

Aislamiento

Se recomienda el aislamiento de dispositivos DeviceNet para dispositivos con conexiones a fuentes de alimentación externas.

HOJAS DE DATOS ELECTRONICAS (EDS)

Los proveedores de DeviceNet deben proporcionar algún tipo de documentación que especifique cómo se configura su dispositivo. El documento puede ser un conjunto de instrucciones impresas o algún archivo electrónico. Como mínimo, el proveedor debe proporcionar instrucciones para cualquier conmutador externo y una lista de valores de Clase / Instancia / Atributo que controlan la configuración del dispositivo. Algunos proveedores crean un “conjunto de configuración” que contiene los datos del parámetro. Este conjunto proporciona un único atributo, un único punto de referencia donde todos los parámetros del dispositivo se pueden leer y escribir.

Por lo general, un proveedor proporciona una lista electrónica de los atributos que configuran un dispositivo DeviceNet. Estos archivos EDS a veces proporcionan poca o ninguna información sobre el dispositivo o pueden ser muy largos y complejos. Los archivos EDS más extensos permiten que las herramientas de configuración configuren de forma precisa el dispositivo utilizando identificadores de texto para valores de bits y otras cadenas de texto muy informativas.

DISPOSITIVOS TIPICOS DE DEVICENET

Dispositivos de E / S DeviceNet

La mayoría de los dispositivos DeviceNet son dispositivos de E / S esclavos. Un dispositivo DeviceNet I / O transfiere puntos de E / S analógicos o discretos a un DeviceNet Master. Los dispositivos de E / S de DeviceNet vienen en todas las formas y tamaños desde uno o dos puntos a muchos puntos. Muchos dispositivos de E / S no están aislados y se alimentan de la red, mientras que otros utilizan salidas aisladas.

DeviceNet Masters

Los dispositivos maestros DeviceNet suelen ser controladores programables o computadoras personales. Los dispositivos DeviceNet Master asignan esclavos DeviceNet y transfieren datos entre el Maestro y sus esclavos.

Puertas de enlace DeviceNet

Las puertas de enlace DeviceNet convierten los datos de otro protocolo a DeviceNet. Las puertas de enlace Modbus, DeviceNet por ejemplo, convierten los dispositivos Modbus en dispositivos DeviceNet. Los gateways ASCII DeviceNet toman datos ASCII y los convierten a Modbus. Hay innumerables convertidores de protocolo para DeviceNet.

El problema difícil para una puerta de enlace DeviceNet es la asignación de datos en el otro protocolo a la estructura de objetos de DeviceNet. Por ejemplo, el protocolo Modbus representa sus datos como una serie de enteros de 16 bits, mientras que CIP representa los datos como atributos que forman parte de los objetos. Una puerta de enlace DeviceNet debe permitir que algún método convierta los datos en su Modbus nativo, ASCII u otro formato a la estructura basada en objetos de DeviceNet.

DeviceNet Master Stack

Una pila de software DeviceNet Master es el software que implementa los protocolos de comunicación DeviceNet y CIP. Un DeviceNet Master debe poder enviar mensajes a través de la red física CAN. Para hacerlo, debe conocer la interfaz de registro particular de un controlador CAN seleccionado. Un desarrollador de dispositivos DeviceNet que quiera implementar un Maestro DeviceNet debe crear la interfaz entre el Maestro DeviceNet y el Controlador CAN seleccionado por el diseñador de hardware. A veces, como en el caso de las pilas maestras de DeviceNet proporcionadas por Real Time Automation, Inc., se entrega un archivo de interfaz para un controlador CAN en particular como parte de la pila maestra de DeviceNet.

Para implementar un Maestro de DeviceNet, la aplicación controla los dispositivos de DeviceNet para asignar, la cantidad de bytes de datos para producir y consumir y la frecuencia con que se sondean los dispositivos esclavos de DeviceNet. Para obtener más información sobre la implementación de una aplicación DeviceNet Master, comuníquese con Real Time Automation, Inc ..

Pilas de esclavos DeviceNet

Una pila de software DeviceNet Slave es el software que implementa los protocolos de comunicación DeviceNet y CIP. Un esclavo de DeviceNet debe poder recibir un mensaje de asignación de un maestro de DeviceNet, consumir las salidas generadas por el maestro y generar entradas. Para hacerlo, debe conocer la interfaz de registro particular de un controlador CAN seleccionado al igual que la pila maestra de DeviceNet. Un desarrollador de dispositivos DeviceNet que quiera implementar un esclavo DeviceNet debe crear la interfaz entre el esclavo DeviceNet y el controlador CAN seleccionado por el diseñador de hardware. A veces, como en el caso de las pilas de esclavos de DeviceNet proporcionadas por Real Time Automation, Inc., se entrega un archivo de interfaz para un controlador CAN en particular como parte de la pila de esclavos de DeviceNet.

Para implementar un Esclavo de DeviceNet, la aplicación controla la dirección de DeviceNet, el número de bytes de datos para producir y consumir y la estructura de objetos del dispositivo. Implementar la estructura de objetos del dispositivo en el esclavo DeviceNet es una de las partes más importantes de la implementación de un dispositivo esclavo DeviceNet. Esta estructura es la estructura que ven los usuarios del dispositivo y debe implementarse correctamente para satisfacer sus necesidades.

¿Desea agregar DeviceNet a su proyecto?

Ver Soluciones DeviceNet.

Contáctanos

ventas@logicbus.com | soporte@logicbus.com | 55-5431-67-18 | Iniciar conversación