Hey,
I've been working on an interface between a PIC micro and a VB 2010 form through a usb bridge. The Pic reads an analog value then sends it to text box in my vb form.


I was wondering if there is a more efficient way of collecting the received data opposed to writing it into a text box. It seems like it cant keep up when I increase the sample rate. It seems to work fine for about 40 samples then it begins to drop random values (I have a date/time stamp with each received figure). If I remove the date/time stamp portion it seems to run ok until I get around 7000 samples around there it begins to bog down.

Now it almost looks like vb has to refresh everything in the text box each time a figure is written into it. When I leave it going for a while it seems to bog down, so I figure this is whats going on.

All I'm doing with the data is saving it to a text file and looking at it in excel. I was hoping someone would know how to maybe just run it into a text file or buffer from the port on the fly or something similar. Additionally, is there limitations as to how much data I can collect?

Thanks

 

It sounds to me like it is possibly a memory leak. Showing the output o a textbox should be bread and butter to VB.

The limitation on the amount of data you can transfer and save (it doesn't sound like you are storing it in the PIC, or on the form?) should be on the type of filesystem you are saving the data onto. FAT16 for example should have a 2gb limit on the file size.

 

Why can't you open a file in VB, receive the data from the usb bridge and write it to the file directly, with no text display at all?

If the pic is sending binary values then you'll probably need to translate them to ascii numbers so excel can display them, and follow each full number with some kind of field terminator, like a carriage return, line feed or comma.

 

I don't know if this applies, but the VB apps I've made to communicate with PICs have a timer setup to read the entire buffer every second (or fraction thereof).

 

davebee, I just covered that in a programming class back in June and I was going to try it then my computer with VB blue screened bad luck. I have the source code saved but they are a pain to recover, I usually just redo the GUI and copy the code over.

Before it died I saw the property "do not display text" in the text box. So when I ran it it was grayed out and worked GREAT! So yea it was just the overhead based on refreshing all the chars on screen each msg. I believe the method you mentioned is the best because excel can be paired with a txt file and refresh the data input to the sheet from a file automatically which is great.

I'm going to rebuild it and give that a try today.

 

VB has to buffer all serial comm before writing to a file and updating the text box. All of this take time and hence you are losing characters.

Why not log the comm data into a text file using Hyperterm and then read into Excel?

 

VB has to buffer all serial comm before writing to a file and updating the text box. All of this take time and hence you are losing characters.

Why not log the comm data into a text file using Hyperterm and then read into Excel?

That's what I was thinking. The Textbox object can get bogged down trying to handle huge quantities of data. Hyperterminal can fail the same way, but I found a free download called something like term32 or terminal32 (I can't locate it now). It was able to keep up with some huge quantities of debug info my app was emitting.

As far as VB goes, you may have better results saving the data immediately into a text file, and just showing the last result in a Textbox.

Edit: found the program. Terminal by Br@y

https://sites.google.com/site/terminalbpp/

 

What is the serial link baud rate? How many chars are being sent/second?

Are you by any chance using DDE for use in EXCEL?

I have used VB6 with MSCOMM control with no trouble at all. The chars were received from a 80c552 (8051 derivative), and the data was being updated in 4 different textboxes after formatting and calculations. This was being stored in a file too.

 

What is the serial link baud rate? How many chars are being sent/second?

my thoughts exactly...

how did you trace the problem to VB?