HELP: Cash Drawer configuration and install

[JPS]

This is a long shot, I know, but you never know ? maybe someone else has experience with these cash drawer systems.

THE PROBLEM
In the middle of a small network overhaul, the client I am working for decided to move their Point of Sale (POS) system and cash drawer (APG 139)to a different computer. POS software install went fine and works as expected and the cash drawer appears to be hooked up properly, but that is it. Client can no longer open the drawer from within the POS, a command prompt, or MS Windows itself.

THE SPECIFICS & BACKGROUND

The old setup was as follows?
The cash drawer was connected to a Dell L933R system (Windows 2000) before the move. The connection between the cash drawer and the Dell L933R was as follows:

Cash Drawer cable terminated at DB25F > DB25M-to-DB9F cable > plugged into serial/COM port on the Dell L933R motherboard.

The cash drawer was configured as a generic printer on COM2.

Dell?s tech support team confirmed that the one serial/COM port on this motherboard did supply 5V across this port. This is needed to trip the solenoid in the cash drawer so that it will open when a command is sent.


The new setup is as follows?
The cash drawer is now hooked up to a custom-built PC based upon a Gigabyte GA-MA74GM-S2 motherboard (AM2/AM2+ AMD 740G Micro ATX). This system is running Windows XP headless as a pseudo ?file server? and I am now doing all the work and configuration through an RDC setup.

The cable connection from the cash drawer to the motherboard is same. In that this motherboard has no COM port on the backplane, I attached a COM port cable/PCI bracket to the motherboard header and tried to set everything. When there was no response across this COM port to the cash drawer, I called Gigabyte tech support and they confirmed that there was no voltage across the COM header on the motherboard. Seems like a simple fix.

So I disabled the COM header on the motherboard and then dropped in a SIIG PCI Serial port card (JJ-P01012-S6) and configured the jumper to allow 5V to flow across the port. I then hooked up the cash drawer to the COM port on this PCI card using the same cable as above in the working configuration. I then configured the cash drawer to be a generic printer in Windows XP, similar to how it was setup on the Dell L933R computer. When I printed a test page, bingo ? the cash drawer opened. I tried it again ? BINGO! And again ? BINGO!

Then I tried to open the cash drawer from within the POS software (Keystroke) and I had absolutely no luck. No errors, but no luck just the same. I then went back and tried to print a test page from within Windows and now the cash drawer would not open, at all.
I tried multiple times to duplicate the success I had earlier, uninstalling and reinstalling the cash drawer as a printer, but no luck. That is where I am right now.

The tech support at APG , while diligent, has not come up with much, primarily because the cash drawer is so old their current techs have little/no experience with it. The tech support at Keystoke has been phenomenal, but until I can get the drawer to open by printing to it or from a command prompt, then they are not of much use.

If anyone has experience setting up cash drawers across COM/Serial ports (esp an APG 139), I would be greatly indebted to any assistance, suggestions, or other help you can provide.

 

[bobsmith1492]

Did you blow the 5V output on your COM port? Try to measure it. Put an oscilloscope on the pin and watch the voltage when you try to "print" the drawer open.

 

[Modelworks]

Is the hardware looking for a 5v port ? Or the original voltage of a serial port. PC serial ports were not TTL 5V devices until fairly recently. Before that they used voltages of 3v-15V that could handle more current. Some devices use that extra voltage for other functions. Finding a pci card that supplies those voltages/currents might not be easy.

 

[Mark R]

It may well be a power problem. Serial ports do not provide power as standard - so devices connected via serial need a seperate power supply.

There is a non-standard method of providing a limited amount of power through a serial port, to allow certain types of device to function without a separate PSU. Although this used to be common for PCs to supply this, this has disappeared from modern PCs as it's usually unnecessary and it saves money and compatability problems omitting it.

It sounds like the drawer isn't getting enough power. So you should check that your serial port card can supply power at the voltage (either 5V - non-standard - or 12V - more common) requried by the drawer, and make sure that this is configured (this may be by jumpers on the card).

 

[JPS]

Thanks for everyone's help and ideas. The voltage issue is starting to look like the crux of the problem. As I mentioned above, Dell support confirmed that the RS-232 port on the Dell Dimension L933R, where the drawer was originally connected and worked properly, did have 5V available for devices connected to it. I have thus set the current PCI card for 5V using the single jumper on its PCB.

As of this morning, here is where things stand:

1) Tested the COM/RS-232 port with a loopback cable and a hyperterm session. It tested fine so the port is communicating as best as I can tell.

2) I then set the cash drawer as a "Generic Printer" on COM1 using the "Generic IBM Graphics 9pin" driver. At the end of setup, a test page was printed and viola, the cash drawer popped open! This is essentially the same configuration the cash drawer was in when it was working before.

The problem now is that I cannot pop the drawer open a second on third or fourth time by printing another test page

I have also uninstalled the cash drawer as a printer on COM1 and dropped to a command line to try and pop the draw by issuing commands such as:

ECHO>COM1

or

ECHO [[>COM1

I am getting no response from the cash drawer when I try and communicate from the command line.

Additionally, these are the current COM1 Port settings:

Status for device COM1:
-----------------------
    Baud:            9600
    Parity:          None
    Data Bits:       8
    Stop Bits:       1
    Timeout:         OFF
    XON/XOFF:        OFF
    CTS handshaking: OFF
    DSR handshaking: OFF
    DSR sensitivity: OFF
    DTR circuit:     ON
    RTS circuit:     ON

Anyone see anything I am missing?

 

[JPS]

Problem solved - I used a USB-to-Serial port adapter and now everything works fine.

 

[Paperdoc]

Glad you found a solution. But FYI, I think you were looking in the wrong place.

Our retail store was using an older POS software package on a 486DX2 - 66MHz machine running Windows 3.1 under DOS 6.22. The POS software actually is a DOS application that plays well in a DOS window. The Star sales slip printer was driven off the RS232 serial port, and it had an output to the cash drawer that simply sent a 5v pulse to the drawer's solenoid. Within the POS software, it was set to terminate the data stream to the printer every time with a CHR$(7), and the printer would use that as the signal to "kick" the cash drawer open.

A year ago I upgraded to a new machine all around, including a mobo that has a serial port, running Win XP Home, again establishing a DOS window for the POS package, and it works fine. Only problem was, it would not print! It kept giving me error messages about the printer. It turns out that the newer Windows insists on taking total control of the Serial Port, and will NOT allow application software to write to it directly. Apparently the old app was trying to do just that. Rather than upgrade my software to the latest version at significant expense, I found the right solution with the software supplier's help. The key is to execute a DOS command sequence using NET USE to re-direct a PARALLEL port to a serial port. It won't work the other way, and you can't redirect a serial port data stream to another serial port. So, in the POS software I re-configured it to believe that all printer traffic was to be sent to that same printer but on the LPT1 Parallel port. Then I constructed a DOS batch file to start up the DOS POS application. It simply runs a version of the NET USE command to erase any prior related settings, then another to "permanently" redirect the LPT1 data stream out to the COM1 port, before launching the POS software.

Then comes the tricky part for me. This is a stand-alone machine with no network connection. But I'm using a NET USE command! It re-directs data among network devices, of which I have none! The solution is a software tool included with Windows but relatively unknown. It originally was devised as a troubleshooting tool for stand-alone machines. When run it establishes and runs a software emulation of a network connection. All network traffic runs down the virtual protocol stack and back up, so Windows believes it really is dealing with a network and is happy to let NET USE re-direct LPT1 traffic to another network resource. This also is in the batch file before NET USE tries to take control of network resources. So it all works just fine.

I don't have full details with me, but if anyone wants them, let me know with a post here and I'll try to dig it up.

 

[JPS]

Ultimately, I am fairly certain there was a communication issue with the PCI Serial card I originally selected for the job as well as the original cabling/adapters my client had pieced together. Once everything was torn down and looked at sensibly, the simple solution to use a USB-to-Serial adpater made sense. The support team for the cash drawer vendor said they cringed everytime they received a support call and the customer was using a PCI card to connect to the drawer. Based on the number of different open codes and settings they had me try, it is obvious problem is not new to them.

I am sure that had I pursued finding a way to make the drawer respond to the computer's commands using the Serial PCI card I would have ultimately made it work. It may not have been elegant, but it would have worked. The saving grace I had in all of this was that the first time the drawer was setup, the client said they encountered huge problems, so this is nothing unexpected.