POS systems mostly can detect thermal printers automatically, as far as I know there are only two ways for an installed application on ios to do that, either by faking it as an Airprint or going with IPP protocol. Since it mostly matters for those application that your printer should be on the same network and subnet configuration and Airprint doesn't support thermal printers, I believe that could be choice that they are using. But my question is that if there is another way that they are all doing it? if not how an application on ipad(iOS) can detect those printers without any need for specific driver installation? If anyone can help me with this would be great!
To print to printers from iOS you can either use the AirPrint API with AirPrint enabled printers or you can implement the printer's protocol and PDL within your own application.
Some solutions include a third middleware like component to fill the gap between the mobile app and the actual device. This is not an elegant way but seems to work for some usecases.
The full process consists indeed of two steps: discovery (like setup) and actual printing (like sending a document). With AirPrint you can check the documentation to learn how Bonjour aka ZeroConf works.
Related
As the title suggests, I'm trying to mimic popular thermal receipt printers using a Raspberry Pi. My aim is to have the raspberry pi be an option for printing receipts from popular mobile based ePOS systems like Shopify POS, iZettle etc. They all support ECS/POS printers. Once I have the document I want to send it to my webserver for processing using OCR (don't need help with this bit).
Currently, I have a working printer driver (cups-pdf) and I can print directly from the iPad, however, these apps either don't recognise the virtual printer or when I pair it, they fail to print with no logs showing on the printer meaning they're failing to establish a connection.
I've also considered a virtual printer driver app that can run on the iPad directly and just handle the file from the print request by sending it to the web server, however, I don't have much of a starting point with that since I've got more experience working with native Android development.
Any and all help would be greatly appreciated and I apologise if I'm vague, I'll be happy to expand if there's anything appearing vague.
I've been looking at printer protocols, and it's still not clear to me how today's computers communicate with printers "over the wire."
Historically, I understand that computers basically started as printers (with teletype machines), but today I read about protocols like AirPrint and CUPS; I understand that some printers (all printers?) take PostScript or PDF files as currency, but I've also read about HPPCL on the FreeBSD docs. It seems like most printers ("98%") support the Internet Printing Protocol, which apparently uses simple HTTP to send "various data formats" to the printer, but I've also found source code in the CUPS repo that seems to translate raster into a proprietary language for some EPSON printers. The discussion in this other StackOverflow question seems to indicate that even IPP isn't the be-all-end-all.
I realize this is a very vague question, but I'm also kinda looking for a general answer—how do computers "get stuff to" printers today? Do we mostly send over PDFs & JPEGs, or do we send G-Code-like commands to the printers? Is it a mixture of both? Can I send commands to my printer to have it arbitrarily move the printhead around, like I can do for CNC machines?
I would not be surprised if the answer is "most printers use a proprietary interface; that's why you still need to implement printer drivers." If so—is there a higher-level standard? Is it just whatever Microsoft says needs to go into a printer driver?
Thanks!
There are multiple aspects in your questions:
what are the discovery protocols?
what are the printing
protocols and PDLs.
Discovery protocol: mDNS/DNS-SD, WS-Discovery (WSD)
Printing protocol: WS-Print (WSD), IPP.
IPP is getting more traction now.
Print Definition Language is that finally what format print job is sent to the device. Following are the some of the standard formats: OXPS, PDF, PWG Raster, PCL, PostScript, and other proprietary formats from each printer vendors.
I have written a printing application that works well. I can write files, update settings and do most all functionality from one console. But one aspect of the program has eluded me for quite a while: the ability to read the Zebra register/configuration values.
It would be good to periodically be able to read the values on the Zebra and compare them to default known good standards and to be able to reset them if necessary.
Currently, in order to see these values, I need to either use the built-in web page (networked printers only), print a report, or scroll through the printer interface. What I really need to is a method to be able to read these registers values and create a known good setup file.
Has anyone been able to find any SDK or trick to read these values using .NET (C# or vb.Net)?
The application is a windows desktop utility used on my shop floor and I communicate with the printers using either LPT and ethernet interfaces (as applicable).
I would recommend checking out the Zebra Link-OS SDK which has a lot of functionality when it comes to what you can do with Zebra printers. Specifically they have a section titled "Getting all printer settings and their configuration". However the code example they provide will not work unless your printer is a Link-OS enabled printer. If that happens to be the case then great! If not you can use the SGD class within the Zebra.SDK.Printer namespace to use Set-Get-Do commands to retrieve and change information. More information on SGD can be found in this ZPL manual under the SGD Printer Commands section.
We are making a lab instrument using an ARM9/RTOS system. The client has asked about printing simple reports from the ARM9 system. In this case, we have USB Host support in the RTOS. I'm thinking about printing bitmaps in generic PCL, hoping that will cover the widest range of printers. Is there a better way to approach this? I'm assuming the RTOS does not have printer drivers, and I don't want to support a lot of printers.
We also support USB device mode on our system, so you could plug in a photo printer, and our device would appear to be a USB stick. So that would work, but it's a bit clunky. This will be a C/C++ embedded system
Pretending to be a digital camera and interfacing with a PictBridge printer actually sounds pretty clever. It would remove the need to deal with different printer drivers, and if my understanding of the technology is correct, you could even control the operation of the printer right from your device.
On the other hand, as someone who has used a fair number of computerized lab instruments (oscilloscopes etc.) I find the ability to save screenshots from an ethernet/web interface to be much more useful. Print is dead.
Have you looked at what all the scope vendors are doing? They all have print options (I think) and I don't know what they are doing to solve this problem.
Last time I was involved with something like this, we used serial ports to talk to HP printers using PCL. That backfired as everyone quickly stopped making serial printers!
PostScript is natively supported by most printers, so you could just send it over the wire, but it would be a lot more cumbersome than straight ASCII. There are libraries, but they're bulky.
Since your device can appear to be a USB stick, a simple solution would be to generate a report as a JPEG image and then have the printer open and print it. This way, the people who want paperless output can use the image as-is, and everyone else can print it.
If I understand you correctly, you could write a formatted text file and do a "print" command through Windows in the "usb stick" mode.
For a simple report, it would be best to stick to straight ASCII. If you need some graphics, PCL would be a good choice for B/W laser printers, but I'm not sure how universal it would be for the more common ink-jet printers.
Edit: the PCL Reference Manual is available as a PDF from HP.
We have a range of PC demonstration programs for our microcontroller products. The programs typically connect to a USB HID chip on the microcontroller board. The USB chip acts as a communications bridge, allowing the programs to communicate with the micros over SPI/I2C/UART. The programs can configure the micros, and get back status information to display to the user.
We are now looking to build some standalone demonstrations using single board PCs. We would like to reuse as much as possible of our existing demo app source code. Ideally, we could just run them as-is.
Does anybody have any advice on the best way forward? The basic options seem to be WinCE or XP Embedded boards. WinCE boards seem to pull less power, which would be an advantage from a battery life point of view.
Our existing demos are built either in C++ under Borland Builder, or in Delphi.
Thanks in advance.
EDIT: see my answer below with info from a board vendor.
Free Pascal/Lazarus can compile some forms of Delphi apps to WiNCE/arm. Even visual ones.
There isn't a Delphi version for WinCE, so you would need to rewrite the applications. The same applies for the Borland Builder's control libraries. Only if you have used plain Win32 API, you would be able to port your application to WinCE easily. You may also encounter problems with the hardware access part. The Serial Port driver may not work as is. Also, you need to find a WinCE board that can act as USB host and provides HID drivers (this isn't very common).
In conclusion, I believe that you would be better of with Windows XP Embedded boards. These should run your applications as they are.
As an update, and for future reference, I thought I'd post the results of our discussions with a WinCE board vendor here. Caveat: I haven't actually tried any of this.
The bottom line is that there isn't a straightforward way to do what we were hoping for (i.e., re-compile our existing demo applications to run under WinCE). The reason is that the generic HID drivers and standard APIs that exist in desktop flavours of Windows just aren't there in WinCE.
To talk to HID devices in WinCE you need to implement a custom HID driver. This needs to support an interface allowing user mode applications to communicate with the driver, and to construct HID reports to be sent to the physical device. As this interface would itself be custom, application code needs to be updated accordingly.
WinCE application development is generally done using Visual Studio and the Microsoft compilers. The approach recommended to us was:
Create a custom HID class driver. This could be based on, for instance, the Microsoft keyboard HID driver.
Create an API for talking to the driver.
Use .net to create our GUI applications, and use PInvoke to actually talk to the API.
The end result of all this head-scratching is that to avoid the time and learning curve associated with this approach, we're going to go for a board running XP. We can then use our existing demo applications straight out of box. The trade-off is that we'll have to live with substantially reduced battery life.