LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

RT targets communication problems

Hello.
We have been experiencing communication problems with our RT PXIs and cRIOs and we need expert support here.

We have a continuous mechanical monitoring application that was first developed for PXI, but last year we moved it to cRIO.
We have this application deployed on three remote sites, for different customers.
The application is designed to work as a standalone on each target, but it also has the capability to send (or "serve") data permanently through a wireless network to a central server on each site, where it is permanently stored.
The permanent networking capability has not been intensively used by our costumers until several months ago. Recently, each of them has set up their permanent wireless networks to take advantage of this capability.

Now, we have been receiving reports from these different costumers about eventual communication problems with the targets (PXIs and cRIOs).

We have detected two kind of symptoms:
1. The target does not respond to ping and FTP service is not availiable.
2. The target does respond to ping but FTP service is not availiable.

Note that in all cases if you go and reset the target, ping and FTP go normal again.

Our impression is that these symptoms could even respond to different phenomena, but we really don't know that.

Now, I will summarize these deployed targets:

Client/site 1:
1.1) PXI-100: PXI running LVRT 8.5.1.
Sometimes FTP goes unavailiable. Sometimes "ping" is not availiable, but we are not quite sure that it's not a wireless network problem.

Client/site 2:
2.1) cRIO-2010: CompactRIO running LVRT 8.5.1.
Sometimes FTP goes unavailiable.

Client/site 3:
3.1) PXI-03: PXI running LVRT 7.1.1.
3.2) PXI-05: PXI running LVRT 7.1.1.
3.3) PXI-07: PXI running LVRT 7.1.1.
3.4) cRIO-06: CompactRIO running LVRT 8.5.1.
PXIs sometimes go completely unavailiable, sometimes only FTP. cRIO-06 is not yet on the network.


Now I will describe some tests that has been made by our costumer on site 2 and by us on site 3:

Client/site 2, cRIO-2010. On his own words:
"After the MAX software reboot last night the cRIO ftp did not come back.  I reset the unit this morning by pressing the reset button on the cRio.
Here is a short description of what I have noted:
   1. After a software reboot using MAX from the server on the plant LAN the cRio can be pinged but MAX cannot connect, FTP is dead,  User1 led blinking (RT application running).
   2. Before pressing the reset button I connected my laptop to the cRio with a crossover cable, IP address, subnet and gateway of laptop changed to the same range as cRio, MAX cannot connect, FTP dead but I can ping the cRio.
   3. Pressed reset button while laptop connected via crossover. After reboot MAX can connect, FTP works. LED status the same as before the reboot.
   4. Laptop still connected directly to cRio. Used MAX to software reboot. After reboot MAX can connect, FTP works. LED status the same as before.
   5. Reboot cRIO using MAX from the server on the plant LAN. Ping OK but FTP dead, MAX cannot connect.
   6. Reboot cRio while it is connected to the LAN with the reset button. MAX can connect, FTP works - normal.
It seems like there is something that stops initial FTP activation when the reboot is done via the network."

Client/site 3, PXI-03:
1. Ping ok from server, FTP dead.
2. Connected by wire to local switch, ping ok, no FTP.
3. Connected directly with crossover cable, ping ok, no FTP.
4. RT application seems to be running ok.
5. Reset by pushbutton.
6. Application starts again, ping and FTP ok.

Client/site 3, PXI-05:
1. No ping nor FTP from server.
2. Connected directly with crossover cable, no ping, no FTP.
3. Connected monitor to PXI. Strange color characters blinking (see attached image).
4. Reset by pushbutton.
5. Application starts again, ping and FTP ok. Log files show that RT application was not running.

Client/site 3, PXI-07:
1. Running ok. Ping and FTP ok from server.

After tests on three PXIs of Client/site 3, they were updated to LVRT 8.5.1 and updated drivers. We will see how will they run now. Note that the "CPU load" indicator on the monitor shows always under 20%, 8% typical.

At the moment we had no opportunity to do tests on Client/site 1.

I have attached MAX reports for the tested targets.



Thanks for your help.


Daniel R.
Download All
0 Kudos
Message 1 of 2
(2,817 Views)
Hola Daniel Disculpa por la mala comunicación que tuvimos en el teléfono. He investigado un poco sobre tu problema y al parecer pueden ser varias cosas, aquí te las expongo para k hagamos las pruebas pertinentes: 1. Puede tratarse de un bug presente en versiones posteriores de LabVIEW y del driver de cRIO, este bug se arregla actualizando a la versión de LabVIEW 8.5.1 (con la que ya cuentas), pero también en la versión del controlador a NI RIO 2.4, aquí te anexo la liga: http://joule.ni.com/nidu/cds/view/p/id/993/lang/es Esto también se debe actualizar en el controlador. 2. Es posible que si ya está actualizado a estas versiones sea un problema de memory leak en la aplicación. Esto es, en ocasione el ciclo de tiempo crítico ocupa demasiados recursos, y se considera que la comunicación TCP/IP no es crítica por lo que se pierde la comunicación sin explicación aparente. Sería cosa de revisar el código con el Execution Trace Toolkit (si se cuenta con el) o con el System Manager para corroborar que las cargas de las tareas estén balanceadas. 3. Otro punto que podemos realizar es que si la red que tienes implementada utiliza multicast para mandar los mensajes por lo que puede estar saturando la red. Lo que se puede hacer es poner el switch en su propia VLAN para eliminar el tráfico extra en la red. Este también ah resultado ser causa de problemas similares Avísame por favor que resultados te dan estas 3 alternativas que te presento, y cualquier cosa que continúe el problema no dudes en contactarnos de nuevo. Saludos
Carlos Pazos

Senior Product Marketing Manager

National Instruments
0 Kudos
Message 2 of 2
(2,769 Views)