Frank,

you asked on Mon, 24 May 2004 13:58:38 -0700:

Does the slow printing problem go away with an upgrade to LV 7 or 7.1 and win XP? I am trying to make the case for upgrading. Changing from the windows platform is not an option but an upgrade to LV 7 and XP may be.
Not really. Some minor improvements may be expected.

I assumed (yes I know <g>) that all Windows had some kind of print spooler that would spool a print job to disk or memory and then send it to the printer in the background.
Yes, but LV is a multiplatform tool and therefor cannot rely on just one platform's functionality. I'll explain it more deeply.

I have seen the slow printing under labview several times (version 6.x) with NT-4 and Win 98. Am I doing something wrong in my programming? My strategy is to check the Automatically print panel every time vi completes execution box and then run the vi.
I want to be lazy and not have to change a lot of code. It seems that with all that NI does to make programming easy, they would have handled this in some way. If that is not an option then I will try the suggestion from Dan.
There are some things you can do while staying lazy (as almost all good programmers are, AFAIK ;-))

But first a little background:
LabVIEW is graphical programming on multiple platforms. So printing is - somehow - like printing a photography - there's a lot of data to be transferred, and it is almost impossibel to just download a font and tell the printer what letters to use. And the techniques used to print a FP must be similar or even the same on all platforms in order to stay compatible. So IMHO there will almost be some kind of slow printing, compared with, say, MS Word on Winx or so.
AND printing has to run in the UI thread, which competes with all the other UI tasks and finally slows down (hopefully just) the whole UI-related part of the program.


You can, however, try several things:
1. Use postscript printing, when your printer supports that. PS puts a lot of the printout preparation 'burdon' to the printer and does typically not need as much data to transfer.
2. Slow printing often means that the printout itself as well as the execution of the other code is slowed down (often incredibly). You can avoid it partially by adopting an idea stated on Thu, 20 May 2004 02:38:06 -0700 by "Dan Press" <[EMAIL PROTECTED]>. He wrote:
> I create a separate application; let's call it the "YYY_Project Print
> Service.exe". The application's job is just to sit there, but its INI
> file configured the VI Server to listen on a port other then the default
> 3363.
You may use this technique as a more global framework. You may also adopt your existing code by just changing your printout.vi
* to provide a method to accept data (a queue, even a temp file),
* make it an exe
* add some code in the caller that sends print data to that exe and
* start that printout.exe as free running.


This provides an extra UI thread for the print process with a minimum of effort. You may try playing with priority and so, but probably this is not necessary.

Just an idea...
--
Mit freundlichen Gr��en!
Greetings from Germany!
--
Uwe Frenz


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dr. Uwe Frenz Entwicklung getemed Medizin- und Informationtechnik AG Oderstr. 59 D-14513 Teltow

Tel.  +49 3328 39 42 0
Fax   +49 3328 39 42 99
[EMAIL PROTECTED]
WWW.Getemed.de




Reply via email to