Not enough memory error when disconnecting device on a virtual com port

[nathand]

There's a good chance you'll need to closer and reopen the connection when a disconnect occurs; you should test this. If so, leave them inside the loop but inside case structures so you only execute them when necessary rather than on every loop iteration.

If you open some other serial program - HyperTerminal, PuTTY, etc - and open a connection to the GPS device, then unplug it, what happens? Same error?

[mikeporter]

If you turn on execution highlighting what specific function causes the error?

Mike...

[Dennis_Knutson]

Sorry, yes I meant outside.

[Hootowl]

With Highlight Execution on, the Property Node "Bytes at Port" returns '1665829787' when the GPS is disconnected and there is no error at the error in terminal, thus triggering the Error Message window.

The number returned by "Bytes at Port" is the same each time and its Error out is 0. When the Error Message is cleared, the Read block gets the big number and returns no data with an error out of 0.

Using Hyper Terminal to look at the GPS data, the displayed data stops at disconnect and no error message is triggered.  Hyper Term does not reacquire the data at reconnect of the GPS.  The connection must be closed and re-opened.

[dacad]

---

@Hootowl wrote:

With Highlight Execution on, the Property Node "Bytes at Port" returns '1665829787' when the GPS is disconnected and there is no error at the error in terminal, thus triggering the Error Message window.

The number returned by "Bytes at Port" is the same each time and its Error out is 0. When the Error Message is cleared, the Read block gets the big number and returns no data with an error out of 0.

---

What is the value of the 'Bytes at Port' under normal conditions?  Perhaps you can use that value as a filter on whether to allow the Read to occur?

[AKA_TG]

I don't expect this to help youi right away but perhaps get you thinking toward a more robust solution.

Recovering from a serial disconnection is possible but not at all trivial. To be able to recover requires a state machine with exception handling embedded in it. You need maximum flexibility in handling Serial I/O errors if the APP is to be considered robust. 

Exeption handling should handle the error and once handled resume back at the point before the error occured.

Doing this in LabVIEW is possible but not so easy.

If you can make a state machine that has an error handling state you could setup the code to go to the error handling state when a disconnect happens. (How a disconnect is sensed is something you have to figure out. When a disconnect is sensed your code should set an error (with custom code) and allowed to leave that state to fall into the error handling state. 

In the error handling state you could filter out the reason for the error (disconnect) and make a handler just for that purpose (reconnect a disconnect) .

Then you could return to the initial state that caused the error in the first place and do a retry from there.

Kind of like Try Catch scenario only in LabVIEW.

Connection recovery is usually possible this way but it is not at all trivial.

The other caveat is IF the external device mis-behaves when disconnected you will have no choice but to power cycle it before reconnecting to it. That adds a lot more complexity.

[JÞB]

---

@Hootowl wrote:

With Highlight Execution on, the Property Node "Bytes at Port" returns '1,665,829,787' when the GPS is disconnected and there is no error at the error in terminal, ....

---

There you go!  That 1.6 GB buffer is not going to allocate and the program will halt.  The good news is you found a reliable way to detect a disconnect.  

If bytes at port is greater than some rational number (say, 4096) don't read!  Clear the buffer and find a state that waits for a reconnect.

[mikeporter]

This was pretty much what I was suspecting, plus it males sense logically in that it is the only part of the code that would have an effect on memory allocation.

Mike...

[Hootowl]

Sorry for the delay in responding but life got in the way. 

The 1.6GB number returned is indeed a reliable indication of a disconnect.  I have reworked the code and it reliably detects a disconnect, and then tries a reconnect every loop until the USB device is found again at reconnect.  It doesn't open, close, or init the port otherwise except at startup of the app.

I added two error traps: one since the data reads are asynchronous to the source which ocasionally give a framing error on read; two since the buffer can ocasionally have more data than the bytes at port indicates, again because of the asynchronous nature of the reads.  The code graphic and the vi are included.

A  BIG thank you for all comments and inputs.  They were a great help.

Mel

Philtronix, Inc.

PS: The vi code was not accepted as an attachent.  It gave me and error: "The contents of the attachents doesn't match its file type."  The vi is in LabView 7.0 format.