Slowdown on Printing

[steve]

My users are experiencing problems with slight slowdown in performance when printing starts and during long printer outputs. 

Background: The application is a bespoke Order Processing System, accessing data files residing on a PC (currently running XP) designated as a file server (i.e. no user access) and printing to serial printer attached to the file server PC.
The operators are really fast at order entry, I've watched them and they can enter 5 or 6 orders a minute!

There seems to be a momentary pause when the printer actually starts printing which is causing problems with the responsiveness of the Order Processing (sometimes causing several keystrokes to be queued which then screws up the flow of the order entry for the operator). Also, if there are multiple pages to printed, then the performance/responsiveness of the Order Processing definitely takes a hit.

Whilst Order Processing is happening there are no other (foreground) tasks running (i.e. no internet, no Word, no Excel, etc) as the PC is being used as a dedicated Order processing terminal.

The output to printers is pure text with embedded Epson codes for formatting (i.e. not pdf etc).

As the PC is a quad-core is there anyway running an independent vDos image so that the Order Processing (in one vDos image) program spools the printer output to local files and the print unspooling and forwarding to the printer is handled within a different core?


Any / all suggestions are welcome as the alternative is breaking some of the operators' fingers so that they slow down on the order entry!!!  :-)

Thanks,
Steve

[Jos]

Is print spooling enabled at the printer driver? Sending the spooled (by vDos) RAW data to the printer driver should then be a snap (milliseconds). You could further try if adding TIO:0 to the printer directive in config.txt works with your application. If so, at least the print process should then start immediately, without a timeout of 1 or 5 seconds.

Jos

[steve]

Hi Jos,

Thanks for the quick response. It's probably a very obvious question but I am exactly sure what you mean by "Is print spooling enabled at the printer driver?". Do you mean on the Order Processing Win-10 computer or do you mean on the File Server Win-XP computer? Are you referring to a vDos some printer driver or a windows printer driver.

Also will TIO:0 work if more than one Order Processing workstation is trying to output to the same printer (or will the printouts be interspersed)?

Thanks,
Steve

[Jos]

Primarily at the Windows 10 PC: The program not being responsive, suggests it’s simply not executed by vDos at those moments. vDos would be waiting for Windows completion of the print job, while with effective print spooling this should be almost instantly.
Check that the printer driver is actually assigned to the shared server printer (not using some printer port redirection), Printer spooling is on, Bidirectional printing off in the print driver properties. Eventually test with “COPY /b #LPT1.asc LPT1” at the vDos command prompt that the copy is seemingly instantly. If not, check the printer spooler service is started.

Jos

[Jos]

vDos has to decide when a DOS print job is supposed to be completed, then pass that on to Windows. The default method is to wait for no data sent to the printer for 5 seconds, or 1 second if the last printer command was a formfeed.

TIO:0 (seconds) disables this waiting time and relies on the program using DOS API file open, write and close calls to print. If your program however writes directly to a hardware port, or uses the BIOS, there will of course be no file close call, and nothing could be printed at all.

So this just dismisses of the timeout vDos normally respects before it processes print data. Printouts can’t be interspersed when the vDos working directory is local. If centralized (on a server) only when using a third party DOS-to-Windows print processor (mostly theoretically and due to the timeouts of that program).

Jos

[steve]

Aug 31, 2018 19:58:03 GMT 1 Jos said:

vDos has to decide when a DOS print job is supposed to be completed, then pass that on to Windows. The default method is to wait for no data sent to the printer for 5 seconds, or 1 second if the last printer command was a formfeed.

TIO:0 (seconds) disables this waiting time and relies on the program using DOS API file open, write and close calls to print. If your program however writes directly to a hardware port, or uses the BIOS, there will of course be no file close call, and nothing could be printed at all.

So this just dismisses of the timeout vDos normally respects before it processes print data. Printouts can’t be interspersed when the vDos working directory is local. If centralized (on a server) only when using a third party DOS-to-Windows print processor (mostly theoretically and due to the timeouts of that program).

Jos

Hi Jos,

Thanks for the advice. I will have to visit the customer's site and do some experimenting - this will be the week after next so I wont be able to respond for a while.

Regards,
Steve