RMA Checklist

The following are the most common problems reported with RMA requests. For each problem, you will find some things to attempt before seeking an RMA number along with an approximate figure telling you how often RMA's are actually given for these particular problems. These values are based on RMA testing history here at Microplex and you'll probably notice that RMA's aren't needed that often after all.

ERR LED Comes on upon Bootup

Per cent of RMA's coming in with this problem which in fact did require further testing at Microplex = 80%

• Have you checked the LED pattern on the front of the print server after waiting 30 seconds after rebooting the unit? Here are some common LED patterns to be aware of:
  • STAT-ERR-NET = ON-FLASH-ON

    Anytime the ERR LED comes on flashing and stays that way right after bootup, it generally points to a board failure or "hardware exception error".

  • STAT-ERR-NET = ON-ON-ON

    Anytime the ERR LED comes on solid along with other surrounding LEDs, the problem is most likely with the PROM chips. Sometimes sending out new chips is all that is required so please contact Microplex before sending it back for RMA.

• Does the ERR LED take 2 to 3 minutes to come on right after bootup? If so, you will need to check the output of "list key" on the print server itself. If you see any fields "disabled", please contact Microplex so your licenses can be re-enabled.

Unit Stopped Talking on Network or Never Started Talking

Per cent of RMA's coming in with this problem which in fact did require further testing at Microplex = 25%

• Have you confirmed the network cable is okay by swapping around network devices or print server locations?

• Are you able to try another network connector on the print server to narrow down the problem to a particular network port? A transceiver would be needed to try this other port.

• Have you tried setting the print server's settings back to factory defaults by using the appropriate jumper on the unit's board? Sometimes setting things back to square one and then redoing the network settings helps kick things into gear. Please see your product manual for more on the default jumper to use for your print server model.

• Has there been a change to the network recently that might affect this print server's communications? For example, on a TCP/IP network, a new device added to the network could be accidentally using the same IP address as the print server.

• Do you have a RARP or BOOTP server running on your network? If so, the print server will send out a RARP and BOOTP request by default upon bootup so even if you have stored network settings in EEPROM, the unit may gain a new IP address from one of these servers.

  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.

• Has there been a change to the unit itself? For example, maybe the unit has been moved to a new location or maybe somebody has changed a key network setting.

• Has a special event taken place such as a lightning storm or power surge? If so, did other equipment on your network get affected as well?

Print Server will not Print

Per cent of RMA's coming in with this problem which in fact did require further testing at Microplex = 10%

• Do you have a working printer attached to a print server I/O port that is ready to go and not in an error state? Use the "lpstat" command on the print server itself to see whether or not the unit's I/O port recognizes that attached printer.

• Are you sure the printer cable is good? The best test is to try a cable that you know is working somewhere else.

• Have you tried running a troubleshooting test on the print server to test communications between the unit's I/O port and the printer? The best test is called the FOX test which submits one ASCII line over and over again to the printer. If your printer can print text, this test will tell you whether or not your printer, cable, and print server I/O port are behaving properly. Please see your product manual for more details on this test.

• Are you sending a job format that is supported by the attached printer? For example, sending a text job to a PostScript printer will not produce any output. The printer will choke on this since it is not PostScript code.

• Is the job even leaving the host and getting to the print server? Once again, use "lpstat" on the print server to see if the job registers on the appropriate I/O port or simply check your host queue to see if the job gets stuck there. If it is stuck on the host, the problem is the spooler configuration most likely unless you can't talk to the print server at all. Then you need to find out why that fails since it will definitely affect all printing.

Print Server Stopped Printing

Per cent of RMA's coming in with this problem which in fact did require further testing at Microplex = 10%

• Can you communicate with the print server over the network still? If not, printing will obviously be affected so look for reasons why communications have stopped.

• Are the printer and printer cable okay still? Try swapping cables and possibly the printer or else use a built-in test like the FOX test to test the hardware involved. Please see the product manual for more details.

• Is the job leaving the host and getting to the print server? Once again, use "lpstat" on the print server to see if the job registers on the appropriate I/O port or simply check your host queue to see if the job gets stuck there. If it is stuck on the host, the problem is the spooler configuration most likely unless you can't talk to the print server at all. Then you need to find out why that fails since it will definitely affect all printing.

• Has there been a change to the print setup? For example, if somebody changes a queue or destination name on the print server itself, various print setups will be affected unless the names are changed there as well.

Get Garbled Output

Per cent of RMA's coming in with this problem which in fact did require further testing at Microplex = 1%

• Has the printer output ever been proper with this setup? If not, then you know there's a configuration error or the data is getting processed on its way over to the print server for printing. If it did work at one point and then started garbling, something might be failing like the printer cable or the flow control between the print server's I/O port and the printer. In addition, maybe somebody turned on some extra processing somewhere along the print path which these print jobs don't like. This would most likely be turned on at the print server in a queue or in a destination's model. Please see the product manual for more details.

  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.

• Have you tried a troubleshooting test like the FOX test to confirm basic communications between the print server and the printer? Please see the product manual for more details.

• Are you sending a job format that is supported by the attached printer?

• Is the data leaving the host in a proper format or is it getting garbled before leaving the host? Sometimes capturing a job to a file first and then viewing this file can tell you where the garbling is occurring.

• Do you have an old firmware version in the print server? There are some versions that have I/O port bugs which garble output so it's recommended that you get atleast version 5.2.3 and higher.