Erractic Printing to Sharp Printer/Copier

ssolberg

VIP Member
We have quite a few various printers throughout our organization but we have recently ran into some issues that have me stumped. I recently finished converting all our forms from 3x to 7x/CTIS and we have been live for awhile now. This issue I'm about to discuss never occurred with any of the 3x forms.

After converting to 7x, we found that some various E1 jobs that print to some of our printers were not complete. We would find that the jobs would randomly hang up at the PRINTER (no error from CF side of things, everything is sent to the printer just fine) and no reportable error at the printer either other than the printer would have an incoming CF job stuck in a "Rendering" status (in the printer job queue) while all other jobs get stuck behind it. Only way to clear it was to shut the printer off and have it clear everything. I would send through the exact same E1 job and it would print fine. Other times it would stop at another random place.

This issue is not just occurring with one particular CF form, it is happening on various forms and I don't suspect the forms at all. What I suspect is more related to "volume" of incoming jobs to the printer. For example. I have an E1 job that generates 1 "big" PDF and as it goes through Director, the set is defined to break that up so it generates maybe 250 individual jobs as it heads to the printer. (there is a reason for this, the director project has other rules it has to adhere to as well). Each PDF headed to the printer is quite small (1-2 pages at most). Another example is an E1 job that when run, generates 50 individual jobs, each of which heads to Director for processing. In both cases, it regularly hangs things up at the printer.

From the CF printer definition side of things, it is setup as Generic/Text and using Postscript, just like all my other printers. I've tried using PCL and a print driver and that actually made things worse! I've tried other things, none of which have made things any better.

All the printers that have this issue are Sharp MX-41xx or MX-50xx model printer/copiers. We have had techs out looking at them and swapping out memory (etc...) and having no luck. And in the back of my mind, though, this only started happening after the 7x upgrade.

Does anyone have any suggestions on what else to try or troubleshoot? The Sharp tech guys say that they only time they have seen similar issues is if somehow the incoming job is corrupted or "invalid" but of course my response was always "then why is it fine the next time I send the exact same job through?" So we are at an impasse.
 
What specific version/patch level of Cform7 are you running? What's the OS on your server?

I had a very similar problem when I first implemented Cform7 on WinServer2008 R2. The job would start going to the printer but then never finish. I don't remember if jobs got stuck/hung behind the job because at the time I was testing for the implementation and sending jobs to the printer in a controlled manner.

I think what you need is the magic "Send processing to same queue" patch. That setting only got added at a certain patch level. Weird thing was that I had to specifically NOT use that setting on printers configured for PCL. So maybe your problem is something else.

Need more details on version, OS and how printers are configured.


Karen
 

Attachments

  • 185386-CformServer7 Printer Properties Merge Configuration.JPG
    185386-CformServer7 Printer Properties Merge Configuration.JPG
    141.7 KB · Views: 32
WinServer 2008 R2 SP1, CForm 7.0.500.3115

I'm aware of the "send processing to same queue" issue. I also ran into this when we first went on and had jobs "skipping random pages" when sent to a printer and this setting resolved that. It didn't happen on all our printers but I turned the option on for all printers. That isn't the same issue as I'm discussing above. In this case, the printer just plain stops at a random place and never completes the rest of the jobs.

BT Support wants to look at the logs from the printer queue but I already have and there is no error reporting in there. They are also asking that I install the latest patch level (7.0.540). As for config on the printers in question, they are setup like all our other; Generic Text, Postscript. Standard BT suggested setup.
 
How about patch "7.0.523 Patch to avoid hang of queue when LaunchCreate crashes"? Have you been given that one yet?

A few weeks back my server all of the sudden started having jobs that hung and blocked others from processing. Maybe what is happening is related to that?
 
We upgraded to C!F7 over 18 months ago and had nothing but problems. 3.2 is very safe but C!F 7 is very buggy. We have some printers using postscript and some using postscript resubmit option to ensure output works.

If you allow me to connect remotely I will more than happy to help out as best I can. Otherwise if you have support with Bottomline I am sure Tony Banham will sort out a postscript_resubmit method on certain printers to overcome C!F7 buggy software. However, if it's not too late I would strongly recommend reverting back to C!F 3.2 or looking at BI embedded or Transform as better method than C!F7
 
Sorry should have added that we have also had to create some director scripts to print only. This is because we found some reports would fail to print, unless director script was present. Very strange as C!F3.2 was able to pass through and print without a director script being setup..... C!F7 is so buggy.

Manaully setting up "Post_Resbmit"

To create Post_Resubmit setting carry out following.

1) Open C!F 7 server
2) Click on Tools
3) Click on Merge Configurations....
4) Click on new button
5) Enter Postscript_Resubmit as Name
6) Select Postscript as based on
7) Place a tick on Send processing onto same queue
8) Click ok
9) change a printer queue setting from Postscript to Postscript_resumbit as it's Default C!f7 merge configuration and then fully test. If all is ok now then this is sadly a C!F7 bug
 
I'm working on installing the 7.054 patch they want me to put in and see what happens....
 
Bottomline gave me 7.0.540 but told me "it had not been QA'd". There have been so many fixes and patches to 7.0.500 that hopefully that release will fix the problem you are having.

The majority of my printers are PostScript. I have all of them using the "Resubmit" function. I'm not going to wait for a PS printer to have problems and then change it. Weird thing is that it DOES NOT work on PCL printers. I forget exactly what happens (jobs got stuck or something). My PCL printers specifically DO NOT use that setting.

I have Cdirector printers and Cform printers. I keep my projects in separate folders. Printers have problems when the folder they get projects from has both CFP6 and CDP6 project files in it. It's no problem to have both types of projects in the folder I use for development - but when I put them on the CformServer they go into separate folders.

I agree with ComeOnArsenal... Cform7 is unreliable and buggy. Makes you watch the CformServer daily to make sure everything is OK.
 
Just an update to this. After trying some patches, which caused even MORE AND REALLY BAD problems (I won't get into the detail), finally found a solution that had nothing to do with a patch.

In fact, I had used this method to correct a totally different problem a year ago. See if I can explain.

So the issue was that the printer would just not process the jobs and hang up. BT suggested that for some reason, the printer could not handle both the merging and the printing of the jobs in one pass, so do it in two passes. Had off the jobs to a CF "printer" that is enabled for CF but instead of pointing that to a physical printer, point it to a Local Port. Setup the actual printer like a normal printer (but not CF enabled) using the PS driver appropriate for the model. Now point the Local Port to this printer. The job comes in and is processed first by the CF enabled queue, then the merged jobs are handed off to the actual printer. Now the printer is just printing PS jobs and not also trying to do the merge.

It works just fine now. I used this same process to correct an issue where I was trying to print to some printers that are not very "local" to our network. I have a CF enabled queue doing all the work, then it hands the jobs off to a computer with a printer setup on the other end that points to the physical printer.

I have to agree with the comment above that at this point 7x is a bit buggy. I'm finding issues with things that were not issues in 3x. But with that said, I couldn't stay on 3x either and there are some nice features in 7x that have been helpful.
 
I don't know what it is about these Sharp copier/printers but now I have yet a NEW problem! So I'm continuing this thread.

My initial solution (see above) has been working just fine to the 3 printers that were giving me fits. Then they replaced an existing (and working) model 4111 with a new 5141 model and now I have an even stranger problem I have never encountered.

There are a couple forms that have been going through fine and after the changeout of the printer, the AP clerk notices that the Debit Statements (R04574) and Additional Attachments (R04573) were "not printing the second page". What? Sure enough, a job would go through that had "lots" of debit statements (some with 1 page per supplier, some with 2 or more) and in all cases, it only prints page 1. Nothing has changed with the forms or the director projects. I send the exact same job through another Sharp printer or ANY other printer and it correctly prints all pages. I am at a loss as to what this is and have tried tons of things with no luck. I'm totally scared to go to BT Support because of the last debacle and another recent debacle I had with their support (unrelated) not being of any help at all.

Thoughts anyone?
 
If you have Create!Form 7 then two solution exists note this is to get round Create!Form 7 buggy merge print issue.
Option 1
1. setup a windows queue that ip is set direclty to printer
2. point C!F queue to windows queue to pass out E1/C!F print requests (BINGO this will work all the time)

Option 2
1. Create a new merge config called Postscript_Resbumit
Send me a web-ex type session and I can help setup/show you how to do this. My e-mail = [email protected]
 
Back
Top