POS for .Net Check Printing

Question

We currently have check printing fully implemented and in the field for a POS application. It runs on Windows, implemented in C# and uses POS for .Net.

We are having an issue where cashiers are too eager and pull out the check a second or so before it is finished franking.

If the check is pulled out during the printing process, we cannot get the printer to stop accepting checks. The slip LED indicator blinks and will take checks until a call to BeginRemoval() and EndRemoval() are called successfully which cannot happen unless you put a check in for it to spit right back out.

I was wondering if there is a way to disable the printer from wanting a check when no check is present. I assume there is merely a method we are not calling correctly.

Specifically the issue is if you call BeginInsertion() and EndInsertion(), both succeed, and the check is removed before the application can call BeginRemoval()/EndRemoval().

Does anyone have a working example in C#, C++, VB or any language for that matter? I need an example of inserting a check, printing, waiting for removal that handles errors properly.

*UPDATE: I forwarded this issue to Epson, and asked for an example app. They have not been able to produce one, but pointed me to a DirectIO() call that supposedly works on the TM-H6000 series to cancel a slip insert. I have not gotten this to work, however. Hopefully we will figure it out and post the fix.

*UPDATE 2: Epson replied with some DirectIO() operations that will supposedlly fix the issue. However, I keep getting ErrorCode.Illegal when trying to call DirectIO(). Anyone have an example of using DirectIO() that works on a legacy device?

The code that should work:

_printer.DirectIO(121, 0, null); //121 is a constant for EPSON_DI_HARDWARE_RESET

UPDATE 3: BOUNTY!

Answer 1

If I were you I'd just install a plastic cover on the printer so they can't grab the check so quickly. :)

Answer 2

How many programmers does it take to screw in a lightbulb?

None, it's a hardware problem.

I like Spencer's idea of a guard to prevent this- unless the hardware understands this problem, there is probably nothing you can do in software to fix it. You mention that when it does happen, you have to stick a check in so it can be spit back out, resetting the machine. There you have a training issue, and a need for lots of check-sized, blank slips of paper.

Answer 3

A combination of the following fixed the issue:

• Better screen prompts and animations for the user (as well as better training)
• Discovered this store had an older version of OPOS (we upgraded them)
• We removed transactional printing from the check printing process (although we still use it on receipts)

OPOS in general can be pretty dumb, I recommend trying different versions. We tried the newest (version 2.6) and it was worse, but the EPSON OPOS ADK 2.5 SP 10 seems the most stable in our environment.