Retraso en variables Network Published Variables

[Fercho8]

Estoy trabajando con un cRIO 9075 en modo Scan Engine (es decir, sin usar la FPGA)

Tengo el Main.vi (que es el VI de la computadora) y el RT.vi que es el vi que esta en el cRIO.

Mi problema es, que la comunicación entre Main y RT usando las Network Published Variables de repente se ha puesto exageradamente lenta.

Por poner un ejemplo:

En el RT tengo 2 whiles el Timed Loop para todo lo referente al control de procesos y un while normal para la comunicación con Main.

Leo una entrada del cRIO; esa entrada la escribo en una Single Process Variable para poder trabajarla en el RT, ésta a su vez escribe en una Network Published variable para poder mandarla al Main.

En RT se ve inmediatamente el cambio de la entrada y se ve que escribe bien en la SPV y en la NPV (éstas 2 cambian su valor inmediatamente al cambiar la entrada). Pero sucede que en el Main, tarda a veces hasta 5 minutos en actualizar el valor de la NPV, por lo que el cambio de una entrada en el cRIO se ve reflejado muy tarde en la computadora.

Los tiempos de espera en los ciclos son los siguientes

Main. While principal = 10ms

RT.

Timed loop, esta sincronizado con el Scan Engine

While secundario. 100ms

¿A que se deberá?

[Alhern · Accepted solution]

Hola fercho8.

Para confirmar, el código en RT si esta corriendo cuando debería, y no hay retrasos en esa parte. El retraso se encuentra únicamente en la comunicación por red?

En este artículo aparecen varias posibles causas del retraso, así como la manera de solucionarlas:

http://digital.ni.com/public.nsf/allkb/6E37AC5435E44F9F862570D2005FEF25?OpenDocument

Además, te recomendaría instalar el System State Publisher desde MAX en el cRIO, y revisar en el Distributed System Manager para ver si no se esta saturando el procesador.

También vale la pena ver que cambios se hicieron al programa para que empezara a pasar esto, o probar un programa sencillo donde solo se haga comunicación con variables compartidas para ver si también se ve un retraso.

Espero esto te ayude.

[Fercho8]

Así es, es únicamente con la comunicación con el cRIO, (el puro programa no tiene retasos). Más aun.. el cRIO se conecta con cable ethernet a la computadora, pero tiene 2 módulos remotos que se conectan a través de unos switch inalámbricos, ya que llevar cable hasta esa locación es muy complicado.

Ya puse un ciclo para leer, luego un tiempo de espera y luego la parte de escritura (esto en un stack sequence), pero sigue siendo muy lento (al rededor de 3 a 5 segundos para recibir el valor de una variable).

Como puedo instalar o de donde descargo el System State Publisher desde MAX en el cRIO, esta en el disco que viene con el cRIO?, y donde encuentro Distributed System Manager?

[Alhern]

El System State Publisher simplemente lo agregas desde "Add or Remove Software", en el apartado de Software del cRIO desde MAX. Ya esta instalado en la computadora.

El Distributed System Manager lo puedes encontrar en Todos los programas: National Instruments: Distributed System Manager.

Es posible que la lentitud en la comunicación se deba al tiempo que toma leer los datos de los módulos remotos (cómo están conectados los módulos remotos? Por medio de un chasís esclavo?). En este caso podrías separar un poco más la adquisición, por un lado leer los datos de los módulos en el mismo chasís, y leer solamente los módulos remotos en otro ciclo.

[Fercho8]

Gracias!

Otra duda, tal vez éste sea la principal razón del retraso:

Las Network process variables, las uso unicamente para comunicarme entre el VI de la computadora y el cRIO, esas NPV estan conectadas a Single Process Variables para poder trabajar entre ciclos del VI del cRIO.

Pero esas SPV las uso repetidamente en varias secciones del programa, lo mismo sucede con las entradas y salidas fisicas, las leo o las activo en diferentes partes del programa.

No sé, si sería mejor, las entradas conectarlas a una variable local, para usar las variables en todo el código en vez de usar directamente las entradas, y usar de igual manera variables locales para activar una salida física (usando una or de todas las variables que pudieran activar esa salida) y así no activar salidas en todo el código, usar esas I/O únicamente en un lugar y que sean controladas por variables locales.

Lo mismo para las SPV, conectarlas a variables locales para no usar en todo el código SPV. ¿Crees que esto es causa de retraso?

¿Hay alguna forma de saber en donde se encuentran en el código todas las SPV, NPV o I/O? Algo parecido a como le haces con variables locales?, (clic derecho, Find variables), eso no lo encuentro con esas variables.

[Alhern]

Hola Fercho.

De hecho las SPV son un poco más eficientes y permiten más determinismo que las variables locales. Solamente asegúrate activar la opción de RTFIFO para asegurarnos que no se pierda el determinismo.

Para buscar donde tienes copias hay dos opciones, puedes ir al proyecto y seleccionar click derecho: Find Callers, o puedes en un VI en específico buscar el nombre de la variable con ctrl+f.

[Fercho8]

Ok, entonces no lo cambiaré, pero tampoco lo de las salidas y entradas? No hay problema que las llame varias veces a la misma en distintas partes del código?. Pero eso de buscar solo funciona con las varibales locales no?

Porque si le doy desde el proyecto Find Caller, solo me dice en que VI se encuentra, pero no todas las instancias de esta variable en el VI. (Por lo menos no con las shared o con las entradas y salidas físicas).

Probaré eso de Ctrl+F.

Gracias!

[Alhern]

Lo de las entradas y salidas puede llegar a ser un problema, ya que son recursos compartidos. En especial si las variables se están publicando por red. Sin embargo reemplazarlas por variables locales no mejorará el desempeño considerablemente.

Lo ideal sería que deshabilitaras la opción de "Network Published" en todas las variables de I/O, y solo pasaras los datos a tu ciclo de comunicación para enviar todo solo una vez desde un solo lugar.

Si los datos son demasiados también podrías considerar agrupar datos relacionados en un cluster para enviarlos en una sola variable y tener menos overhead por la comunicación. Esto también reduciría el tiempo que toma pasar los datos.

[Fercho8]

Ya instalé el Add on que mencionas, y pude ver el rendimiento.

Como te mencioné anteriormente tengo 2vis el Main (que es el de la computadora para interacción con el usuario) y el RT que es el de el control en el cRIO.

Noté que el CPU del cRIO se consume al 100% porque el delay del while principal del Main.vi era de 10ms, al cambiarlo a 100ms se redujo casi al 50%.

Sin embargo en ambos casos el retraso en las I/O sigue siendo muchísimo tiempo; cuando yo presiono un botón desde Main.vi para activar una salida a través de RT.vi el cambio se ve reflejado de 2 a 8 segundos después.

Ya intenté el trouble shooting que mencionan con las variables compartidas, pero no he tenido éxito. También he puesto un delay entre la lectura y la escritura, y cada vez lo he aumentado más, (ahorita ya tiene 300ms que ya se me hace demasiado)

¿Que otra cosa pudiera checar?

Adjunto mi vi RT.vi, quizá sirva de algo, no estoy seguro de estar manejando bien la comunicación entre SPV, NPV y I/O físicas, para manejarlas entre el ciclo de comunicación con la pantalla y el ciclo de control.

[Fercho8]

Encontré un ejemplo en el que no mandan llamar en ningún lado directamente las I/O físicas del chasis del cRIO, en vez de eso las leen o escriben a través de variables tipo I/O Alias con Aliasing. 

¿Que diferencia hay entre usar directamente las I/O del chasis a usar variables tipo I/O Alias direccionadas a estas entradas/salidas físicas? Esto podría ayudar con mi problema que hay en el retraso de las señales?