LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Printer Status Revisted (Checking Online Status)

So it looks like I was a bit preemptive in declaring a solution in the thread below Smiley Indifferent

 

http://forums.ni.com/ni/board/message?board.id=170&thread.id=425404

 

What I'm looking to do is use LabVIEW to check whether any printers are available ONLINE before I proceed with a print.  Using the printing property nodes appear to only return a list of configured/installed printers on Windows regardless of whether they're connected or powered on. 

 

Any suggestions?   

Message 1 of 10
(3,896 Views)
Unless Microsoft has changed things recently, it can be tricky to check the printer status before you print the job.  There are a number of properties and methods in .NET that seemingly would do what you need (PrintQueue Class in the System.Printing Namespace).  As of the last time I tried something like this in Windows, the printer status was only updated when a job was submitted.  In Microsoft's logic, the job of the OS is to provide an abstraction layer between your application and the printer hardware.  If the OS is ready to receive the data for a print job, it considers a particular printer 'Online'.  When the OS gets around to sending it to the printer, then it might discover a problem (turned off, disconnected, out of paper).  At this point, the OS will report a problem to the application, but Microsoft considers it an OS issue, not an application issue.  As you've seen, the OS method of resolving the issue usually involves hangs, crashes, dialog boxes and other things you'd like to avoid in the first place.
Message 2 of 10
(3,887 Views)

Hey Darin,

 

Thanks for the response.  The main issue I have is that the LabVIEW executable hangs up when the user requests a print and nothing is connected or turned on.  In this scenario it would ideally return an error and cancel the print.  At the very least, it shouldn't hang up even if the queue remains.  The only way I can get out of this hang up is by turning the printer on or cancelling the print job through windows.  A timeout error would help resolve this issue, but this functionality does not appear to be available.  I've considered attempting to query printer status through a Windows command line request through LabVIEW or checking the status of all LPT ports.  Unfortunately, I'm not really familiar with these topics and I have a limited time frame in which to get this done.  If there was a way to at least avoid/detect this hang up, it would be sufficient (even if the printer job was put on queue).  I'll take a look at the .NET property you specified and see if I can use it for this functionality. 

Thanks.   

 

0 Kudos
Message 3 of 10
(3,882 Views)

Darin,

 

I tried the attached VI to see if I could at least take a look at the printer queue properties for testing purposes, but so far I only had luck getting back a name property.  This only worked on one of my systems (on a local network) running Windows XP.  On the other (not connected to any network), the program crashed.  You see anything wrong with the references used in the attached code? I have determined that if I enable spooling on my printer, the easyprint VI at least won't hang up the LabVIEW executable.                

0 Kudos
Message 4 of 10
(3,870 Views)
I am a bit behind the times, please save a version for 8.20 (or 8.0) and I'll try to look it over.
0 Kudos
Message 5 of 10
(3,857 Views)
Here's a version 8.2 save.
0 Kudos
Message 6 of 10
(3,855 Views)
The code looks fine, and works for me as well (XP with networked printers).  Spooling (as you noted) and using network printers are my best advice for avoiding hangs.  Once the data is dumped into a file or the ethernet as far as your app is concerned printing is over.
Message 7 of 10
(3,848 Views)

I see. Yeah, the computer this wasn't working on is an older version of Windows XP which does not come with this system.printing.dll.  So yeah, it looks like the properties are processed very quickly during a basic print.  I think the best I can do in this case is to wait maybe 50-100 ms to print and then check if there are any jobs in the queue.  If there are, I could then send a warning message to the user.  I'll have to settle for that since there doesn't seem to be an easy way to check for available printer hardware connections, thanks.   

0 Kudos
Message 8 of 10
(3,843 Views)

I am having the same issue. I would love to try the VI that was posted but I have labview 8.0.

 

Can someone please save this VI back for earlier revision use?

0 Kudos
Message 9 of 10
(3,652 Views)

I suppose...

 

 

0 Kudos
Message 10 of 10
(3,609 Views)