I am developing a POS system for cafe-bar-restaurants. It works fine, but I have some problems regarding printers. People here suggest I use POS for .NET.
But I can't because:
My client has a machine with windows home edition as server. So POS for .NET has no luck at one of his two stores.
The previous pos software he had printed to thermal printers using GDI graphics.But was too slow dont know why.. you had to wait for 10 sec to print a receipt.
I get complaints because font is a bit small using these printers.(42 chars 80mm paper) And that is true. Native printer's font sucks way too much. All of the printers i see suck because they arent from a good brand.Also guys that developed the fonts were too bored that used latin letters mixed with local ones. But prints from graphics mode look WAY WAY WAY better and antialised and smooth and clear and nearly same speed.
Printers dont have OPOS.NET drivers. I sent emails at chinese companies that produce these printers and said that they didnt have developed one yet..
Some of these printers dont support some basic ESC/POS commands! Even command for paper feed is problematic. Only the newer printers are almost compatible but the older ones arent at all.
Using plain text + esc/pos i cant make the font larger only x times larger.
GDI seems to be the most compatible way unluckily
Our fiscal device seems to not support sending raw text to printer. It is partly implemented and works only for 32 bit systems as it is for "DOS".. Had no luck installing it. So I had to use graphics. Actually it is a virtual printer. The company that has the fiscal device told me that graphics is the best way to print a thermal receipt and I should not use plain text etc... Also asking them for OPOS drivers for some of their printer told me "what the f* are you talking about?"
So I don't know what to do. I think that I should support 3 ways of printing: POS for .NET / raw text / graphics.
Also, how do you overcome difficulties with thermal printers when sending raw text? Because graphics give you more freedom. Does the fiscal device suck for not supporting text mode?
Comments related to your numbered points:
You're right. POS for .NET won't even install on home edition. The officially supported OS's are Windows Embedded for Point of Service , Windows Server 2003 Service Pack 1, Windows Vista Business, Windows Vista Enterprise, Windows XP Service Pack 2. (http://www.microsoft.com/en-us/download/details.aspx?id=5355) Windows 7 also works from my experience. (Of course, you need the .NET framework installed as a prerequisite.)
It's probably an interface issue and I'm assuming the interface type is serial since you mentioned DOS. Serial printers take forever to print graphics.
Not only is print quality better, but speed increases dramatically if you're using any interface besides serial. Ethernet is the best modern connection type for most kitchens.
Any printer manufacturer that doesn't have POS for .NET support (or any other ARTS standard) is cutting corners and you shouldn't do business with them. The price might be cheaper, but part of the reason is they don't provide full solutions. Bad driver/software support, hardware features are lacking... That's when we developers run into these headaches.
See #4. But if you're using ESC/POS commands (which is manufacturer-specific), then you're not using POS for .NET.
ESC/POS has commands to make text double high and double wide:
ESC ! n (27,33,n) Change print style:
n=0 all styles OFF
n=16 double high print
n=32 double width print
n=48 double high & wide print
Not necessarily a bad thing; I elaborate more on this below.
Echoing my comment for #4... OPOS is an industry standard and has been around since the 90's. If the manufacturer doesn't know what you're talking about when you ask about it, they shouldn't be in the printer business.
I don't see any requirements binding you to using POS for .NET or OPOS based on what you wrote. These standards are great for quick development and supporting lots of printer models at once.
However, if you're using a DOS-based system, you're probably dumping all print data to a COM port. This doesn't mean you need to use a serial printer though. The major players in printer manufacturing offer a virtual serial port. You install a USB/ethernet printer driver (which allows you to print graphics) and then enable the virtual port. Your software sends all the data to COMn (no change). The virtual port "listens" to that COM port, intercepts the commands, and then translates them into what the USB/ethernet printer can understand.
Even if you take this route, print data sent direct to port isn't pretty and customizing it can be troublesome.
The TSP100 is probably what you'd need. It comes with a configuration utility which has both a virtual serial port and a setting to convert device font (the print data being dumped to the COM port) to graphical font of your choice. Check this link out: http://www.futureprnt.com/receipt-redesign-tool/
This question was asked a while back so maybe the requirements changed. Tablets and smart phones are taking the restaurant industry by storm now. In that case, you should definitely investigate Star's SDK for Android and iOS which includes a printing API for these OS's, print samples, and manuals: http://www.starmicronics.com/support/SDKDocumentation.aspx
Related
I have tried the sample code found at https://learn.microsoft.com/sv-se/samples/microsoft/windows-universal-samples/bluetoothadvertisement/. C#.
It uses the class BluetoothLEAdvertisementPublisher. I have built that on my machine and executed it. I start the advertisement in foreground (or background) and then start an app on my phone (LightBlue and BLE Scanner tried). My PC isn't seen (I do see other devices)
The same when I try to write similar code myself. I have also tried writing a GattServiceProvider implementing a number of services. When I publish that one, I do see the services on the phone, and can read and write to them. So yes, bluetooth IS enabled and working (to some extent) on my machine.
I have latest version of Win10, with Intel AC8265 (with latest Intel drivers). It supports Bluetooth 4.2.
So why can't I see the advertisement? There are no error messages at all and the callbacks reports the advertisement is started as it should.
I'm also a bit confused by the relation between the BluetoothLEAdvertisementPublisher and the GattServiceProvider. Both do "publish" and the GattServiceProvider seems to be able to announce itself. But there is no way to add CompanyId or ManufacturerData to it. Shouldn't both be used? And both working...
To be more specific, it looks like the GattServiceProvider does actual advertising, but only advertising the computer name, bt address and service guids. No CompanyId or ManufacturerData at all. Googling around I found some people claiming that Company Id isn't required in advertisement, and others saying it is (and has to be registered). If Microsoft is advertising without Company Id, then I guess it's allowed.
And I can kind of understand if I'm not allowed to advertise an Intel NUC as having a Company Id from a totally different company. But if that is the case, one would think that the BluetoothLEAdvertisementPublisher would give some error code when used on a Win10 machine?
I want to write a program that programmatically sends faxes. Or receives faxes. But not with a modem. I guess I'm trying to write a fax simulator. Everything that the hardware does, I want to do using software.
There are a billion SO questions on the topic, but they either suggest an online service to use or they point me to a library, which talks to my computer's modem. So here are my specific questions:
When I send a fax, I can hear the warbling on the telephone line. This tells me that my fax machine is generating tones that are consumable by the recipient's. What is that protocol? Is there an RFC which specifies how a "pixel" is converted to a "frequency"? Do the machines communicate back and forth, or is it one-way?
If we can agree that a fax machine translates sound frequencies to images, then one ought to be able to write a program which takes an MP3 of a fax transmission and outputs a graphic. What do I need to know in order to do this?
Are these questions based on any flawed assumptions? Where should I start so that I can accomplish goal #2 from above?
Actually in modem a chip called "DSP => Digital Signal Processing" is responsible to convert audio signals into digital DATA. and same can be done with a software library. there is already an open source DSP library called SpanDSP developed by "Steve Underwood" http://www.soft-switch.org/.
You can build your own application while using SpanDSP library, but it is wise to use some existing implementation of SpanDSP. Currently SpanDSP is implemented in open source FreeSwitch, CallWeaver and Asterisk PBX systems.
But if you only want to send and receive faxes without bothering low level development then try out ICTFAX Open Source FAX system.
The fax specifications you would need are ITU T4 and T30, which costs lots of money and are almost wilfully difficult to understand, and they'll refer you to the various modem standard for how the actual 'warbling' is done.
If you're hoping for something free/easy like an RFC, then you should probably give up now.
If you did want to decode an audio file, you would need to view that as two completely separate tasks - firstly decoding the tones to a data stream (build several soft-modems, for the various ways fax machines can agree to communicate), and then secondly decoding the data-stream to pixels (write a fax machine's software).
You are not fundamentally wrong that a fax machine converts light and dark into sound and then back again, or that it's possible to eavesdrop on a conversation between two fax machines and recover the image (either in real-time or via some kind of capture file, though I'm not sure that MP3 would work), but I suspect you've hugely, hugely underestimated the amount of work involved.
http://en.wikipedia.org/wiki/Fax
has plenty of background.
The ITU protocols are very involved, IIRC the exact specifications are not free.
Im in need of a solution, I basically require a way to print from a web page to a printer. But the printer needs to be standalone, either plugging directly into phone line, using a sim card etc. Does anyone know of a good solution for this?
It needs to be cheap to run, setup costs aren't that much of an issue, but obviously the cheaper the better.
If landline is okay, I believe the device you want is an antiquated piece of hardware called a "fax machine"
If wireless on a mobile network, the service plan is more of a cost concern than the hardware, though the two might be bundled together. For example, a company called bug labs is working on some kind of partnership with verizon for connecting their embedded linux device construction kit.
I need to communicate with a bar code scanner connected over a serial port in Microsoft Access. In older versions of Access I was able to use a wrapper around MSCOMM32.ocx that no longer seems to work. I can't use wedge communication because I need to use ACK/NACK which is only supported through the RS232 interface and I need to send messages to the scanner, which is also only supported through the RS232 interface.
Are there any controls in widespread use that support serial communication in Access 2007?
EDIT: In case anyone comes across this, the newest version of MSCOMM32.ocx (I believe dated 3/09) still works fine as of this writing. It is older versions of MSCOMM32.ocx that do not work.
I can't vouch for the answer, but I can say that Tony Toews is a reliable person, and on this topic, he posted on his blog last year:
An older version of MSCOMM32.OCX has had the "kill bit" flag set.
As Tony says, it's almost always better to rely on Windows APIs than it is to build your app with connections to an ActiveX control. Windows APIs don't really have the versioning problems that ActiveX controls and OCX's do.
A bit of history: We have an application, which was originally written many years ago (1998 is the first date in PVCS but the app is about 5 years older than that as it originally was a DOS program). This application communicates with a piece of hardware via serial. When we got to Windows XP we started receiving reports of the app dying after a short time of running. It seems that the serial comms just 'died' and the app was left in a stuck state. The only way to recover from this situation was to restart the application.
The only information I can find regarding this problem was apparently the Windows Message system would miss that information was received, the buffer would fill and the system would get stuck. This snippet of information was left in a old word document, but there's no evidence to back this up. It also mentions that this is only prevalent at high baud rates (115200+).
The solution was to provide customers with USB->Serial converters along with the hardware.
Today: We are working on a new version of the hardware that will run across a network as well as serial ports. So to allow me to work on the network code, minus the actual hardware we are using a VSCOM NetCom113 device. It also installs a virtual comm port on the users (ie: mine) machine.
Now I have got the network code integrated with the app, it appears that the NetCom device exhibits the same behaviour as a physical commport. This is undesirable as I need the app to run longer than ~30 seconds.
Google turns up zero problems that we experience.
I was wondering:
Has anyone experienced this before? If so what did you do to fix/workaround the problem?
Does anyone have any suggestions as to whether the original author of the document is correct and what I can do to test the theory?
Unfortunately I can't post code as the serial code is tightly couple with the rest of the system, though if you have questions regarding it I can answer questions about it.
Updates:
The code is written using Win32 Comm routines - so I am using CreateFile, ReadFile. There's also judicious calls to GetOverlappedResult.
It's not hanging per se, it's just that the comms stops. You can access the menus, click the buttons, but nothing can interact with the connected hardware. Using realterm you can see that no data is coming in or going out.
I think the reference to the windows message is that the problem is internal to windows. Data has arrived but the kernal has missed it and thus not told the rest of the system about it.
Flow control is not used.
Writing a 'simple' test is difficult due the the fact that the code is tightly coupled and the underlying protocol is quite complex and would require a lot of work.
Are you using DOS-style serial code, or the Win32 CreateFile approach?
If the former, be very suspicious: if at all possible I'd convert to the latter.
If the latter, do you know on what kind of system call it's hanging? Are you in a blocking read call? or an overlapped I/O call? or waiting on an event? (I'm not sure I have enough experience to help, but those are the kinds of questions that come to mind)
You might also check into the queue size, which you can set with the SetupComm function.
I don't buy the "Windows Message system" stuff -- it sounds fishy; you can write good Win32 serial i/o code that never uses Windows messages.
edit: does your Overlapped I/O use events? I seem to remember something about auto-reset events occasionally missing their trigger... check your overlapped I/O calls very carefully to see whether you're handling the possible outcomes properly. Perhaps there's a way to make your code more robust by automatically cancelling the overlapped i/o and restarting another read. (I assume the problem is in the read half, not the write half?)
edit 2: A suggestion: assuming the win32 side has missed a byte or packet, and your devices are in deadlock because they're both expecting each other to respond to something, can you tweak the other side of the serial I/O to regularly send some type of "ping" packet with an incrementing counter? (and log the ping packets on the PC side; that way you can see whether you've missed any)
Are you sure you have your flow control set up correctly? DTR, RTS, etc...
-Adam
i have written apps that use usb / bluetooth serial ports and have never had an issue. with bluetooth i have seen bit rates (sustained) of 800,000 bps for long periods of time. most people don't properly implement the port.
My serial port
Not sure if this is a possibility for you, but if you could re-write the code using C#.NET you'd have access to the SerialPort class there. It might remedy your problem. I know a lot of legacy code based around the Win32 API for hardware I/O ports tended to fail in XP due to timing (had a small bit of experience with MIDI).
In addition, I don't know if you can use the Win32 method of Serial Port access in Vista, so that might shut out future MS OSes from being able to use your code.