Hello David,

 

This may sound crazy and off the wall but, Is the printer cable an IEEE 1284 type cable(Bi-Directional)?  I remember from my days of selling Computers , printers…etc that some printers would run slow as molasses if they where using a standard (Non-Bi Directional) printer cable. Generally this applied to Ink Jet printers, however, it may be part of the problem.

 

Hope this may be of some help to you.

 

Richard A. Starkey

 

 

 

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of david blocker
Sent: Wednesday, July 04, 2001 10:15 AM
To: [EMAIL PROTECTED]
Cc: Conroy, Frank; Tellef, Karen
Subject: Printing to high speed dot matrix printer from Windows

 

Dear R:Base folks

 

I CAN"T believe there is not a simple solution to this ridiculous problem Frank Conroy and I ran into this week in installing a conversion and enhancement of an R:Base for DOS application to R:Base for Windows.

 

Working with Frank, Karen Tellef and William Mason, we have set up a slick inventory control system for a company that is in the TRANSFER business. They are at the fish pier in Boston, and their facility consists of a large refrigerated warehouse space with many truck bays. Trucks are pulling up all day (and night sometimes) with loads of fresh or frozen fish, which stay very little time in the facility before they are shipped out again.  Four salespeople work their butts off in a cramped little office at the edge of the warehouse entering orders and printing out bills of lading.  THey are harrassed all day by truckers impatiently waiting for their paper work so they can get on the road.  The pace is very fast; to accomodate this, they purchased a high speed Lexmark 370 printer which when printing in Draft mode prints 700 or so characters per second. When the application ran in DOS, all four of them could be entering and printing these bills of lading (on pre printed forms with carbons) nonstop and the printer would be printing them so fast that by the time they pressed [Enter] and got up from their chairs to walk the four steps to the printer, despite the high volume and four stations sending bills all day, the bill of lading was done and sitting there waiting to be torn off.

 

Monday, we installed the new system, where we had put little attention on this bill of lading as a minor and easy report and put attention instead on the very complex inventory control system, and bar coding application we were implementing.

 

IMMEDIATELY, we learned about the Achille's Heel effect.  The bill of lading report was suddenly taking so long to print (25 - 30 seconds per for the simplest one item bill) that they were backed up to the point where they didn't get out of work Monday, a very busy day, till 1 AM.  We MUST speed up this printing by Friday or they are going to go back to the DOS app until we can figure it out.

 

Here's the details:

 

Four PC's, running Windows 98.

Windows 2000 is the server system

All printing goes to a Lexmark 370 Printer.

All printing cycles through a PC which IS very slow, just a Pentium.

The Lexmark has four fonts built into it:

  Fast Draft, at 700 CPS

  Draft, at 630 CPS

  Courier and Gothic letter quality at 150 CPS

 

Tech support at Lexmark suggested we use a font in R:Base that matched one of the built in fonts.  For now, the best we have been able to do has been by:

*  Using Century Gothic Regular 10 font

*  Under Windows print manager, setting the print settings to print coarse text, graphics at the simplest resolution

*  Using a PRNSETUP "printer name" command in the R:Base for WIndow program for this printer followed by an OUTPUT PRINTER command

 

The result is that as each new BOL prints, you can watch the printer take 5-6 seconds "setting up", then about another 9 seconds to print the simplest of the BOL's.  Clearly, it's printing at the 150 CPS speed.  Originally, the printer WAS printing a line, then cycling back to the left before starting again.  With the changes we figured out, at least it now prints left to right, next line right to left, and so on, hence the cutting the time in half.  (The ideal, which they had under DOS, was NO delay on starting and maybe 3 seconds to print even a complex BOL)  On the more complex BOL's, something wierd happens.  The report is based on a detail table, with many rows sometimes per bill.  To save paper, the report prints as a group header the lot number and item name (eg, Lot 142 Cod) and then creates in a footer a list of the weights of the individual boxes (sometimes as many as 100) as a long text string with commas between them which wraps onto several lines to print the weights of the boxes being shipped from that lot.  In DOS, as in R:Base for Windows, the report CREATION is very fast.  In DOS, the PRINTING is also very fast, with each line printing right out.  In WIndows, these individual lines of weights cause a second or so delay between the lines!  The sales reps and truckers are losing patience fast.

 

In addition to the above we have tried:

 

*  Printing to a file; the report doesn't print correctly and the printer still doesn't use the draft font when we TYPE it out.

 

Frank's had a brilliant idea for a temporary fix to stave off the wolves which we will be trying today / tomorrow: In WIndows app, don't print, just flag a row in the bill of lading table as ready for printing (such a column already exists and is indexed).  Then create a little DOS program that will connect to the database and in a constant loop look for rows in the table where status = ready to print, and print the BOL. 

 

We will try this and hope it works. But I can't believe that we can't get R:Base for Windows to print to a high speed dot matrix printer in fast draft mode!!!!!  SOMEBODY SOMEWHERE must be doing this!

 

Any and all ideas are welcome!

 

Thanks

 

David Blocker

 

 

Reply via email to