Application using VI Server suddenly crashes. Why is it ?

[Giovani]

Hi everyone !

I´m developing an application which makes extensive use ov VI Server. I´m going to give a short explanation of it before going ahead.

This application is supposed to run, simultaneously, on three different PCs, namely, ESTACAO_A, ESTACAO_B and ESTACAO_C, which share an Ethernet network. One feature of it is that it has a master / client architecture which means that, when one of the named PCs is the master, the others are the slaves. Anytime the user operating a slave PC can require command from that operating the master PC and, if this user acquiesces it, it becomes the new master.

This application communicates with an PLC using LabVIEW DSC and the master / client architecture was necessary because the application must run on three diferent computers, as said before, and each one of the slaves must monitor the state of the process under surveillance. That´s when VI Server gets in ! I found it was easier to implement this architecture using it than if I decided to use the TCP/IP VIs. The problem is that when I run the application on the PCs ESTACAO_A and ESTACAO_B only, ESTACAO_A and ESTACAO_C only and on the PCs ESTACAO_B and ESTACAO_C it works quite well but, when it is executed on the three PCs, and the user of ESTACAO_B requires to become the master, sometimes the application will crash on ESTACAO_B, and that will make the application crash on the other two PCs, since they won´t be able to communicate with the PC which was supposed to become the new master, in this case, ESTACAO_B. For the sake of information I tell you that when I ping the other machines on ESTACAO_B it takes a longer time to respond than that taken when I ping the other machines on ESTACAO_A and ESTACAO_C. I´m beginning to think it has something to do with it.

Any help will be deeply appreciated.

[Philip_Courtois]

Please provide your VIs to show the implementation of the Master/Slave configuration.

[Giovani]

Thanks for the interest in helping me solve my problem, Philip !

Sorry for the delay but here is the library file containing the VIs used to implement the MASTER / SLAVE architecture I've talked about. Also, I decided that it would be a great help if I provided you with the additional information :


Below follows a short explanation of the most important VIs found on the attached .llb file.

PROTOTIPO_TESTE_PEDINDO.vi : it´s the main VI and implements a state machine architecture to handle the required features of the application.

The state machine is composed of the following states :

"Tenta ser MESTRE" : the PC in question tries to become the MASTER station.

"Envia comandos para o PLC" : in this state the application sends and receives data from the PLC and, when necessary, exhibits a window when another station has required to become the new MASTER, asking for the acquiescence of the user currently operating the actual MASTER station.

"Leitura de dados do MESTRE" : here the station first tries to identify which one of the stations - that is, ESTACAO_A, ESTACAO_B, ESTACAO_C and ESTACAO_D - is the actual MASTER. In case that there´s a MASTER, it´ll read data from the MASTER station through some VI Server subVIs I´ve created. Also, it´ll send a cluster consisting of a string specifying the current station address and a boolean value indicating that it has required command of the system.

"Fim da supervisão" : This is the last state before the aplication ends.

Escreve_Serial.vi : Sends a command to a switch connected to a serial port of the current station to swith to the port connected to it.

COM_PLC.vi : Initializes the Tag Engine, so that the Lookout driver can be loade to allow data exchange with the PLC.

ATIVA_DESATIVA.vi : Disables or enables the controls of the front panel, depending of the state of execution of the station in question, that is, SLAVE or MASTER.

CONTROLE_DA_VI.vi : This subVI sends a command to run another VI or to change the value of a boolean control named FIM to true, both commands are sent through VI Server.

CRIA_MENSAGEM.vi and MENSAGEM.vi : The first one creates a message telling which one of the currently SLAVE stations want to be the new MASTER and the last one shows it on the screen.

IDENTIFICA_MESTRE.vi : Identifies which station is the actual MASTER; if there´s a MASTER, it´s output will be a string composed of its address, if not it´s output will be a NIL string.

LEITURA.vi : Through the VI Server, this VI reads the values of controls and indicators of the MASTER station and assigns them to their correspondents on the SLAVE station by means of controls and indicators references.

PEDIDO_DE_COMANDO.vi : Sends a data cluster consisting of a string specifying which station required command of the system and a boolean value of true to the specified station.

[Philip_Courtois]

I am surprised to see that you are not passing error clusters between the SubVIs or even using an Error Handler to show the errors. In most cases you choose "No Dialog" for the Error Handler, so you will never see if an error occurs.

I will strongly suggest you to implement the error handling or at least enable the error dialogs before proceeding the troubleshooting. It will most likely tell us where the error/crash is occurring.

[Giovani]

Thanks a lot, Phil

I´ll implement your suggestion and do some tests. After that, I´ll post a message to tel you what happened.


Thanks again,

Giovani Marcelino Nesi

[Giovani]

Phil,

I could not implement your suggestion because, if I did, errors would be generated through all the application execution. That´s because, as I said, in some subVIs I use VI Server and, if I did as you recommended me, when said subVI executed errors would appear because one of its inputs would be the IPs of all the stations and not necessarily the application is running or opened in all of them.

I decided to try another thing. I realized that all stations had the same port specified to be used by the VI Server and that, instead of the MASTER station send the data to the SLAVE stations, they were reading it from the MASTER station ... on the same port ! So, I configured a different port - through the menu Options > VI Server : Configuration - for every station on the system - in this case, port 3363 for ESTACAO_A, port 3364 for ESTACAO_B and port 3365 for ESTACAO_C - and modified the program so that the MASTER would send tha data to the slave stations.

The outcome of the done alterations is that the application running on all three stations took a surprisingly longer time to crash but, eventually, it would crash anyway. Before them after a few changes of which station operated as MASTER the crash ocurred.

Yesterday I decided to let the application running on all stations during a longer time - from 17:00 to 08:00 - to see which alterations happened on the permormance of the stations in terms of memory and CPU usage. So, before starting them I annotated the value of the parameters CPU usage and Memory Usage given by Windows task manager. The values of the said parameters, both before starting the application execution in all stations and when I arrived the next day are given bellow :

ESTACAO_A : BEFORE EXECUTION CPU USAGE 4%
MEMORY USAGE 138388 K

AFTER I ARRIVED CPU USAGE 86%
MEMORY USAGE 169678 K

ESTACAO_B : BEFORE EXECUTION CPU USAGE 1%
MEMORY USAGE 107536 K

AFTER I ARRIVED CPU USAGE 57%
MEMORY USAGE 158832 K

ESTACAO_B : BEFORE EXECUTION CPU USAGE 1%
MEMORY USAGE 138296 K

AFTER I ARRIVED CPU USAGE 57%
MEMORY USAGE 202564 K



Analysing the above I think the the problem has something to do with the way LabVIEW is managing memory. I decide to do two tests, first I´ll put the Request Deallocation.vi inside every subVI of my application and, if it doesn´t work, I´ll load each one of them dinamically using the VI Server, thus forcing LabVIEW to release memory. Do you think my supposition is correct ?

[Giovani]

I did the tests and decided to let the application run on all three stations for a longer time, i.e, from 17: 00 pm to 08:00 am. When I arrived the net day I founf that LabVIEW was closed in ESTACAO_B

[Giovani]

Sorry guys but I accidentaly pressed the wrong button 🙂

The explanation is as follows :

I did the tests and decided to let the application run on all three stations for a longer time, i.e, from 17: 00 pm to 08:00 am. When I arrived the next day I found that LabVIEW was closed on ESTACAO_B and a window showed telling that a fatal error ocurred and LabVIEW had to be restarted. The information concerning the error is given below :

Fatal Internal Error : "memory.cpp", lINHA 593
LabVIEW version 7.0
You will lose any unsaved work. For assistance in resolving this problem, please relaunch LabVIEW, or contact National Instruments.

Also, an error logfile was generated in the directory C:\Documents and Settings\Administrator\My Documents\LabVIEW Data\ lvfailurelog\lvlog12-28-04-10-32-34.txt. The file appears below :

####
#Date: Mon, Dec 27, 2004 3:11:01 PM
#OSName: Windows NT
#OSVers: 5.0
#AppName: LabVIEW
#Version: 7.0
#AppKind: FDS



D:\lvworm\src\mgsource\memory.cpp(593) : DAbort:
$Id: //labview/branches/Wormhole/dev/mgsource/memory.cpp#45 $
0x00B3341D - LabVIEW + 0
0x005031E7 - LabVIEW + 0
0x00502FA6 - LabVIEW + 0
0x007B7F47 - LabVIEW + 0
0x009BF5FB - LabVIEW + 0
0x009BF3E4 - LabVIEW + 0
0x009BEBA3 - LabVIEW + 0
0x007882C6 - LabVIEW + 0
0x00771358 - LabVIEW + 0
0x00771053 - LabVIEW + 0
0x00769F97 - LabVIEW + 0
0x0076C82E - LabVIEW + 0
0x00787E41 - LabVIEW + 0
0x00771358 - LabVIEW + 0
0x00771009 - LabVIEW + 0

Can anyone help me find out what can be causing the ocurrence of this error ? Any help will be deeply appreciated.

[Giovani]

After carefully analysing my application I think I found what was causing the problem I´ve encountered so far. It has something to do with not closing previously opened references in some of my subVIs; after I closed each one of those which remained opened in my subVIs, I decided to let the application running until today in the morning so that I could see if everything remained as it should be, and, to my satisfaction, I found it remained ... OK ! The CPU Usage remained at low levels and Memory Usage also remained constant!

So to everyone of you interested in obtaining good information reading this message do no forget to close, I repeat, to close, every reference you open on your VIs, otherwise, you´ll find your application clashing because of memory leakage problems.

See you all next message !!!