VISA Waveform GUI Crashes after a period of time

[LabviewNovice89]

Hey everyone,

SUMMARY:

I'm working on a project through my university which has us reading data from an eZ430 USB drive.  The eZ430 is connected to a wireless receiver (a board using an MSP430) which is receiving data from a sensing node (also a MSP430 based board).

We have developed a .vi that displays our data on two waveform charts - one for the temperature data, and one for moisture data we are gathering from the sensing node.

The GUI works fine for a random period of time then it gets hung up.  This hang up can occur within minutes, or sometimes even within seconds of running the .vi

Sometimes the hangup returns an error and sometimes LabVIEW goes into (Not Responding).  I'm currently in the process of trying to reproduce the error popup so i can supply the error code - i'll add that to this post as soon as it happens.

DETAILS:

Our transmitter sends our data in a packet that contains a numerical value and a header - either A or B.  A procedes our temperature value whereas B is the header for our moisture value.  The string is then terminated by '\r\n'.  The numerical values range from 0 to 4096.  A series of packets in hyperterminal would be as follows:

A1034

B901

A1040

B895

...

We're assuming the byte count is 7 - (one for A) + (one each number) x (4 numbers) + (one for \n) + (one for \r)

The .vi attempts to pull the A or B from the string using a string split function, and then inputs the letter A or B into a case structure.  This case structure decides which data is being input based on the A or B input byte that is pulled from the string.  The numerical value that is passed into the case structure is then output to our waveform chart accordingly to which ever case is determined.

We also had to include a third case, case C to be assigned as a default case to prevent any null readings from being mixed in with our actual data.

WHAT WE'VE TRIED:

So far we've tried various things:

We've included/enabled a check for the termination character ('\n' = 0x0A) in the visa setup block.  We've also tried setting this character to ('\r' = 0x0D).  With no luck, we've tried the other obvious option of leaving the termination character disabled...  In each case we re programmed our transmitting node to have ONLY the respective termination char (or none) and adjusted our byte count accordingly.

I understand that our case may be situational and hard to debug without our actual transmitting and receiving nodes, but i was wondering if there may be something obvious jumping out at more trained eyes.

Any advice is appreciated!

[Taki1999 · Accepted solution]

Hmm. . .

Why are you closing your VISA reference after each read?

You should keep it open until you're done with it and then close it.

Also, you have controls and indicators which don't have labels.  This could be causing LabVIEW some trouble but I'm not sure.

Your while loop is also spinning without a wait so you may have CPU usage issues.  The VISA read may be providing a time delay for you though.

[RavensFan]

1.  Don't close the VISA resource on every loop iteration.  Move the Close to after the while loop.

2.  Clean up wires.  Your error wire is overlapping your VISA resource wire going into the VISA read.

3.  Since you know you are getting a termination character, I would enable the termination character and set that.  Then ask for a large number of bytes, more than you expect.  The VISA read will terminate automatically when it gets the termination character.    By closing the port every iteration, then trying to read a precise number of bytes, you run the risk of occasionally losing a byte and throwing your entire byte sequence out of whack.

4.  Make sure you do something with the error wire.  Right now it is going nowhere out of the VISA close, so you should be getting a popup.  That could get really annoying if it is something like a disconnected cable causing a timeout.  The pop up will keep occurring over and over until you fix the problem.  Put an error indicator on the wire, and wire the error through the loop to the VISA close which you should have by now moved outside of the loop.

[RavensFan]

---

@Taki1999 wrote:

Hmm. . .

Why are you closing your VISA reference after each read?

You should keep it open until you're done with it and then close it.

I think that is the main problem.

Also, you have controls and indicators which don't have labels.  This could be causing LabVIEW some trouble but I'm not sure.

This won't cause LabVIEW any problem.  It is just a problem for the programmer because you can't figure out what the control terminal is actually linked to just by looking at it.  It is poor programming style to have unlabeled terminals on the block diagram.

Your while loop is also spinning without a wait so you may have CPU usage issues.  The VISA read may be providing a time delay for you though.

Yes, the VISA Read will be providing the timing of the loop.  So there should be no need for a wait statement here.  Actually a Wait statement would be a bad idea if the wait is longer than the rate that data is being sent.  Eventually the serial port buffer would fill up.  But paying attention to whether a loop needs a wait statement for can get by without one is a good point to bring up.

---

[LabviewNovice89]

Thanks for the quick replys.

Working with my group now and trying the suggestions.  

Will get back with results ASAP.

[LabviewNovice89]

Moving the VISA Close outside the loop solved the issue!

We were basing our initial block diagram off an example code that was used in a previous project.  For whatever reason this earlier project operated fine with the visa close inside the loop.  Obviously not the case for us!

We will take the advice and clean up our block diagram a bit for our final .vi

Really appreciate the quick reply and the great advice.

Thanks guys!