[Logo]


Print Server Support Tips


The following are the most common problems reported with the Microplex print servers. For each problem, you will find some things to attempt along with an overview of why it is happening. In most cases, these steps will be all that is needed to solve your printing problems but if not, you can then use the Support Request Form to get further help.


Table of Contents


General Problems with the Print Servers

Forgotten Password

Sometimes a password has been set for the root user on a print server but it is either forgotten over time or the person who set it is no longer around. This means no configuration can be done on the unit until the root user can properly log in. If this happens, please consider the following:

TCP/IP-related Problems

Unit Won't Talk on Network

Sometimes the print server won't communicate over the network from the beginning or it will suddenly stop communicating after working for a while. In these cases, customers most often think something has gone wrong with the unit meaning an RMA is needed, but 75% of the time, the problem is related to configuration or network problems. Therefore, if you run into this situation, please consider the following:

Nothing Prints

Most often when nothing prints, the problem is with the configuration whether it be the host configuration or the print server configuration. Rarely is it a problem with the hardware (e.g. I/O port interface) unless it's the printer cable or printer itself having troubles.

What's important to find out with this problem is where exactly is the print job faultering. Therefore, you need to start with the most basics (i.e. take the network right out of the picture) and work backwards towards the host end.

If you come across this situation, please consider the following:

Stair-stepped Output

This refers to any Unix output that starts on the top left of the page but every line thereafter, starts a little more over to the right rather than coming back properly to the left margin. It also refers to Unix jobs that print one line at the top of the page but then follow that with blank pages rather than the rest of the job.

The reason for this funny output is the lack of carriage returns in the job. The printer may be told to do a linefeed but this may not be followed by a carriage return to start the next line at the left margin. Therefore, the printer does a linefeed but then starts the next line where the previous line left off.

This should only happen with Unix text jobs and to avoid this, you need to turn on some type of carriage return insertion in the print path. The easiest and most common location is on the print server itself and the feature is called onlcr. This can be set on in a queue (for print servers with firmware versions prior to 4.0) or in a model (for print servers with firmware version after 4.0). For example, if you were printing to an M202 with version 5.2.3 and you had your printer attached to PRN1 with jobs going to the destination, d1prn1, the command to turn on onlcr in the appropriate model would be:

set model m1 stty onlcr

save

Please see your product manual for more details on onlcr.

Note:
Be careful that you do not double up on this carriage return insertion or else you will get a double-spaced job.

No Formfeed or Extra Page Comes Out

Unix text jobs may also have problems kicking the last page of the print job out of the printer. Instead, you may have to go to the printer and press the formfeed button.

To make this process automatic, you can tell the print server to do the manual formfeed for you. Once again, this is set on in a queue (for print servers with firmware versions prior to 4.0) or in a model (for print servers with firmware version after 4.0). The code is actually put into a trailer string so it is appended to every job coming through. For example, if you were printing to an M202 with version 5.4 and you had your printer attached to COM1 with jobs going to the destination, d3com1, the command to turn on a formfeed in the trailer string of the appropriate model would be:

set model m1 trailer $FF

save

The "$FF" refers to a pre-defined variable on the print server seen with the command "list var". It simply equals the hexadecimal code of "0x0c" as defined in the Hewlett Packard printer manuals.

Note:
Be careful that you do not double up on formfeeds or else you will get the job ejected properly out of the printer plus an extra blank page. The trick is to let the application do it if it can but if not, then turn this on at the print server.

Garbled Output

Garbled data means any output that does not look as it should. This can range from missing or overlapping characters to funny spacing. Most often it is caused by some extra unwanted processing done to the job as it passes through its print path or else it may be related to the hardware involved. No matter what, 99% of the time it is fixable without having to bring a print server back for repair. If you run into this situation, please consider the following:

Novell-related Problems (NetWare 3.x and General)

No PSERVER Connection

The most important aspect of a Novell setup is getting the connection from the Microplex print server to the Novell file server. If you don't have that, you will never be able to print. Jobs may go to your file server queue but they will never get any further until you have this network print connection. Therefore, if you run into this situation, please consider the following:

Novell-related Problems (NetWare 4.x only)

No PSERVER Connection

Most of the problems and suggestions listed under "Novell-related Problems (NetWare 3.x and General)" apply to NetWare 4.x environments as well but there are a few additional points to consider if you do not get a PSERVER connection:

The last thing to remember about NetWare 4.x PSERVER setups is that you are dealing strictly in bindery mode. This means all objects you've created with this setup may not be seen everywhere like non-bindery objects. It's important to be aware of this.

Note:
If you'd like to avoid bindery emulation altogether, you can try an RPRINTER setup instead. This has no bindery requirements like a PSERVER setup. Please see your product manual for the exact steps to follow.

Windows NT 3.5x-related Problems

Queue Hangs

Hanging print jobs or queues with Windows NT 3.5x usually means there's a problem at the host end. Most likely the printer and print server are sitting on the network waiting for some form of activity but the host is not doing anything. This is very typical for any LPR printing with Windows NT 3.5 and is possible with NT 3.51 as well.

The first thing to check is that the printer is in fact ready to go meaning it is willing to accept more data. The best way to do this is to the use the "lpstat" command found on the print server. In fact, this command's output will tell you where exactly the problem is. Therefore, you'll want to telnet into the unit when the hanging occurs and issue "lpstat". Search under the appropriate I/O port you are printing to and see if you see any messages like:

Various Errors Come up

Printing in a Windows NT environment can produce various errors that don't always mean too much to the user at first glance. Some common ones are "Windows cannot write to this file." or "A network error has occurred."

In most cases, the errors are all related to the LPR bug with Microsoft NT 3.5. That or an error comes up because the print server cannot take more data for some reason (i.e. the printer is in an error state). Windows has a real problem if it can't send all of the print job data right away so if it's blocked from sending data, its spool file builds and builds leading to an error like the ones mentioned. Be sure to check the "lpstat" output on the print server to determine where the problem is and if it's host related, keep the LPR bug in mind.

NetBIOS Connection Won't Print

Besides the LPR client available with Windows NT, there is also another print method called NetBIOS. This involves establishing a NetBIOS over TCP/IP connection with the print server and then creating a printer to utilize this new connection for printing. The LPD protocol is not used at all with this method.

Once again, there is a problem from the Microsoft end though. It turns out that the packet formats outlined in RFC 1002 are violated meaning the NetBIOS stack on the print server will ignore any NetBIOS packets coming from an NT host. This means printing will not go through and you may get various printer errors on your host end. The most common error is "Windows cannot write to this file."

So what can be done if you run into this problem? A new firmware version for the print server, version 5.5.2, tries to tackle this problem for Microsoft. This is probably the wisest choice. Please contact Microplex for further help with this or feel free to check out the Technical Support page at the WEB site (http://www.printserver.microplex.com/support/) for the latest firmware code and instructions.

Windows for Workgroups-related Problems

Printer and Network Errors

Anytime you have several Windows for Workgroups (WfW) stations printing directly to a print server, you will run into various printer and network errors. The problem is if one station is printing to the printer already and another station tries to send a job to the same printer, the print server tells the second station to hold on to its data until it has finished with the first job. The Print Manager on this second station doesn't like this though so it errors out and the job has to be resubmitted when the printer is clear again.

This problem will come up with any external print servers that do not spool entire print jobs (which is the case for every print server on the market today). Print Manager likes to send the data it spools immediately and if it can't for some reason, it will produce an error saying the network or printer is busy. The best solution is to then have a central spooling station like an NT server which allows each WfW station to spool the print job immediately to its hard drive where it can then sit until the print server can take it. The unit then only deals with one station and it goes through each job as it gets queued up.

Note:
It is not possible to set up a WfW station as the central spooling device since you cannot share a printer on the network that is already being shared. It is the fact a "net use" connection is used between this central station and the print server that causes the problem. However, a central NT station can offer a shared network printer to these WfW stations.

NetBIOS Connection Won't Print

Windows for Workgroups (WfW) printing involves a NetBIOS over TCP/IP connection to print to the print server. It does not offer any other print method.

However, there is a problem from the Microsoft end though. It turns out that the packet formats outlined in RFC 1002 are violated meaning the NetBIOS stack on the print server will ignore any NetBIOS packets coming from a WfW station. This means printing will not go through and you may get various printer errors on your host end. The most common error is "Windows cannot write to this file."

So what can be done if you run into this problem? A new firmware version for the print server, version 5.5.2, tries to tackle this problem for Microsoft. This is probably the wisest choice. Please contact Microplex for further help with this or feel free to check out the Technical Support page at the WEB site (http://www.printserver.microplex.com/support/) for the latest firmware code and instructions.

Windows 95-related Problems

** Since Windows 95 hasn't been out long enough yet, this section will be filled in within the next few months.

AppleTalk-related Problems

Application Hangs upon Printing

Not a lot goes wrong in an AppleTalk environment but once in a while, you may come across an application that hangs up when trying to print to the Microplex print servers. Most often this will happen when you have a printer attached to a parallel port of the unit; serial printing should go through just fine though.

AppleTalk printing is slightly different in that it requires a lot of feedback from a printer before a host will print to it. This is fine for serial printing since all serial ports are bi-directional but with parallel printing, not every parallel port is bi-directional. Therefore, some applications don't get the feedback they need so they don't print properly.

When a print server is thrown in with a parallel printer, things get even harder because not only does the printer have to be able to respond through its parallel interface, but the print server must also be able to accept data back through its parallel interface which it can then send back to the Apple host. Unfortunately, Microplex print servers don't quite yet have full bi-directional parallel ports so to allow for parallel printing in an Apple environment, the print server has to fake the printer responses for the printer attached. The units currently fake a generic PostScript printer. This way most applications can print just fine since they receive the basic printer information back from the unit.

If you run into an application that seems to hang up when printing to a print server's parallel printer, then you can probably guess the problem is with this feedback issue. There are two things you can then tryzzz:

  1. Make sure you have the latest LaserWriter driver (atleast 8.x) installed on your Macintosh.

  2. Make sure you have the latest firmware in your print server.


Microplex Home Page | Product Info | Tech Support | Contact Us