How to configure point of sale hardware in microsoft pos.net for brands that don't provide an SDK/Driver

685 views Asked by At

This is a general question about if and how you can configure a point of sale peripheral to work in pos4.net (Microsoft's point of sale for .net framework). To briefly exclaim, it isn't quite clear to me, if and how you can self configure hardware without special drivers offered by the vendor in question.

To give some context about my question. I'm researching a couple of peripherals (scanners to be exact) that I'll need to interface with c# code. I'm relatively new to this, but from my understanding, on the surface, pos4.net appears to be a .net flavor implementation of the upos specification, an abstraction layer to simplify compatibility.

Similarly, there is jpos if people want to interface from java, and opos seems to be a legacy standard. What actually confuses me, is there are a couple of lesser known brand scanners (like NADAMOO) and their compatibility isn't that opaque to me.

From my own experience before the PosExplorer recognized a HoneyWell scanner and Epson Printer they had to be configured and had software installed provided by the respective vendors. This works well, however, these lesser-known brands, don't appear to have a website nor downloadable drivers and it genuinely puzzles if they can be interfaced from.

The scanner I want to use only states it can be configured with virtual com, or act as a keyboard using a USB plug and play driver. But how can you configure the scanner to be used from PosExplorer? From bits and pieces I read, it appears pos.net requires a service object or opos driver. The former appears to be just some xml in a file?

So if the vendor doesn't provide any installable software/driver, can I support the peripherals by manually creating the xml or are there more required than just this.

<ServiceObject Type="Scanner" Name="HoneywellScannerSO">
<Device HardwarePath="COM1"></Device>
<Device HardwarePath="" HardwareId=""></Device>
<Device HardwarePath="COM6"></Device>
<Device HardwarePath="COM5"></Device>
<Device HardwarePath="COM7"><LogicalName Name="genisis" /></Device>
<Device HardwarePath="COM8"><LogicalName Name="Scanner1234" /></Device>
<Device HardwarePath="COM10"></Device>
<Device HardwarePath="COM11"></Device>
<Device HardwarePath="LPT1"></Device>
</ServiceObject>

The XML for a com based scanner doesn't look that daunting. But I'm not sure that is the right way, and if there is anything more to it? And I'm also curious how this would extend to more complicated hardware, how would you even know what XML to construct, what properties, etc.

Can somebody explain how people are doing this?

1

There are 1 answers

1
kunif On

If the scanner hardware vendor does not provide an OPOS or POS for.NET service object, you must create it yourself.
It is not something that can be used only by setting and customizing the configuration file.

If you are an application vendor/developer and have no experience with I/O device control, you should switch to a scanner from a vendor that supports OPOS or POS for.NET, or use the scanner in keyboard input emulation mode. It will be good.

If you have experience in controlling I/O devices, it is better to control the scanner device directly from your application using the COM port, without using OPOS or POS for.NET.

If you have experience with I/O device control and plan to create service objects, the easiest is to do a complete installation of POS for.NET including the SDK and it will be provided as a very simple sample. Based on the source of the scanner service object you have, modify it for the scanner you want to use.
Microsoft Point of Service for .NET v1.14.1 (POS for .NET)


Added in response to comments:

UPOS is an API standardization that brings greater portability and interoperability to both applications and devices.

It cannot guarantee full plug compatibility, but it facilitates multi-vendor support for systems, such as applications switching between devices used and I/O devices supporting multiple applications.

And since API standardization is a specification standardization, not a program or library implementation standardization, there is no working program that can be applied to actual devices.

It is also related to timing issues and the strength of the vendor's business demands.

For example, regarding barcode scanners, there is AIM(ISO/IEC-15424) as a specification for reading barcode type(symbology) notification, but when OPOS was created, it was not ISO, and even now from the participating vendors of standardization work.
Is not supported by UPOS because there is no request for it.