In my last post I discussed how the UPOS specification, and by extension Pos .Net (and OPOS) are supposed to provide device independence, but fail due to differences in service object implementation. In this post I am going to discuss some of the specific differences I have found with the hardware I have available.
Epson vs. Epson
I had a TM-T88III and a TM-T88IV both of which are Epson printers (the T88III has since died). Neither of these devices supported plug and play even when configured to using an xml file, and must be setup using the Epson SetupPOS program.
When you configure the TM-T88III there is relatively little to configure, except for port names and so on. When configuring the TM-T88IV, however, you get an option to say whether or not bitmaps stored in the printer using the SetBitmap command are stored in NVRAM or0 not. Event though the Epson TM-T88III also has NVRAM and can store and print images, it’s service object doesn’t support this setting. The TPG printer I have also doesn’t appear to have any option to use NVRAM.
There is also no way to determine how this setting is configured via the Pos .Net interfaces. This means you have no idea whether you need to call SetBitmap every time your application starts, or only when the image changes.
Not setting the image (with SetBitmap) often enough could mean your application won’t print images when you expect it to. Setting it too often could cause corruption to the memory or use up all it’s write cycles, depending on the type of memory used, and will cause an unnecessary performance hit to your application anyway.
There’s also a significant performance difference between the OPOS and native Pos .Net drivers from Epson, and sadly the native Pos .Net ones seem to be slower on the Open and Claim methods.
Epson vs. TPG
I also have a TPG A779, and this has distinct differences in implementation to the Epson TM-T88IV.
When calling SetBitmap on the Epson, it appears you can send any bitmap you want and the service object will convert it to the format required by the printer. The TPG printer, however, will throw an exception for any bitmap that isn’t a 1 bit per pixel monochrome bitmap (which is harder to create via a System.Drawing.Image object than you might expect).
Additionally, the SetBitmap method in the Epson service object will throw an exception if the extension of the image file isn’t .bmp, while the TPG one doesn’t seem to have this requirement.
The TPG printer can be setup to use plug and play if you create an appropriate xml file to map the hardware id’s to the service object, but the Epson one cannot because of the additional configuration it requires. That having been said, even the TPG doesn’t work exactly as expected when configured for plug and play, and has some odd issues around the claim functionality if the device is disconnected and reconnected after it has been claimed.
My current code also has issues with the TPG printer when trying to set the alignment for text. The code works perfectly with the Epson TM-T88IV for left, right and centre aligned, but with the TPG all text is left aligned. The TPG printer can print text in the other alignments, as my code has worked with it in the past, but I have changed some thing I can’t figure out that has broken it with the TPG device… this shouldn’t be possible though, it should work with both printers or neither.
The Epson service objects work fine when you are logged into"The TPG service objects throw an exception if the Windows user account is not at least a power user." Windows as a non-administrative user, however the TPG service objects throw an exception on open if the user account is not at least a power user. For most retail environments, even power user is too permissive for most staff, and this can cause you a problem at deployment time.
Also, as an aside, while both printers appear to print very quickly once started the Epson ones take a lot longer to start and stop printing than the TPG ones. I suspect this is because of work done in the service object at print start and end, possibly something to do with opening ports or some such.
These are just the differences I’ve found between three devices and service objects in the same device class. No doubt if I had more devices to test with I would find even more differences.
The worst differences are those where one service object throws an exception when another service object doesn’t. That will usually cause your system to either stop with an unhandled exception, or best case scenario, report the exception to the user and give them the option to retry the print or not… which is useless since reprinting will result in the same error (and possibly an incomplete receipt), and failing that the user is still going to the get error every time they print.
The morale of the story is… even though you’re using Pos .Net or OPOS, always test your system with a specific device and service object before telling a customer to purchase and install it.