ICE

Please login or register.

Login with username, password and session length
Advanced search  

News:

ICETCP.PRO and ICETCP.PLUS are compatible with Windows 11!

Author Topic: Interfacing Bar Code Scanners to work through TCP-PRO  (Read 1407 times)

AllenK

  • Jr. Member
  • **
  • Posts: 5
Interfacing Bar Code Scanners to work through TCP-PRO
« on: July 29, 2008, 12:31:13 pm »

We are currently trying to interface bar code scanners to use with our application running on SCO Unix via TCP-PRO.  The scanners have a USB connection and when we hook them up, they work but we are trying to scan a UCC128 bar code of 48 characters and the input is just way too slow.  I believe this is because the Windows keyboard buffer is inherantly a slowed down driver (not sure why).  We got another driver for the scanner which redirects the USB input to COM5 and it is significantly faster.  The problem of course is how do we get the input from COM5 to come into our application running on unix looking like it came from the keyboard.  Is there anything that can be done in TCP-PRO to help us with this?
« Last Edit: July 31, 2008, 06:27:14 pm by AllenK »
Logged

Bob

  • Administrator
  • Ice Artist
  • *****
  • Posts: 1607
Re: Interfacing Bar Code Scanners to work through TCP-PRO
« Reply #1 on: July 31, 2008, 09:24:02 am »

I don't think you will be able to pull external input from a com port INTO the emulation.

You could try changing the character delay in the control panel keyboard setup to see if you can speed up the input through the keyboard driver. It might also be worth trying the classic version of the terminal emulation in Pro. It's simpler so that may make a difference. You can have both classic and TelnetPro running on the same machine without using any extra licenses.
Logged

AllenK

  • Jr. Member
  • **
  • Posts: 5
Re: Interfacing Bar Code Scanners to work through TCP-PRO
« Reply #2 on: July 31, 2008, 06:25:18 pm »

Thanks for the help.  Actually we found another piece of software called a software wedge that gets the data from COM5 back into the keyboard data stream but at a much higher rate.  This seems to have solved our problem. :)
Logged
 

Page created in 0.013 seconds with 21 queries.