Friday, September 04, 2009

Pos .Net Series, Post #6 – Performance, and Locating Service Objects

This is the sixth post in a series on Pos .Net. You can find the first post here, or see all the posts here.

I’ve combined the topics of performance and finding service objects into one post because there’s only a little to say about each.

First, performance is another one of those device dependent issues. I’ve had remarkably different performance even between the Epson OPOS service objects and the Epson native Pos .Net service objects, and sadly the latter is the one that seems to perform the worst. You’d think the OPOS service objects would be slower because of COM if nothing else, but that doesn’t seem to be the case. The Open and Claim methods in the native Pos .Net service objects can take half a second or so each to run, and sometimes setting the DeviceEnabled property can also take a noticeable amount of time.

Because of this it’s best to open the device once on start-up and close it when you shutdown, rather than every time you want to use the device. If you can do the same with Claim/Release and DeviceEnabled then you’ll get the best performance possible, but you won’t be sharing devices with any other software on the computer. You may need to invent configuration settings to say whether you claim at start-up or on each use, otherwise you may run into problems when a customer wants to use other software with the peripherals.

As for locating service objects, this is quite a mission. It seems not a lot of vendors have native Pos .Net service objects and those that do don’t publicise them all that well. More common are OPOS service objects, which are usually compatible with the Pos .Net system and are generally easier to find. The downside is they don’t support plug and play, they are COM based so require registration etc. which can lead to DLL Hell and performance may not be optimal because Pos .Net uses a special shim layer to integrate to them. Despite that, if an OPOS service object is all that’s available its better than nothing.

There isn’t a single repository on the web to locate service objects for Pos .Net, or even OPOS. Since Pos .Net and OPOS are useless without service objects you’d think it would be easier to find them, and that publishers would have a vested interest in advertising them.

There are a few websites that provide lists of service objects;

Monroe Consulting Services Site

Software Informer Website

In an attempt to provide a single/more complete source I’ve started my own collection which I plan to update as I come across new ones, or have them submitted to me by my readers. You can find my own list at;

Pos .Net and OPOS Service Object Links

I have tried to list all the service objects I could find or find references to, along with whether or not they are for OPOS, Pos .Net or both and a download link wherever possible. If you know of any service objects or supported devices not listed, please contact me with the details.


  1. Your blog is excellent. While POS .NET is a game changer (USB devices, self powered, plug and play), the problem with POS .NET is the lack of documentation and lack of good anecdotal information is a downfall. This combined with exceeding difficult time finding out about service objects from manufacturers makes implementing POS .NET quite frustrating.

    Your blog is a godsend. please keep up the articles.

  2. Hi,

    Thanks for the comment, it's always good to hear that sort of thing !

    I'd say the documentation in the Pos .Net SDK is pretty good in terms of how to implement an application using it, but it is of course written from the point of view that everything works and you have service objects available. Also, some of the information is a bit spread out among different pages, so it can be hard to find all the little tricks and traps you have to know about.

    I agree that outside of the SDK documentation, there isn't a lot said... but the recently created Pos .Net forum is a good resource too.

  3. I'm deployment device component to control all the OPOS device for my Point of Sales (POS) system. I had Open/Claim all my OPOS device during program startup.
    During POS operation, I can have multiple print job class that print to the same printer and hook the printer outputcomplete/deviceerror event to each print job class. My problem is when there is one printjob fail, all the printjob class that hook to printer event will received the same event.
    For outputcomplete event, i use OutputID for filtering those event but for deviceError event , HELP!!
    So, is there any method i can do to prevent this?

  4. Hi TuanFoo,

    The inbuilt mechanism for dealing with this would be the claim/release mechanism, i.e don't call these on start-up but rather every time the printer is accessed, and only connect the print job that has the device claimed to the error event.

    Other than that, you will have to implement your own solution somehow... tracking which print job is active and which class owns it and calling it back at the right time, or inventing your own claim/release mechanism based around thread locking (might be faster than the service objects implementation).

    Sorry, there isn't a magic answer in this case.

    You might want to suggest in the Pos .Net forum that outputid is added to the event args of the error event in Pos .Net 1.13, they might add it in the future.