# Problemas con largo de cable UTP en red industrial



## Feldom (Feb 18, 2010)

Estimados amigos,

Tengo el siguiente problema. Instalamos una red ethernet usando protocolo MODBUS TCP/IP con los siguientes equipos conectados:

1 controlador ethernet de Wago modelo 750-842
http://www.wago.com/wagoweb/documentation/750/eng_dat/d084200e.pdf
2 controladores ethernet de Wago modelos 750-841
http://www.wago.com/wagoweb/documentation/750/eng_dat/d084100e.pdf
3 pantallas touch Hakko, modelos V706CD (Las pantallas Hakko incluyen el adpatador ethernet DU-01)
1 PC (Estación de trabajo)

Todos los equipos anteriores, están conectados a un switch d-link DES-1016D.

El objetivo es adquirir datos de proceso y almacenarlos en el PC con la ayuda de Kepserver y Visual Basic.

Sin embargo, el problema se presenta con el largo del cable. En un principio estuvimos usando un cable UTP categoria 5e. Cuando el cable no excede los 15 mts, anda todo perfecto, ya que las comunicaciones se hacen efectivas. Sin embargo, cuando el largo del cable excede los 30 mts, la comunicacion se pierde ya que al hacer ping (desde el PC) a los equipos, estos no responden. 

Luego, se cambio el cable existente por uno apantallado categoria 5e, pero sigue pasando lo mismo.

¿Cual puede ser el problema?

Nota: Tengo un probador de cable Rj-45 y cuando pruebo los cables, tanto cortos como largos, me anda todo bien.

Ojala puedan ayudarme.

Saludos a todos.


----------



## DOSMETROS (Feb 18, 2010)

Probaron poner a tierra las pantallas del cable ?


----------



## Feldom (Feb 18, 2010)

Muchas gracias DOSMETROS por tu ayuda. Probaré el poner a tierra la pantalla y te cuento como me fue. 

De todas formas, igual es raro que no comunique a 30 mts, ya que las pruebas las estuvimos haciendo en un lugar con nada de ruido que me pudiese interferir la comunicación. Además, el estandar señala que el largo maximo del cable puede ser de 100 mts y yo apenas estoy usando 30 mts.

Saludos!


----------



## elbrujo (Feb 18, 2010)

No puede ser hay algo raro.. postea la configuracion de todo. Router, pc's ip, gateway, dns. Podes tener problemas por encima de 100/150 metros.

La red esta certificada? El probador que tienes es de continuidad o de trafico? ancho de banda, etc..


----------



## DOSMETROS (Feb 18, 2010)

Te puede estar entrando ruido por la alimentación? Podés poner un osciloscopio ahí?

La PC tiene la tapa puesta?


----------



## Feldom (Feb 19, 2010)

*elbrujo*, así es la configuración de las direcciones:

PLC Wago 750-841: 192.168.1.12
PLC Wago 750-842: 192.168.1.14
PLC Wago 750-842: 192.168.1.16
Switch: No tiene IP
Hakko 1: 192.168.1.11
Hakko 2: 192.168.1.13
Hakko 3: 192.168.1.15
PC: 192.168.1.10

No se configuro dns ni gateway porque es una red cerrada. De todas formas la configuración de IP no creo que sea el problema, porque cuando hago pruebas con cable corto (2 ó 3 mts), la comunicación se me hace efectiva.

Sobre el cable de red, es certificado y el probador es sólo para medir conductividad de los cables.

*DOSMETROS*, probe la pantalla a tierra y nada.

Un dato interesante de las pruebas que hemos hecho, es que hicimos pruebas usando la red de la empresa en que trabajo y funciona todo ok. ¿Será un problema del switch?

Les agradezco mucho sus aportes, porque la verdad el problema es bastanta raro y poco usual. Incluso roza lo esotérico...jajajaja.

Saludos a todos!


----------



## elbrujo (Feb 19, 2010)

Cuando haces ping que te devuelve? paquetes perdidos? cuantos? cuando anda, cuantos ms (milisegundos) te reporta?

Cuando haces ping, de que puesto a que puesto haces? uno contra todos y viceversa? en todos los casos siempre se corta?

 Habria que ver si el switch tiene algun modo de auditoria, pareceria que si. Hay que entrar y ver el log a ver que dice al respecto.. tenes un pdf del switch?

El cable corto que pones es derecho o cruzado? el largo es derecho o cruzado?

Tenes algun sniffer para auditar la red?


----------



## Feldom (Feb 19, 2010)

- elbrujo, aqui los ping solicitados. Tengo los 6 equipos industriales conectados con cable UTP normal y corto. El PC esta conectado con un cable de 30 mts apantallado. Es importante señalar que no siempre me arroja estos mismos resultados...es bastante aleatorio.

- Los ping siempre los hago desde el PC hacia los equipos industriales. Cabe señalar que existen equipos que transmiten a 10 mbps y otros a 100 mbps. 

- Cuando ocupo cable corto en todas las conexiones hacia el switch d-link, todos los ping que realizo son exitosos.

- ¿Como se hace el modo de auditoria al switch?

- Todos los cables, tanto cortos como largos son derechos

- No tengo sniffer, ¿cual me recomiendas?

C:\>ping 192.168.1.11

Haciendo ping a 192.168.1.11 con 32 bytes de datos:

Respuesta desde 192.168.1.11: bytes=32 tiempo=2ms TTL=30
Tiempo de espera agotado para esta solicitud.
Respuesta desde 192.168.1.11: bytes=32 tiempo=2ms TTL=30
Respuesta desde 192.168.1.11: bytes=32 tiempo=1ms TTL=30

Estadísticas de ping para 192.168.1.11:
    Paquetes: enviados = 4, recibidos = 3, perdidos = 1
    (25% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
    Mínimo = 1ms, Máximo = 2ms, Media = 1ms

C:\>ping 192.168.1.12

Haciendo ping a 192.168.1.12 con 32 bytes de datos:

Respuesta desde 192.168.1.12: bytes=32 tiempo=2ms TTL=255
Respuesta desde 192.168.1.12: bytes=32 tiempo=2ms TTL=255
Respuesta desde 192.168.1.12: bytes=32 tiempo=1ms TTL=255
Respuesta desde 192.168.1.12: bytes=32 tiempo=2ms TTL=255

Estadísticas de ping para 192.168.1.12:
    Paquetes: enviados = 4, recibidos = 4, perdidos = 0
    (0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
    Mínimo = 1ms, Máximo = 2ms, Media = 1ms

C:\>ping 192.168.1.13

Haciendo ping a 192.168.1.13 con 32 bytes de datos:

Tiempo de espera agotado para esta solicitud.
Respuesta desde 192.168.1.13: bytes=32 tiempo=1ms TTL=30
Tiempo de espera agotado para esta solicitud.
Respuesta desde 192.168.1.13: bytes=32 tiempo=2ms TTL=30

Estadísticas de ping para 192.168.1.13:
    Paquetes: enviados = 4, recibidos = 2, perdidos = 2
    (50% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
    Mínimo = 1ms, Máximo = 2ms, Media = 1ms

C:\>ping 192.168.1.14

Haciendo ping a 192.168.1.14 con 32 bytes de datos:

Tiempo de espera agotado para esta solicitud.
Respuesta desde 192.168.1.14: bytes=32 tiempo=3ms TTL=255
Respuesta desde 192.168.1.14: bytes=32 tiempo=1ms TTL=255
Respuesta desde 192.168.1.14: bytes=32 tiempo=2ms TTL=255

Estadísticas de ping para 192.168.1.14:
    Paquetes: enviados = 4, recibidos = 3, perdidos = 1
    (25% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
    Mínimo = 1ms, Máximo = 3ms, Media = 2ms

C:\>ping 192.168.1.15

Haciendo ping a 192.168.1.15 con 32 bytes de datos:

Respuesta desde 192.168.1.15: bytes=32 tiempo=3ms TTL=30
Respuesta desde 192.168.1.15: bytes=32 tiempo=2ms TTL=30
Respuesta desde 192.168.1.15: bytes=32 tiempo=1ms TTL=30
Respuesta desde 192.168.1.15: bytes=32 tiempo=1ms TTL=30

Estadísticas de ping para 192.168.1.15:
    Paquetes: enviados = 4, recibidos = 4, perdidos = 0
    (0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
    Mínimo = 1ms, Máximo = 3ms, Media = 1ms

C:\>ping 192.168.1.16

Haciendo ping a 192.168.1.16 con 32 bytes de datos:

Respuesta desde 192.168.1.16: bytes=32 tiempo=1ms TTL=30
Respuesta desde 192.168.1.16: bytes=32 tiempo<1m TTL=30
Respuesta desde 192.168.1.16: bytes=32 tiempo<1m TTL=30
Respuesta desde 192.168.1.16: bytes=32 tiempo<1m TTL=30

Estadísticas de ping para 192.168.1.16:
    Paquetes: enviados = 4, recibidos = 4, perdidos = 0
    (0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
    Mínimo = 0ms, Máximo = 1ms, Media = 0ms

*Muchas Gracias por la ayuda!

Saludos!*


----------



## elbrujo (Feb 19, 2010)

Bueno estuve viendo el manual del switch y no es administrable..  vas a tener que auditar con algun soft. Yo uso linux como plataforma de trabajo y conozco solo sobre linux.  El sniffer se llama *wireshark* es facil de usar cuando lo tengas instalado te indico. Desde aca lo podes bajar para M$ http://www.wireshark.org/download.html

Tenes que habilitar una placa de red, la de la pc en modo promiscuo, asi captura todos los paquetes. Exporta el log y lo vemos.

Entiendo que el software esta sobre la pc, cada cuanto tiempo captura datos de los dispositivos? Cuando haces ping y no responde el software esta en ejecucion?

Cuando dices que lo probaron en la red de la empresa anda OK, tienen router ahi o switch?

El software tiene algun control sobre los plc y resto o es solo como instrumentacion/datalogger? lo hicieron uds?

Si la red esta certificada en 100megas no deberia tener problemas de cable. Lo unico que se me ocurre que haya mucho trafico innecesario dentro de la red lo que esta produciendo colisiones, como el switch tiene un mecanismo anticolision.. lo debe estar postergando en el tiempo.. ordendando el trafico.. habria que ver quien/es son los que estan mandando paquetes a la red y en que frecuencia...

Estas en Santiago?


----------



## Feldom (Feb 22, 2010)

La verdad es que la captura de datos la estamos realizando cada 100 ms, pero podriamos subirla a 1 segundo, no habría problema en eso. Cuando hago ping, el software no está en funcionamiento.

Soy un principiante en el tema linux, así que averiguaré el uso del sniffer que me mencionas.

El software no realiza ningun control sobre los equipos, sólo captura de datos.

En la empresa existe un switch y un router.

Me parece bastante interesante lo que mencionas sobre el tema de las colisiones. Una vez en terreno, probaremos disminuir la velocidad y ver que ocurre.

Estoy en santiago.

*Saludos!*


----------



## elbrujo (Feb 22, 2010)

Empieza por subir a 1 segundo, que estan midiendo? Entiendo que el software esta interrogando a cada dispositivo, es correcto? El link que te mande es de windows! es interesante ver lo que va por el cable.. 

Si el soft es quien interroga no deberia haber colisiones en la medida que lo haga por su ID del MODBUS.

Por el 2001 estuve radicado en Santiago un año 1/2  trabajando para una empresa de tecnologia, despues un año mas en Osorno mas cerca de Bariloche..


----------



## superpower (Feb 22, 2010)

Feldom:Tube exactamente el mismo problema .y con menos metros de cable.
cambie el cable utp por uno STP y solucionamos el problema.
Despues de un breve periodo de vuelta con lo mismo.
solución: tiramos al tacho de basura al dlink (al del proveedor) y lo cambiamos por otra marca.
De esto hace unos 5 años y todabia funciona.
Este comentario solo es a modo de darte una idea ,no afirmo que tu problema sea el switch.
Aparte;, colisiones es raro, porque justamente los switch estan diseñados para evitar las mismas ,no como en el caso de los viejos Hub.
Suerte y mucha paciencia,que a veces estas cosas nos ponen de cabeza.
Saludos


----------



## elbrujo (Feb 22, 2010)

El switch controla las coliciones haciendo drop.. para el caso es lo mismo.. no las evita las controla.. 

O bien el tiempo de lectura es demasiado rapido teniendo en cuenta que variables estan leyendo, y que las mismas no esten cambiando tan rapido.. se pueden estirar a 1 segundo. 

Tambien hay que conocer el flujo de datos de donde a donde estan yendo y con que frecuencia a ver si es un tema de saturacion de la red. Aparentenmente hay dos sentidos de flujo.


----------



## Feldom (Feb 22, 2010)

Espero dentro de esta semana poner a prueba al sistema. Aplicaré todas las sugerencias realizadas en este tema del foro y por medio de aqui mismo les contaré los resultados

Gracias!


----------



## superpower (Feb 22, 2010)

elbrujo:
Tenés razón me expresé mal.
Lo extraño del caso según Feldom que solo tiene problemas cuando utiliza cable de mayor longitud.
Tambien como decis vos, puede ser un tema de saturacion de la red,pero si en pocos metros le funcionas bien,es raro verdad?.
por eso mi comentario anterior.
Un gusto.
Saludos.


----------



## elbrujo (Feb 22, 2010)

Todo bien superpower, en terminos generales es como vos decis. El hub hace broadcast constantemente cuando recibe un paquete y anda prenguntando en la red algo como "de quien es esto" hasta que alguno le responde y se lo entrega. Imaginate el trafico que hay solo de broadcast.. es alli donde se producen las coliciones.

El switch una evolucion del hub graba las MAC de cada host de la red y al menos distribuye por mac. Ahora porque digo que para este caso es lo mismo?

Cada vez que manda algo que no es recibido entero o fraccionado como nadie se lo recibe termina tirandolo.. eso no quita el trafico de la red, solo evita la colision.. a que costo? y tirando paquetes..

Recien el router por su tecnologia y concepto al trabajar en otra capa del modelo OSI se maneja con los IP de las maquinas. Entonces ahora tengo un paquete que se para quien va.. no va haber colisiones y tampoco lo va a desechar en la medida que el destinatario exista y este online.

Si bien quizas cambiando el switch por uno mejor o con un router se solucione el problema, es bueno (para mi) saber cual es/era el problema asi la proxima vez te sirve el tiempo dedicado en encontrar la falla.

Si el cable no es, porque la red esta certificada, entonces te queda el switch o el trafico. Ya pedir cada 100ms un dato, a no ser que sea una central nuclear.. para que queres tanta velocidad? si es que puede cambiar, todo bien.. entonces hay que poner un hardware que se banque esa demanda.. no se si es el caso..

Por otro lado al haber PLC en el control de procesos como me imagino, la pc esta auditando lo que pasa en alguna planta.

Los PLC cada cuanto actualizan los datos? y las pantallas cada cuanto? para mi ahi hay un flujo de datos y por otro lado la pc contra los PLC pidiendole info..

Si todo esto ocurre muy rapido.. es una bolsa de gatos.. y tenes que tener hard para que se banque esa exigencia. Quizas con mover a 1 seg que es bastante rapido el refresco de datos se soluciona..

Si con pocos metros anda OK y con 30metros que es el 33% de lo que soporta el hard se cae es que algo pasa dentro... que no se banca 30mts y uno motivo puede ser mucho trafico.. con el sniffer se analiza que es lo que esa pasando desde donde a donde cada cuanto? y con esa info se resolvera..

Si cambias el cable estas mejorando la calidad de un mismo ancho de banda, es solamente un eslabon de la cadena..

Esperemos que el colega haga las pruebas y sepamos por donde pasaba la cosa..


----------



## Feldom (Feb 25, 2010)

Estimados colegas,

finalmente realicé las pruebas en planta y los resultados fueron los siguientes:

- 2 de los 3 PLCs funcionaron OK. El que no comunica lo hace porque esta canalizado (por altura) junto a los cables de fuerza (principalmente alimentación de motores) y sin ningun tipo de protección. Las otras conexiones se canalizaron por medio de un flexible recubierto de aluminio. Para comprobar que era problema de interferencia, tomé el cable STP y lo conecté directo desde la cabina de trabajo en donde está el PC hasta el tablero en donde está el PLC (30 mts) y todo funcionó OK. Por lo tanto, fue un tema del apantallado.

- Las tres pantallas hakko conectadas me lanzan problemas de comunicación (Error de Formato). Cuando les mando un ping, ninguna contesta. En este caso, tambien conecté un cable de largo no mas alla de 10 mts (UTP) entre el PC y una pantalla Hakko (todo pasando por el switch). Algunos Ping me respondían. Lo interesante fue el mensaje de error que me lanzo la pantalla Hakko:
*




*

Leeré en los manuales la causa del problema y le cuentos como me fue.

- Sobre las pruebas que realicé al momento de crear este tema en el foro, desconozco los problemas de comunicación que se presentaron cuando hice las pruebas en mi empresa. Pero al final, lo que interesaba mas fue el funcionamiento en la misma planta.

- Todas las conexiones en terreno se realizaron con cable UTP, así que en los casos que sea necesario, se usará STP.

En resumen, fueron dos los problemas que se presentaron en terreno:

El primero, fue la canalización de unos de los cables conectado al PLC que estaba junto a los cables de fuerza.

El segundo, fue el mensaje de error de formato que me lanzó la pantalla Hakko conectada.

El primero, se soluciona cambiando el UTP por STP. También se incluirá un felxible de protección.

Para el segundo problema, investigaré y estaré atento a cualquier apoyo que puedan darme.

*Saludos a todos!*


----------



## elbrujo (Feb 25, 2010)

Subiste  a 1 seg?


----------



## superpower (Feb 25, 2010)

Feldom:Me alegro que estés haciendo progresos.
Probablemente tengas resultado positivo si blindas el cableado de las pantallas.
Probaste con la sugerencia  de tener un refresco de 1seg.?
El error de comunicacion probablemente se deba a que perdes datos,no por mala conexion ,y en mi opinión,
se puede dar como te ha ocurrido, y solucionando el tema con cables apantallados.
El otro,y es para tener muy en cuenta , la velocidad de refresco que estas utilizando y 
muy bien explicado por el amigo elbrujo.
exitos.¡

Saludos


----------



## Feldom (Feb 25, 2010)

Muchas gracias por su interes en el tema. La velocidad de captura de datos no la reduje por el momento ya que me estaba transmitiendo bien los datos desde los PLCs al PC a través del HMI.

El problema de las pantallas Hakko no creo que se deba a altas velocidad de transmision ya que para el cable pasado en la planta, los ping no daban resultados y para el cable que pase directo desde la caseta de trabajo a la pantalla, me respondía solo algunos ping. Incluso, la imagen que adjunte se presentó cuando conecte al hakko con el PC directamente (obviamente pasando por el switch).

Les agradezco mucho su atención

Saludos!


----------



## elbrujo (Feb 25, 2010)

Los mensajes del hard que digan lo que digan.. sino tenes respuesta con un ping *no tenes conectividad.. *En lo particular me gustaria que pongas el sniffer para analizar el trafico y ver donde esta el moño, lo mismo en subir a 1 seg la adquisicion de datos.

Los procesos los controlan los PLC, no? entonces se puede retardar la adquisicion en la PC. Hay que tener en cuenta que un rate de refresco demasiado rapido innecesario esta llenado la red de requerimientos, que a la hora de que los PLC quieran actuar sobre la misma red no tengan la ventana de tiempo. Y ni hablar si hay alguna alarma!.. en que momento tienen la red libre?

El soft del PLC y el soft del PC deben tener que trabajar con las novedades. Si bien puedo estar leyendo en tiempo real una variable o un grupo de ellas, si lo que lei hace 1 seg o 10ms no cambio, para que lo voy a informar? (Es indipendiente a las acciones que tengan que hacer sobre el control de los procesos)

De ese modo tengo una ventana de tiempo para que la red este libre. 

Bueno esperamos ver como sigue el cuento..


----------



## Feldom (Mar 21, 2010)

Estimados colegas,

Finalmente llegué a la solución del problema. La solución resultó ser bastante particular:

No estaban bien ajustados los conectores RJ-45 al cable UTP. 

Limpie la prensa, ya que tenía pequeñas suciedades y rehice los cables. Todo funcionó perfectamente esta vez. Lo raro igual, es que a pesar que los conectores estuvieran mal hechos, el tester de conductividad de RJ-45 me marcaba estado OK en todos los pines. Aún desconozco porque ocurría esto. Sin embargo, logré gracias a la ayuda brindada por todos dar solución al tema.

Muchas gracias nuevamente a todos por toda la ayuda brindada.

Cordiales Saludos!


----------



## elbrujo (Mar 21, 2010)

Me alegro por terminar el hilo y compartir el exito. Me llama la atencion de mi post #4 donde te pregunto si esta certificada la red, me dijiste que si. En una certificacion de red no es simplemente la prueba de conductividad...


----------



## superpower (Mar 21, 2010)

Muy bien¡¡¡
Lo importante que encontraste el problema,para la próxima ya sabes.

Saludos.


----------



## Feldom (Mar 21, 2010)

ou!...mis disculpas por mi ignorancia elbrujo, la verdad es que pensaba que una red certificada tenía que ver con la conductivdad y el tipo de cable usado. 

Saludos a todos!


----------



## elbrujo (Mar 22, 2010)

Todo bien Feldom, certificar una red te lo hace la empresa que instala la misma, a diferencia de la red que puede hacer cualquiera de nosotros y que no cuente con la instrumentacion para certificar la red. Con las pruebas que realizan y certifican se descarta los problemas que tenias. 

Entonces, en el arbol de logica de reparacion al hacer esa pregunta, yo descarte cables y conectores abocandome al switch y al programa de adquisicion de datos. Simplemente hubiesemos terminado antes.


----------

