I have a laboratory equipment that performs some chemical data
analysis and emits a printed report. The printer port is the only
output interface to the world.

The problem is that I would like to capture the data with a computer.
I tried, ingenuously, to make a polling software to read the data, of
course it failed loosing some characters. Even though I have taken
care of the handshaking, I guess the problem is with the STROBE short
duration.

I have searched the Internet for a simple solution, but I still did
not found, everybody that had the same problem solved in some other
way.

I think that maybe the simplest thing to do is to convert the parallel
signal to serial, and read it nicely through the serial port. But I don't
know exactly how can I convert the parallel signal sent to a printer
to a serial one.

I have PRN2FILE dated 1988 ! - it was a PC magazines utility.
As the name suggests, it sends printer output to a file.

Used to work well for me but haven't used it in a long while.
This works from DOS which may not be what you have.
If you want a copy (all 1,392 bytes :-) ) email me privately and I'll send
you a copy.

Russell McMahon

> I have a laboratory equipment that performs some chemical data
> analysis and emits a printed report. The printer port is the only
> output interface to the world.
>
> The problem is that I would like to capture the data with a computer.
> I tried, ingenuously, to make a polling software to read the data, of
> course it failed loosing some characters. Even though I have taken
> care of the handshaking, I guess the problem is with the STROBE short
> duration.

>Hi Russell
>
>
>Maybe I my explanation was not clear, I am not very good in english.
>
>My problem, by now, is to capture the PRN file, if I had the PRN file
>I could use the software you suggested, and probably I would like to
>have it.

Try to manipulate the READY/BUSY signal with a flipflop instead of that
complex NZ project. You'd clear the BUSY signal and the machine would set
it with a STB. Then you can read 8 bits and clear the flipflop again.
This could be done directtly with a PIC. If the machine ignores READY then
you have a problem. But I've never seen anything drive a pp that ignores
the READY/BSY signal.

I agree with you about converting the parallel data to serial and reading
it into the pc that way. You won't need to write pc software for this; you
should be able to use a terminal program to capture the data.

There are parallel to serial converters on the market - or at least there
used to be. That might be the fastest way to solve your problem.

If not, it should not be very difficult to wire up a pic to do the job.
There is *plenty* of information on the net about the centronics parallel
port.

I am assuming that your equipment that generates the data uses handshaking
signals to avoid over-running the printer. If so, you let the pic toggle
these to control the flow of data. Latch a byte, send it to the uart (or
bit-bang if you like) and continue. It takes more time to describe than to
actually do it.

>Hi,
>
>I have a laboratory equipment that performs some chemical data
>analysis and emits a printed report. The printer port is the only
>output interface to the world.
>
>The problem is that I would like to capture the data with a computer.
>I tried, ingenuously, to make a polling software to read the data, of
>course it failed loosing some characters. Even though I have taken
>care of the handshaking, I guess the problem is with the STROBE short
>duration.
>
>I have searched the Internet for a simple solution, but I still did
>not found, everybody that had the same problem solved in some other
>way.
>
>I have found LPTCAP
>(http://home.clear.net.nz/pages/kheidens/lptcap/lptcap.htm), which
>seems to do the job, but I would like to know your opinion about what
>would be the best choice.
>
>I think that maybe the simplest thing to do is to convert the parallel
>signal to serial, and read it nicely through the serial port. But I don't
>know exactly how can I convert the parallel signal sent to a printer
>to a serial one.
>

Pic Dude writes:
> Either way, why do you say that converting to serial is
> the simplest thing? I would think that working with parallel
> signals is easier.

It seems to me that converting that parallel data to serial would turn
the handshaking to be performed in hardware, so it will be fast, and I
would not loose (synchronization) strobes and bytes
consequently. Additionally I could be helped by the serial port
buffer.

About the PDF Writer, I don't know if I understand your suggestion,
but I would need to configure a printer like I do in my computer,
isn't it? The problem is that the equipment is "closed", it just sends
ascii data to a printer.

> In practice what I need is to connect a cable from equipment I
> mentioned to the computer and simulate a printer behavior.

Sounds like a perfect application for a PIC and maybe a 24LCxxx serial
EEPROM for buffering data, doesn't it? Or you can still find parallel to
serial converters, they used to be quite common and still are pretty easy
to find. Of course by the time you order one and have it shipped, you
could build a PIC solution to do the work for you!

>Thanks for all the contributions you gave to my ideas.
>I will try to follow the idea of use a PIC to do the job.
>My second choice is to use a Parallel to serial conversor.
>Rodrigo Real

Note to all: He has a piece of lab equipment that outputs parallel
data. End of story. No pdf readers running on his voltmeter, etc.

1. You tried to read the data by polling the strobe bit. Yes,
it is too fast to "catch".

2. Whatever you used to catch the data (a PC?) may have a feature that
lets you program the input strobe bit to "latch", rather than
trying catch it as a transparent read. You could also
use interrupts but I'll bet you want to avoid that, for simplicity.

3. You could use a PIC, but you actually have to solve the same
problem. You must either "latch" that strobe input, or make it
interrupt the PIC.

4. The simplest solution is a piece of hardware on the
strobe line to either stretch the pulse or latch the data
entirely, as Peter described. It would take one chip.

5. Note that if you build a serial converter you will _still_
have to solve the "short strobe" problem. And once you do,
converting it to serial really isn't necessary.

On Mon, Aug 26, 2002 at 10:07:36AM -0700, Barry Gershenfeld wrote:
> >Thanks for all the contributions you gave to my ideas.
> >I will try to follow the idea of use a PIC to do the job.
> >My second choice is to use a Parallel to serial conversor.
> >Rodrigo Real
>
> Note to all: He has a piece of lab equipment that outputs parallel
> data. End of story. No pdf readers running on his voltmeter, etc.

I do think that some missed that. However the parallel to serial converter
suggestion was valid. It would convert the parallel output into a standard
RS232 bit stream that could be input into any ordinary serial port.

>
> 1. You tried to read the data by polling the strobe bit. Yes,
> it is too fast to "catch".

That seems right.

>
> 2. Whatever you used to catch the data (a PC?) may have a feature that
> lets you program the input strobe bit to "latch", rather than
> trying catch it as a transparent read. You could also
> use interrupts but I'll bet you want to avoid that, for simplicity.

Starting here is where the ACK and BUSY flags of the parallel port can
be your friends as it'll allow for flow control.

> 3. You could use a PIC, but you actually have to solve the same
> problem. You must either "latch" that strobe input, or make it
> interrupt the PIC.

One other option though: 40 pin PICS have Parallel Slave Port hardware which
creates an 8 bit hardware parallel interface. Not sure about handshaking off
the top of my head though. But in any case the hardware will track the the
strobe so that you don't have to do it in software.

>
> 4. The simplest solution is a piece of hardware on the
> strobe line to either stretch the pulse or latch the data
> entirely, as Peter described. It would take one chip.

My favority for this is a 74HCT573 or 74HCT574. They will latch all 8 bits.
Add a flip-flop for ACK/BUSY and you're in business because the hardware will
then be completely self latching at whatever speed you want to pull data off.

>
> 5. Note that if you build a serial converter you will _still_
> have to solve the "short strobe" problem. And once you do,
> converting it to serial really isn't necessary.

Yes if you build one. However if you buy one, it'll have the handshaking built
in.

>4. The simplest solution is a piece of hardware on the
>strobe line to either stretch the pulse or latch the data
>entirely, as Peter described. It would take one chip.

It may take two. I think one needs an inverter somewhere besides the
flipflop. There is no need to latch the data usually, as the sender won't
change the outputs until it is allowed to write again. Effectively
withholding ACK should stretch the output but some evil devices only check
for BUSY. Even so the data does not change until the next strobe.

>Note to all: He has a piece of lab equipment that outputs parallel
>data. End of story. No pdf readers running on his voltmeter, etc.

>5. Note that if you build a serial converter you will _still_
>have to solve the "short strobe" problem. And once you do,
>converting it to serial really isn't necessary.

The parallel to serial converter I and others recommended to Rodrigo is an
off the shelf unit. Cuts hardware to plugging in three cables, software to
four mouse clicks (if I remember getting into HyperTerminal correctly.)

How DO I connect my Fluke voltmeter to a pdf reader? Never thought of that
before but it sounds interesting.

I'd say you're on the right track. I'd be tempted to try it this way,
assuming you can manipulate your PC's parallel port pins directly:

Use the remote equipment's STB line to clock data into an 8-bit latch,
like a 74LS374.

Use an SR flip-flop to latch the STB line from the remote end. Now it
doesn't matter how long it takes the PC to read the data. The same
flip-flop can be used to keep the ACK and/or BUSY lines high until the PC
has a chance to deal with the data.

Once the PC has read the data, simply pulse the reset input of the SR
flip-flop. This resets the STB latch and raises ACK and/or BUSY

Next, a project that may be of some use. This project has a circuit design
available and software for capturing data from a legacy device that uses a
printer. I don't know if you want this data for a PC or for a PIC. But the
circuit should be usefulhttp://home.clear.net.nz/pages/kheidens/lptcap/lptcap.htm

1. Reset a flipflop that sets READY (this sends a false ACK that is
ignored by the device).
2. The STB signal from the printer sets the flipflop:
When the flipflop is set READY is reset and ACK is NOT sent
3. You poll the flipflop and see that it is set, read the data from D0..D7
and go to 1.

>Hi
>
>Barry Gershenfeld writes:
>
> > 4. The simplest solution is a piece of hardware on the
> > strobe line to either stretch the pulse or latch the data
> > entirely, as Peter described. It would take one chip.
>
>It seems that most of you think that this is the simplest solution. In
>fact I think that too :).
>
>So I'm going to change the order of my "tries" and put this one as a
>first try.
>
>If I understand right, a general algorithm could be:
>
>1 - Latch the STROBE line
>2 - lock the sender (manipulating ACK and BUSY signals)
>3 - read the data lines
>4 - free STROBE line
>5 - unlock sender
>
>What do you think? It seems right isn't it?
>
>[]s <--- is this a world wide know icon?
>Rodrigo
>
>--
>http://www.piclist.com hint: The list server can filter out subtopics
>(like ads or off topics) for you. See http://www.piclist.com/#topics
>
>
>