-
-
Re: Slow processing
What print driver? Try chaning emulation
Should be using the KX driver -
Re: Slow processing
Put it on the networkComment
-
Re: Slow processing
USB is a lot slower than TCP/IP. =^..^=If you'd like a serious answer to your request:
1) demonstrate that you've read the manual
2) demonstrate that you made some attempt to fix it.
3) if you're going to ask about jams include the jam code.
4) if you're going to ask about an error code include the error code.
5) You are the person onsite. Only you can make observations.
blackcat: Master Of The Obvious =^..^=Comment
-
Re: Slow processing
If I were to take this literally, you are saying that the files are already rendered. The .prn extension typically comes from a Windows 'Print to File' operation.
It would be a 'Ready-to-Print' file not requiring any driver processing. Like a PDF, it can be sent directly to the printer via a network port (Generic Text only driver on Port9100), copied into a Windows UNC shared Printer(or device NetBios Printer share), or copied to a Windows Shared printer spool folder. (The 2 later are generally command line operations using SMB)
Hell you could even FTP them over with a PUT command, Kyo’s FTP is EZ.
So if this is true the only variable is how you get it to the machine, and it should not be by a typical 'File->Print' method unless you are using the Generic Text only driver.
Either way FRPO Host buffers are for the old dedicated controllers with limited RAM (like the FS-9530) and have no effect on newer machines."Being ignorant is not so much a shame, as being unwilling to learn" - Benjamin Franklin
Comment
-
Re: Slow processing
Yes the files are preprocessed, the customer uses two installations of the driver, one with the output configured to a file, and the other one is renamed for the use of the printing software.
The printer is embedded into a card Mailing machine, so when a barcode reader detects a card number, the software sends print data to the machine.
The problem with the speed is because for each card is one print job. If you send a .capt file with 12 sheets of data, the printer goes fast; but it slows down with a pile of .prn jobs.Comment
-
Re: Slow processing
Well you are kind of in a box with this one. Sounds like a specialized application not open to a lot of configuration changes.
With separate jobs over the network, the system spools down and up between jobs I expect like Crystal Reports has a habit of doing.
The jobs need to be assembled prior to sending as you did with the .capt file.
The 2 queues system is interesting, the first queue is probably producing the pure image and the second I expect is adding some mailing meta-data or images.
With processing in this way, each file has a PCL reset code (ESC%-12345x) in it and will cause an engine cycle between jobs.
I do not recall any configuration options to resolve this, perhaps someone else has. (I learned too many other printer languages to want to master Prescribe).
While not a fan, a Fiery might provide better job queuing and delivery to the printer.
Good luck."Being ignorant is not so much a shame, as being unwilling to learn" - Benjamin Franklin
Comment
-
Re: Slow processing
No problem. I was thinking about the PDL side of define this problem and I would only expect it to effect actual rendering time but could change the job processing.
The reset command I posted was for PCL and most apps like to use it because post-driver process manipulation is simpler than Postscript (Crystal reports in EPIC Healthcare software has actually moved to PDF/PS and correcting their media calls is a bugger).
Either way you didn't say if they were actually using a Kyocera driver or if they used the same driver for both processes. I am just curious so excuse me going on about it.
The Kyocera Unidriver in PCL or KPDL(for Postscript applications) is light and represents the type of driver most of these specialty report apps are developed around. They may even be using a generic HP Unidriver and it would be fine.
That being said, for the second Driver in this process, the KX driver PDL can be set to KPDL and you will have an option to 'Allow data Passthrough'. This should prevent the KX driver from re-rendering and messing up what ever commands the specialty app is sending.
Getting a look at it via Data Capture MM977 is always informative at getting under the hood of what apps like this are doing to the print code. In the new generations you can run it past the first job instead of have it stop at the first job reset command.
Let me know if you find anything!"Being ignorant is not so much a shame, as being unwilling to learn" - Benjamin Franklin
Comment
-
Re: Slow processing
Check if this crappy WSD port is enabled and in case it is - switch it back to TCP/IP portComment
Comment