|
For those who have found it impossible to get help in communicating with Wasp's WDT-2200 Barcode Scanner through a COM Port, except by using their supplied DTComm software, I am presenting what I have found through use of a Protocol Analyzer connected to the COM port, and how I have managed to upload (from Scanner to Computer) a file holding transactions recorded by others using the scanner to "Issue Parts".
Quickly though, allow me to note their AppGen software has proven sufficient in designing the application I loaded onto the Scanner in order to allow it to be used to record these transactions. This application records "Issued To", "Part Number", "Location", "Quantity" and a "Date/Time Stamp", with each field separated by a TAB (instead of a comma, since AppGen does not save CSV files containing commas according to standards, and such SINGLE fields get interpreted as MULTIPLE fields when the comma is encountered). So I highly recommend you set the delimiter to be a TAB, that is, unless you are likely to have a TAB character in one of your fields.
Now to the Wasp WDT-2200 protocol...
A single null byte is sent to turn the WDT-2200 on, if it is off, and is not required if the WDT-2200 is on. However, sending a null byte when the unit is on causes no problems, so that is what I would recommend you do if there is the possibility it may be off. (The WDT-2200 will turn itself off to save battery life after a certain period of time.) It takes between 4 and 4.5 seconds for the WDT-2200 to turn on, so I have used a 5 second timer between the null byte and subsequent command, and I recommend you do the same. If you want to add extra code to see if the WDT-2200 will respond to the command before using implementing a 5 second delay, then I can say that is what the DTComm software does, but for code simplification, I just coded the delay whether or not the scanner is on.
==============================================
Command sequence for requesting Scanner identification...
0x00, {5 second delay}, 0x02, 0x1B, 0x76, 0x45, 0x44, 0xC1
Which is...
NULL, {delay}, STX, ESC, v, CRC16a, CRC16b, proto ETX
Note1: I have not determined how they calculate what I have decided is some sort of CRC16 code (perhaps someone can enlighten me?), but as long as you use the exact same ones that DTComm uses for the exact same command string, it will work. I ignore the CRC16 code that the WDT-2200 sends with its own data packets, since I assume the data gets to my software uncorrupted.
Note2: Byte 0xC1 appears to be what the WDT-2200 expects to see for End of Text, though it sends back an actual ETX byte for it's own transmissions; hence my calling it "Proto ETX".
To the above command, the WDT-2200 responds with...
0x02, 0x1B, 0x76 followed by the byte representation of...
"WDT2200 V1.20" followed by 0x48, 0x4A, 0x03
Which is...
STX, ESC, v, "WDT2200 V1.20", CRC16a, CRC16b, ETX
==============================================
Command sequence for requesting Scanner DIRECTORY...
0xFF, 0xFF, 0xFF, 0x02, 0x1B, 0x44, 0x42, 0x42, 0xC1
Which is...
0xFF, 0xFF, 0xFF, STX, ESC, D, CRC16a, CRC16b, proto ETX
To the above command, the WDT-2200 responds with...
0x02, 0x1B, 0x44 followed by the byte representation of the filenames separated by commas, followed by 0x45, 0x4F, 0x03
Which is...
STX, ESC, D,
"ISS-RCV.EXE,JENG.EXE,JENG.LOG,ISSUED.TXT,RECVD.TXT",
CRC16a, CRC16b, ETX
Filenames will differ depending upon your own application, but I have included those on my scanner for those who might wish to work out what type of CRC code is being employed. The CRC code will of course be different if you have different filenames, since it will be calculated on what data is actually being sent to the COM port.
==============================================
Command sequence for requesting a file size...
I will use the example for requesting the file size of "ISSUED.TXT", since the CRC code recorded could be used by others if they choose to use the exact same filename for their own application.
0x02, 0x1B, 0x4A, "ISSUED.TXT", 0x42, 0x4D, 0xC1
Which is...
STX, ESC, J, "ISSUED.TXT", B, M, proto ETX[/b]
To the above command, the WDT-2200 responds with...
0x02, 0x1B, 0x4A, 0x00, 0x37, 0x30, 0x4D, 0x41, 0xC1
Which is...
STX, ESC, J, NULL, 7, 0, M, A, ETX
My file (ISSUED.TXT) was 70 bytes when I recorded this data stream.
Here are more CRC16(?) bytes for other file sizes returned by the WDT2200
4008 bytes => 0x43, 0x 48
40172 bytes => 0x46, 0x4B
0 bytes => 0x49, 0x49
==============================================
Command sequence for requesting Scanner Free Space...
0x02, 0x1B, 0x47, 0x42, 0x45, 0xC1 which is...
STX, ESC, G, B, E, protoETX
The scanner responds with more than the Free Space, perhaps it is the Scanner Serial Number, or something else, but in my case the free space was 2,237KBytes, and though file sizes were reported in bytes, Free Space appears to be recorded in Kbytes. Here's the response noted on the Protocol analyzer...
0x02, 0x1B, 0x47, 0x32, 0x35, 0x36, 0x30, 0x30, 0x32, 0x33, 0x36, 0x32, 0x32, 0x33, 0x37, 0x4D, 0x46, 0x03 which is...
STX, ESC, G, 2, 5, 6, 0, 0, 2, 3, 6, 2, 2, 3, 7, M, F, ETX
==============================================
Command sequence for downloading "ISSUED.TXT" from the WDT2200...
0xFF, 0xFF, 0xFF, 0x02, 0x1B, 0x55, "ISSUED.TXT", 0x43, 0x48, 0xC1
After sending this command, the WDT2200 will respond with an ACK byte (0x06) if the file is on the scanner, and it will respond with a NAK byte if it isn't.
After receiving the ACK byte, finish the command with the following...
0x02, 0x1B, 0x59, 0x43, 0x47, 0xC1
The WDT2200 will then respond with...
0x02, 0x1B, 0x59, {Data Stream of ISSUED.TXT}, CRC16a, CRC16b, 0x03
To which you need to respond with an ACK byte, followed by a delay (mine is 0.1 second), followed by repeating the command above
(i.e. 0x02, 0x1B, 0x59, 0x43, 0x47, 0xC1)
...until the WDT2200 responds with SIX SPECIFIC BYTES as follows...
0x02, 0x1B, 0x5A, 0x47, 0x47, 0x03
With this final response from the WDT2200, you may or may not choose to send a final ACK byte.
==============================================
In my application, I strip off the headers and control bytes, and then I save it to a string in C#. One should note though that CR and LF will not be the bytes you might expect. Instead the WDT2200 sends 0x8D for CR and 0x8A for LF, while a 0x89 is sent for the TABs. When I encounter these bytes, I replace them in my C# string with "\r", "\n" and "\t" respectively. That way I can then perform a simple text file save by supplying the proposed filename and my C# string
==============================================
If you wish to code your application to delete the file from the scanner after it has been successfully downloaded, use the following...
0x02, 0x1B, 0x45, "ISSUED.TXT", 0x42, 0x48, 0xC1
The WDT2200 will respond with... 0x02, 0x1B, 0x48, 0x00, 0x46, 0x43, 0x03 ...if the file exists.
It will respond with a NAK byte if it doesn't.
==============================================
Unfortunately, I could not determine the method used for the two error control bytes, so file specific commands will only work as posted for the filenames I have used. Since I don't need to use any other filenames, this is sufficient for my own application, and it allows me to grab the scanner data directly from within my application, rather than trying to instruct users in the use of DTComm to download and delete the scanner file, then have them go back into our database application to import the data from that file. Also, the DTComm software doesn't allow me the flexibility to assign unique filenames to each file download from several scanners, which is important for us, but I simply save the file created by my own application with a Time Date Stamp of sorts as part of the filename.
=================================================
I hope this helps others who have had no success in requesting the protocol from Wasp's "Free Lifetime Support". You get what you pay for though.
Last edited by sdbranum; Aug 7 '09 at 12:15 AM.
Reason: edited to correct bold facing of specific text
|
