用于 .Net 支票打印的 POS
目前，我们已在 POS 应用领域全面实施了支票打印。 它在 Windows 上运行，用 C# 实现，并使用 POS for .Net。
我们遇到的一个问题是，收银员太急于在支票盖完邮资之前一秒钟左右就将其取出。
如果在打印过程中支票被拉出，我们无法让打印机停止接受支票。 滑动 LED 指示灯闪烁并进行检查，直到成功调用 BeginRemoval() 和 EndRemoval() 为止，除非您进行检查以使其立即返回，否则不会发生这种情况。
我想知道是否有一种方法可以在没有支票的情况下禁止打印机需要支票。 我认为只是我们没有正确调用一个方法。
具体来说，问题是如果您调用 BeginInsertion() 和 EndInsertion()，两者都成功，并且在应用程序调用 BeginRemoval()/EndRemoval() 之前检查将被删除。
有人有 C#、C++、VB 或任何相关语言的工作示例吗？ 我需要一个插入支票、打印、等待删除以正确处理错误的示例。
*更新：我将此问题转发给爱普生，并要求提供示例应用程序。 他们无法生成一个，但向我指出了一个 DirectIO() 调用，据说该调用适用于 TM-H6000 系列以取消滑动插入。 然而，我还没有让它发挥作用。 希望我们能弄清楚并发布修复程序。
*更新 2：爱普生回复了一些 DirectIO() 操作，据说可以解决该问题。 但是，在尝试调用 DirectIO() 时，我不断收到 ErrorCode.Illegal。 有人有在旧设备上使用 DirectIO() 的示例吗？
应该有效的代码：
_printer.DirectIO(121, 0, null); //121 is a constant for EPSON_DI_HARDWARE_RESET
更新 3：赏金！
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!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
以下组合解决了该问题：
OPOS 一般来说可能相当愚蠢，我建议尝试不同的版本。 我们尝试了最新的（版本 2.6），情况更糟，但 EPSON OPOS ADK 2.5 SP 10 似乎在我们的环境中最稳定。
A combination of the following fixed the issue:
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.
如果我是你，我只会在打印机上安装一个塑料盖，这样他们就不能这么快拿到支票。 :)
If I were you I'd just install a plastic cover on the printer so they can't grab the check so quickly. :)
需要多少程序员才能拧紧一个灯泡？
没有，这是一个硬件问题。
我喜欢 Spencer 的防护装置来防止这种情况的想法 - 除非硬件理解这个问题，您可能无法通过软件来修复它。 您提到，当这种情况确实发生时，您必须签入，以便可以将其吐出，从而重置机器。 那里有一个培训问题，并且需要大量支票大小的空白纸条。
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.