Konica Minolta bizhub C250 confounds all attempts to print from computer, via IP network

[John B]

Can anyone help me get this silly machine to print a basic test page from a
Windows XP Pro machine, via our IP intranet?
My friend's C250 has served for years as a reliable copier. Now we want to
use it as a network printer.

We have installed the relevant drivers, from the bizhub's CDROM collection,
to a new WinXP Pro computer named "Gamma." We installed into Gamma the
Windows capabilty to print to an LPR printer, first by adding "Print
Services for Unix" in the XP Control Panel; then by adding the printing
device "locally" that is an LPR with the relevant IP address... and
hostname. The "address of the server providing lpd" is 192.168.1.81. The
"name of the printer on that server" is KMBT560A94. I must wonder about
that hostname, which comes to us as a "given." I was not able to assign a
hostname into the bizhub, as I have successfully done with various
ip-accessible print servers that attach to printers.

I ping the ip address 192.168.1.81 successfully, every time, from the
computer.

When I print a test page to this LPR printer, there is a brief spooling
action under Windows Control Panel ...printers. The job seems to go through
perfectly...at the computer, at least. The document number rises from 0 to
1, and then goes back to 0. The document name flashes briefly in the
printer's queue, before disappearing, as should be the case when a job turns
into hard copy at a printer.

The only problem is that no print job EVER emerges. 100% failure.

Any suggestions would be appreciated.

My friend, who owns the machine, and who is "non technical," wonders if he
might need to "log into" the bizhub, at its key panel, in order to get print
jobs to come out. Meanwhile, the machine works fine as a copier, without
any ip involvement.

P.S. Some time ago, I got into the keypanel of this machine, changed the
password, and entered the ip address shown above. I enabled the "ping"
reaction, too.

THANK YOU.

 

[Warren Block]

Can anyone help me get this silly machine to print a basic test page from a
Windows XP Pro machine, via our IP intranet?
My friend's C250 has served for years as a reliable copier. Now we want to
use it as a network printer.

We have installed the relevant drivers, from the bizhub's CDROM collection,
to a new WinXP Pro computer named "Gamma." We installed into Gamma the
Windows capabilty to print to an LPR printer, first by adding "Print
Services for Unix" in the XP Control Panel;

That's unnecessary. All it gets you is a Microsoft lpr command-line
client and maybe an lpd server. XP lets you create a port that will
talk to lpd servers without needing the "Print Services For Unix" stuff.

then by adding the printing device "locally" that is an LPR with the
relevant IP address... and hostname.

Probably not a hostname that is needed (IP address is enough), but an
lpd queue name.

The "address of the server providing lpd" is 192.168.1.81. The "name
of the printer on that server" is KMBT560A94. I must wonder about
that hostname, which comes to us as a "given."

It's not a hostname. lpd servers can have multiple queues, each
printing to a different printer. Naming of queues is haphazard.
Sometimes can be left blank, sometimes "lp", sometimes "raw", sometimes
something totally random, like a printer brand and model number.

I was not able to assign a hostname into the bizhub, as I have
successfully done with various ip-accessible print servers that attach
to printers.

It really shouldn't matter if the job is making it to the printer. A
DNS entry for the printer would not be bad.

I ping the ip address 192.168.1.81 successfully, every time, from the
computer.

When I print a test page to this LPR printer, there is a brief spooling
action under Windows Control Panel ...printers. The job seems to go through
perfectly...at the computer, at least. The document number rises from 0 to
1, and then goes back to 0. The document name flashes briefly in the
printer's queue, before disappearing, as should be the case when a job turns
into hard copy at a printer.

The only problem is that no print job EVER emerges. 100% failure.

The most obvious option is that the print job isn't formatted in a PDL
that the printer understands. Could be PCL, could be PostScript if
you're lucky. Could be that the CDROM drivers are outdated, so try the
latest from their web site. Or it could be that the drivers support
different versions of the printer and the printer doesn't have options
the driver thinks it does.

You can use the lpr command-line client to send simple test files. I
can't remember the options, except that they're true to Microsoft and
therefore incompatible with any other lpr client.

For test files, start with a simple text file created in Notepad. Just
text, and more than 60 lines long to force a page eject.

Using Notepad, write this to a file, then send with lpr to test for
PostScript:

%!PS
/Courier findfont 20 scalefont setfont
72 72 moveto (I am a PostScript printer.) show showpage

Any suggestions would be appreciated.

My friend, who owns the machine, and who is "non technical," wonders if he
might need to "log into" the bizhub, at its key panel, in order to get print
jobs to come out.

Entirely possible, the bigger printer/copiers are like that. There
should be options in the driver to activate that instead of just
printing directly, but I've not tried KM printers.

 

[Elmo P. Shagnasty]

We have installed the relevant drivers, from the bizhub's CDROM collection,
to a new WinXP Pro computer named "Gamma." We installed into Gamma the
Windows capabilty to print to an LPR printer, first by adding "Print
Services for Unix" in the XP Control Panel;

That's unnecessary. All it gets you is a Microsoft lpr command-line
client and maybe an lpd server. XP lets you create a port that will
talk to lpd servers without needing the "Print Services For Unix" stuff.[/QUOTE]

I disagree. First off, you cannot create what Microsoft calls "LPR
port" without installing print services for Unix.

Microsoft's "Standard TCP/IP Port" can be configured to do lpr, but it
has proven to be anything BUT standard.

Installing the print services for UNIX and using "LPR port" instead has
solved many, many problems over the years.

 

[Warren Block]

That's unnecessary. All it gets you is a Microsoft lpr command-line
client and maybe an lpd server. XP lets you create a port that will
talk to lpd servers without needing the "Print Services For Unix" stuff.

I disagree. First off, you cannot create what Microsoft calls "LPR
port" without installing print services for Unix.

Microsoft's "Standard TCP/IP Port" can be configured to do lpr, but it
has proven to be anything BUT standard.

Installing the print services for UNIX and using "LPR port" instead has
solved many, many problems over the years.[/QUOTE]

Okay. The lpr mode of the "Standard TCP/IP Port" never gave me any
trouble, but that was mostly talking to JetDirects. I'd expect that to
be the most common situation and the most debugged.

 

[Elmo P. Shagnasty]

I disagree. First off, you cannot create what Microsoft calls "LPR
port" without installing print services for Unix.

Microsoft's "Standard TCP/IP Port" can be configured to do lpr, but it
has proven to be anything BUT standard.

Installing the print services for UNIX and using "LPR port" instead has
solved many, many problems over the years.

Okay. The lpr mode of the "Standard TCP/IP Port" never gave me any
trouble, but that was mostly talking to JetDirects. I'd expect that to
be the most common situation and the most debugged.[/QUOTE]

Microsoft's "Standard TCP/IP Port" was designed SPECIFICALLY to talk to
JetDirects.

That it works with anything else is, frankly, incidental.

 

[John B]

Thanks for your prompt replies. See below for my additional replies to
yours.

Probably not a hostname that is needed (IP address is enough), but an
lpd queue name.


It's not a hostname. lpd servers can have multiple queues, each
printing to a different printer. Naming of queues is haphazard.
Sometimes can be left blank, sometimes "lp", sometimes "raw", sometimes
something totally random, like a printer brand and model number.

I will look again at a different system (my own office system) where I
employ a simple print server successfully all day long. It has a "name" as
well as a "number." And by now I am using LPR printing in my office,
instead of just TCP/IP printing. (Both work here.)
By now I have figured out how to log into the printer's administrative
screen. Yes, I could change that hostname if I cared to; it's right there
in all its glory.

I think I'll deliberately install a WRONG "name" somewhere, to see if that
changes the mode of failure. Maybe that will stall the spool. Right now,
it appears that the print jobs are going right through properly...until
someone inspects the hard copy hopper...only to find nothing is there.

Bear in mind that this bizhub printer is physically in a downtown law
office. I am accessing it remotely, via TCP connections. So I can't walk
in and look at the printer's hopper. I have the secretary do that when she
comes in during business hours.

It really shouldn't matter if the job is making it to the printer. A
DNS entry for the printer would not be bad.

('This can wait.)
Where should I place such a "DNS entry"? In the XP computer? I don't know
how to supplement a DNS list anywhere. I've never had to do that. There is
provision for entering ip addresses of DNS servers IN THE BIZHUB, which I
have ignored, because that seems relevant only for OUTGOING information. My
sole interest here is to push print jobs into the printer, and have hard
copy come out in the hopper.

Such failures include the Windows XP test page. Said test page has never
failed me, as an adequate vehicle, in many many years. But I'm all ears to
your ideas of "proper" formatting.

The most obvious option is that the print job isn't formatted in a PDL
that the printer understands. Could be PCL, could be PostScript if
you're lucky. Could be that the CDROM drivers are outdated, so try the
latest from their web site. Or it could be that the drivers support
different versions of the printer and the printer doesn't have options
the driver thinks it does.

You can use the lpr command-line client to send simple test files. I
can't remember the options, except that they're true to Microsoft and
therefore incompatible with any other lpr client.

For test files, start with a simple text file created in Notepad. Just
text, and more than 60 lines long to force a page eject.

I'll look into this today, during business hours. Thank you for your reply
and suggestions.

 

[Warren Block]

('This can wait.)
Where should I place such a "DNS entry"?

In your DNS servers, or hosts file, depending on what you have.

In the XP computer? I don't know how to supplement a DNS list
anywhere. I've never had to do that. There is provision for entering
ip addresses of DNS servers IN THE BIZHUB, which I have ignored,
because that seems relevant only for OUTGOING information. My sole
interest here is to push print jobs into the printer, and have hard
copy come out in the hopper.

Some lpd implementations really want to be able to resolve their own IP
addresses and those of clients submitting print jobs. Since the job is
arriving, that particular lpd either doesn't care or already has DNS.

Such failures include the Windows XP test page. Said test page has never
failed me, as an adequate vehicle, in many many years. But I'm all ears to
your ideas of "proper" formatting.

The Windows test page, nasty as it is, isn't really any different from
any other print job. No more--or less--likely to print. It will go
through all of the Windows spooler and driver plumbing. Using the lpr
client avoids all that, sending an unprocessed file straight to the
printer. That lets you at least narrow things down.

 

[phineaspaine]

Can anyone help  me get this silly machine to print a basic test page from a
Windows XP Pro machine, via our IP intranet?
My friend's C250 has served for years as a reliable copier.  Now we wantto
use it as a network printer.

We have installed the relevant drivers, from the bizhub's CDROM collection,
to a new WinXP Pro computer named "Gamma."  We installed into Gamma the
Windows capabilty to print to an LPR printer, first by adding "Print
Services for Unix" in the XP Control Panel; then by adding the printing
device "locally" that is an LPR with the relevant IP address... and
hostname.  The "address of the server providing lpd" is 192.168.1.81.  The
"name of the printer on that server" is KMBT560A94.   I must wonder about
that hostname, which comes to us as a "given."  I was not able to assigna
hostname into the bizhub, as I have successfully done with various
ip-accessible print servers that attach to printers.

I ping the ip address 192.168.1.81 successfully, every time, from the
computer.

When I print a test page to this LPR printer, there is a brief spooling
action under Windows Control Panel ...printers.  The job seems to go through
perfectly...at the computer, at least.  The document number rises from 0to
1, and then goes back to 0.  The document name flashes briefly in the
printer's queue, before disappearing, as should be the case when a job turns
into hard copy at a printer.

The only problem is that no print job EVER emerges.  100% failure.

Any suggestions would be appreciated.

My friend, who owns the machine, and who is "non technical," wonders if he
might need to "log into" the bizhub, at its key panel, in order to get print
jobs to come out.  Meanwhile, the machine works fine as a copier, without
any ip involvement.

P.S.  Some time ago, I got into the keypanel of this machine, changed the
password, and entered the ip address shown above.  I enabled the "ping"
reaction, too.

THANK YOU.

Take a look at "Chapter 3. Setting up Network Printing" in the manual
for this printer, available here (http://207.194.48.151/intranet2/
view.php?
sess=0&id=4915&parent=3793&action=pdf_show&expand=1&order=name&sortname=ASC).
It clearly states that only the PCL driver will work with Windows.
Also later in the chapter, it explains how to configure it under
Windows.

Don't forget to configure it with a static IP address within your
router's network, but not within the DHCP server's range. See this
thread for a similar explanation (http://groups.google.ca/group/
comp.periphs.printers/browse_thread/thread/ba45e3624ccee016/
f6a8909631ae36b8?hl=en#f6a8909631ae36b8).

That should do it.
Phineas

 

[John B]

The IP addressing is already as you say.
I will look into this PCL requirement. That's news to me.
THANKS.


Take a look at "Chapter 3. Setting up Network Printing" in the manual
for this printer, available here (http://207.194.48.151/intranet2/
view.php?
sess=0&id=4915&parent=3793&action=pdf_show&expand=1&order=name&sortname=ASC)
..
It clearly states that only the PCL driver will work with Windows.
Also later in the chapter, it explains how to configure it under
Windows.

Don't forget to configure it with a static IP address within your
router's network, but not within the DHCP server's range. See this
thread for a similar explanation (http://groups.google.ca/group/
comp.periphs.printers/browse_thread/thread/ba45e3624ccee016/
f6a8909631ae36b8?hl=en#f6a8909631ae36b8).

That should do it.
Phineas

 

[John B]

I hit this link and it says "anonymous access." A username and password are
required. I couldn't guess correctly.
Can you advise?
Thanks.
John


Take a look at "Chapter 3. Setting up Network Printing" in the manual
for this printer, available here (http://207.194.48.151/intranet2/
Phineas

 

[John B]

I may not be able to log into that link yet, but I found the book. Yes, I
have in my possession four books pertinent to this machine. The "Quick
Guide [Print Operations]" manual correlates exactly with your instructions.

Chapter 3: Setting Up Network Printing.

Lo and behold, I had previously read this chapter and even marked it up. I
sailed right past the PCL driver demand.
It says:
"When the installer was not used and when using a printer driver other than
the PCL printer driver, the Peer to Peer Printing Tool must be installed
separately."

Whatever that means.
I thought we used the "installer" because we used the KonicaMinolta CDROM
that was intended for this purpose of getting network printing to work.

Can you tell me what's so special about a "PCL" driver? As opposed to
"PostScript," I suppose?... I have never used PostScript drivers...I think
they're associated with Apple??

What kind of drivers have I been using, unwittingly, all these years with HP
and NEC printers? Any idea? I thought they were all PCL drivers,
implicitly. Perhaps that is my big mistake?


I am remotely situated from this printer, which is in a downtown law office.
My friends at the office walk around and install CDROMs, etc., at my behest.
This can be done only during business hours, needless to say.
My friend the lawyer put the CDROM into his new XP computer, for this C250
machine, and all seemed to go well. So I figured we used the "installer."

**How can we check to see the NATURE of the driver that is already in place
for our LPR printer icon, within my friends's XP Control Panel, "Printers,"
area?**

Thanks again,
John

 

[John B]

The XP computer bears this information in its "Printer" icon:
KONICA MINOLTA C250/C250P PS

That looks like a PostScript driver, doesn't it?
Hmmm...
I'll have to get some help at the office, to install the PCL driver.
Thanks again for this lead.

 

[John B]

I removed the "PS" printer icon.

I installed another icon, after downloading an April 2007 "PCL" driver from

http://onyxftp.mykonicaminolta.com/download/SearchResults.aspx?productid=861&filetypeid=0

After installation, the description under the general tab isn't "...PCL" but
"KONICA MINOLTA C250/C250P VXL"

I don't know what "VXL" is supposed to be, but it's OK with me if the jobs
come out.
Well, I just heard from the secretary and she said, "Sorry, no print job
came out."


So back I went to that download site. This time, I took an older "PCL"
driver, from June 16, 2006.
After installation, this icon clearly says:
"KONICA MINOLTA C250/C250P PCL"

Testing....
STILL NOTHING.

All this, despite the appearance, as always, from the XP computer screen,
that the print job went through OK.

What could I be doing wrong??



Take a look at "Chapter 3. Setting up Network Printing" in the manual
for this printer, available here (http://207.194.48.151/intranet2/
view.php?
sess=0&id=4915&parent=3793&action=pdf_show&expand=1&order=name&sortname=ASC)
..
It clearly states that only the PCL driver will work with Windows.
Also later in the chapter, it explains how to configure it under
Windows.

 

[Warren Block]

I may not be able to log into that link yet, but I found the book. Yes, I
have in my possession four books pertinent to this machine. The "Quick
Guide [Print Operations]" manual correlates exactly with your instructions.

When you top-post and have no quote marks, it's very difficult to see
which is quoted text and which are your responses. If you like OE, this
may help:

http://home.in.tum.de/~jain/software/oe-quotefix/

There are specific Usenet clients which may be easier, too.

Can you tell me what's so special about a "PCL" driver? As opposed to
"PostScript," I suppose?... I have never used PostScript drivers...I think
they're associated with Apple??

PCL is the old way, a file marked up with escape codes. PostScript is a
newer way, where the file is a program that is run by the printer to
draw the page. PS is resolution independent--display at 72 DPI on the
screen, print at 300 DPI on a home printer, print at 2540 DPI on a
phototypesetter, all from the same file.

PostScript is preferable for print quality and compatibility.
Unfortunately, poorly written drivers can make PS printing slow, and PCL
drivers are used much more frequently on Windows.

Apple was the first to use PS, but it's not theirs, and is not limited
to use on Apple equipment.

 

[John B]

Thank you, Warren, for this very useful information, coming obviously from
an expert who's been around for a while. I appreciate this.
See my later posting for the successful conclusion to this mystery.

 

[John B]

This problem has been solved. A Konica Minolta serviceman came to the site
and solved the dilemma.

The problem was that, in the settings inherited with this equipment, there
was an "authentication" requirement, in order to print. This requirement is
viewable under the administrative setup screen, viewable at the IP address
of the printer, through an internet browser. It's under the Network
tab...authentication sub-tab.

There are two kinds of authentication: "domain" and "account." We have
only workgroup, no domain, so domain authentication was never enabled.
Turns out that "account" authentication was, indeed, enabled. The
secretary's passcode was the information that enabled the hard copy job to
come out into the printer's hopper.

Where does one enter said passcode? Well, apparently the secretary enters
it at the keypad, when she's copying documents. But a person attempting to
print remotely would enter it at his computer screen. Where? Right click
and bring up "properties" of the PCL printer icon. General tab. Hit
"printing preferences" button. This brings up a "Setup" tab. Inside there
is found a "User Authentication/Account Track" button. Hit that and you'll
find a box to check titled, "Account Track." With that checked, a passcode
can be entered. "Department Name" can be left empty. Click OK OK etc. to
save all this. It seems that this information can be kept inside the
printer icon, and does not have to be re-entered every time.

That being done, the "VXL" driver has no similar provision to satisfy an
account track passcode. The VXL driver, consequently, could not produce a
print job that worked. I removed all the VXL drivers from my friend's
desktop XP computer. The PCL driver will remain.

The technician said he succeeded in printing with his PostScript driver,
from his laptop computer. I might try that some other day, if I have
nothing else to do.

From now on, I will be leery of very fancy printers with very fancy
"drivers."