Help VB Gurus!,

I am working with a problem that I HOPE can be solved using VB, perhaps using API calls, but the only API code that I use is borrowed, moved to modules and accessed with functions that I understand because the API is way beyond me. Here is a basic outline of the problem:

A PC on a ship needs to communicate with an MCS system that monitors a large number of sensor inputs around the ship. The current method of doing this uses a form with a mscomm control and a Timer control. The Timer control checks the I/O status (ie sends a request for certain sensor inputs, or Waiting for a response). The mscomm_OnCom event is used to trigger data retrieval and processing. Everything currently works fine until a user begins to drag windows around or do other things that occupy the system for more than 2 seconds (the MCS drops communication after a 2 second timeout limit) and then the monitoring system crashes (or ceases to monitor). The problem seems to be that the VB code is not “High” enough in the system priority list. The obvious answer is to have a computer dedicated to the sensors, but because of space limitations this is not a desirable solution. The ultimate goal of the app is to store real time sensor data in a database, and to allow the user to select which sensors to monitor. The MCS system can accept a request for up to 70 sensors in a block and the communications take around 2ms from request for data to data recieved …. Ok, enough back ground. Four solutions seem viable: 1) Use the API to adjust the priority of the VB app at run time. So that no matter what the user does the Monitoring app receives processing time for at least 2ms out of each second. 2) Write the equivalent of a “TSR” that handles the I/O and keeps the MCS connection open and either places the data in the database or holds it in a buffer that the App can access. 3)Use "C" to write an interface. (I have NO experience with C, but understand that it allows a great deal more control over the OS than VB.) 4) Find or Develop an interface card that will allow communication with the MCS to remain open and communicate with the program in a less time critical manner. (Least desirable solution).

Any help and/or suggestions on how to accomplish the goal would be greatly appreciated. I find myself in way over my head. I hate it when everything works except when the client goes to use it, and then he does things that weren't part of the description!

Thanks,

Hunter

ps. There is a similar post in the API forum. In case any one else is interested in this sort of problem I will post replies here if there are any viable solutions posted there and vice versa. Thanks again!