Maker Pro
Maker Pro

Computer (Linux os) to emulate/act as a printer.

P

Peteris Krumins

Jan 1, 1970
0
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.


Thanks,
P.Krumins
 
P

petrus bitbyter

Jan 1, 1970
0
Peteris Krumins said:
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.


Thanks,
P.Krumins

Peteris,

A lot of info about interfacing you can find at:
http://www.beyondlogic.org/
From "Interfacing the parallel port" you will learn that PE (Paper End) is
active high and nFault is active low. So if you keep these pins high it will
be interpreted as PE.

You did not mention some other pins. nAuto-Linefeed, nInitialize and
nSelect. You'd better satisfy them by pull-up resistors of let's say 10k as
you can't be sure this has been done internally.

Are you sure you changed the direction of your (receiving) parallel port to
input?

Are you sure you don't mis a strobe? This pulse may be as short as 1us and
can easily be overlooked when polling it. So you either have to use an
interrupt on the receiver side or you have to add some extra hardware that
lengthen the pulse until it has been read.

BTW, why are you using the parallel port? When your source computer runs
either Windows or Linux, it can be easily instructed to sent the printer
data to a serial port. Which can be handled on the receiving side using
available software. If you do not have the necessary access to the source
computer, you can also try to find a parallel to serial converter.

petrus
 
P

Peteris Krumins

Jan 1, 1970
0
Peteris,

A lot of info about interfacing you can find at:
http://www.beyondlogic.org/
From "Interfacing the parallel port" you will learn that PE (Paper
End) is active high and nFault is active low. So if you keep these
pins high it will be interpreted as PE.

Oh. This must be one of resons the wiring did not work as i expected.
Will solder it a bit differently (PE and Fault).
You did not mention some other pins. nAuto-Linefeed, nInitialize and
nSelect. You'd better satisfy them by pull-up resistors of let's say
10k as you can't be sure this has been done internally.

I just left the other pins, as they were not needed.
I will satisfy them by a pullup resistor.
Are you sure you changed the direction of your (receiving) parallel
port to input?

Yes, i changed. I tested it by connection +5 from other computers
parallel port then reading that input pin.
Are you sure you don't mis a strobe? This pulse may be as short as 1us
and can easily be overlooked when polling it. So you either have to
use an interrupt on the receiver side or you have to add some extra
hardware that lengthen the pulse until it has been read.

Might be i missed it because the minimum pulse i can poll is ~10us.
I also tried a tight while (1){} loop, trying to make the handshake
and read data. Data never changed but it must be because of Fault being
high.
BTW, why are you using the parallel port? When your source computer
runs either Windows or Linux, it can be easily instructed to sent the
printer data to a serial port.

Printer data to a serial port? How is this done?
The source (which sends output to a printer) only has a parallel port
and that device is not a computer.
Which can be handled on the receiving
side using available software. If you do not have the necessary access
to the source computer, you can also try to find a parallel to serial
converter.

Parallel to serial converter seems to be my last chance if i will not
be able to get the parallel port working.


Thanks,
P.Krumins
 
Top