![[Logo]](/graphics/img0015.gif)
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 email support@microplex.com to get further help.
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:
rsh spike set user from default
save
where rsh is the remote command on this system and spike is the IP or host name of the print server. The save command will save these new settings into EEPROM so they are remembered after reboots.
Now you have set the user settings back to factory defaults meaning the next time you try and log in as a root user, you can simply press ENTER or RETURN at the password prompt.
With each print server, there is a specific jumper inside that has a position for EEPROM Enable (i.e. reads the EEPROM settings upon bootup) and for Default IP (i.e. automatically boots with factory defaults). If you move this jumper to the Default IP position and boot the unit up on the network, it will know nothing about any settings that you may have stored. Therefore, it won't know about any root password. However, it won't know about any TCP/IP network settings either so it has to be reminded of this before communications are allowed. For more details on this jumper, please see your product manual.
The steps to follow for this jumper procedure are:
arp -s 192.75.11.11 00:80:72:00:1c:0a
where 192.75.11.11 is the IP address for this print server to use and 00:80:72:00:1c:0a is the Ethernet address found on the bottom of the unit.
set user from default
save
Now once the jumper is placed back to the EEPROM Enable position and the unit is booted up, it will read this new setting from EEPROM and no password will be required.
In addition, you will still need to move the jumper to the Default IP position so you can log in through the serial port. You are automatically prompted for a login when you attach. Then once you log in to the command shell on the unit, you can enter these commands:
set user from default
save
Then turn off the unit, move the jumper back to EEPROM Enable, and try logging in. No password should be required.
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:
If you choose to try this default test, you will want to boot the unit up with the jumper in the Default IP position. Then you will need to:
arp -s 192.75.11.11 00:80:72:00:1c:0a
where 192.75.11.11 is the IP address for this print server to use and 00:80:72:00:1c:0a is the Ethernet address found on the bottom of the unit.
If the telnet connection succeeds, you will want to log in to the unit as root and restore your network settings in EEPROM to defaults with this command:
store net from default
Then you can store your IP address, netmask, and default router (optional) while still in this telnet session. Once this is done, turn the unit off and put the jumper back to the EEPROM Enable position. Then boot the unit up and try telnetting again to make sure things are still working.
If you'd like to eliminate this possibility, it's best to turn off the RARP and BOOTP request on the unit. If you can't communicate with the unit over the network though, you will need to go in to the unit through one of its serial ports. Then you can use the commands listed in your product manual to turn these features off. Please see your product manual for more details on logging in through the serial port and on the unit's command set.
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:
To test this hardware, use the FOX test right on the print server itself. This sends an ASCII line over and over again to the attached printer ruling out the network side of things completely. The only condition when running this test is that the attached printer can support text output. Please see your product manual for more details on this test.
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.
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 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:
Narrowing down the problem is the most important step in trying to determine where the garbling is happening and the FOX test concentrates solely on the print server's I/O port, the cable, the printer, and the communications between the print server and the printer. The network and host are not brought into the picture at all. This way if the data garbles here, you know the problem is setting or hardware related.
Note:
The most common extra processing that causes
garbling is onlcr which provides carriage return insertion
for Unix text jobs. This tends to garble any jobs coming from non-Unix
hosts so be sure to have this off with any non-Unix printing.
If you have to print from both Unix hosts and say, PC's, it is recommended that you use two different print queues so you can have onlcr on in one for the Unix jobs and have it off in the other queue for the PC jobs.
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:
Note:
The printer name comes up once you've created a queue and defined
a print server (e.g. M_001C0A) in PCONSOLE.
Upon bootup, the unit will send out a SAP request looking for a file server to talk to. From this file server, it will get a server list telling the unit about all file servers out there. The unit will then contact each one and see if there's a print setup to service. However, if the print server cannot find that initial file server, it will never be able to see any file servers on the network.
To solve this, the print server must be placed on a segment that has a Novell file server on it as well or else SAP requests must be able to get through to other segments which have file servers.
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:
For example, let's say you have an M202 with version 5.3 and you want to print to the destination, d4com2. By default, this name is lowercase so once you log in to the print server using one of the methods mentioned above, you will need to issue these commands to change the name to uppercase:
set dest d4com2 name D4COM2
save
Then you need to make sure you have this destination name defined as the printer name in your PCONSOLE setup.
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.
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:
If you see this message with the seconds to the right of the "blocked" message incrementing with every "lpstat" command you issue, then the printer is not allowing the print server to pass data to it. This will hang the print queue because the print server cannot take more data in its output buffer until the "blocked" message goes away (i.e. the printer sends the signal saying it's okay to send more data). Once the printer is cleared of any error situation and the "blocked" message goes away, the print job should then kick through and the queue should move along properly.
Note:
If the printer is in fact
online and ready to go but you're still seeing "blocked" messages,
there may be a problem with the communications between the print server's I/O
port and the printer. Maybe the cable is faulty and the send signal isn't
getting through to the print server or maybe the printer and print server
aren't talking properly. If this is the case, you need to look closely at the
settings on both the printer's interface and the print server's I/O port
interface. Another option is to try another printer to see if it works any
better.
Anytime you see this message, the print server says it knows about the print connection but it is waiting for the host to send data. Currently the unit's buffer has some room in it for more data but the host is not co-operating. Therefore, you need to look to the host to see why it is hung up. Look for errors that might lead you in the right direction and definitely make sure the host can still see the print server on the network using "ping" or "telnet".
Note:
This "waiting"
message is very common when using NT's LPR client with NT version 3.5.
Microsoft has a known bug that hangs up LPR printing periodically but this is
supposed to be fixed with NT v3.51 according to Microsoft's online Knowledge
Base.
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.
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.microplex.com/support/) for the latest firmware code and instructions.
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.
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.microplex.com/support/) for the latest firmware code and instructions.
** Since Windows 95 hasn't been out long enough yet, this section will be filled in within the next few months.
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: