Tenemos una aplicación de visual basic basada en la aplicacion prueba 2 de la nota de aplicación AN001
La cuestión es que nos genera muchos problemas de conectividad...
¿Qué clase problemas estás teniendo?.
¿Perdida de datos? ¿Errores de recepción? ¿Cuelgues de la aplicación?.
...por otra parte hemos estado visualizando los paquetes de datos en la app de C# llamada "PawnUdpRx" en la cual no tenemos problemas de comunicación.
La principal diferencia que veo entre ambas aplicaciones (de forma superficial), es que "
PawnUdpRx" utiliza un
BackgroundWorker para esperar los datos provenientes del PLC.
Un
BackgroundWorker corre una operación o tarea en un hilo (thread) diferente al programa principal. Es decir, en paralelo a la ejecución del programa. Esto permite que el programa principal pueda responder a otros controles sin que se "congele" mientras hace una operación en paralelo.
En tu caso, veo que utilizas un timer que llamás cada determinado tiempo . Esto no es muy práctico, porque tu programa se "congela" y no responde a otros comandos mientras espera la recepción de un dato. Así mismo, cuando llega un dato, tu programa lo sabrá cuando el timer llame a la función para leerlos.
En cambio con el
BackgroundWorker corrés la recepción en un hilo diferente en paralelo a la ejecución principal, como en "
PawnUdpRx".
Te dejo unos links al uso del
BackgroundWorker en VB.Net:
https://codigoscript.com/2015/08/21/vb-net-tareas-asincronas-con-backgroundworker/https://www.dotnetperls.com/backgroundworker-vbnethttps://msdn.microsoft.com/es-es/library/system.componentmodel.backgroundworker(VS.95).aspxEsta puede ser unas de las causas, ya que no tengo indicio de otro problema según me comentás.
La pregunta es si tendras desarrollada alguna aplicación en visual basic pero que reciba los paquetes de datos como la del ejemplo "PawnUdpRx" ya que en esta una vez activado el botón escuchar temuestra cualquier cantidad de datos a diferencia de la de Prueba 2.
No, lo tengo implementado en VB.Net, ya que es un lenguaje que no utilizo. Sin embargo, con los links que te pasé y mirando un poco el código de
PawnUdpRx no tendrás problema en copiar la recepción con el
BackgroundWorker.
Otros puntos a tener en cuenta:
Como
UDP es un protocolo "sin conexión", es decir, a diferencia del protocolo
TCP, no hay un método de handshake y comprobación exhaustiva de errores, se recomienda evitar cableados o redes cargados con muchos computadores o dispositivos con gran actividad, o cableados que pasen por muchos routers intermedios que puedan hacer perder algún paquete. Redes Wi-Fi para este protocolo pueden ser problemáticas si hay poca señal o muchos routers intermedios. No sé si es el caso, pero de serlo, ver la posibilidad de lograr una conexión más directa con el PLC, como un cable independiente de ser posible. Si esto mejora o viene por este lado el problema, seria un indicio, en ese caso, debería evaluarse utilizar el protocolo
TCP sí no se puede colocar un cable directo.
Saludos
