A continuaci�n menciono y explico varios de estos protocolos, estos son los m�s importantes y/o comerciales hoy d�a:

• FTP
• HTTP
• IPX/SPX
• NFS
• POP3
• SCP
• TCP/IP

Con este tipo de forma de hacer las cosas le ayudamos much�smo al usuario a despreocuparse si el tiene contacto con macrocomputadoras, micro, mini o simples PC�s, gracias a un protocolo como este, no se necesita saber mucho y se logra lo que se quiere.

FTP ha ido evolucionando demasiado en todos estos a�os desde que se creo, este empez� en 1971 con un modelo de transferencia llamado RFC 141 en M.I.T.. Fue hasta despu�s de muchas revisiones que lleg� a RFC 265 cuando ya se le considero un protocolo de transferencia de archivos completa entre HOSTs (servidores de archivos) de ARPHANET. Finalmente un documento declarando un FTP oficial se publico cuando se llego a RFC 454.

Por Julio de 1973 muchos cambios hab�a sufrido ya el FTP, pero siempre conservo la estructura principal desde el principio.

Al final de la edici�n de RFC 765 se incluyeron algunos de los que son ahora los comandos de este protocolo:

Alguna de la terminolog�a usada en este protocolo son las siguientes definiciones:

Existen tres tipos de datos en la transferencia por FTP, tipo ASCII, EBCDIC e IMAGEN.

El tipo ASCII, es el mas com�n en el protocolo FTP, este se usa cuando se transfieren archivos de texto, la computadora que env�a (sender), debe convertir cualquiera que sea su estructura de archivos interna, debe convertir sus datos al formato gen�rico de 8 bits, y el que recibe (receiver) lo debe convertir de nuevo a su formato propio.

El tipo EBCDIC es el mas eficiente cuando ambos el que recibe y el que env�a lo usan como formato propio, este tipo se representa tambi�n en 8 bits pero de forma EBCDIC. Lo �nico en lo que cambian es en la forma de reconocer los c�digos de los caracteres.

El formato de IMAGEN es cuando se empaca todo lo que se quiere enviar en cadenas seguidas de paquetes de 8 bits, esto es no importa el formato en que internamente se maneje la informaci�n, cuando se va a enviar se tiene que hacer una conversi�n de 8 bits en 8 bits y cuando el que recibe tiene todo el paquete, el mismo de be codificarlos de nuevo para que la transmisi�n sea completada.

En la estructura de datos en FTP se consideran tres tipos diferentes de archivos:

Al establecer una conexi�n por FTP se debe tomar en cuenta que el mecanismo de transferencia consiste en colocar bien la transferencia de datos en los puertos adecuados y al concluir la conexi�n estos puertos deben ser cerrados adecuadamente. El tama�o de transferencia es de 8 bits, en ambos. El que va a transferir, debe escuchar desde el puerto hasta que el comando enviado sea recibido y este ser� el que de la direcci�n de la transferencia. Una vez recibido el comando y establecido una transferencia del servidor a que solicita se inicializa la comunicaci�n de la transferencia para verificar la conexi�n, esta es una cabecera con un formato espec�fico, despu�s de esto se comienza a enviar las tramas de 8 bits sin importar el tipo de datos que sea (antes mencionado), y al finalizar se env�a otra trama cabecera ya establecida confirmando la transferencia completada.

Existen tres modos de transferencia en FTP

• STREAM MODE
• BLOCK MODE
• COMPRESSED MODE

Algunos de los comandos mas usados en FTP son los siguientes:

Comandos de acceso

USER NAME (USER)

PASSWORD (PASS

ACCOUNT (ACCT)

CHANGE WORKING DIRECTORY (CWD)

CHANGE TO PARENT DIRECTORY (CDUP)

REINITIALIZE (REIN)

LOGOUT (QUIT)

Comandos de transferencia

DATA PORT (PORT)

PASSIVE (PASV)

FILE STRUCTURE (STRU)

TRANSFER MODE (MODE)

Comandos de servicio

RETRIEVE (RETR)

STORE (STOR)

STORE UNIQUE (STOU)

APPEND (with create) (APPE)

ALLOCATE (ALLO)

RENAME TO (RNTO)

ABORT (ABOR)

DELETE (DELE)

REMOVE DIRECTORY (RMD)

MAKE DIRECTORY (MKD)

PRINT WORKING DIRECTORY (PWD)

LIST (LIST)

HELP (HELP)

Algunos de los c�digos usados en la transferencia son los siguientes, estos c�digos no son mas que mensajes enviados por el protocolo:

• 200 Command okay.
• 500 Syntax error, command unrecognized. This may include errors such as command line too long.
• 501 Syntax error in parameters or arguments.
• 202 Command not implemented, superfluous at this site.
• 502 Command not implemented.
• 503 Bad sequence of commands.
• 504 Command not implemented for that parameter.
• 110 Restart marker reply. In this case, the text is exact and not left to the particular implementation; it must read:
• 211 System status or systems help reply.
• 212 Directory status.
• 213 File status.
• 214 Help message. On how to use the server or the meaning of a particular non-standard command. This reply is useful only to the human user.
• 215 NAME system type. Where NAME is an official system name from the list in the Assigned Numbers document.
• 120 Service ready in nnn minutes.
• 220 Service ready for new user.
• 221 Service closing control connection. Logged out if appropriate.
• 421 Service not available, closing control connection. This may be a reply to any command if the service knows it must shut down.
• 125 Data connection already open; transfer starting.
• 225 Data connection open; no transfer in progress.
• 425 Can't open data connection.
• 226 Closing data connection. Requested file action successful (for example, file transfer or file abort).
• 426 Connection closed; transfer aborted.
• 227 Entering Passive Mode (h1,h2,h3,h4,p1,p2).
• 230 User logged in, proceed.
• 530 not logged in.
• 331 User name okay, need password.
• 332 Need account for login.
• 532 Need account for storing files.
• 150 File status okay; about to open data connection.
• 250 Requested file action okay, completed.
• 257 "PATHNAME" created.
• 350 Requested file action pending further information.
• 450 Requested file action not taken. File unavailable (e.g., file busy).
• 550 Requested action not taken. File unavailable (e.g., file not found, any access).
• 451 Requested action aborted. Local error in processing.
• 551 Requested action aborted. Page type unknown.
• 452 Requested action not taken. Insufficient storage space in system.
• 552 Requested file action aborted Exceeded storage allocation (for current directory or dataset).
• 553 Requested action not taken. File name not allowed.

• 110 Restart marker reply.
• 120 Service ready in nnn minutes.
• 125 Data connection already opens; transfer starting.
• 150 File status okay; about to open data connection.
• 200 Command okay.
• 202 Command not implemented, superfluous at this site.
• 211 System status, or system help reply.
• 212 Directory status.
• 213 File status.
• 214 Help message. On how to use the server or the meaning of a particular non-standard command. This reply is useful only to the human user.
• 215 NAME system type. Where NAME is an official system name from the list in the Assigned Numbers document.
• 220 Service ready for new user.
• 221 Service is closing control connection. Logged out if appropriate.
• 225 Data connection open; no transfer in progress.
• 226 Closing data connection. Requested file action successful (for example, files transfer or file abort).
• 227 Entering Passive Mode (h1, h2, h3, h4, p1, p2).
• 230 User logged in, proceed.
• 250 Requested file action okay, completed.
• 257 "PATHNAME" created.
• 331 User names okay need password.
• 332 Need account for login.
• 350 Requested file action pending further information.
• 421 Service not available, closing controls connection. This may be a reply to any command if he service knows it must shut down.
• 425 can�t open data connection.
• 426 Connection closed; transfer aborted.
• 450 Requested file action not taken. File unavailable (e.g., file busy).
• 451 Requested action aborted: local error in processing.
• 452 Requested action not taken. Insufficient storage space in system.
• 500 Syntax error, command unrecognized. This may include errors such as command line too long.
• 501 Syntax error in parameters or arguments.
• 502 Command not implemented.
• 503 Bad sequence of commands.
• 504 Command not implemented for that parameter.
• 530 Not logged in.
• 532 Need account for storing files.
• 550 Requested action not taken. File unavailable (e.g., file not found, no access).
• 551 Requested action aborted: page type unknown.
• 552 Requested file action aborted. Exceeded storage allocation (for current directory or dataset).
• 553 Requested action not taken. File name not allowed.

El protocolo para la transferencia de hipertextos es para todos los sistemas de informaci�n distribuidos que tengan la necesidad de mostrar la informaci�n y pasarla por una comunicaci�n normal haciendo uso de las ligas de este lenguaje. La primera versi�n de este lenguaje (HTTP 0.9) se uso desde 1990.

El Protocolo fue implementado inicialmente para WWW en 1991 como una iniciativa de software y se denomin� HTTP 0.9. El protocolo completo fue definido en 1992 e implementado en marzo de 1993.

• HTTP 1.0 Esta especificaci�n prev� las caracter�sticas b�sicas del protocolo. Fue desarrollado por Tim Berners-Lee, Roy T. Fielding, y Henrik Frystyk Nielsen.
• HTTP 1.1 La primera versi�n no est� aun habilitada, pero las especificaciones son muy similares a la anterior.
• HTTP-NG Next Generation of HTTP, propuesta por Sim�n Spero. Es un protocolo binario con nuevas caracter�sticas para un acceso m�s r�pido usando TCP. Este es el �ltimo HTTP en la actualidad, este es mas complejo que un 0.9.

El protocolo como todos tiene una propia terminolog�a, a continuaci�n la menciono:

Este es un protocolo usado y registrado por la compa��a mundial de redes Novell�

NFS es un sistema distribuido para archivos, este es para las redes heterog�neas, con este protocolo, el usuario solo ve un directorio cuando esta dentro de la red, claro que tiene ramas dentro pero no puede ver mas arriba de el nivel en el que se entra, tal ves los archivos dentro de esta estructura del directorio ni siquiera esta en la misma computadora.

Este es netamente un protocolo para la administraci�n de correo en Internet.

En algunos nodos menores de Internet normalmente es poco pr�ctico mantener un sistema de transporte de mensajes (MTS). Por ejemplo, es posible que una estaci�n de trabajo no tenga recursos suficientes (espacio en disco, entre otros) para permitir que un servidor de SMTP [RFC821] y un sistema local asociado de entrega de correo est�n residentes y continuamente en ejecuci�n. De forma similar, puede ser caro (o incluso imposible) mantener una computadora personal interconectada a una red tipo IP durante grandes cantidades de tiempo (el nodo carece el recurso conocido como "connectivity").

A pesar de esto, a menudo es muy �til poder administrar correo sobre estos nodos, y frecuentemente soportan un user agent (UA) (agente de usuario) para ayudar en las tareas de manejo de correo. Para resolver el problema, un nodo que s� sea capaz de soportar un MTS ofrecer� a estos nodos menos dotados un servicio de maildrop. Se entiende por maildrop, el "lugar" en el sistema con el MTS donde el correo es almacenado para que los otros nodos puedan trabajar con �l sin necesidad de mantener su propio MTS. El Protocolo de oficina de correos - Versi�n 3 (POP3) est� destinado a permitir que una estaci�n de trabajo acceda din�micamente a un maildrop en un host servidor de forma �til y eficiente. Esto significa que el protocolo POP3 se usa para permitir a una estaci�n de trabajo recobrar correo que el servidor tiene almacenado.

POP3 no est� destinado a proveer de extensas operaciones de manipulaci�n de correo sobre el servidor; normalmente, el correo es transmitido y entonces borrado. IMAP4 es un protocolo m�s avanzado y complejo y es tratado en [RFC1730] y revisado en [RFC 2060].

De aqu� en adelante el termino (host) cliente se refiere a un host haciendo uso del servicio POP3 y host servidor al que ofrece este servicio. Inicialmente, el host servidor comienza el servicio POP3 leyendo el puerto 110 TCP. Cuando un host cliente desea de hacer uso del servicio, establece una conexi�n TCP con el host servidor. Cuando la conexi�n se establece, el servidor POP3 env�a un saludo. Entonces, el cliente y el servidor de POP3 intercambian comandos y respuestas respectivamente hasta que la conexi�n se cierra o es abortada.

Los comandos en el POP3 consisten en una palabra clave (keyword), posiblemente seguida de uno o m�s argumentos. Todos los comandos terminan con un par CRLF. Las palabras clave y los argumentos consisten en caracteres ASCII imprimibles. Las palabras clave y los argumentos est�n cada uno separados por un �nico car�cter de espacio. Las palabras clave son de una longitud de tres o cuatro caracteres, mientras que cada argumento puede ser de hasta 40 caracteres de longitud.

Las respuestas en el POP3 consisten de un indicador de estado y una palabra clave posiblemente seguida de informaci�n adicional. Todas las respuestas acaban en un par CLRF. Las respuestas pueden ser de hasta 512 caracteres de longitud, incluyendo el CRLF de terminaci�n. Tambi�n existen dos indicadores de estado: positivo o afirmativo ("+OK") y negativo ("-ERR"). Los servidores deben enviar el "+OK" y el "-ERR" en may�sculas.

Las respuestas a ciertos comandos son multil�nea (una respuesta compuesta de varias l�neas). En estos casos, que se indican claramente m�s adelante, despu�s de enviar la primera l�nea de la respuesta y un CRLF, se env�a cualquier l�nea adicional, cada una terminada en un par CRLF. Cuando todas las l�neas de la respuesta han sido enviadas, se env�a una l�nea final, que consiste en un octeto de terminaci�n (en decimal 046,".") Y un par CRLF. Si alguna l�nea de la respuesta multil�nea comienza con el octeto de terminaci�n, se ponen bytes de relleno precedidos por el byte de terminaci�n en esa l�nea de la respuesta. De aqu� en adelante una respuesta multil�nea termina con los cinco bytes "CRLF.CRLF". Al examinar una respuesta multil�nea, el cliente comprueba si la l�nea comienza con el byte de terminaci�n. Si es as� y si siguen otros bytes a excepci�n del CRLF, el primer byte de la l�nea (el byte de terminaci�n) es ignorado. De este modo si el CRLF sigue inmediatamente al car�cter de terminaci�n, entonces la respuesta desde el servidor POP termina y la l�nea conteniendo "CRLF " no es considerada como parte de la respuesta multil�nea.

Una sesi�n POP3 progresa a trav�s de una serie de estados a lo largo de su vida. Una vez la conexi�n TCP ha sido abierta y el servidor de POP3 ha enviado el "saludo" (l�nea especial que se utiliza cuando se establece la conexi�n), la sesi�n entra en el estado de autorizaci�n (AUTHORIZATION). En este estado, el cliente debe identificarse al servidor de POP3. Una vez el cliente ha hecho esto satisfactoriamente, el servidor adquiere los recursos asociados al maildrop del cliente, y la sesi�n entra en el estado de transacci�n (TRANSACTION). En este estado, el cliente realiza una serie de solicitudes al servidor de POP3. Cuando el cliente ha emitido el comando de finalizaci�n (QUIT), la sesi�n entra en el estado de actualizaci�n (UPDATE). En este estado, el servidor de POP3 libera cualesquiera recursos adquiridos durante el estado de transici�n, "dice adi�s" y la conexi�n TCP se cierra.

Un servidor debe responder a comandos no reconocidos, no implementados, o sint�cticamente incorrectos con un indicador negativo de estado (respuesta negativa). Tambi�n debe responder con un indicador negativo de estado cuando la sesi�n se encuentra en un estado incorrecto. No hay un m�todo general para que el cliente distinga entre un servidor que no implementa un comando opcional y un servidor que no esta dispuesto o es incapaz de procesar el comando.

Un servidor de POP3 puede disponer de un temporizador o cron�metro de inactividad (autologout inactivity timer). Tal cron�metro debe ser de por lo menos 10 minutos de duraci�n. La recepci�n de cualquier comando desde el cliente durante este intervalo reinicia la cuenta de este cron�metro. Cuando el cron�metro llega a los diez minutos, la sesi�n no entra en el estado de actualizaci�n. Entonces, el servidor deber�a cerrar la conexi�n TCP sin eliminar ning�n mensaje y sin enviar ninguna respuesta al cliente.

USER nombre

PASS cadena

APOP nombre digest

AUTH mecanismo

TOP mensaje

UIDL [mensaje]

Este es un simple protocolo que deja al servidor y al cliente tener m�ltiples conversaciones sobre una TCP normal, esto como es evidente declara que el protocolo SCP necesita montarse sobre el SCP, Este protocolo esta dise�ado para ser simple de implementar.

El servicio principal de este protocolo es el control del dialogo entre el servidor y el cliente, administrando sus conversaciones y agilizadas en un alto porcentaje, este protocolo le permite a cualquiera de los dos (servidor cliente) establecer una sesi�n virtual sobre la normal.

La descripci�n de un formato de comunicaci�n en las cabeceras enviadas por la red es la siguiente:

El TCP/IP es un conjunto de protocolos de comunicaci�n, es decir de convenciones particulares, creadas para permitir la colaboraci�n y la partici�n de recursos entre m�s ordenadores conectados entre s� en la que est� definida como red o network. Internet es en absoluto la m�s grande entre todas las redes existentes, debido a que logra conectar entre s� ordenadores personales y redes de menor amplitud en todo el mundo. Sobre Internet, de hecho, puede usted encontrar en conexi�n los ordenadores de instituciones del gobierno, militares, universidades y empresas privadas. Lo que permite a m�quinas tan distintas por hardware y por prestaciones, comunicar entre s� de manera casi transparente, es el, TCP/IP, el cual constituye un tipo de 'lenguaje universal' comprendido y utilizado por todas las m�quinas que cooperan en red.

Vamos a empezar con algunas definiciones de base. El nombre m�s apropiado para indicar este conjunto de protocolos, es Internet protocol suite, es decir colecci�n de protocolos de Internet. El TCP y el IP son dos protocolos que pertenecen a esta colecci�n.

Puesto que �stos son tambi�n los protocolos m�s conocidos, ha entrado en el uso com�n llamar TCP/IP a toda la familia, aunque en algunas ocasiones una generalizaci�n parecida pueda resultar un error. Como quiera que se llame, el TCP/IP representa una familia de protocolos, proveen a la gesti�n de las funciones de bajo nivel, que son necesarias para la mayor�a de las aplicaciones. El TCP y el IP pertenecen a los protocolos de bajo nivel. Sobre esta base, se desarrollan otros protocolos que gestionan funciones particulares, como la transferencia de ficheros, el env�o del correo electr�nico, la conexi�n remota, el control de los usuarios que se han conectado a la red en un momento espec�fico, condividir impresoras y de programas aplicativos, y algo m�s.

Todo esto est� generalmente simplificado en un modelo cliente/servidor, en el cual el servidor se identifica con el ordenador que proporciona un servicio espec�fico, a trav�s del network, (por ejemplo el (sitio FTP de VOL FTP es un servidor de ficheros y de informaciones sobre c�mo utilizarlos de la manera mejor) y en el cual el t�rmino cliente se identifica con el ordenador que explota este servicio, aunque con la palabra cliente incluya tambi�n aquellos programas que uno utiliza para tener acceso a estos mismos servicios (por ejemplo el Tiber y el Netscape son dos clientes t�picos para tener acceso a las p�ginas del WWW).

El TCP/IP es un conjunto de protocolos 'a capas' o, si se prefiere, 'a niveles'.

Para entender qu� significa todo lo anterior pongamos un ejemplo sencillo. Imaginemos que se tiene que enviar correo a trav�s de Internet. Lo primero que se necesita es definir un protocolo espec�fico para el correo, o sea, un conjunto de reglas un�vocamente reconocidas por todos los ordenadores conectados en red.

Dicho protocolo tendr� la tarea de coger la carta que hay que enviar, a�adirle el emisor y el destinatario y enviarla a quien corresponda. Esto �ltimo es la tarea del protocolo espec�fico de gesti�n del correo, que podr�a ser comparado al de una persona a la que un amigo muy ocupado le deja una carta y ella se encarga de ponerla en el sobre, escribir los datos de expedici�n y echarla al correo.

Evidentemente, si s�lo existiese esta figura la carta se quedar�a eternamente en el buz�n sin que nadie se preocupase de hacerla llegar a su destino. Sin embargo, nuestro amigo muy ocupado tendr�a suerte ya que existe una camioneta del servicio de correos que dos veces al d�a vac�a el buz�n y transporta las cartas que all� encuentra a un lugar donde ser�n clasificadas y diferenciadas; all� su precios�sima carta ser� cuidada y mimada hasta que llegue al buz�n del destinatario.

Para continuar con el paralelismo del ejemplo, diremos que el TCP/IP representa el sistema de transporte de Internet. En particular, el TCP se preocupa de 'empaquetar' bien todos los datos que le son suministrados por los protocolos de nivel superior; es posible que los subdivida en m�s partes si resultasen demasiado largos para un solo env�o en red; asimismo recuerda lo que ha sido enviado, se acuerda de volver a enviarlo en el caso en que se hubiera perdido y controla que todo se realice de forma transparente para el usuario.

Ya que este tipo de operaciones es de uso general y es necesario tanto para enviar correo como para enviar ficheros u otras cosas, se ha pensado en hacer un protocolo propio, que pueda ser utilizado por muchos otros. Es precisamente por este motivo por lo que hemos definido protocolo de bajo nivel.

El TCP, sin embargo, no es el protocolo de nivel m�s bajo desde el momento en que �ste utiliza el IP para realizar determinadas acciones. De hecho, a pesar de que el TCP sea muy utilizado, existen protocolos que prefieren no usarlo y que para funcionar s�lo necesitan las funciones que puede ofrecer incluso el m�s humilde IP.

Este tipo de organizaci�n 'a capas' permite una gran eficiencia y un menor gasto de recursos.

Para terminar con un ejemplo, el env�o de un mensaje de correo electr�nico a trav�s de Internet utiliza un sistema compuesto por cuatro capas:

Un protocolo de alto nivel espec�fico para el correo 2.El protocolo TCP que es utilizado tambi�n por otros protocolos de alto nivel 3.El protocolo IP que se ocupa de la espec�fica tarea de tomar los paquetes y enviarles a su destino 4.El protocolo del hardware espec�fico, que se utiliza para la transmisi�n y la recepci�n de los datos

A este punto se nos aparece claro el motivo por el que el conjunto de los protocolos de Internet es llamado gen�ricamente TCP/IP. De hecho, estos son los protocolos m�s utilizados y de los que s�lo pueden prescindir muy pocos protocolos de un nivel m�s alto.

Antes de terminar esta exposici�n general sobre el funcionamiento del TCP/IP es necesario introducir el concepto de datagrama (datagram), que representa cada uno de los paquetes de informaciones que es enviado a trav�s de la red. Como ya hemos dicho antes, un conjunto de informaciones demasiado largo que es subdividido en paquetes m�s peque�os, precisamente llamados datagrama, que viajan individualmente en la red. Esto significa que si un fichero que se debe enviar es subdividido en 10 datagramas secuenciales, no est� dicho que el cuarto llegue antes que el s�ptimo, desde el momento en que �ste puede perderse o tomar un camino equivocado. Ser� una tarea de los diversos protocolos el hacer que dicho paquete sea enviado nuevamente y colocado en el correcto orden secuencial a su llegada a destinaci�n.

Y ahora, para evitar los ataques de los "puristas" diremos que a pesar de que los t�rminos datagrama y paquete son muy a menudo utilizados como sin�nimos, en realidad existe una diferencia. Mientras el datagrama es espec�fico del TCP/IP y representa la m�nima unidad l�gica utilizable por los diversos protocolos, el paquete es una entidad f�sica bien presente para quien administra una red de tipo Ethernet. En el caso, por lo dem�s muy frecuente, que en un paquete viaje un solo datagrama, la diferencia es s�lo te�rica pero existen tambi�n espec�ficas configuraciones hardware de red que utilizan paquetes de dimensi�n menor respecto a la del datagrama individual. Entonces sucede que un datagrama se descompone en m�s paquetes durante el env�o a la red espec�fica y que sea recompuesto a su llegada, de forma absolutamente transparente respecto al mismo datagrama que... 'no se da cuenta' de haber sido descompuesto y luego recompuesto. Es evidente c�mo en dicha situaci�n los t�rminos paquete y datagrama no coinciden. Es una buena medida, por tanto, acostumbrarse a utilizar el t�rmino datagrama cuando se habla del TCP/IP.

DeviceNet

DeviceNet es un enlace de comunicaciones de bajo costo para conectar dispositivos industriales como sensores inductivos, fotoel�ctrico, fines de carrera, pulsadores, lectores de c�digo de barra, indicadores luminosos, interfaces de operador, controladores de motores, etc, a una red, evitando costosos y complejos cableados.
La conectividad directa provee una mejor comunicaci�n entre los dispositivos, y un diagn�stico a nivel de dispositivo que ser�a imposible en el caso de interfaces entrada / salida cableadas. Por otra parte, permite un f�cil intercambio de productos, incluso de componentes similares provistos por diferentes fabricantes.

Los productos DeviceNet de Rockwell Automation incrementan la eficiencia y flexibilidad de su sistema de control, integrando esta red abierta con los controladores PLC�, SLC� t ControlLogix�, sensores fotoel�ctricos serie 9000 y sensores de proximidad 871TM, variadores de velocidad de corriente alterna y continua, y una gran variedad de dispositivos de entrada y salida modular y compactos, as� como interfaces de operador y otros productos de control. Adem�s se permite el acceso a otras arquitecturas basadas en productos de Rockwell Automation, como DH+, DH485

DeviceNet es una red abierta creada por Rockwell Automation en el a�o 1993. Las especificaciones y protocolo son abiertos, lo que significa que otros fabricantes no necesitan adquirir hardware, software o derechos legales para conectar dispositivos a un sistema. Rockwell Automation ha pasado la especificaci�n de DeviceNet a la Asociaci�n Abierta de Fabricantes de DeviceNet (ODVA, www.odva.org ), lo que ha derivado en la instalaci�n de m�s de medio mill�n de nodos, y la red de dispositivos que m�s r�pidamente ha crecido en el mundo.

MODBUS.

Este protocolo permite tanto el intercambio de datos entre el PLC y la estaci�n de supervisi�n, como la programaci�n y cambio de par�metros del PLC.

Modbus es un protocolo de comunicaciones abierto, dise�ado por Modicon para ser utilizado en controladores l�gicos programables (PLC). Omodbus se ha convertido en uno de los est�ndares m�s utilizados de la industria, ya que representa el m�todo m�s com�n para interconectar dispositivos electr�nicos industriales.

Contar con esta certificaci�n asegura que el dispositivo puede ser integrado f�cilmente en redes Modbus existentes y soporta los c�digos de funci�n m�s com�nes (1, 2, 3, 4, 5, 6, 15, 16, 23), indic� la empresa.

SLX200 permite enlaces seriales no aislados a velocidades de hasta 115.2Kbps y 10Mbps Ethernet, soportando la conexi�n de hasta 32 sistemas en el enlace de comunicaciones RS-485, ofreciendo adem�s la opci�n de utilizar tarjetas de comunicaciones Ethernet.

Los dispositivos ofrecen algunas caracter�sticas interesantes como una exactitud de �0.03%, linealidad de �0.005%, aislamiento de 1500Vrms y protecci�n de voltajes de entrada de 240VAC.

El sistema permite dos modos de escaneo: uno para monitoreo de se�ales de prop�sito general mostrando valores m�ximo, m�nimo y promedio en tiempo real y la otra utilizada para obtener datos con un tiempo recorrelaci�n entre muestras altamente preciso.

SLX200 ofrece tambi�n otras funciones, como configuraci�n de de los valores de las se�ales de salida, para asegurar que se encuentren a niveles seguros, y una actualizaci�n autom�tica de las se�ales de salida, que asegura que las se�ales permanezcan en los niveles en los que fueron configurados.

Este DAQ cuenta con 12 canales anal�gicos de entrada/salida, sin embargo, un m�dulo SLX200 puede operar hasta 60 canales diferenciales de anal�gicos y 128 canales digitales de E/S.

El sistema tambi�n integra convertidores anal�gico-digital y digital-anal�gico de 16bits. El ADC utiliza la t�cnica de aproximaciones sucesivas y ofrece realizar conversiones en un m�ximo de 60 canales en un tiempo de 15milisegundos, mientras que el DAC tiene un tiempo de 30 milisegundos.

ETHERNET.

Este tipo de tecnolog�a mas utilizada en redes de �rea local (LAN). LA RED Ethernet apareci� por primera vez en 1970 por parte de la empresa Xerox con una velocidad en ese entonces de 2.94 Mbps, velocidad muy alta para tal �poca. Con el paso del tiempo esta tecnolog�a ha sufrido varios cambios, de los cuales los mas significativos son la velocidad de transferencia y la longitud m�xima permitida entre los equipos.

Los cables DH-485

Est�n dise�ados para redes DH-485, mientras que los cables Longline est�n dise�ados para la interconexi�n de m�dulos de conexi�n Allen-Bradley. El cable DH-485 contiene una l�mina/trenzado de 1,5 pares con una l�nea de referencia com�n situada fuera de la l�mina, pero dentro del trenzado. Los cables de conexi�n directa tienen pares blindados individualmente para conseguir una protecci�n extra frente a diafon�as e interferencia de RF. Se dispone de versiones de cables en conducto (CIC) para ambos cables.

RS-232

conexi�n a traves del Puerto serie (Canal 0) de un controlador SLC 5/03 o 5/04 usando protocolo DH-485. La terminal con puerto RS-232 proporciona una conexion dedicada para datos de alta prioridad. Soporta la funcion de Pass-Through desde la red DH+ al PanelView a trav�s del Puerto 0 de un controlador SLC 5/04. as� tambi�n soporta conexi�n a controladores MicroLogix 1000 y 1500.