for the last year or 2 I have been using a serialcash draw trigger box for opening a cash draw on my POS system (model DT-100RS) or if I was attaching it to a Tablet the USB version (DT-100U).
All I needed to do was send anything to the serial port (or virtual serial port) and the cash draw would open - fine and dandy.
The hardware company has added the RJ11/RJ12 port directly inside the POS system so no need for an external box - but my software fails to open the draw.
After 3 days of trying and sending everything I could to it - by using lists on the internet
I thought i'd cracked it when the draw opened .. BUT it was a false dawn.
So I did my usual googling and found others had the same problem but no fix for the "printer codes"
Writing to COM5: (the "Hardwired" com port for the Trigger) it was opening after I had successfully opened the draw with the company test program or by sending the bytes via a terminal program or whatever other means.
If I sent the control codes:
Code: Select all
27,112,0,20,80 or even 27,112,0,50,250
numtoChar(27) & numtochar(112) & numtochar(0) & numtochar(20) & numtochar(80)[/code]
The cash draw will NOT open.
If I use Realterm (a great alternative to the missing Hyperterminal) and send the same string as numbers which are sent as the characters by the program , the cash draw WILL open.
If I then run my program - the cashdraw will open EVEN if I change serialcontrolstring to any rubbish as long as it was successfuly opened by any program before
In fact my old code will work in this case.
If I restart my machine and not use realterm to open the cashdraw first, then the same code I used will NOT open the draw.
---- and just as I wrote those words a light came on.
I rewrote my test program to wait 200 milliseconds (just a guess) after writing the data to the port before closing the serial port - SUCCESS.
I did some other tests and I only need the 27, 112, 0 as the serial string and it will open as long as I wait 200 milliseconds (probably less but who cares) before closing the serial port.
basically 27 is <ESC> and 112 'p' which is the epson printer instruction to send output to open the cash draw the '0' is cash draw 1 and if we send a 1 instead of the zero it will open cash draw 2. The two other characters where the on off timings for the pulse but they don't seem to be needed with newer circuitry.
So it seems calling the serial port close routine , closes the port before the control strings are fully transmitted - so it was a timing error which I thought it was but the protocol analyzers I used only showed me what was sent.
On a side note, when I initially tried to do the cash opening via the printer it was printing a sliver of paper - because i was PRINTING the control codes to the printer - I would assume writing to the port like this even if a printer is attached would stop that , but I haven't tried that yet - I only have 25 hours in the day
Anyway here is my little test harness - I have the close and open calls on separate buttons (i take longer than 200 milliseconds to press the button )