Slow processing

[martinar]

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.

Thanks a lot!! Your point of view is really helpful!

[PrintWhisperer]

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!

[fishleg]

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!

Sorry for being daft but what is Data Capture MM977 and how do you do it?

[martinar]

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!

Thank you!
We are currently refurbishing a fs9530dn to fulfill the client requeriments of speed. The thing is that the only machine that replaces fs9530dn is the p4060/ta5002series, but when you need a face up output because the printer is part of a mailing line, you have half speed already because you need to do duplex printing caused by the paper feed direction. if you add this slow processing issue, it´s a recipe for disaster.

Sorry for my english.

[Gift]

Check if this crappy WSD port is enabled and in case it is - switch it back to TCP/IP port