Ricoh Aficio SP c830dn and Windows Print Server

Greg,

Thanks for responding. I stumbled upon the cups web interface. There's quite a bit of info there. I can see where authentication might be the issue, but it's not obvious if it is or why. We don't use any kind of authentication for our HP printers and I set this one up pretty much the same way.

Since this printer needs to be accessable to the general public we need to have it setup for anyone who wants to add a printer to their computer. So any kind of modification to cups is not really practicle.

Any advice on modifying the Windows server to accomplish the same thing? I tried enabling guest access and givng guest printing priviledges but that did not seem to work. Of couse that was local guest access not domain guest access. We use Pharos Uniprint for print management, so we don't need to have authentication on if that is the issue.

I didn't setup this server, so I'm not completely sure how it is configured and am not a sys-admin thought I could probably play one on TV.

It still puzzles me that if we let it sit in the queue eventually it will print 20-30 minutes later.

- Karl

Before I do something I regret...

There are several SNMP read errors in the CUPS log relating to the Ricoh printer queue.

I don't see any of these errors when printing to other queues.

I looked on the server and it does not look like SNMP service is installed. Could this be the culprit? Will I mess anything up by adding this to see it it will work?

PAHU wrote:

Karlowens wrote:

There are several SNMP read errors in the CUPS log relating to the Ricoh printer queue.

I don't see any of these errors when printing to other queues.

One any Mac, if you open System Information and select Printers in the left sidebar, you will see the Ricoh listed in the top right pane. With this selected, the lower right pane will show information about this printer. Look for an entry called Printer Commands. Based on what you have written above the Ricoh driver having the delay but the Generic PS driver working fine via the same Windows queue, I would expect that the Ricoh driver has an entry that checks the printer status and this is impacting the overall spool time. If this is so, then it would be possible to modify the PPD for the printer to remove the SNMP query and possibly improve the spool time.

The printer command line in System Information is identical to the other functioning printers. The contents of the printer's information are:

Ricoh:

Status: Idle

Print Server: Local

Driver Version: 10.4

Default: No

Shared: No

URI: lpd://aaa-output.uoregon.edu/Ricoh

PPD: RICOH Aficio SP C830DN PS

PPD File Version: 1.1

PostScript Version: (3018.102) 2

CUPS Version: 1.5.4 (cups-297.11)

Fax support: No

Scanning support: No

Printer Commands: AutoConfigure Clean PrintSelfTestPage

CUPS filters:

commandFilterR12S.app:

Path: /Library/Printers/RICOH/Filters/commandFilterR12S.app

Version: 1.08

commandfilterRV1.app:

Path: /Library/Printers/RICOH/Filters/commandfilterRV1.app

Version: 1.0.3

jobLogFilterC:

Path: /Library/Printers/RICOH/Filters/jobLogFilterC

pstopsR11A:

Path: /Library/Printers/RICOH/Filters/pstopsR11A

pstopsRV1.app:

Path: /Library/Printers/RICOH/Filters/pstopsRV1.app

Version: 1.0.8

commandFilterR12S:

Path: /Library/Printers/RICOH/Filters/commandFilterR12S.app/Contents/MacOS/commandFil terR12S

Permissions: rwxr-xr-x

Version: 1.08

PDEs:

ricohJobLog11A.plugin:

Sandbox compliant: Yes

PAHU wrote:

The other thing to note is the spool file size of the Ricoh driver vs the Generic PS. It is quite possible that the Ricoh driver is generating a larger spool file and when sent via the Windows queue, this is adding to the delay (because Pharos will also be scanning the file for user details for billing).

Since most of the testing has been using the test page generated by the print queue the spool files would be minimal. A compted job sent from the Mac shows spooled document size as 482,607 bytes. A test page from the server shows a spooled document size of 71,727 bytes. That is bigger, but shouldn't justify a 20-30 minute delay should it?

PAHU wrote:

Don't do anything on the server. It is merely providing a path for the Mac spool file.

And you will find that Windows is already using SNMP. This is how it would get information about supply levels. You can check by opening the printer on the Windows server and selecting Printer Properties > Ports > Configure Port. Here you will see SNMP Status Enabled and the Community Name being used, which by default is Public.

I mentioned the SNMP issue to our sys-admin and he went ahead and enabled the SNMP service. You mentioned that this is how it gets the supply levels. When I click on the supply level tab in the queue on the Mac it says, "Informaiton Not Available".

I checked the port configuration and the port shows that SNMP was not enabled for the port. When I enable SNMP on the port, the behavior did not change.

Here is the error information that gets repeated over and over again in the CUPS log:

D [26/Aug/2013:10:52:07 -0700] [Job 772] CUPS_SC_CMD_SNMP_GET: 36 (.1.3.6.1.4.1.367.3.2.1.2.24.1.1.5.1)

D [26/Aug/2013:10:52:07 -0700] [Job 772] Get Supply-Info request failed with status: 2

D [26/Aug/2013:10:52:08 -0700] [Job 772] SNMP read error...

D [26/Aug/2013:10:52:08 -0700] [Job 772] CUPS_SC_CMD_SNMP_GET: 36 (.1.3.6.1.4.1.367.3.2.1.2.24.1.1.5.1)

D [26/Aug/2013:10:52:08 -0700] [Job 772] Get Supply-Info request failed with status: 2

D [26/Aug/2013:10:52:09 -0700] [Job 772] SNMP read error...

D [26/Aug/2013:10:52:09 -0700] [Job 772] CUPS_SC_CMD_SNMP_GET: 36 (.1.3.6.1.4.1.367.3.2.1.2.24.1.1.5.1)

D [26/Aug/2013:10:52:09 -0700] [Job 772] Get Supply-Info request failed with status: 2

D [26/Aug/2013:10:52:10 -0700] [Job 772] SNMP read error...

This seems to confrim your first comment about the driver requesting the printer status. The question now I guess is... How do you modify the PPD? and is installing the modified PPD all that is necessary for someone who is going to be using the printer? or would I need create a custom installer?

- Karl

PAHU wrote:

Karlowens wrote:

There are several SNMP read errors in the CUPS log relating to the Ricoh printer queue.

I don't see any of these errors when printing to other queues.

One any Mac, if you open System Information and select Printers in the left sidebar, you will see the Ricoh listed in the top right pane. With this selected, the lower right pane will show information about this printer. Look for an entry called Printer Commands. Based on what you have written above the Ricoh driver having the delay but the Generic PS driver working fine via the same Windows queue, I would expect that the Ricoh driver has an entry that checks the printer status and this is impacting the overall spool time. If this is so, then it would be possible to modify the PPD for the printer to remove the SNMP query and possibly improve the spool time.

The printer command line in System Information is identical to the other functioning printers. The contents of the printer's information are:

Ricoh:

Status: Idle

Print Server: Local

Driver Version: 10.4

Default: No

Shared: No

URI: lpd://aaa-output.uoregon.edu/Ricoh

PPD: RICOH Aficio SP C830DN PS

PPD File Version: 1.1

PostScript Version: (3018.102) 2

CUPS Version: 1.5.4 (cups-297.11)

Fax support: No

Scanning support: No

Printer Commands: AutoConfigure Clean PrintSelfTestPage

CUPS filters:

commandFilterR12S.app:

Path: /Library/Printers/RICOH/Filters/commandFilterR12S.app

Version: 1.08

commandfilterRV1.app:

Path: /Library/Printers/RICOH/Filters/commandfilterRV1.app

Version: 1.0.3

jobLogFilterC:

Path: /Library/Printers/RICOH/Filters/jobLogFilterC

pstopsR11A:

Path: /Library/Printers/RICOH/Filters/pstopsR11A

pstopsRV1.app:

Path: /Library/Printers/RICOH/Filters/pstopsRV1.app

Version: 1.0.8

commandFilterR12S:

Path: /Library/Printers/RICOH/Filters/commandFilterR12S.app/Contents/MacOS/commandFil terR12S

Permissions: rwxr-xr-x

Version: 1.08

PDEs:

ricohJobLog11A.plugin:

Sandbox compliant: Yes

PAHU wrote:

The other thing to note is the spool file size of the Ricoh driver vs the Generic PS. It is quite possible that the Ricoh driver is generating a larger spool file and when sent via the Windows queue, this is adding to the delay (because Pharos will also be scanning the file for user details for billing).

Since most of the testing has been using the test page generated by the print queue the spool files would be minimal. A compted job sent from the Mac shows spooled document size as 482,607 bytes. A test page from the server shows a spooled document size of 71,727 bytes. That is bigger, but shouldn't justify a 20-30 minute delay should it?

PAHU wrote:

Don't do anything on the server. It is merely providing a path for the Mac spool file.

And you will find that Windows is already using SNMP. This is how it would get information about supply levels. You can check by opening the printer on the Windows server and selecting Printer Properties > Ports > Configure Port. Here you will see SNMP Status Enabled and the Community Name being used, which by default is Public.

I mentioned the SNMP issue to our sys-admin and he went ahead and enabled the SNMP service. You mentioned that this is how it gets the supply levels. When I click on the supply level tab in the queue on the Mac it says, "Informaiton Not Available".

I checked the port configuration and the port shows that SNMP was not enabled for the port. When I enable SNMP on the port, the behavior did not change.

Here is the error information that gets repeated over and over again in the CUPS log:

D [26/Aug/2013:10:52:07 -0700] [Job 772] CUPS_SC_CMD_SNMP_GET: 36 (.1.3.6.1.4.1.367.3.2.1.2.24.1.1.5.1)

D [26/Aug/2013:10:52:07 -0700] [Job 772] Get Supply-Info request failed with status: 2

D [26/Aug/2013:10:52:08 -0700] [Job 772] SNMP read error...

D [26/Aug/2013:10:52:08 -0700] [Job 772] CUPS_SC_CMD_SNMP_GET: 36 (.1.3.6.1.4.1.367.3.2.1.2.24.1.1.5.1)

D [26/Aug/2013:10:52:08 -0700] [Job 772] Get Supply-Info request failed with status: 2

D [26/Aug/2013:10:52:09 -0700] [Job 772] SNMP read error...

D [26/Aug/2013:10:52:09 -0700] [Job 772] CUPS_SC_CMD_SNMP_GET: 36 (.1.3.6.1.4.1.367.3.2.1.2.24.1.1.5.1)

D [26/Aug/2013:10:52:09 -0700] [Job 772] Get Supply-Info request failed with status: 2

D [26/Aug/2013:10:52:10 -0700] [Job 772] SNMP read error...

This seems to confrim your first comment about the driver requesting the printer status. The question now I guess is... How do you modify the PPD? and is installing the modified PPD all that is necessary for someone who is going to be using the printer? or would I need create a custom installer?

- Karl

PAHU wrote:

<snip>

As for the toner levels and the "Information Not Available" message, there are many printers that do not support the Supply Levels tab of Options & Supplies. Instead they have their own plugin for providing toner/ink information. But, since you are connecting via a Windows shared queue, this could also be the cause of the failure. And based on the SNMP Get command in the CUPS error log, it would appear that the driver is trying to obtain this information but as I said, this will not typically work when you have the printer using a Windows queue. If you were to connect the Mac directly to the printer then this message would most likely not appear.

And with regards to modifying the PPD, that should really be up to Ricoh to perform for you - but you've already indicated their desire to help. So when I get a chance to look at the PPD, I will see if it is possible to comment out the Get Supply-Info command and get back to you.

What you describe seems correct. I've spent a little bit of time looking over the PPD code. There is a plugin call to a routine that must talk to the printer. I tried deleting sections that I thought related to the driver making the request to the printer. I don't think I"m following the code well enough or there is some kind of PPD magic I'm not familar with with regard to having the changes take effect.

On another forum a MS engineer said there was nothing in the LPD protacol that would allow the server to request and send printer specific printer data.

If you or anyone who knows about PPD code could help either by taking a look or pointing me in the right direction that would be appreciated.

If I don't resolve this soon I'm going to have to try to return it to the vendor which isn't going to work out well for the university.

I applied the changes. It improved things quite a bit. The test page comes out in 3-4 seconds. Plain text pages in a few minutes, but full graphic layouts still seem to be a chore. It's 2-3 minutes per page.

The cups log shows the driver is still making the supply requests, but now shows read/wrote infomation being compiled as well. The actual sending of the compiled print job looks like it is pretty quick, but it appears that the driver is compiling it really slow.

Printing the same job directly to the printer is really quick (prints in seconds). Even using the modified PPD file.

I'm wondering if the snmp error causes the rendered page to be restarted, and if it can render the page before the next request is made it will continue to render the next page?

Without any idea what these commands might do or why they might be needed, I decided to try commmenting out the entire section to see what would happen. Turned out that breaks the PPD, all together.

I began adding back the lines I thought might be relevent and my first attempt produced results. The two lines that I left in were:

*cupsFilter: "application/vnd.cups-command 0 /Library/Printers/RICOH/Filters/commandFilterR12S.app/Contents/MacOS/commandFil terR12S"

*cupsSNMPSupplies: False

Everything else I left commented out.

So far, the modified PPD has printed successfully without delay on two sperate Macs using two seperate versions of the Mac OS on 4 different applications.

I think we have a winner.

Now I only need to figure out how to build an installer to deploy the modified PPD. 😟

Another PPD question. When I change the PPD file name it still shows up in the list of avialable printers with the original name. I want to rename the PPD to identify the modified PPD seperately from the manufactures version so that an update doesn't overwrite the modified PPD or confuse any end users about which PPD they should choose when configuring the printer.