Skip to main content
gamedev.net
🔒 Locked

COM Programming

Started by jrmiller84 8 replies 1.4k views
Original Post
jrmiller84
jrmiller84
Hey everyone, I wanted to ask a design question to see if I can get some brainstorming happening. Here's my problem. I have been developing inventory software for my company for the past few months and everything was going fine for a while until we started using new barcode scanners. Our old scanners are bluetooth and transmit each barcode upon scanning. This works well except that they can't get too far away (they say they have a 300yd range, but I seriously doubt that) or they just die. The new scanners (ones that have started giving us trouble) are memory scanners in that they transmit nothing until you dock the scanner to the base, then it quickly syncs everything. Now here is the problem. Due to the speed in which the memory scanners dump data, it almost seems as though the program is tripping over its own feet. It will grab everything for a while and then just start losing huge chunks of data here and there. For example, we scan items in alphabetic order and we will miss like all of the M's and N's, get some of the P's, miss the O's, etc etc. It's all random as well, never the same on each go at it. We had to revise the scanning logic once before because we thought this was happening. We revised it to have all the barcodes pulled from the port and written to a buffer. Then a timer would check the buffer every X milliseconds, process valid barcodes, and then wait for the next timer click. This works better than pulling barcodes straight off the buffer and processing but it still seems to miss data. I know this is a lot to chew on, but can anyone think of a better way to do this? I'm open to any idea, no matter how radical or out of the box. Thanks guys, you're always life savers whether it's game programming or anything else!
I will forever be a student.
Prozak
Prozak
It seems as though you're having some sort of problem during the transmission.

Data loss can occur if the "Get" side of the two machines gets data, but doesn't signal it has it, and therefore the "Send" side keeps sending data that overruns the transmission buffer.

This situation can be tested if you add delays to your program. Also check if you're using some sort of serial DB9 to parallel dongle. Some crappy ones seem to have the lines responsible for signaling data send/receive readiness cut off.

PS: Format your text if you expect replies, people just don't bother reading a pile of chars.
jrmiller84
jrmiller84
Yeah, sorry about the formatting. I've been trying to work on that but as you can see I'm not doing so well ;)

What you described with the data overrunning each other I believe is what was happening before I revised the code. It was just pulling in data as soon the event fired and if it wasn't finished processing the prior scanned data it would just run over it. That's why I implemented the timer based method, to give it a chance to queue the data as it likes and have another process check it. I thought this was a ghetto solution at first but it was working great until we got these new scanners.

Unfortunately we are not using any sort of dongles to connect them. It is connected to the base using a network cable-esque connection and a serial connection on the other end. I wish it was that easy ;) I'm just trying to think if there is a better way of handling the data. I may try to add the delay or crank up the time in between the ticks of the timer. Anyone have any other ideas?
I will forever be a student.
Prozak
Prozak
Well, you can try formating your data using header blocks, something along the lines of:

[Magic Number] [Data Size] [MD5 Hash] [Data Block] [Magic Number] [Data Size] [MD5 Hash] [Data Block] [etc]

This way you can be sure that the incoming data is valid. If you lose some bytes your magic number will be misaligned. If the data size is valid, but there are some corrupt bytes, your hash test will fail.

You can use this 24 byte header (4+4+16) for every 64.000 bytes, so the overhead is minimal, but I advise you to use smaller block sizes, like 1024, to test out the transmission.

I work on something similar, embedded C++ for PDAs, and I've run into pretty much the same problem.
jrmiller84
jrmiller84
That sounds good, although I am not completely sure I understand one thing in your description. I understand the purpose of the data size as well as the hash but I'm not quite sure I understand the "magic number" part. Is this just random data that will always be a fixed length to aid in helping me determine if the data is offset or missing? I may be misunderstanding your description.

Also, I am guessing this data would need to be embedded in the barcode to allow for verification. Am I right?
I will forever be a student.
Prozak
Prozak
Quote:
Original post by jrmiller84
That sounds good, although I am not completely sure I understand one thing in your description. I understand the purpose of the data size as well as the hash but I'm not quite sure I understand the "magic number" part. Is this just random data that will always be a fixed length to aid in helping me determine if the data is offset or missing? I may be misunderstanding your description.

Also, I am guessing this data would need to be embedded in the barcode to allow for verification. Am I right?


"Magic Number" is just computer slang for any number that you already know beforehand. Your magic number could be 0x0BADC0DE for example. Then, all you have to do is check if those 4 bytes == 0x0BADC0DE.

Well, in principle you already know that all the data in your terminal is OK. It's the syncing part that isn't working, so I would say that you should apply this scheme on the communications software that syncs the data between the terminal and the PC.
jrmiller84
jrmiller84
Alright, so there has been a new development within this project I've been working on. It seems that my MSComm object's (vb6) CommEvent property is returning a "Receive Buffer Overflow" error and I believe this could be the culprit that is making sections of my data go missing.

I am not sure how to avoid this error though. As soon as the event fires, I pull the data off of the com port and into my own string buffer so I'm not sure how else to fix this problem. I'm guessing it must be some parameter of the mscomm object?

It must be code related since Hyperterminal pulls all of the data fine. The scanner just seems to be dumping so much data so quickly.
I will forever be a student.
Prozak
Prozak
Scour the technical manuals for some sort of handshaking capabilities. You have to be able to, on the receiving side, say that you've pulled all the data, so that the sending side can 1) clear its buffers and 2) fill them with more data.
jrmiller84
jrmiller84
Yeah, I just did that and I find it hard to believe that a $1000 scanner doesn't have handshaking abilities. I was thinking that maybe turning down the baud rate might help but I'm afraid that may just be avoiding the problem. Thanks for all your help so far Prozak, it's helping to get the gears moving :)
I will forever be a student.
jrmiller84
jrmiller84
Wait a second, I take that back. Handshaking is available. I'm not sure how I didn't see it the first time. This will definitely give me something to chew on for a while. You're the man.
I will forever be a student.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.