OPOS Service Object causes application crash

Question

Hi all,

I appears that the OPOS service object of our printer is sometimes misbehaving and causing our application to crash completely. I'm saying service object here, but it might as well be caused by another (driver) component that is out of our control. If we disable the printer we never have a crash.

I could live with an exception being thrown when something goes wrong, but in this case the application just terminates without giving us a chance to react - no exception is thrown. I didn't even realize that an external (unmanaged) dll could crash the .NET runtime. I would expect Pos for .NET to handle this situation, but apparently it does not. Is there any known solution for this? This probably is a more general problem, so any pointers to a solution are appreciated.

Thanks,

Bert.

Answer 1

Does the application keep open and claim the OPOS printer driver while the application runs? Or do you go through the whole cycle to open-claim-print-release-close?

I ran into a similar problem with a combination of OPOS and service objects for an application in my book. By doing the open-claim-print-release-close for the printer and another OPOS driver seemed to keep the applicaiton running smoothly.

-Sean

---

www.sjjmicro.com / www.seanliming.com, Book Author - XP Embedded Advanced, XPe Supplemental Toolkit, WEPOS / POS for .NET Step-by-Step

Answer 2

We open-claim-enable the printer at application startup and keep it claimed/enabled from then on. I could of course give your suggestion a try. In fact, what is the best practice for this? Our application is the only user of the printer so keeping it claimed for the entire application lifetime seems perfectly reasonable.

A really big problem is that this error is very hard to reproduce. It seems to occur at random instances in time and of course most of the time in the production environment ;). I would be fine with trying out all kinds of open/claim/enabled patterns if we could at least prevent an application crash until we find the best one.

Thanks,

Bert.

Answer 3

When your application crashes, do you know if/what exception is thrown?  Are you able to isolate it to a specific API?

It is possible that you are getting an unexpected error from the OPOS SO, but I would expect this to come back to you as a PosException().  If this is the case you should be able to handle it.  

There is also a possibility that the SO has a crash/bug in an async thread, in which case the best advise would be to report the problem to the OPOS SO manufacture.

Answer 4

We have a try/catch around our main method as well as an UnhandledExceptionHandler to log exceptions. Both of them don't log anything when the app crashes.

From the printer, only use open/claim/deviceenabled/close, printnormal, cut and directio to open the cashregister (we already tried to leave out the latter and going through the cashregister SO, without seeing any improvement).

We don't use async printing, so that should not cause any problems.

At this moment we are trying out Sean's suggestion of going through the open/claim/enable cycle every time we access the device. I'll report on this later on this day or week when I have any results.

Bert.

Answer 5

Ok.. the application seems to be running (more) stable now.

It's really incredible how bad and inconsistent many OPOS drivers seem to be. This has already cost us so much time.

Bert.

Answer 6

I am glad it is working better. Can you share what devices/manufacturer and what is using a service object / OPOS driver?

-Sean

---

www.sjjmicro.com / www.seanliming.com, Book Author - XP Embedded Advanced, XPe Supplemental Toolkit, WEPOS / POS for .NET Step-by-Step

Answer 7

We're using the Toshiba TRST-A10 with driver version 1.005 on the Toshiba (WillPos) ST-A20 terminal. We have also tested with a Star (can't remember the exact type) and Citizen CT-S2000 printer, who don't cause the same problems (they do have other issues unfortunately :) ).

Bert.