How to not lock up LabVIEW exe by printing?

[Sirin]

The task manager processes doesn't really indicate much out of the ordinary; in fact, it tends to act just as sluggishly as the LabVIEW application. There isn't a networking tab in Windows 2000 Task Manager unfortunately.

My next step is going to be hooking a printer directly to the computer to see if that changes what is happening. I don't think I have access to the Report Gen VIs since I only have the Base Development system for LV6.1.

I wouldn't put the network out of blame; but even at 10MB it should still be faster than 1.5 minutes to print something (and it really shouldn't lock up my PC for that amount of time).

[Donald]

---

@Sirin wrote:

... I don't think I have access to the Report Gen VIs since I only have the Base Development system for LV6.1.

---

You should still have (or at least I'd really hope you'd have) the ability to use an Invoke node to access the "Print VI To HTML" method.
Apologies if I'm wrong.

[Sirin]

I will have to try that. What would be the best way to print the png once I've gotten it printed to html though? (I'm beginning to doubt that it is LabVIEW or my program that is causing the system to halt, I think it is the fact that I'm printing to another computer's printer over the network; it is Windows itself that is slowing things down.) 

I will know better tommorrow when I bring in a separate printer to directly hook up to my test PC.

[Sirin]

I got a chance to hook up another printer (a Dell 1700 via parallel cable). I made sure that spooling was setup in the printer preferences, and tried to run my program. I got worse results than with the printer over the network.

The test computer in question is a P3 550Mhz with 64 MB of RAM, running Win2k, connected to a Dell 1700 via parallel cable.

The computer that worked is a P3 850Mhz with 512 MB of RAM running Win XP, connected to a HP1022n via TCP/IP.

Seeing that huge difference in RAM, I ran with a P3 850 with 128 MB of RAM with Win2k, connected to the same Dell 1700 via parallel cable and achieved acceptable results.

I'm guessing that the RAM is what was making things grind to a halt; but the extra 300Mhz of processor might also play a factor.

[AnalogKid2DigitalMan]

Yes, I would agree that a Win2K machine with 64MB RAM would be resource starved. We had a similar system that was upgraded from 95 to 2K, could not do too much 'usable' work on it at all. Click here, wait, click there, wait...

Memory is cheap (if you can find compatible sticks), you may want to bump it up at least to 128MB, probably 256MB

[Sirin]

Sorry to dig up this old topic again; but, I've found that even adding memory to the PC has not helped the main symptom.

On my VI's main screen, there are various buttons that start routines that make equipment move. What is happening is that users are pushing these buttons at the same time as a report is being printed, thus are seeing an unacceptable "lag" between when they push the button, and when LabVIEW actually processes the data (since the boolean controls are all set to latch). Is there some way to tell LabVIEW not to make printing more important than processing the entire rest of the program?

I'm still using LV6.1, base development version.

[rolfk]

---

@Sirin wrote:

Sorry to dig up this old topic again; but, I've found that even adding memory to the PC has not helped the main symptom.

On my VI's main screen, there are various buttons that start routines that make equipment move. What is happening is that users are pushing these buttons at the same time as a report is being printed, thus are seeing an unacceptable "lag" between when they push the button, and when LabVIEW actually processes the data (since the boolean controls are all set to latch). Is there some way to tell LabVIEW not to make printing more important than processing the entire rest of the program?

I'm still using LV6.1, base development version.

---

No. LabVIEW printing is an unprotected subsystem and therefore in order to avoid race conditions has to run in the user interface execution system too. You can make VIs that run in different execution systems and they will happily run while LabVIEW is printing but all user interfaces (and user clicks etc) have to be handled in the user interface execution system too. I can't really remember the details about printing in LabVIEW 6.1 but I think there have been a few smaller or not so small improvmenents in newer systems. It might be also Windows XP which helped a bit here but I wouldn't really be sure.

Basically in most applications I wrote until now printing is a user invoked operation and a dialog will be present during printing so that users don't really expect the applciation to continue working immediately after they have started a print. Though 1.5 minutes for a printout seems like a very bad system setup/printer driver or whatever.

We use a HP Laserjet 4000 printer over TCP/IP and from my last LabVIEW 7.1 application under Windows XP I get something like a few seconds before the printer starts printing the page.

Rolf Kalbermatter

Message Edited by rolfk on 04-12-2006 10:36 PM

[Sirin]

Yeah, I did get it down from 1.5 minutes, but the delay of a few seconds (between 3 and 10)  is still too much for our demanding users. Would it even help things if I had a separate exe that was called from the main program, or would it still cause the same problems?

Thanks for your good explanation though; it is nice to learn at least one new thing a day. 🙂

[rolfk]

---

@Sirin wrote:

Yeah, I did get it down from 1.5 minutes, but the delay of a few seconds (between 3 and 10)  is still too much for our demanding users. Would it even help things if I had a separate exe that was called from the main program, or would it still cause the same problems?

Thanks for your good explanation though; it is nice to learn at least one new thing a day. 🙂

---

Printing in a different executable should definitely help, except when the printing operation itself is taking up so much CPU resources that other applications won't get to run much at all. But it will at least avoid the possible lockup of the user interface interaction in your UI. If a separate process (excutable) for printing does not help much, that would be the indication that your hardware is simply to low end to handle the printing task gracefully without locking the rest of the system considerably and then buying a newer machine will be really the only remedy. Considering nowadays computer prices, going for the new machine directly might be the cheapest solution actually.

Rolf Kalbermatter

[zou]

A seperate exe will solve the problem.  A seperate thread will work too.

I used a seperate thread to do the print.  Lockup time is less than 2 ms.

George Zou
http://gtoolbox.yeah.net