Everything in Particular

I recently had the “opportunity” to learn first hand how to go attack the topic of batch printing against an Epson Dot Matrix Printer. I’m posting this here to document my woes and difficulties on this very bumpy road.

Defining the Problem

Why should batch printing be any different than single printing? There are a few simple reasons this is different:

1. Running out of paper
2. Paper jams
3. Printer becomes paused

Basically the problem is, if you send 100 print jobs to the printer, you want some way of assuring the jobs actually completed. Imagine if you sent 100 print jobs to the printer and the printer runs out of paper at 50. If your application isn’t set up to do batch printing properly it will send the remaining 50 jobs to the printer even though the printer may have no way of receiving them. Whether it is capable of receiving these jobs is really a matter of the model and how much memory it has to queue up your jobs. The size of the print jobs is also a factor. So your application happily sends the remaining 50 jobs to the printer, how many ultimately print successfully when the paper is loaded? 20? If so what happens to the other 30 print jobs? How does the user even know that they didn’t print or which ones didn’t print?

Finding the Answer

Epson was exactly 0 help on this issue. There was no information online that even gives a hint of a clue of an inkling of where to even start looking. So, I emailed their support department. Here is the email I sent them:

I am writing an application that will print invoices to [a printer with model #LQ-2090]. One requirement of this application is for batch printing. I have a few questions about the support for batch printing with this printer:
1. If it runs out of paper while jobs are being sent to it, what is its behavior? Does it queue requests? What queue limitations (memory limit etc) does it have?
2. If #1 isn’t possible is there a programmatic way to query when the printer is out of paper or otherwise unable to print?
This email was sent originall on 06_05_2008. Since I was actively working on the application I couldn’t wait for their response. The chances it would take too long or that it wouldn’t be helpful were too great. So I did some researching of my own as well. Ultimately the answer came through my own research. I think Epson sent some response about how much memory was available on the printer and then said there was “no way” to ask the printer for a status. So just as I anticipated the response didn’t yield any information that would be helpful, in fact it was wrong about not being able to query the printer for a response. Their email also came several days after I wrapped up the project. I can’t find their response so I can’t say the date exactly but I want to say it took them something like 2 weeks to respond.

The Solution

Ultimately, as I said, I found the answer myself. I was coding along happily one day when one of my colleagues mentioned there was a web server built in to the network card we installed in the printer. Curious, I decided to check it out. It was from that web site that I got my first glimmer of hope. The printer supported SNMP and there were configuration items for setting up SNMP and SNMP traps Sweet! My first instinct was to do it all through traps. Surely the printer would send me a message saying “Please Load Paper” or something like that whenever there was an alert. So I pulled out my Trap Receiver application (iReasoning) and told the printer to send all traps to my desktop. With that all set up I simulated a few scenarios by forcing an out of paper situation, a paused situation and a jam situation. From across the room I could see my trap receiver filling up with traps. Excited I ran over to my computer to see what information the printer was sending me. My elation was premature and short lived. For a few minutes I compared the different traps I had received trying to notice differences. If I was sent the number 12398521 for instance whenever the printer was out of paper, I could just put those values in a config file and be done with it. What I found though over the course of a few minutes was that every trap was the same! What? It didn’t even matter if the trap was sent for a different reason, the data I recieved was exactly the same! Well, the same save for the fact that it was including in the trap an incrementing number. So the first trap sent 0, the second sent 1, the third 2 and so on. Well this is completely useless! If I want to know how many traps I have received I can count them myself! . I have a little experience with SNMP traps but if this is a standard thing to do with traps this is a new one for me. Whenever I send a trap I include a human readable message letting someone (or some program) know what is going on. Ultimately I did figure out (I think) what these incrementing numbers were supposed to be telling me. More on that later though. Well, it was apparant that the SNMP traps weren’t going to be of any use. I could treat them like a toggle I guess, but how would I know to have the toggle on or off to begin with? How would I know if I got a message even if the printer was capable of continuing to print? This is not a solution I would except, so I decided to keep looking. The next place I began looking was google. I decided to do a search for something less specific, a search that didn’t include Epson or LQ2090. Doing that got me a hit that ultimately led to the answer. The hit I got was of someone asking how to use SNMP messages to get printer status information. While the article I found was for a different printer and didn’t have any information in it that was, in the end, directly usable getting the hint that SNMP messaging is a possible route I could go was invaluable.

From there it was more and more google searches that led me to this real gem (extreme sarcasm applied here): ftp://ftp.pwg.org/pub/pwg/pmp/mibs/rfc1759.txt. This my friends is rfc 1759. I recommend you look away, look away! Everytime I try to get any useful information from an RFC it always leaves me asking “WHY!?!”. Why on earth would someone write this, and how is it supposed to be useful? After a lot of searching I was finally able to find a guide that explains the RFC. This guide broke down the RFC terminology and explained what it meant, then gave the SNMP OID for each item. This guide, IMO should be the RFC. In any case, guide useful, RFC useLESS! *sigh* ok I feel better now.

As much as I have talked up the guide, it was also ultimately of no help . Although it did contain what I was searching for, I couldn’t find what I was looking for as a consequence of just not expecting what I was looking for to be called what it was called.

So how did I find the answer? Good old trial and error / brute force. I opened up my MIB browser app (also by iReasoning) and told it to hit the printer with every SNMP message possible by doing a walk on OID 0. This yielded hundreds of results, with after a little doing I was able to copy into a text file and save it. I did this 3 times: once when the printer had paper and was good to go, once when the printer was in an out-of-paper error state, and once when the printer was paused. I then took those 3 files and did a diff on them using KDiff (a very nice diffing tool). What I found is below (you will want to click to enlarge):

The OID that is shown in this diff is the “printmib.prtAlert.prtAlertTable.prtAlertEntry.prtAlertDescription.1″ OID. While this seems like a very reasonable thing to call it I was still unable to find it through my searches either in google or in the above-mentioned guide. I was always searching for things like “printer status” or “out of paper”. In any case, this brute force method did give me all I needed to begin querying the printer for its current state and so I was basically done with my discovery session. I don’t know all of the unique alert descriptions that can be retrieved from this printer on this OID (I couldn’t find a list anywhere from epson even after I knew some items on the list) but here are those I have found: supply the paper, remove the paper, paused. Of course it is not unlikely for this to be different between printer manufacturers and models so you may have to do a bit of trial and error.

One Final Small Problem

One minor final thing I ran into was that the OID would change slightly upon each new alert. The first alert would show up under OID printmib.prtAlert.prtAlertTable.prtAlertEntry.prtAlertDescription.1.0, the second printmib.prtAlert.prtAlertTable.prtAlertEntry.prtAlertDescription.1.1 and so on up the number scale until the printer was power cycled. This gave me another “A-HA!” moment when I suddenly realized what those stupid traps I mentioned before were all about. The aforementioned printer RFC had some information in it indicating the printer could have multiple rows of alerts in a table in its MIB and that there needs to be some method by which one can return things like total number of alerts and current alert index via SNMP. I never figured out how to send an SNMP message to the printer to retrieve the current alert index (although the RFC seems to indicate it is possible), but I now realized the incrementing number in the traps was the alert index. I could then use that number to construct the correct OID for my SNMP message querying the printer for its alert status description! Pretty cool!

Now, For those of you who aren’t receiving or cannot programmatically receive traps from your printer another solution to this problem (and the one I ended up implementing) is to attempt to get the alert description at OID .0. If that fails (or returns an empty value), tell your SNMP client to do a GetNext(). If the GetNext returns a non-empty value that belongs to an OID that begins with “printmib.prtAlert.prtAlertTable.prtAlertEntry.prtAlertDescription.1″, then you are good to go. Here is some sample code that does that for your reference:

[code lang='csharp']

while (manager.LastError == 0 &&  returnedValue.OID.StartsWith(oid))

{

value = returnedValue.Value;
returnedValue = SnmpObject.manager.GetNext();

}[/code]

When this loop completes “value” will have the “next”-most value for the OID we are targeting.

All Done

This marks the end of the material I set out to cover. Hopefully this will be useful to anyone trying to get a batch printing application off the ground. SNMP is universal so as long as your printer is network attached, even with vastly different features, the solution could likely be similar.

Comments and questions welcome, thanks!