Tobit FaxWare 6.0 Print Issue (Ricoh) [Long]

[unisys12]

I have an account that is really giving me fits and just really want some independent opinions on weather or not I am heading in the right direction on not. We all have times when we think we are on track to solving a tough problem, but want someone else's opinion just to make sure? Well, this is one of those times for me.

What we have here is a WAN (wide area network) with a fax server that routes incoming faxes to the proper destination. Those destinations are Savin MFP's. The jobs are sent as print jobs in a TIFF format. Whats happening on a few of the machines is that some of the faxes (completely random) have either a solid block of missing data or a full path of missing data from lead edge to trail edge.

Our dealership installed two 3535's into a otherwise perfectly working environment several months ago. About a week after these machines came online, I got a phone call about a copy quality issue concerning fax jobs on one of the machines. I made a service call to the account and spoke with two of the admins there. After talking with them for awhile and testing the machine, I concluded that the machine was not at fault. I asked the IT person in charge of the fax server to reprint one of the faulty faxes to the same machine. We found the CQ defect was duplicated perfectly. No matter how many times you resent the job to the CMFP, the defect was the same. At this point I was certain that the machine was not at fault, the IT personal was dead set that it was something with the MFP. I asked him if he could eliminate any differences between the two subnets of networks and he said, "NO!". At this point I asked if he could resend the job to another MFP on site, so he sent it to the 8035g in their office. The CQ was perfect and did not have the same issue.

At this point I was a little confused to say the least. One of the admin staff suggested that they install the Client software on the end users PC to see if the issue went away... and it did. So, this department has been working this way for several months now. When she gets a bad fax, she opens the Tobit client software and reprints the job directly from her PC. Everytime, the issue does not repeat.

Again, at this point, I am totally convinced that the 3535 is not to blame. It has to be something in either the Tobit FaxWare Server or the I-Print Server or even something in between. For goes several months with no complaints. That is until 2 weeks ago when I have a message at the shop about this "long standing issue" and that we (our dealership) needs to find a solution to this problem.

I called the admin in charge of the fax server and he tells me that he checked the ports on the switch leading from the server to the MFP's and there were no errors. Now, in my head I am thinking to myself, no S**t Sherlock! But I don't say this to him... no... even though I wanted to! I tell
him that I will order a IPU and go from there. (my mistake!! Damit to hell!!)

A few days later I get an e-mail stating that a newly installed 8055 has the same problem, note that it is in the same building as the 3535's that have the same problem, but this time it is with the threat that they will not purchase any more 8055's until this issue is resolved.

After speaking with our owners, they are going to go with me to the account on Monday and we are going to either get more info this or get to the bottom of this. I spoke with tech support and the person I got had no idea what Tobit was, but I cannot hold that against them since I didn't either. Once I explained what had happened up until this point, he agreed with me. And I personally feel that it's a driver issue. Why? Well, after doing some Google searches on Tobit 6.0, I found that it only runs smoothly on Win2000 or Win98. And I know that these guys have installed only PCL6 drivers for all the machines. I feel that if they install a PCL5 driver the issue will be solved, but as a simple tech I cannot get them to understand this.

What do you guys think?

[Cipher]

'Rather you than me' is what I'm thinking.

TIF(F) is raster format and I think most PCL drivers are set to use vector by default.
Try changing the default setting to raster and test it.

[blackcat4866]

I was going to suggest sending the faxes as PDFs. Personally I like Daz's advice better.

[unisys12]

You know, I haven't thought of that!

Great suggestion. I will be sure to make a note of that and suggest it when we meet on Monday.

[unisys12]

Update after todays meeting -

- First of all, system was not set up like I was lead to believe before. It's not that important though, now, because we found that the FaxWare Server does not use a driver to send out the print jobs. It simply sends the jobs out coded in PCL5e and specifically PCL5e. All the machines do support PCL 6 1.1 or as listed on the config sheet as PCL XL. But, as I said before, the FaxWare Server only uses PCL5e commands, so that's what we have to deal with.

What you do, when setting up a new printer, is set up a new queue. You assign an incoming marker/destination tag (in this case, the last four digits of the fax number) and all incoming faxes are placed in that queue. You then use PCL5e commands to configure how you want the jobs to print out of that queue, such as default paper tray, destination trays, watermarks, etc... You do all this through a command console. At this point, the server takes the compiled TIF and sends out the print job based on the PCL5e settings you configured and there you go.

With this new, more insightful knowledge of how everything works, we started our troubleshooting.

- We started out be printing config sheets off three of the machines in question (8055, 2-3535's) and one that did not have the problem (8035g). After very close inspection of the config sheet, we found that the 8035g and 8055 both used PCL5e natively on the machine. But they used different PCL symbol sets by default. The 8035g used Roman-8 and the 8055 used PC-8. We went to the `55 and changed it to the Roman-8 symbol set and the problem went away! We tested 5 known bad faxes from the server and issues was resolved. So, the PCL Symbol Set was the key here.

- After applying the same change to the 3535's, we found that it had no affect at all. We looked closer at the native PCL support on the config sheets and found that the color MFP's supported only PCL5c. At this point, we tried a few other things at the machine, but found that it didn't matter.

At this point, my manager and I both, feel that the difference in PCL5e and 5c shouldn't been that much different. But we also have nothing else to blame either. I just downloaded the HP PCL5c technical manual, but I haven't had a chance to look through it yet. It's only 286 pages! I did do a quick search on wikipedia and found that the only difference should be that the 5c language introduces color support to the PCL set. I will have to read through it and see what I find.

And of course another other findings will be updated here!

[blackcat4866]

Definitely subjective, definitely.......

Now these are only very subjective opinions:

If a difference as small as the default font can prevent your fax receptions from printing, the additional commands for color seemingly would also have this effect. You might try defaulting your new print queue to monochrome. You also might install a PCL5e driver and point it at the color machine, just to see if it will print. The worst thing that can happen is it just won't print. What choices of emulation do you have on these printers?

If this application uses only PCL5e, it certainly limits its uses. Most everything these days uses PCL6 or Postscript. I guess you're beyond the point of talking them out of using this obsolete application. It's a last resort.......

=^..^=

[unisys12]

If this application uses only PCL5e, it certainly limits its uses. Most everything these days uses PCL6 or Postscript. I guess you're beyond the point of talking them out of using this obsolete application. It's a last resort.......

=^..^=

This is basically were we are at this point. I got an e-mail from the IT person this afternoon stating that the 8055 started messing up again, the 3535 we changed the symbol set on started acting worse and now the 8035g, which has not had a problem in a year, has started doing the same thing.

I have been talking closely with Ricoh's solutions group on this issue and at this point I am turning it over to them. I feel know, more than ever, that I cannot convince these people their obsolete application is the problem. Even if the FaxWare Server could stream the jobs in PCL6, I don't think that would help because PCL6e (PCL XL or enhanced, which our machines support) is actually geared more for a Windows environment and this is not one, so... I am totally out of ideas and handing it off to the "uppers". Maybe they can find a way to convince them of their problem.

[unisys12]

PROBLEM SOLVED!!!

After getting a copy of the raw PCL data stream and some helpful suggestions from a few members of the Ricoh Solutions Group, we have the issue solved.

What was happened was that the PCL data stream was being sent, with a image resolution of 300dpi. I was able to duplicate the problem on another color machine we had at the shop. But then changed the machines default print resolution to 300dpi and the problem went away. I was able to test this on three other machines at our shop and prove that it solved the problem. If they were using a driver, this would not normally be an issue, since the machines are set by default to allow the driver to override MFP default settings. Since they weren't using a driver, the machine was trying to print a 300dpi document in 600dpi and there was too much loss.

This change to the machine should not affect print quality for normal use, for same reasons outlined above. That way, since the driver is set for printing at 600dpi, the machine will switch to that res for the job, then back to the new setting of 300dpi.

Glad to have this one behind, but I now know far more about PCL then I ever wanted to know!!

Also, as a tip any else out there gets in this boat like I did... check out this program News This is what I used not only view the raw PCL data, but compile it into an viewable image to make sure the PCL was good. As well as pull PCL config info directly from different MFP's (not their driver!) and send the PCL data stream to different MFP's for testing. (remember, when the image was sent through a windows driver it printed fine. It was when the raw PCL was sent to the machine directly that the problem would occur)

[blackcat4866]

Congratulations!

Most Copystars-Kyoceras will do these data captures on a CF card. The resulting file can be viewed in Textpad. I also, have looked at too many data captures.......

=^..^=

[Cipher]

Jolly good show.

So it was basically a software compatibility problem that you found a work around for.

I would now pay a visit to the asshole who threaten you and ask him how many machines he is going to order now you have sorted out his problem.

If they don't order anything... charge them the full 'no mercy' price.