I want to be able to make my printer (HP DeskJet 1280 on USB) print out all raster data I have sent to it so far, without ejecting the page. I am sending only plain raster graphics and cursor positioning commands — no vector graphics, no text.
More precisely, I have two questions:
1) After sending some raster data to the printer (with Transfer Raster Data ("\033*b%dW")), how to make it print it out right away and stop, without ejecting the page?
2) After sending a vertical cursor positioning command with a positive argument (e.g., Vertical Cursor Positioning (Decipoints) ("\033&a%+dV")), how to make the printer advance the paper to the new position right away and stop there?
(Note that even solving only (1) would be almost sufficient, because advancing the cursor could be done indirectly by sending a blank raster of the appropriate height.)
Since PCL is a page description language, it could be actually impossible to do things at such a low level. But after an extensive search in the PCL documentation and the Internet, I have not yet found a definite negative answer either.
It seems that the printer has some kind of internal buffer to store its data, and that it flushes (i.e., prints out) that buffer when it grows large enough. If there were a command to tell the printer to flush that buffer immediately without doing anything else, everything would be fine. But I have not found such a command. Even "\033*rC" (End Raster Graphics) has no immediate effect.
I am using CUPS' USB backend to communicate with the printer, and have verified (using usbmon) that the backend actually sends all my commands to the printer as soon as it sees them, so it cannot be the issue of data getting stuck in the driver.
Commands that print out partial pages include, for example, "\033E" (Printer Reset), "\033%%-12345X" (Universal Exit Language), "\033&r1F" (Flush All Pages (including partial pages)) — but all of them also eject the partial page.
Can somebody suggest a clever way to do what I want, or confirm my impression that it is an absolute impossibility?
Related
I am transmitting and receiving data using aux cable and GNU RADIO between two laptops.
I have implemented DQPSK using PSK mod block.
The problem is that while receiving I have to provide a delay, some integer value e.g 0,1,2 etc.
It is different every time.
Is there a way to dynamically check for the right delay value or any other workaround to this situation?
I have written 'start.' at the start of data being transmitted and 'end.' at the end.
I have to give a demo for this project and I dont want to manually change the delay at runtime.
I cannot find the .cc file of file sink in GNU RADIO, I can change the C++ code according my requirement but there is no such file.
Below is the screenshot of the grc file on the receive side.
Any help will be appreciated.
Since there's no way for the receiver to know when the transmitter started transmitting, it decodes stuff before there's actually anything to decode.
In essence, you need some kind of preamble or so to tell your receiver when to start – side effect of having something like that would be that you could correct some things (the two sound cards don't share the same oscillator, which leads to a symbol rate offset, and a center frequency offset).
You basically added that framing - your start. and end. strings.
I cannot find the .cc file of file sink in GNU RADIO, I can change the C++ code according my requirement but there is no such file.
It's in gr-blocks/lib; however, you shouldn't modify the file sink. Really,
I'd recommend you take the time to go through the guided tutorials, use gr_modtool to generate a general block which has a state machine that looks for the bits of your start string and drops everything before and including those, and then passes everything till it sees the stop string. That all can be done with a single state machine, and a bit of python or C++ code.
The device is a label printer. It can be connected to via bluetooth and USB. I would imagine it is running some kind of linux, as it has a fairly complex interface/screen, but am not sure. In fact, this is something I would like to determine. But my goal is to get a shell, or some kind of 'meaningful' connection through which I can send commands/data which will trigger print events by the printer without using the manufacturer's software
Connecting to the device in ubuntu via USB creates /dev/usb/lp0. I tried connecting to this using python's serial module, but it couldn't connect to the serial port.
Via bluetooth I was also able to connect, using hcitool scan to get the device's MAC address and then rfcomm to connect (using this approach) . This created /dev/rfcomm0, which I was able to connect to and send data to using python.
Is it feasible to mimic the data normally sent over usb/bluetooth by the manufacturer's software to print without the software? I assume getting this would be possible by 'sniffing' data sent over bluetooth while a normal print command is sent by the manufacturer's software (although I suppose there's no reason it would look intelligible to a human).
If this kind of mimicry is possible, I am wondering whether simply sending the equivalent data over bluetooth, for example, would result in a print event. So far I have no reason to believe that data I send via the bluetooth connection is not being received, but I have yet to get any kind of response (data or physical) from the bluetooth connection.
Any advice/suggestions on how I might achieve my overall goal would be appreciated
This is certainly possible (sorry for the answer 6 years later, but hopefully this will help anyone later in need). I have a similar problem and this is how I solved.
I have a MHT-P80F thermo printer. I figured out in settings that it supports a protocol called TSPL. These are the instructions you need to send to a printer and tell it to do either raw text printing, or even bitmaps.
All you need to do is to construct the correct bytestream (in mostly human-readable ASCII) and send it to /dev/usb/lp0. I have not tested it via bluetooth but I assume it should be similar.
For example, if you want to print out a "Hello World", these instructions will suffice:
CLS
SIZE 80mm,50mm
GAP 5mm,0mm
HOME
TEXT 0,0,"0",0,1,1,"Hello World"
PRINT 1
Each line is separated by a "\n".
Explanations (more could be found by searching TSPL):
CLS Tell the printer to clear all previous staged commands.
SIZE Tell the printer the size of each label (width, height).
GAP Between each label there's 5mm space without paper.
HOME (Re-)locate the paper roll for a new print.
PRINT Start printing of 1 copie(s).
Note these instructions are for the use of discrete labels. For a whole paper roll it might be different. TSPL implementations on different printers may differ, so you might to experiment a bit.
Generally, if you can print a bitmap, then you can print virtually any document (e.g. using PIL in Python or Jimp in Node.js to generate an image beforehand). So here's the most useful BITMAP command:
BITMAP 16,24,40,256,0,<BYTE STREAM>
where
16: the starting (left most) X coordinate for your bitmap
24: the starting (top most) Y coordinate for your bitmap
40: the width of bitmap, in BYTES (see below)
256: the height of bitmap, in DOTS
0: mode of print, 0 being overwritting anything in that region
and <BYTESTREAM> being the binary data(black/white) of this image, from left to right and from top to bottom.
The bitmap width is given in bytes, so each byte represents 8 horizontal continous dots in the image. The highest bit 7 being most left, the lowest bit 0 most right. So if as in example we write 40 in this parameter, the image would be 40x8=320 dots in width.
The bitmap height, on the contray, is given in dots.
Most such thermal printer have a DPI of 203. This is an interesting start point to investigate into: 203/25.4 = 7.99, or rounded as 8. So for the printer, each 8 dots equals 1mm. In the above example, X=16 and Y=24 (both in dots) corresponds to starting location X=2mm and Y=3mm.
And finally, you generally do not need to inverse the color of this image. In BITMAP command, a 1 in a bit means correctly white or non-printed dot, and 0 means the black or heated dot.
I am not sure about bluetooth but for USB printing you can use the cups library (licups) and use the APIs to do the priting. It uses IPP protocol. Usually cups uses a .ppd file specific to the printer (which contains the details about the printer) for installing it. For new language versions such as PCL5, 5e, 6 etc there are generic ppd files that can be used to install any printer that uses the respective language
I have a software that prints labels. It generates many pages with n columns to be printed in a label printer (commonly Argox or Zebra). I use report builder to do so, meaning I send the jobs through the windows driver and not directly to the printer.
I have this one customer that is having a really hard time printing her labels. The printer pauses for 15-20 seconds between one page and another.
I´ve reviewed each and every configuration I could and did not find anything.
To make my problem worse, my customer uses the Bartender software (wich comes with Argox) and when printing there it has not this delay. Bartender uses the windows driver as well.
Well, from the point of view of my client, the problem is with my software, I don´t blame her.
From my point of view I can´t control such a thing (pause between pages) once I am using the driver.
Am I wrong? Is there anything I could do to avoid such a delay?
Important Info
Argox OS 214 TT - PPLA
Drivers updated to the last version (7.2)
Serial Cable being used
Does the report software you use create ZPL output, or a bitmap? You can check this by setting your printer driver to print to a file. If the file is huge, >1MB, it's probably creating a bitmap and that could take a long time to send to the printer.
Bartender would create ZPL if using internal fonts and barcodes, so the output will be tiny and the printer is optimized to print native ZPL. If your software uses fonts not on the printer (Arial, Times new roman, etc), it will send the label down as a graphic instead of using the printer's built in fonts, which would result in a HUGE file even for a small amount of text. Same thing goes for graphics, inlined vs. recalled graphics
I'm working on an embedded home surveillance system. I want to interface a couple of serial-enabled JPEG capture cameras, maybe a couple of door sensors, etc. Problem is, I can't for the life of me figure out how to interface a camera to a microcontroller. Stills, streaming video, it doesn't matter - I can't find any how-to documentation on this.
I understand serial communications, and most of the camera documentation I've found out there describes the protocol necessary to instruct the camera to send the datastream down to the uC for capture. What they don't show is what you're supposed to do with the data once you get it.
Here's an example.
They show a great little video, and the datasheet describes which bytes must be sent to the camera to retrieve the image. What I need is an example or tutorial of some sort that will explain what to do with the stream of bytes that make up the image itself. How do I arrange those bytes into an image and save it as a file?
I've looked all over the place for a tutorial of some sort, but have come up dry. I'm not sure which processor I'll use for this project just yet, but this question isn't really processor-dependent. All I need is the algorithm, maybe a peek at a library, if one exists. I'll take that process and adapt it to my hardware, I just can't seem to find a place to get started.
Have any of you done this?
I think the details are pretty clear in page 10 inside this document:
http://www.4dsystems.com.au/downloads/micro-CAM/Docs/uCAM-DS-rev4.pdf
First, one package is between 64 to 512 bytes - flexibly defined by the programmer. Image size is the actual JPEG image itself....nothing more or less....just pure JPEG image. So the equation to calculate the number of package based on image_size / package_size is given in page 10.
Next, is that (package_size - 6) is to be consistently used everywhere, because 6 bytes are used up for non-data purpose, so (package_size - 6) will be just the data - but u have to reassemble it yourself.
To assemble the data from the package, u have to strip the 4 byte header + 2 byte trailer and concatenate all these from all the package sequentially one after another.
Other facts:
a. "Set Package Size" command must be sent from host to CAM - before "SNAPSHOT" command, which capture the image from the camera into the CAM memory buffer.
b. Next is to send "SNAPSHOT" command to capture the image into memory buffer.
c. Last is to send "GET PICTURE" command (only one time, but data will come back multiple times - see diagram in page 15) to extract out all the images....and it will come back in the form of "package" as we have defined the size earlier in "set package size". Since u have calculate the formula u will know when to stop asking for the next package. And there is a verification byte - u have to used that to make sure data is correct.
I have not used this camera but looks like it works exactly the same is a camera (C328) I have used. Send an image resolution/colour command. When you want get an image send an image capture command. The camera responds by sending a binary file over the serial link.
In Internet Cafes where people are allowed to print, sometimes they print more pages than they intended to.
I'm looking for a way to display an "Are you sure you want to print X pages?" dialog after they pressed print (in any application), but before the job is sent to the queue.
I'm looking for pointers on how to implement such a hook.
(I have considered modifying a FOSS PDF printer to first print into a PDF and then display the dialog and then if the user presses "Yes", print it on the real printer. But this seems a really roundabout way of doing this and one also loses printer-specific features this way.)
One of the things you could do which is also kind of round about, is pause the print spooler, print your job, get a page count, and then prompt the user for confirmation. If the user okays the job, then release the spooler. I don't have the API calls handy but I have manipulated spooler queues quite easily.
Of course the downside to this idea is if the queue is server-based and potential permission issues could be afoot.
Another alternative would be to force the output to a WMF or EMF file and tally the page count that way, then hand it off to the spooler. This is similar to your notion of outputting it to a PDF, but uses a native approach. (This is essentially what applications typically do(did) for doing previews-- rendering the job in a metafile format which is then displayed on screen or spooled to the printer)
Unfortunately there is no way to get the page count ahead of rendering the print job unless you are intimately aware of the contents and can judge it, so you are forced to at least go through the motions of printing.
Hope this helps.