Sending data to fast on comm?

I have some software I have been working on. I did all the programing on my laptop using a usb to serial adaptor. Every thing works perfectly when I run the software on my laptop with the adaptor. However when I test out the software on my desktop with a built in com port it ends up sending some of the information but the rest seems to get droped or moved. The device I am dealing with is a serial VFD display. I can get my software to work on my normal com but I have to put a Sleep 1 command after it sends one line of text to the display. That would be fine but eventualy the software locks up on my desktop pc.

Basicly I need to figure out what would be the difference between the usb to serial adaptor and a regular com port. I will post my entire project on here as soon as I get to work. If any one has any ideas please post them. Below is the documentation for the display I am using.

Here is the whoal project. This is my last hope. If no one can help here I'm going to have to abandon the project. :eek2:

What I don't see is any handshaking. Normally I use MSComm and is easy to handle with handshaking. Check your API's and USB-driver on RTS/CTS or Xon/Xoff.

As far as I can tell the vfd dosn't use any handshaking. I have options in there to turn it on. The dose bring up another good point when I enable RTS on a normal com port the software sends ok with out the sleep 1 command but it still eventualy locks up. I'm not sure if the lock up is because of the comm controler or all my timers (3).

If the option "handshake" is available I think you have to use it. Your program will always be faster then USB, Comm or what ever. Try MSComm in a test project, then you can use error trapping etc.

I put the option in my software to turn it on but the VFD dose not use handshaking as far as I can tell. There is mention of an SBUSY line though.

I can't help you with "SBUSY"

I studid the pdf file on SBUSY. You can use this line as a CTS and use handshaking RTS/CTS.
An other point is to keep your Baud rate as low as possible.

No problem. I just hope some one has some more idea's I can check on.

Read myn last post!

Alright going to look threw docks now to see what I have to change to enable that. Why would you want to lower the com speed? Right now its is at 38400

Just gave that a try. Seems to do the trick but my software is still locking up :/ Did any thing look wrong with it that would be causing it?

Some serial hardware devices have a predefined maximum baud rate, beyond which they will not accept data properly.

USB adaptors tend to accelerate the comms throughput, so turn the speed down as far as it will go and then increase it until it fails again, then turn it back down 1 increment.

I did read in your pdf, section 5.3.2, that your device has a receive buffer of only 1 byte. So your send buffer is not allowed to send ANY character when SBUSY is active. With high baud rates this can be a problem. Also some comm devices too. Try measuring with a scope. Delaying with a timer can be a solution (not a nice one however).

Is there any issue with using as many timers as I have or do you think the reson it is locking up is because of the timing issue?

I can't read and analyse your project because lack of time. Number of timers is not a problem. Make a test project, just the display and a program to set up the display.

Humm well I did vfdcom.outbuffersize = 0 before I opened the port. I set the display to 9600 bps and set my program the same. Every thing has been working fine so far. Been runing about 5 min or so I would guess. I'm going to leave it in this configuration and let it run well I sleep. If it isn't locked when I get up I'll call it fixed.

Just to make sure I learned some thing. When you have a high baud rate the timings have to be controled more where with slower settings it isn't so critical?

Yes, in a PC it is, in a microcontroller not.

Have a good sleep then.

Doh! Always happens right before I go to sleep it locked up agine. Slowing the speed down just seems to delay the lock up. Humm well I honestly dont know any thing else to try at this point. I may just try and find a parellel lcd that is suported by lcdsmartie. I have one last hope a friend is trying to make me a serial port dll that I can use insted of this mscomm crap. From our testing with this it dosn't seem to matter how fast we send data it gets there.

Can I run your program without the display?

I studid your code and changed some things in Form1.frm. If this is not working the problem is somewere else.

I'm runing it now. There are a few things I'll need help fixing. Like making sure it always sends 20 or 10 letters/numbers. This is to avoid having to send the Carage return and line feed command to it. When you send all 20 (or 10 depending on text size) then the vfd automaticly moves the cursor down one line and then you just have to move it to the begining with the Chr$(13). Then agine I realy could make an if statment that checks the length of the text and sends the right command.

PS: we are at 10 + min with the software and no lock up :D

Ok I got the if statment added. I did notice one thing though. When I have say 3 long lines of text (15-20 letters long) and have a %time display at the bottom it skips some seconds because of the long time it takes to send all the letters before it. I know this can be worked out by moving the %time display to the top line but is there any way to make the sleep time a little less? Right now its at 1 milisecond which you would think is good. Maby I'm missing some thing?


Edit:
Oh I know how I could speed things up. This vfd is fast enough to recive 1 command + 15 (letters, numbers, and additional commands) at a time. So by sending 15 at a time insted of 1 it would only be refreshing 6 times to fill the whoal screen (assuming there wernt alot of commands). Which I know it can do in under a second. The only issue is I dont know exactly how to go about doing that.

Ok here is my modified form1 to do what I was talking about the only problem agine is locking up. Dose any one know if there is another way to access the com port's other than mscomm? I'm also going to try the form1 you gave me agine and let it run and see how long it is stable for.

EDIT: well that didn't take to long. Eventualy even the code you gave me ends up messing up. It dosn't lock up but it will pause for a long time then start agine. Also some times just the text on the display gets out of order. So I guess I realy need to find a better way to send data to the com port. If you know of any please let me know.

Location here is the Netherlands. So I just have had breakfast.
If my code gives problems then I'm not sure the Comm gives the problems. The delay is enough for the display to proccess.
Descripe "lock up".

Well when it fully locks up you cant move the software on the desktop, it dose not redraw the gui if another application window is moved over it, None of the buttons respond to input, and when you click on the x after a while windows 2k lets you know its crashed.

When it just stalls it dose the same thing but only for a few seconds then resumes working. Normaly not long after the first stall it crashes.

Well if you stay in pure VB (without API's) such crashes can't occur. If "via Tools-Options-General=>Break on all errors" is enabled Vb will stop if an error occured, even with MSComm like in this case. This has to do with an API!

An other point is the timers. Perhaps its better to use 1 timer with a static counter and a select case to get a good sequence?

I see more then 1 SendMessage items:
1 Api (public declared in module WinAMP)
1 function in frmSettings

Watchout!

Fixed but its still locking up.

EDIT: I love how no matter what I set the mscomm info to it always locks up. I'm going to comment the actual send portion of my code and see if it still locks up. If it dosn't then we no 100% that it is the mscomm controler.

Well no lock up so far and by now it has normaly froze up.

EDIT: keep in mind it is not actualy sending data to the serial port my software is just runing threw its various loops.

Quote:

---

Originally Posted by hcker2000

I have some software I have been working on. I did all the programing on my laptop using a usb to serial adaptor. Every thing works perfectly when I run the software on my laptop with the adaptor. However when I test out the software on my desktop with a built in com port it ends up sending some of the information but the rest seems to get droped or moved. The device I am dealing with is a serial VFD display. I can get my software to work on my normal com but I have to put a Sleep 1 command after it sends one line of text to the display. That would be fine but eventualy the software locks up on my desktop pc.

Basicly I need to figure out what would be the difference between the usb to serial adaptor and a regular com port. I will post my entire project on here as soon as I get to work. If any one has any ideas please post them. Below is the documentation for the display I am using.

---

This is very strange of you to post this. I just had this exact problem!

I resolved it. I had to pause 100 milliseconds (using a timer control) after the initial On_Comm event, and keep scanning every 100 milliseconds. Kinda like this:

On_Comm Event Raised: Scan Com Port, get 8 bytes
Wait 100 ms
Scan Com Port again

The code is faster than the incoming data. That's why you have to wait like that. My scanner was at 9600 baud. Good luck!

On_Comm event???

Oh, well I was using the MSCOMM32.OCX

Yes I understand. HCKER2000 did use it too. But he only send some info to a display. He didn't use any events of MSComm.
Did your app freeze too??

never.

Here, I actually posted my code the other day:

http://www.vbforums.com/showthread.php?t=315098

This problem intriques (English?) me.

Oops! That was the code before I fixed it! If you can't fix it by using your own delay method let me know and I will upload the correct code tonight.

Well HCKER2000 is not here now. I see it on monday.

Was sleeping :D Any way so your software gets data from the com port? Also I would if you posted your compleatly working source so I could check it out. Now when using RTS there will be an on com event right? If so maby I just need to up mine from 50 to 100 and try it agine. I'll give it a try right quick then let every one know how it worked out after I get back in tonight.