Home » .Net Framework

POS Receipt Printing

Hi All,

I have been setting up a pos system, and would like to print receipts on an epson TM-T88IV printer. I have been using some code and it prints fine on the microsoft recepit printer simulator. If the code works for the simulator will it work for the TM-T88IV straigt out the box. If not what will I need to install driver wise etc..??

Any help and code will be greatly appreciated


11 Answers Found


Answer 1


Epson have a thing called the epson  OPOS ADK for .Net which contains native service objects for a lot of their printers, including the TM-T88IV. You should download this to get the correct driver/server object. To get it you need to register at www.epsonexpert.com, then when you log in go to the application developement area, then click on the OPOS section... scroll to the bottom of the OPOS downloads pages and you'll find the .Net ADK which actually contains native service objects for pos  .Net.

Sadly, I would not guarantee your code  will work  with the real Epson device just because it works  with the simulator... it should, and it might, but different service objects behave different ways and so the device indepenence is kind of broken. You can read about some of the problems I've had/differences I've encountred with Epson and TPG printers at http://www.yortondotnet.com/2009/08/pos-net-series-post-4-device.html.

In short, since the simulator  is not using the real service object or hardware, there's no guarantee. You'll have to try it to be certain. Also, even if your code does work without modifications, you will still need to install  the Epson service objects and configure them with the Epson SetupPOS application that is also installed before you'll be able to use the real device.

Answer 2

Yort. you are correct.  Sadly this is a big downfall for POS for .NET.  Promised as a way to bring device independence, this promise is far from reality.  Without any certification process or standards based auditing, each IHV develops their service object as they see fit.  While it may be loosely based on the UPOS standard, this is not adequate to fulfill the notion of device independence.  The real losers in this are the small ISVs who try and give their customers a competitive advantage, but instead create headaches for them.

I have said it many times before, Microsoft stands to benefit greatly if POS for .NET takes off.  A lot of older systems (dos, foxpro, access, etc) are rolling over and being redeveloped in .NET.  Certainly, POS for .NET would be the logical choice for developers in this situation.  Microsoft  should fund or encourage at least one manufacturer in each device class (scanners, check scanners, micr, biometrics) to ensure that ISVs have options or at least availability.  Without true choices its really not much better than OPOS, and in some ways just implementing against the OPOS standard would be less maddening because there arent many expectations.

To have each ISV reinvent the wheel isnt efficient and doesnt make sense when Microsoft could easily create service objects for these devices or provide code  samples.  for example in the case of Biometrics, there is such a dearth of information available it is almost eerie.   To the extent is almost seems like we are doing this for the very first time.  And certainly that cant be the case.... can it?

Answer 3

I agree with your sentiments, although it is kind of possible this is the first time small ISV's have had the ability to put biometrics stuff in retail applications. I have never been in a retail store where biometrics have been in use anywhere a customer could see (perhaps time clocking out the back, but I didn't see that), and most retailers are fairly tight and won't buy hardware they don't need... if there's no compelling reason to put biometrics in the store they won't.

You also have to consider the uses... there are already plenty of non-biometric systems for controlling user/staff access to the software, and using biometrics for identifying customers is full of pitfalls... will customers give you their biometric data ? Are there privacy issues ? How many customers can you actually store enrollement data for and search in any kind of quick/useful timeframe etc.

Also, biometrics are relatively new to pos  .Net and certainly new to UPOS etc. so from our perspectice it is a 'new' thing, even if biometrics themselves have been around in one form or another for a while.

I do agree on your other points though. Some guys from Microsoft have actually contacted me about my blog entries and have asked for information on my experiences using Pos .Net, the system  I built etc. because apparently they get relatively little feedback on Pos .Net itself... I've given them plenty of info and we can only hope this helps improve the situation in the future... but you have to appreciate their position too. The UPOS standard wasn't created by just Microsoft, and if they create their own new standard they'll be punished on the net and in the media for not being open etc... most of the other companies that were involved in UPOS probably don't have too much of a vested interest in updating it, even if they should. MS can only apply pressure to IHV's, not force them to write service objects, and if they build something that doesn't work  with OPOS (and is better for it) then you get a chicken and egg scenario where no one uses the technology because there's no hardware, and no one is building hardware/drivers because no one is using the technology.

Of course, all of these problems are solvable to some extent...

Answer 4

I suspect that some of the tension here is that Microsoft offers a competing product (POS2009) so they dont want to give out any "production" code  (service objects) that would aid other developers.  This to me is outrageous.   I understand that it is normally up to IHV to develop drivers but in this case if none or few of them are stepping up to do this, and Microsoft has developed drivers it should provide them to developers.


Answer 5

PosReady2009 is an OS and I don't see how it's a competing product to Pos .Net... in fact if there were more service objects for .Net it could help  increase sales of PosReady2009 since Pos .Net is a Windows technology, and ships as part of PosReader2009/WePOS... more hardware support would equal more people interested.

Also, it isn't up to MS to write the service objects (except for hardware they produce, like perhaps their desktop finger print  readers) and so that's why MS don't release code  themselves. The point is that MS hasn't developed drivers, except a couple of sample ones like the sample Barcode Scanner service object, and that was created as a sample for IHV developers to work  from more than anything else.

I think the point is that MS actually need to apply pressure/encourage/give reason to the IHV's to develop the drivers... and that's hard.


Answer 6

The simulator  is useful to verify basic application operations based upon the Unified POS standard.This is especially helpful when one does not yet have a physical device available.It is not, however, intended to replace testing with a physical device.The simulators do they provide the full set of capabilities of a real device (for example, barcode printing  is not included in the simulator) nor are they intended to do so.

Given that the simulators generally offer the minimum functionality required by UPOS, generally if an application is able to use the basic operations for a given device category, then the simulator is useful to help  development when a physical device is not yet available.

All UnifiedPOS devices require Service Objects to be installed.Thus once you have the printer  (TM-T88IV in this case) you still must install  (and configure if required by the IHV) the service object for a given device.Think of UPOS as a device object model, but you must still install the driver.


Answer 7

While I understand your concerns, this is really more of an issue with the UnifiedPOS standard itself, and is not specific to POS for .NET.It is true that there are no requirements to certify that a device/service object conforms to the standard – this has been a topic of the standard board for many years.

Microsoft does offer some basic testing guidelines to help  IHVs conform to the standard, but as this is an open standard there are no enforcement mechanisms.

I would suggest you bring your concerns to the UPOS technical committee as it is always looking for ways to improve compatibility and the “promise” of device independence.


Answer 8

Hi Sylvester,

Thanks for that last comment,  I agree and have already said in my blog that I think it is UPOS that is deficient rather than Pos .Net specifically.

You mentioned some basic testing guidelines that Microsoft has... where can we find these ? It might be helpful to put a sticky link at the top of this forum to those guidelines for people looking to develop service objects. I think these would be really, really useful... both to service object developers and to application developers.

Also, would it not make more sense for Microsoft to gather feedback from it's user base and present that feedback to the UPOS board ? It seems that user opinion backed by Microsoft would count for more than the odd email from unknown internet users.


Answer 9

Do not use the OPOS ADK. It's very very slow, and I don't mean code  wise, but printing  is slower. 


Epson T88's, 200 series, 300 series to my knowledge require only the Generic / Text Only print  Driver. Granted this driver  doesn't get a lot of the kind of neat features that OPOS but the large majority of receipts  are just text. Logo's can be directly loaded into the RAM of the printer  and thus never need to print through the actual print code. 


Just my .02. I currently work  on POS development and we've found this to be the best solution.


Answer 10


I agree, I have also found the Epson ADK to be slow... in fact in some cases I've found the legacy OPOS drivers from Epson to be faster even though they are COM based and should do the same thing otherwise.

However, I would point out;

1. Sometimes you NEED the extra features provided by OPOS. For example, we have one EFTPOS integration where we are required to perform ALL printing  on behalf of the EFTPOS PinPad, and they also require (for type approval) that we prevent further EFTPOS transactions from occuring if we detect a printer  error. That's pretty easy to do with OPOS (at least where the service object supports status notifications), but quite difficult to do with the Windows printer driver, especially when it's set to print  through a spooler etc.

2. Some people may choose to support OPOS because it allows them to support a wide variety of devices from a variety of manufacturers... at that point it may be easier and/or cheaper to just use the Epson OPOS stuff instead of maintaining a seperate system  for using the Windows printer drivers. Of course if the printing speed is an issue they may have to invent the alternative instead, but that depends on their requires.

3. With the TM88 III (I think) and 88 IV (defintely) you can actually configure the service object to save images passed to it via the SetBitmap method into NVRAM, which gives you the same perf benefits as using TMFLogo and can make deployment easier (no need to actually remote control a PC and install/run TMF logo to update/install the logo if you can push it out to your software over the network and have it make the setbitmap call for you). This does have it's own problems however... it's not supported by all printers and you don't want to flash the image to RAM everytime you startup or open the device, so it requires extra code  to use this feature properly... but again it can save massive amounts of time on deployments.

4. Transactional printing, and making the minimum number of print calls possible as well as claiming the device only when neccessary (which is often on startup, rather than every print) can make a significant improvement to performance, although it still doesn't match the printer driver  speed.

In our own system we actually have seperate 'drivers' within our own software, one that uses OPOS for those customers that require/want it, and one that uses the Windows Printer driver.

Thanks for pointing out the speed issue though, as I have forgotten to mention it in the past and it can be a real issue. Of course, perf varies between service objects anyway.



Answer 11

Do not use the OPOS ADK. It's very very slow, and I don't mean code  wise, but printing  is slower. 


Epson T88's, 200 series, 300 series to my knowledge require only the Generic / Text Only print  Driver. Granted this driver  doesn't get a lot of the kind of neat features that OPOS but the large majority of receipts  are just text. Logo's can be directly loaded into the RAM of the printer  and thus never need to print through the actual print codec


Just my .02. I currently work  on POS development and we've found this to be the best solution.

It's very valuable, Many thanks to your description!


<< Previous      Next >>

Microsoft   |   Windows   |   Visual Studio   |   Sharepoint   |   Azure