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.
Last edited by hcker2000; Mar 30th, 2005 at 10:13 PM.
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 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.
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
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).
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?
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.
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
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.
Last edited by hcker2000; Mar 31st, 2005 at 06:20 PM.
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.
Last edited by hcker2000; Mar 31st, 2005 at 09:14 PM.
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?
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.
Last edited by hcker2000; Apr 1st, 2005 at 03:27 AM.
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!
Nobody knows what software they want until after you've delivered what they originally asked for.
Don't solve problems which don't exist.
"If I had eight hours to cut down a tree, I'd spend six hours sharpening my axe." --- Abraham Lincoln (1809-1865)
Was sleeping 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.
Reply With Quote
Originally Posted by hcker2000
