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

[Hootowl]

I maintain a large application that collects data from many data source channels (using coustom hardware read thru a conventional COM port) and I am adding a GPS data source on a USB port using a virtual COM port driver. The application runs 24/7/365 and works well including the GPS data, if undisturbed. However, the application needs to tolerate a physical disconnect and reconnect of the GPS device without user intervention.  When I disconnect the GPS, the application becomes unresponsive most of the time (the mouse responds and other programs that are open on the desktop work fine). I abstracted the serial code and made a separate vi (below) for testing.  When I disconnect the GPS from the COM port, I get a "Not enough memory to complete this operation" message 9 out of 10 times and the vi is unresponsive until I clear the error message (the tenth time it continues working). I built the vi this way to collect data continuously. I suspect that this is the problem with the full app but I don't see the Not enough memory message there and therefore the full app does not respond and must be terminated via Task Manager. The full app runs full screen mode.

The LV app runs on Windows XP and LabView 7.0 (the client doesn't want to upgrade).

I have tried probing the error message lines at all points in the vi but they don't show anything when the 'Not enough memory' message occurs (they show the expected device not found error after clearing the error message).

Any suggestions would be greatly appreciated,

Mel

Still learning LV......

Please post any code suggestions as graphics as I don't have access to any version of LabView newer than 7.0.

[JÞB]

The default timeout for serial reads and writes is 10 seconds.  This can make your code LOOK unresponsive since the time to finish the read can get very long compared to good communications.

This may also impact any other processing thats going on in the same loop (A darned good argument for collecting and analizing in seperate loops) and suddenly your memory needs skyrocket.

I would strongly encourage you to rethink your requirement:  "the application needs to tolerate a physical disconnect and reconnect of the GPS device without user intervention"

First, there likley WAS human intervention that caused the GPS device to be removed.  That wont happen when you lock the device inside a cabinet with the rest of the test system.  Physical access control first!  If someone goes and mucks with your experiment setup while its running, that's a "poor Labratory procedure" not a "new software requirement"

[dacad]

---

@JÞB wrote:

First, there likley WAS human intervention that caused the GPS device to be removed.  That wont happen when you lock the device inside a cabinet with the rest of the test system.  Physical access control first!  If someone goes and mucks with your experiment setup while its running, that's a "poor Labratory procedure" not a "new software requirement"

---

I think he was meaning to say without user intervention on the software side.

I have seen odd behavior if you disconnect from a com port whilst LV still has the port open.   There are a couple things I myself woud try, being the experimenting type that I am.  Perhaps setting up a com port check to see if it has a valid connection before polling for data. If not then a blank case or some other generic code. 

The issue with this would be if it became disconnected while LV was polling data.  Hard to get around this condition.  Is there a way that the cause of the of the connect/disconnect (whether human or otherwise) could be set up so that a signal can be sent to the controlling system (pre-disconnect and post-connect) to trigger an event to handle the software side?  A simple signal switch or something.  Just thinking out loud. Withoug knowing all the particulars, it's hard to make detailed recommendations.

[mikeporter]

Could you by any chance post a screenshot of the error message?

Mike...

[Hootowl]

The error message is:

I suspect it is a windows system error and it grabs the focus away from the test vi and holds the LabView focus until it is cleared.

The Timeout of the COM port has no effect on the action of the test vi or the full app.  The full app can't be used until it is killed via Task Manager and restarted.

The full app is a fielded data acquisition product that acquires data 24/7/365, presents the data in screens, analyzes the data against limits, and sounds an alarm it a limit is exceeded. The users are not technical and the physical access to the GPS needs to be provided in case the unit fails.  I need to have the ablity to tolerate the GPS failing and the user being able to replace the GPS unit without the system appearantly locking up and not responding.

Mel

[nathand]

Hate to suggest this because it's ugly, but it's worked for me when I had one component that kept crashing and taking down the whole system: move that component to a separate exe and access it through VI server. This gives you some ability to keep the main code running. If the misbehaving component stops responding, kill it and restart it.

[Dennis_Knutson]

What's unclear to me is the actual physical connection. Are you using an external usb-rs232 converter or is the conversion being done by the gps unit? If you are losing the com port in Windows and MAX, you will almost certainly need to restart the application. I don't understand why you wouldn't be doing this anyway. If the gps fails, went continue running? What sort of gps has such a high failure rate?

I also hope that your actual app is better written than that image you posted. Never open, init, close inside of a loop.

[Hootowl]

The GPS capability is an option on the product.  The GPS device has a native USB interface connected to a USB port on the PC and uses a virtual COM port driver supplied by the GPS vendor.  I used the VISA objects in LabView to access the virtual COM port. The test vi posted continues to run after the error message is cleared and reacquires the GPS connection when it is reconnected to the PC.  Many disconnects, clearing the error message, and reconnects using the test.vi causes no problems to other tasks running on the PC.

The full app collects other data thru propietary hardware that is a multiplexed RS232 serial to fiber optic interface, connected to a different COM port. That data needs to continue to be gathered in the unlikely event that the GPS were to fail. The system can be unattended for days and I'm trying to make as much of the data available for the highest percentage of time.

Dennis_Knutson wrote:

"Never open, init, close inside of a loop."

________________________________

What would you suggest as an alternative?  The data needs to be updated at less than 2 second intervals.

Thanks for all replies and suggestions to this point.

Mel

[Dennis_Knutson]

The alternative is to do each one once. They just need to be moved to inside of the loop.

[Hootowl]

"They just need to be moved to inside of the loop." ???

Did you mean outside fo the loop?