The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Point of Sale application - device integration questions

We are developing a Point of Sale application using C#.NET/SQL Server 2005/Windows Server 2003.

We have run into some obstacles with device integration and I am hoping someone here has some experience and can offer some suggestions.

We currently plan to integrate devices such as Pinpad, Magnetic Stripe reader, receipt printers, barcode readers.

We are looking at OPOS integration using Microsoft Point of Service .NET v1.11.  However, I am having major problems locating OPOS device drivers.  For example, there is no OPOS driver for Verifone pinPad 1000se on that i can locate.

We are told that we can use legacy OPOS drivers, but to really take advantage of Microsoft POS for plug and play support, we need service objects written for the device.  But alas, no manufactuers seem to have custom service objects.

I have searched the web exhaustively, but there are really limited resources for OPOS device support.  Even the big proponents such as nrf-arts.org have crappy documentation and support. 

Is there a central site to find all OPOS compatible devices and get drivers?  not that i can find.

So, my specific question is whether OPOS is the way to go?  If so, any general overview of the integration process would be appreciated.  For example, do you need to install each OPOS driver on each client machine and then register the device name and device type on the server referencing that workstation along with the com port, baud rate, etc...

In such case is a good approach to create a table on the server with the workstation unique id and for each workstation list the device type and device communication method so the server knows where to find it.

So the server looks to a particular workstation and if looking for a Pinpad type device, how does the device registeration and communication work?

Thanks,
Gary
Gary Lombard Send private email
Tuesday, June 12, 2007
 
 
We are developing Point of sale software too. If you want to use OPOS technology, please check this site, https://www.epson-pos.com/cgi-bin/sdssm/main/td_login.jsp?url_jsp=EXIT&sel_lang=en. It may be help to you.
Normally all Epson device support OPOS and also all other brand that is compatible with Epson device should be supported by OPOS.
In case of OPOS, all device need to register for using. And software need to identify what is what by registered name.
James Choi Send private email
Tuesday, June 12, 2007
 
 
Thanks. I checked it out and it has some good information on Epson products, but hardly is it an authoritative resource. It would be nice if there were a central resource for this type of information.  I guess no one wants the expense of maintaining it though.

I can't even find a forum dedicated to POS development.

For example, we are doing some pretty interesting stuff and it would be nice to share and get help in return to further the technology.
Gary Lombard Send private email
Wednesday, June 13, 2007
 
 
Why not put the POS app on hold, write some drivers, and market those?

Then build the POS app.
*myName
Wednesday, June 13, 2007
 
 
Its the manufacturers that should write the service objects for the devices.

I can't imagine it would be worthwhile to be in the business of trying to sell Service OBjects for devices.

Sounds like a losing proposition.

We can just use legacy drivers until service objects are available.
Gary Lombard Send private email
Wednesday, June 13, 2007
 
 
Unfortunately, Epson is one of the only companies really doing OPOS with their hardware and even their implementation is iffy.

To the other poster, asking about writing drivers:  The idea of OPOS is a set of standard Point-Of-Sale based calls that software can make into the OPOS drivers and not have to worry about specific implementation, so coding drivers yourself means your married forever to that hardware. OPOS is a HAL, unfortunately, it's not implemented anywhere near consistently enough to allow an application developer to REALLY ignore device specific issues.
jasallen Send private email
Wednesday, June 13, 2007
 
 
FWIW, these are the interesting acronyms to find info on:

OPOS: the one you know, COM based standard
JPOS: Java class equivilent
UPOS: Attempt to bring the above two into some sort of agreement.
jasallen Send private email
Wednesday, June 13, 2007
 
 
The OPOS/UPOS standard is severely flawed, having been designed by hardware manufacturers, each with their own agenda, rather than software developers.

The most flagrant example of this is the OPOS Tone Generator device, whose API is specifically designed to expose the functionality of the tone generator in one of Fujutsu's POS keyboards - look at the specs and laugh (or cry).

The printer device is the most inconsistent between suppliers, mainly because of poorly specified and therefore inconsistent error handling (it's the device that is most susceptible to mechanical errors - paper jams and the like, so error handing is important), and also because it is slow (so that requests must normally be sent asynchronously to get decent performance, which means that in the event of an error you don't always know what's been printed and what hasn't).

Having said that, OPOS is probably your best option, as you will be at least be able to market your application as being device-independent, even if in reality you have to tweak it for each manufacturer.

I would recommend:
- Use OPOS for the printer, cash drawer, line displays.
- Possibly use OPOS for the barcode scanner, and  MSR, though some have "keyboard wedge" software so that you can simply treat it as keyboard input.
- Not sure if the OPOS standard is adequate for other devices such as PINpads and weighscales - the protocols vary from country to country, so you need to check that OPOS is right for your target market.
Joe
Wednesday, June 13, 2007
 
 
"Why not put the POS app on hold, write some drivers, and market those?

"Then build the POS app."

I'll take a stab at answering that:

- The OP doesn't have experience with low-level applications development.

- The OP has domain knowledge in a specific industry and wants to leverage that, not learn systems-level stuff.

- The OP realizes that he may be able to sell 1,000 copies of a driver for $500 but he could sell 10,000 copies of his POS software for $10,000 each.
Karl Perry Send private email
Saturday, June 16, 2007
 
 
When creating a POS app, look at USB hardware instead of serial/parallel. You can build quite a line up with USB based devices over serial/ethernet based products.

First reasons behind this: USB drivers are far more common from companies like Epson, as they are really trying to push their USB products & add-ons.

Second reason: Most devices such as USB/PS2 Pin-Pads, Card Readers, and POS Keyboards are recongized as HID-Compliant devices, and you can directly monitor their input as most will be treated like a keyboard. Especialy the keyboards and card-readers. (And without drivers at that too)

Third reason: USB devices are far easier to add-on to a system than serial devices. Sure you can buy a Serial Addon card but that requires a free PCI slot and $20, as where you can easily get a non-powered USB hub for $5.(Better for your overhead) And even then you can add on more than serial.

Only down-side is that there (that I know of) USB driven cash-drawers. It's been a couple of years, but almost all of the units I saw where serial based. But cash-drawers are either 1 (open) or 2 (open or lock/unlock) signal driven and can be easily configured using even .NET built-in serial communication.

As for printers, Epson's line of USB thermal printers (and some impact) all support regular USB drivers and can provide all the same features as OPOS based drivers with a little extra work. (Such as drawing images, special text, and barcodes) Although using non-OPOS for printers can be a bit frustrating. Almost all of Epson's printers use roughly the same formatting for control sequences, not all devices are the same, and as such, you may have to modify code to support specific models.
Inari Send private email
Monday, July 09, 2007
 
 
And I forgot to mention only a small portion of Epson's product line is OPOS compatible.
Inari Send private email
Monday, July 09, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz