Somebody wrote:
> Thanks to all for both the private and public responses to our problem with
> an Intermec printer. Maybe I should point out that the printer does not stop
> working while spooled output is in progress . It just skips some of the
> pages in the middle and then prints some more, loses some, etc.
>
> For those who could not read all the responses here is a brief summary.
>
> 1) It could be a wiring problem.
>      We followed the printer recommendations. Only pins 2,3 and 7 are used.
> We were planning to test it directly connected to the DTC port to see if
> there was any difference but decided to wait for more suggestions first.
Never trust a wire you haven't checked.  Especially pin 2 on a printer.
That's where those Xon/Xoff things get sent.  Without it, your printer
will act just as you have described.
 
> 2) Double check Xon/Xoff and parity settings.
>      Done.
If Intermec can do Xon/Xoff, you should be able to get this to work.
 
> 3) Try a lower speed, the printer might be too slow.
>      It is a Bar Code Labels printer. So it IS slow. Even so, if the spooler
> and the printer are singing the same tune, the spooler should be able to
> recognize when to wait. Since we are using 9600, we may try 4800 but I do
> not put much of my hopes here.
 
Probably the wrong answer.  I've seen a lot of people fooled by this.  But
you knew that. Unless--there is a problem with a lack of "robustness" in
Intermec's Xon/Xof handling.  In which case this might just do the
trick.  Or your friend who says it is impossible, might be right.
 
> 4) Verify the printer's internal memory. The downloaded label itself could
> be filling it.
>      Here I must say that the label is very simple. Just  one line of text
> and a barcoded number. No fancy fonts, no embeded graphic, nothing worth
> considering.
 
Again, I think you're right.  Another common error is to handle overflow
problems with a larger buffer.  That's like "fixing" your kid's
out-of-money problem with a bigger allowance (when he's spending most of
it on video game parlors).  The real answer is learning to budget.  Or in
this case, control memory usage by implementing proper flow control.  I've
seen cases where somebody bought a larger buffer, only to find that it
staved off the problem just long enough for the tech to get in his car and
drive away.
 
> 5) Change the port to a terminal type, modify the program to include pauses
> between groups of pages and optimize the number of seconds of delays by
> trial and error.
 
Only as a last resort.  If Intermec can't handshake with HP, this is
probably necessary.  Since this isn't perfect, you'll need better
operator-controlled restart capability than you'd have to implement
otherwise.
 
> This recommendation comes from someone who has experience with Intermec
> printers and working for a company with GOOD technical resources. He says
> that the 3000 and the Intermec printers CAN NOT handshake properly.
>
> Surprise, surprise. :-(
> (I would like to know why)
 
Possibly Intermec requires DTR handshaking, which is something HP has
never handled.  This is why we call Serial a "standard" (because it's
not), and Parallel a "compatibility" (because the standards boys haven't
messed it up--yet).  But you said it had Xon/Xoff, which should work.
 
> We decided then to try a modified approach on the last suggestion for
> testing. Since the spooler works fine on a reduced number of  pages
> (labels), we can do the testing as it is now with the following changes.
> First print the labels to disk. Make a simple program to read the disk file,
> find the number of records, and print chunks of 6 pages each with a pause in
> between to be adjusted by trial and error. Keeping it spooled may chew up
> some resources and we may change it to be a regular terminal port later. At
> that time we must reevaluate the delay between print sets.
 
Fragile solution--anything you do to speed up your system, will break it.
 
Sounds like the options aren't good.  Now for a quick check:  Hook an old
HP terminal (2392, 700/92, whatever) on in place of the printer.  With the
right baud rate and parity, of course.  Send it a long printout.  Now see
if control-S/control-Q will actually stop and start the output properly.
It is quite possible that you don't really have pin 2 working.  Only after
you have _verified_ that ^S/^Q work properly manually, should you attempt
to iron out the issues cited above.
 
One tool you really need for this: a "Check Tester" from Jameco
(1-800-831-4242, part #14285).  At $11.95, this is the most important
piece of test gear in my RS212 kit.  This has LED's for _both_ positive
and negative voltages.  Don't bother with the cheaper kind with only
positive-voltage lights.  This device will tell you when data is going
back and forth.  It is absolutely essential for finding out what's going
wrong with any serial printer connection.
 
--
         /\--.      John Beckett               "Fresh outta sigs"
        /  \  )     Southern College of SDA
       /----\---.   (615) 238-2701 voice
  \   /      \   \  238-2431 FAX
   `-'        `--'  [log in to unmask]