Prev: 4d plot
Next: analog output over labview?
From: Sirin on 19 Sep 2005 16:43
I've seen various forms of this question; but they are all from 2002 or earlier. I am using LV 6.1 on Windows 2000 (and XP). My test station is set up using Windows 2000, so that is what I am currently troubleshooting.
 
I have a program that needs to run continuously updating a waveform graph on the screen; meanwhile, after recieving a digital signal, I need to do some statistical calculations and print out two pages of a report. The problem is that once I start running the routine starts printing out the reports (they are just VIs that print the front panel when complete) my waveform graph, and the rest of the GUI stops executing for about a minute and a half.
 
The printer I am printing to is connected via windows networking (it is a shared printer from a server, also running Windows 2000). I've looked at the different printing options (standard, postscript, and bitmap) but none of them really help any in terms of freeing up the cpu for my program to continue updating its front panel. The most 'freeze-time' I can accomodate in the program is 10 seconds; as the user may need to make additional time-critical (or, at least things that can't wait a minute and a half) requests on the system at that time.
 
Are there any ideas as to how I can improve the speed of this process? I know that it lies within the printing, because if I 'comment out' the printing portion only; things run just fine. I've tried building a separate executable in LV that just handles the printing, but this still does not solve my problem.
 
 
From: xseadog on 19 Sep 2005 17:13
How is the threading ( preferred execution system)?
Try user interface and standard-- who knows - just a suggestion:smileytongue:
Have you disabled debugging ?

Read application note 199: Labview and Hyper -Threading

chow
xseadog
From: zou on 19 Sep 2005 17:44
I had this problem before LabVIEW 5.1, before LabVIEW became multithread.
My solution was: embed postscript code in LabVIEW, bypass Windows print spooller, send postscript code directly to a local postscript printer on LPT1.
The reason it works is because that instead of sending a big image I sent postscript code which can be splitted to a few lines at a time.  That minimize the  lockup time to < 9 ms.
 
With LabVIEW 6.1, you shouldn't have this problem.  You might want check the multithread settings.  See attached image.
 
George Zou
<a href="http://gtoolbox.yeah.net" target="_blank">http://gtoolbox.yeah.net</a>


print.png:
http://forums.ni.com/attachments/ni/170/143314/1/print.png
From: Sirin on 20 Sep 2005 11:10
Yes, spooling is enabled; it is set to start printing immediately once the first page is spooled.
I'm beginning to think that the issue may be that I am printing to a windows shared printer, and the delay is the spooling taking place over the network? I have not studied how windows handles shared printers, but it seems like what may be happening is that my test PC is sending the data to the spooler on the remote&nbsp;server that is connected to the printer. This server is far from beefy (in fact, it may even be slower than my test machine is in terms of processor speed), it is also running Windows 2000.
From: AnalogKid2DigitalMan on 20 Sep 2005 12:40
There is a PrintControlExample.vi in Help (LV7.1) that uses report generation vi's to print to a printer or to a HTML file. Do not know about 6.1 availability.
Have you also looked at Task Manager Processes and also the Networking tab to look for what may be using up the resources- the LV program, the spooler, or the network connection. Is network connection running at full speed, full duplex?
Have you also tried a printer directly connected to the parallel port (skip all networking) to see what happens.
I do not have all that much experience in these isssues, I am just trying to throw out fresh ideas.
 |  Next  |  Last
Pages: 1 2
Prev: 4d plot
Next: analog output over labview?