I have an issue with a Metrologic scanner and my Visual Basic .NET program. It is a connectivity issue. I think my Visual Basic .NET program needs to get a little smarter about how it Opens the COM port and initializes the connection.
With the scanner configured on the PC with drivers installed and our software installed, connectivity is okay UNTIL the scanner craddle accidentally get's unplugged momentarily from the USB port. If the scanner cable becomes unplugged for a few seconds or minutes... and then gets plugged back in, our software can't find the scanner anymore on the PC. The PC can be shutdown and restarted every night and connectivity remains OK. The problem only occurs if the cradle gets unplugged momentarily from the PC. And then rebooting doesn't help.
The only thing that can "fix" things is to rerun the Metrologic installation software. Part of that installation process sets the BAUD rate for the COM port on the cradle. Our app stores that BAUD rate and uses it in communicating with the scanner.
The scanner sits in a cradle which has a USB connection back to the PC. It creates a serial COM3 automatically on the PC.
Interestingly, I just discovered that I can run one of the TEST utilities that comes with the Metrologic even after a momentary unplug incident and have good connectivity to the scanner from the PC. This utility is a small app onboard the scanner with a PC counterpart. It is a simple ECHO app. Both the PC counterpart and the onboard app ask for the BAUD rate before starting the test. This app always works. Even after
successfully running this ECHO test app in a post-unplugged-replugged-i
n condition, my app can't find the scanner.
WHAT I KNOW:
1) My app works fine until the scanner gets unplugged from the PC.
2) The vendor's ECHO test program works fine ALL of the time.
3) I have to re-run the vendor Installation program to get my App to work after an unplug even.
4) The Vendor's ECHO test app is smarter than my App. I need to learn what it does to "wake up" the cradle.
WHAT I SUSPECT:
I think I need to make my connection routine smarter. I suspect when the craddle get's unplugged, it is defaulting back to some other baud rate (or other com setting). I have attempted to connect at other baud rates by hard-coding all of the other baud rates that the cradle supports. I tried them one at a time while I was in a post-unplugged-replugged-i
n state. That didn't work. I tried 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200 bauds. All of these with standard 8 databits, No parity, and 1 stop bit (8N1). Flow control isn't something our App addresses. That could be the problem too.
I really think the cradle defaults to some com condition that I am not finding when it gets unplugged. Obviously the vendor's echo TEST program can get the Cradle to communicate. I'm missing something with my app.
My app does the following to determine if it can talk with the scanner. This works fine until the scanner is unplugged. The error that gets thrown by the CATCH routine below is:
"Read Error: Timeout error"
The Rs232 class is pretty robust and we've never had any issues with it with other equipment we utilize. It is in our code from before my time. I sincerely don't think it is at fault.
'Other things happen above this line but here are the guts of the routine to see if we can connect
Port = New Rs232()
Port.Open(StoredComPort, StoredBaudRate, 8, N, 1, StoredBufferSize)
If Port.Read(1) = 1 AndAlso Port.InputStream(0) = Asc(Rs232.ACK) Then
fOK = True
txtComDetails.Text = "Scanner found on COM"&StoredComPort.ToString
Catch ex As Exception
The small App we have on the Metrologic is VERY simple. We put it in SYNC mode when we want to sync with the PC. When in SYNC mode, it just sits there waiting for a connection from the PC. It watches for the Rs232.ENQ and does a quick response. This ability to do this very simple communication is what we lose when the cradle gets unplugged momentarily.
Any insights or suggestion anyone has would be greatly appreciated.