Log in to create and rate content, and to follow, bookmark, and share content with other members. Not a member? Join Now!

AnsweredAssumed Answered

how to notify client if error on printer

Question asked by Paul Bento on Nov 3, 2014
Latest reply on Oct 8, 2015 by Steven English

Like • Show 3 Likes3
Comment • 13

Hello Everyone,

We have to manually change the name of a print device or queue in order to keep users from unintentionally releasing jobs to a printer that has issues.

Even if the door is open -- the print job is released and money is debited from user's account.

Money is not taken off -- if the printer is "off-line".

Seeking guides or examples on how the following can be accomplished....

I'd like to use Notify to send a message or messages if the following occurs --

If a printer has an issue -- such as a defective sensor, jammed printer or other.

Message might say -- "printer you selected is out of order --- please seek alternate printer".

And on top of that prevent the print job from arriving at the release station.

Does anyone have examples or has a similar scenario running?

Thank you,

Paul

3 people also have this question

Outcomes

13 Replies

Mark Decker Feb 5, 2015 5:27 PM
Mark Correct
Correct Answer
This response assumes that you are referring to Uniprint 8.4 or 9.0. The answer might be slightly different for older versions.
If I read this correctly, there are actually two different things going on here. First, the job being released to the device. This happens when a job is already sitting in the queue and the user is standing at a release station (of whatever type). In this scenario, the status of the device is very important because the job is about to be released so if it is not ready at this time for any reason, the job should not be released (otherwise the user is charged but does not get output).

In the second case, you mention the submission of the job to the queue. For Secure printing, it is intentional that the device status is not checked because there may be many devices that the user can release from. And, in addition, the user may submit the job while the device is jammed, but not actually go to release it until later, after the jam has been cleared. So, the answer to your question depends on which bit you are concerned with and what you want to happen.

Upon job release, an appropriate error message should be displayed to the user. If you are not seeing this, there are ways to modify how we interpret messages from the device. If this is something you need more information on, let me know and I can direct you to the appropriate resource.

As for job submission, are you sure you want to stop a job from being submitted to a secure queue because a device is offline at that time? If so, this would require scripting to get the status of the device (or devices) associated with that queue at the time the job was submitted.

If I missed it, you can do this fairly easily if you happen to be talking about job submission to a DIRECT queue. There is a script on the Uniprint CD that will notify direct print users if a job fails for any reason. On the Uniprint 9.0 CD the script is named "PrintEndJob - Notify User.txt" and is found in ...Uniprint 9.0.8467 GR\MainCD\tools\plugins\scripts.

Let me know if I misunderstood any part of your question and I will try again
Like • Show 1 Like1
Actions
- Paul Bento @ Mark Decker on Aug 6, 2015 4:29 PM
  Mark Correct
  Correct Answer
  Hello Mark,
  We are using the "secure release" method.
  We have 26 OMEGA PS200 1.0.1 around our campus.
  
  Again -- we would like to keep patrons from printing to a printer -- that might have a paper jam or low on cyan toner -- for instance.
  The process is -- when a Patron releases a print job -- he/she gets charged -- regardless if the printer is online with no errors or certain conditions.
  The user is never warned that -- which explains "it is intentional that the device status is not checked".
  There is no appropriate error message displayed.
  
  We would love to have a script that checks and the user gets notified -- either through a popup window on a client workstation or at the OMEGA -- preferably at the OMEGA.
  
  If you can forward additional information -- as how we can get a message to the patron -- for instance "PRINTER-BW-1 is jammed -- please do not try to release print jobs to that printer".
  
  That would -- cut down the requests for patron credits -- due to bad output.
  
  Regards,
  
  Paul
  Like • Show 1 Like1
  Actions
  - Steven English @ Paul Bento on Aug 6, 2015 4:53 PM
    Mark Correct
    Correct Answer
    Paul Bento,
    
    Major portions of this conversation are only applicable to Uniprint 8.3 or newer, so if you are running an older version, an upgrade might add the protection from billed jobs on offline devices that you are looking for.
    
    I think what Mark is saying is that when dealing with Print Groups configured for Secure Release as opposed to direct printing (sounds like this is you based on reference to an Omega), the status of the printer itself is not checked when a user submits the job but rather when the job is released. This is due to Print Groups having the ability to release to more than one printer. It is not uncommon to have a "Print Anywhere, Release Anywhere" mentality in many places that results in you literally being able to release to any Pharos printer on campus regardless of where the job was submitted from. Obviously, it would not be reasonable to reject a job submission when a single printer on campus is down, especially when you have no idea if the student intends to release the job at that printer.
    
    As such, the status of the printer is verified at the time of release, and the rules regarding that check are as follows (this is off the top of my head):
    The device must be associated with the print group that the job belongs to
    The device must be associated with the release station from which the job is being released
    The attributes of the job being released must not exclude it from being released at a printer determined as eligible in steps one or two
    The Online State Check must enabled on the device selected for release
    
    Letting us know which version of Pharos you are on is probably the best piece of info to provide at this point. Since 8.3, the default is for Pharos to perform an SNMP check on the device to ensure it is indicating that it is ready/ready enough to receive a print job so that users are not billed for jobs that we know in advance are unlikely to make it to the printer or be pressed to paper.
    
    Regards,
    Steven
    Like • Show 1 Like1
    Actions
    - Paul Bento @ Steven English on Aug 6, 2015 5:03 PM
      Mark Correct
      Correct Answer
      Hello Steven,
      We are using Uniprint 9 (Version: 9.0.8467.36).
      
      Correct Steven — we’re using Print Groups — not direct printing.
      
      Regards,
      
      Paul
      Attachments
      ITSO-sgnature_email_color.gif3.7 KB
      Like • Show 0 Likes0
      Actions
      - Steven English @ Paul Bento on Aug 7, 2015 12:09 AM
        Mark Correct
        Correct Answer
        Paul Bento,
        
        In response to your original questions then...
        
        I'd like to use Notify to send a message or messages if the following occurs --
        Notify requires that the Notify client be present on the target machine (the one receiving the message) which limits it to Mac or Windows machines.
        
        If a printer has an issue -- such as a defective sensor, jammed printer or other.
        The online state check for each device should be enabled along with proper configuration of SNMP. Once done, if the default behavior of the SNMP responses is unsatisfactory, they can be customized to be more aggressive in evaluating a devices as being offline.
        
        Message might say -- "printer you selected is out of order --- please seek alternate printer".
        This functionality is essentially already baked in, but the default warning/error is "No Suitable Printer Available" when Pharos detects that all eligible printers for that release station are offline.
        Edit: It would probably be possible to intercept this error message at some point along the way in order to deliver a more intuitive error message, but I have not tried to do this yet, so you would probably be just as well off messing with it on your own or just ask your Pharos reseller or rep for a quote to get this done if it is important enough.
        
        And on top of that prevent the print job from arriving at the release station.
        As previously posted, in a Secure Release environment this would not really be considered as a feasible mechanism except perhaps in very specific configurations. It would be fine in a direct print environment, and the PrintEndJob notify script would essentially provide this response, but obviously no release station would be involved. I think if the problem is resolved at a different level, you may find it to be a better solution as the user can simply go to another release station to release their job instead of having to re-submit. Of course, this makes an assumption that you do not have your SRS queues divided up like direct queues would be.
        
        Regards,
        Steven
        Like • Show 0 Likes0
        Actions
        Paul LaFollette @ Steven English on Aug 6, 2015 5:29 PM
        Mark Correct
        Correct Answer
        Steven English
        
        Is there a resource or guide advising proper configuration of SNMP?
        
        Thanks,
        - Paul L.
        Like • Show 0 Likes0
        Actions
        Steven English @ Paul LaFollette on Aug 7, 2015 12:17 AM
        Mark Correct
        Correct Answer
        Paul LaFollette,
        
        Not that I am aware of. Here are the some informative bullet points:
        The Get community name is what should be entered in the Pharos Administrator > Output Management > Devices
        Pharos uses SNMP v1/2 so this version must be enabled
        I have seen problems occur when v3 is also enabled (this happened once, on Xerox IIRC)
        The default SNMP port is 161, so the firewall rules would need to allow for this
        Once SNMP is working, you should see it automatically populate the make and model of the printer and you will be able to successfully run the online state check available in the action pain
        
        That online state check button will prove useful when testing modification of the default SNMP rules if you prefer to force Pharos to evaluate a device as being offline that it would regard as being online by default. See the links below for the how to guides as well as an incident I was working on where the rules were not working as expected. That thread would likely give additional insight on the rules, how the interpret SNMP codes, and therefore how they work.
        
        Regards,
        Steven
        
        TechNote Checking Device Status.pdf (2014 version)
        TechNote: Checking Device Status (2015 version)
        Re: SNMP Device Status check
        Like • Show 1 Like1
        Actions
    - Paul LaFollette @ Steven English on Aug 6, 2015 5:06 PM
      Mark Correct
      Correct Answer
      I am interested in the same kind of "feedback" to the end user at the release station (we're using the Pharos Station software running on a VM system). It would help me A LOT to be able to tell the end use why (or at least a better idea) as to why the release station refused to release their job. Or if their job was released and then saw an error ... what happened. Perhaps even provide a place for them to enter feedback ("nothing happened", "printer is jammed!", "your system sucks")... something that helps us to better serve our customers.
      
      As for the "PrintEndJob - Notify User.txt" script ... I assume this provides feedback to end users of Direct Printing queues ONLY when the end user's printer installation was done with the Pharos Packages (which include Pharos Popup, Pharos Notify, etc.), correct? I've located the "PrintEndJob - Notify User.txt" file on the Uniprint 8.4 CD (same path as version 9, we're using 8.4).
      
      I ask because our system has around 470 "Direct" queues on one of our Uniprint servers, and creating packages for each of those "Direct" queues ... would be extremely tedious (not to mention a pain to manage) ... therefore we only create a package if it is necessary. I wish I could provide better job status (or error status) feedback to the end users that without having to create each and everyone of those packages followed by installing the packages on a few thousand computers.
      
      Also, does the "PrintEndJob - Notify User.txt" script also notify Mac users (if their Mac is setup with the Pharos Popup)? Or is it only the Windows systems? I'm not aware of Pharos Notify being part of the setup for Mac users.
      
      NOTE: Don't let me derail this thread from Paul Bento 's questions.
      
      Thanks,
      - Paul L.
      Like • Show 0 Likes0
      Actions
      - Steven English @ Paul LaFollette on Aug 6, 2015 5:27 PM
        Mark Correct
        Correct Answer
        Paul Lafollette,
        
        Maybe put those questions in a new discussion and then edit your post to include a link to the new discussion? I'll try to get you an answer later today.
        
        Regards,
        Steven
        Like • Show 0 Likes0
        Actions
        Paul LaFollette @ Steven English on Aug 6, 2015 5:38 PM
        Mark Correct
        Correct Answer
        Steven English
        
        I've put those questions here: Printer Job status and Feedback questions
        
        Thanks,
        - Paul L.
        Like • Show 0 Likes0
        Actions
Paul Bento Oct 8, 2015 12:40 PM
Mark Correct
Correct Answer
I'm certain that there are a lot of Pharos customers who would love to have the ability to change / customize end user feedback instead of having generic popup messages stating -- "An internal server error occurred." or "Please see your systems Administrator".
I know that many of these comments are hardcoded.

Pharos -- I'm proposing a new feature request:
Please allow the site admins of Pharos Uniprint to have the ability to modify those "canned responses" seen within Pharos Notify and/or any Pharos Release station or OMEGA.
Tailored feedback will allow the site Admins to give feedback to their end users -- thus reducing end user frustration and provide needed direction.

Thank you,

Paul
Like • Show 1 Like1
Actions
- Paul LaFollette @ Paul Bento on Oct 8, 2015 12:56 PM
  Mark Correct
  Correct Answer
  If the site admin had the ability to modify those "canned responses", it would probably be nice to have an option allow the end user to input some info (answer a question or two) since info about the job can be useful, or input about what the printer currently displays can help the site admin troubleshoot/analyze the root cause of the error, or perhaps some contact info of the end user.
  Like • Show 0 Likes0
  Actions
- Steven English @ Paul Bento on Oct 8, 2015 11:30 PM
  Mark Correct
  Correct Answer
  Moving back to the original topic just for a bit, Paul Bento, if you have not already done so, the device status can be configured so that Pharos evaluates the device as being offline. TechNote: Checking Device Status
  
  Regarding the current topics of customizing error messages, it probably would be best to propose the feature request in new thread or even do it as a poll so that it can be voted on. The scripts do allow for certain messages to be customized, but they are wrapped by the default "internal server error" and "contact Pharos support" messages. I normally just use line breaks in the scripts \r\n to add line breaks so that the message that I want the end user to see is much more readable and is not lost in the "header" and "footer" errors.
  
  Regards,
  Steven
  Like • Show 0 Likes0
  Actions

Incoming Links

Printer Job status and Feedback questions

how to notify client if error on printer

Outcomes

Attachments

Related Content

Recommended Content

Incoming Links