Other Software > Announce Your Software/Service/Product

[Python][Windows] Debug/Gather printer information

<< < (2/2)

Stoic Joker:
Yea at the moment this project only works for local printers (as you understand, networkprinters on remote sites also counts as local) :)
I'm actually heading for usage tracking and report errors on the fly.-DoXiD (April 26, 2011, 02:26 AM)
--- End quote ---

Cool. Now for the errors, are you looking for communication errors (getting the job there), machine errors (printer out of something /jammed), or both?-Stoic Joker (April 26, 2011, 07:38 AM)
--- End quote ---
Originally my plan was to just follow the communication errors from the PC (client) to the printer, once there the printer is a whole nother story, but when you mention it i could probably get that up on my todo list, getting the printer errors as well.-DoXiD (April 26, 2011, 09:17 AM)
--- End quote ---

For the most part, the printer errors aren't worth the trouble. There is no consistent (RFC/Industry Standard) location for the error data, and if the printer actually does throw a truly Critical Error ... It'll be lucky if it can record it in its own logs before locking up. Anything else can be pulled out of (an SNMP query for) the Display text in real time (supplies out/paper jam - [User stuff]) which is in a standard location.

Now if you can track which ring of hell the print job just fell through on the communication side... That would be Uber Handy.


These days (with direct IP printing so common/cheap) print servers seem to only get used for user usage tracking scenario. However most of the (driver/spool interrogation level) ones I've tested have great difficulty tracking duplexed pages, multiple copies, and the larger paper sizes (like 11x17) that can make a big difference when calculating someones actual usage.

Then there are the printers that locally store the by user usage tracking info... Which is great if you want to pole for it constantly to avoid missing something (not recommended) because they dump the logs when restarted.

Only thing I found that will guarantee-ably accurately catch everything sent to a printer is Capella Megatrack. Which is an accessory firmware add-on that sits on the printer and reports back to a SQL db. At the time I had investigated the options available, including a scratch write ... but decided the best thing for the company was to recommend the client go with Capella (which ain't cheap). The deployment has been running just fine for the last (almost) 5 years.

Please understand, I'm not trying to talk you out of the project. I really and truly hope you succeed ... I'm just sharing the fact that I couldn't quite pull it off.-Stoic Joker (April 26, 2011, 07:38 AM)
--- End quote ---
I understand, no worries :) i find it better to know what I'm getting myself into but i myself always live by the motto "you can do anything, don't let nobody tell you otherwise, nothing is impossible" and i firmly believe that there's no problem that can't be solved, the only question is who will come up with the answer :)-DoXiD (April 26, 2011, 09:17 AM)
--- End quote ---

Agreed. But I have seen features turn into administrative nightmares because of differences between where a given piece of information is stored between different makes and models. Interrogating the driver/spool probably is the safest bet, but permissions issues come into play then also.


I'm looking in to the direct IP (TCP) printing as we speak, mainly this idiotic function:
"Output is transmitted directly to the printer without staging or respooling, saving system resources and enhancing print routing performance."
Sure it's a performance saver perhaps, but for a sys admin not in charge of the "pre-spool" server (Streamserve) it's really hard to debug anything cause the document that you print is just that, a TCP connection and nothing else, there's no spooled documents and no indication of what's getting printed. Love that the feature excists but there has to be more info in this area :)-DoXiD (April 26, 2011, 09:17 AM)
--- End quote ---

I may be missing what you're after here. but to me Direct IP is way simpler to deal with. The spooler client side is just a cache that frees up the application quicker so the print job can crawl up the wire. Print servers really just allow for another place for the job to get stuck ... Especially when the spooler becomes badly fragmented because it was left in the default location on a high traffic print server.

I just love it when a client's IT department swears everything is clear...Only to watch the printer vomit paper for a half an hour just seconds after coming back on-line.


Yours is more of a scanner then a job-information tool o guess even if yours had a few information features such as printer toner levels etc. Have you developed yours entirely from scratch cause it looks like you were surprised that "web access" was in your feature list? :P
What's it written in? C# or .NET?-DoXiD (April 26, 2011, 02:26 AM)
--- End quote ---

Yes, Page Countster's primary function is to find and list all of the printers on a network and collect page count and tracking information for billing purposes. I'm not sure what you're referring to regarding the "surprised that "web access" was in your feature list" part. But if you can link me to the statement I'll have a better chance of answering.-Stoic Joker (April 26, 2011, 07:38 AM)
--- End quote ---
http://www.youtube.com/watch?v=plLrAZrvq3I
1min 41sec into the video:
"i did wanna show you one thing tho that surprised me quite a bit, which was that i didn't even realize that my printer could be accessed and configured through the web" (think it's you in the video? or is that mauser?).-DoXiD (April 26, 2011, 09:17 AM)
--- End quote ---

Ah! lol Yes, that was mouser in the video ... I do 99% of the printer configuration through the Embedded Web Server, and only physically touch the printer if forced to.

At any rate, yes it was a from scratch project, that occupied a great deal of my time for about 3 years. It is written in pure Win32 API C++ (no .NET/MFC/run-time requirement nonsense) using MSVS2005.
-Stoic Joker (April 26, 2011, 07:38 AM)
--- End quote ---
Cool, haven't been here long enough perhaps but i haven't seen many projects that doesn't involve PHP or "simple" programming, not yet at least, except yours.
Gotta hand it to you for making such a in-depth project with packet forging/managing etc :)
-DoXiD (April 26, 2011, 09:17 AM)
--- End quote ---

Thank you. Most of the simple stuff are just by request programs done by members to help people with simple requests. But there are many extremely talented programmers here, most of which are far better at it than I. My nitch is Network Deployment & Server Administration, programming for me is a hobby. Or rather it was supposed to be a hobby, until the boss found out what I could do. I designed and scratch wrote many of our company's internal database systems. Page Countster was/is also a company project.

Navigation

[0] Message Index

[*] Previous page