View Full Version : Linux to emulate/act as a printer.
Peteris Krumins
12-25-2003, 08:22 PM
Hello,
I have a device which outputs data to a printer.
I have to collect these data and do smth with them.
Today (working already 15+hours), i read a lot about parallel
port and how data is transmitted/received, so i wired
my own cable:
data to data,
pin 1 (at pc) to pin 11 (at device), so i could write not busy
pin 10 (at pc) to pin 1 (at device), so i could read strobe
pin 16 (at pc) to pin 10 (at device), so i could write ack
pin 17 (at pc) to pins 12 and 15 (at device), so i could write
not out of paper and not error (tell that nothing is wrong with
printer)
ground to ground,
other cables not used.
My idea is to control the status registers, so i (linux box) could
act as a real printer, for example if i saw 'strobe low' (reading
status ack (pin 10 at pc which is connected to device's pin 1),
i'd know device is sending a byte, i would acknowledge that
(by writing to pin 16) and continue reading byte by byte.
Unfortunately something is wrong. I have tested the wiring -
it is ok. I know about hardware invertion in parallel port, so
i high and low pins correctly.
The device just holds 'strobe' high, data bit 2 high and data bit 4
high. As i understand the device waits me (printer) to low busy,
and do the same to error and out of paper. I have done it but the
device never changes those strobe, bit2 and bit4.
If i connect the device to a printer, the printer prints data out
perfectly. I dont have so advanced devices to trap printer and device
to see their conversation..
So something is wrong, i must ask if i have have understood how the
printers work correctly:
1) If there is no paper or is error, those pins are set high.
2) Printer sets busy low, indicating it is ready to accept data
3) Device sets data pins high, putting a byte on the wire, and sets
strobe low.
4) Printer sets busy high, indicating it is processing data
5) Printer reads data pins.
6) Printer sets busy low, sets ack low, waits ~ 5us, highs ack
7) goto 1, procedure continues.
Am i correct?
Also, please, if you know how to do this easier, be so kind and
tell me.
Charles Howse
12-28-2003, 05:48 AM
Previously Peteris Krumins <pkruminsREMOVETHIS@inbox.lv> wrote: Hello,
I have a device which outputs data to a printer. I have to collect these data and do smth with them.
Today (working already 15+hours), i read a lot about parallel port and how data is transmitted/received, so i wired my own cable:
data to data, pin 1 (at pc) to pin 11 (at device), so i could write not busy pin 10 (at pc) to pin 1 (at device), so i could read strobe pin 16 (at pc) to pin 10 (at device), so i could write ack pin 17 (at pc) to pins 12 and 15 (at device), so i could write not out of paper and not error (tell that nothing is wrong with printer) ground to ground, other cables not used.
My idea is to control the status registers, so i (linux box) could act as a real printer, for example if i saw 'strobe low' (reading status ack (pin 10 at pc which is connected to device's pin 1), i'd know device is sending a byte, i would acknowledge that (by writing to pin 16) and continue reading byte by byte.
Unfortunately something is wrong. I have tested the wiring - it is ok. I know about hardware invertion in parallel port, so i high and low pins correctly. The device just holds 'strobe' high, data bit 2 high and data bit 4 high. As i understand the device waits me (printer) to low busy, and do the same to error and out of paper. I have done it but the device never changes those strobe, bit2 and bit4.
Is ack high? Otherwise it might see an endless ack and not continue.
If i connect the device to a printer, the printer prints data out perfectly. I dont have so advanced devices to trap printer and device to see their conversation..
So something is wrong, i must ask if i have have understood how the printers work correctly: 1) If there is no paper or is error, those pins are set high.
As far as I remember, yes. That is why printing to an unconnected
printer port gives "out of paper". The inputs have pull-up resistors.
2) Printer sets busy low, indicating it is ready to accept data 3) Device sets data pins high, putting a byte on the wire, and sets strobe low. 4) Printer sets busy high, indicating it is processing data 5) Printer reads data pins. 6) Printer sets busy low, sets ack low, waits ~ 5us, highs ack 7) goto 1, procedure continues. Am i correct?
Are you waiting for strobe inactive with your ack? I think that
while strobe is active the sending device is not listening for any
acks. But I think the above is essentially correct.
Also, please, if you know how to do this easier, be so kind and tell me.
I think you can do without busy.
There is one other problem. Linux process sheduling is 10ms resolution.
If the device just sets strobe low for 1us (as it may do by the standard),
your linux-box may never see that. There are several solutions:
1) Have the strobe cause an interrupt and write a kernel-driver for it
(might be too slow still, since task switching may take too long).
2) Have strobe trigger a 8-bit latch (for the data) and a flip-flop
(so you know a strobe happened). Read the data, clear the flip-flop
and give the ack. With this linux process scheduling does not matter
at all.
Caveat: It has been a long time since I did something with the
paralell port. I might remember things wrongly.
Arno
--
For email address: lastname AT tik DOT ee DOT ethz DOT ch
GnuPG: ID:1E25338F FP:0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
"The more corrupt the state, the more numerous the laws" - Tacitus
MyLounge.com Site Map
Forum:
Cars,
Cell Phone,
Database,
Games,
Home Improvement,
IT,
Music,
School,
Sports,
Web Design,
Web Server,
Weight Loss
The MyLounge.com forum is intended for informational use only and should not
be relied upon and is not a substitute for any advice. The information contained
on MyLounge.com are opinions and suggestions of members and is not a representation
of the opinions of MyLounge.com. MyLounge.com does not warrant or vouch for
the accuracy, completeness or usefulness of any postings or the qualifications
of any person responding. Please consult a expert or seek the services of an
attorney in your area for more accuracy on your specific situation. Please note
that our forums also serve as mirrors to Usenet newsgroups. Many posts you see
on our forums are made by newsgroup users who may not be members of MyLounge.com
Term of Service
vBulletin v3.0.7, Copyright ©2000-2009, Jelsoft Enterprises Ltd.