ScreenPrinting pauses LabVIEW application

[CEY]

System Configuration:
LabView 6.02
Windows NT 4.0
Pentium III 800 MHZ dual CPU, 256 Mbytes
PXI chassi

Problem:

My LabView application encounters two intermittent problems while printing. A printer is directly connected to the system thru the printer port.

The first problem occurs in the serial communication (RS232) with another computer (VAX) while printing. Characters are detected missing from the string of characters that my system is receiving from the VAX (other computer). This problem occurs almost every time that my system prints a page.

The second problem is not as frequent as the first one. This one appears to occur the first time that you try to print after a long time without printing. What occurs is
that if one tries to print at the same time that one of the Control fields (String control) number is changed, the field is locked out and the number can not be changed unless the file that is open (recording data) is closed.

[Ben]

Hi Boeing!

This could be simple or hard.

Simple:
Is the printer configured to "print in background"?

Hard:
The combination of software and hardware you are using is exhausting some resource (i.e. memory, CPU, etc).

Suggestions:
A) Check printer config.

B) Watch "Task Manager>>>Perfromance" to see if you are running out of CPU or memeory.

I will watch for updates to if I can be of greater assistance. Posting your code would also help us help you.

Ben

(ex-DEC)


Ben Rayner
Certified LabVIEW Developer
www.DSAutomat
ion.com

[Brian_Powell]

Regarding the serial issue...

Are you using VISA or the "builtin" serial VIs? Are you using hardware flow control?

If you aren't using flow control, then it's very likely that the serial port isn't being serviced fast enough and bytes are being lost because of this.

I think the "builtin" VIs (on the Serial palette) have problems with flow control. You could try turning them on, or maybe choosing a slower baud rate.

The VISA functions do hardware flow control better, so you may want to try them instead.

I'm not sure I understand the description of your second problem. I think Ben's thoughts about running low on resources might be relevant.

I hope this helps.

Brian

[Tom_Hawkins]

It might be worth checking for anything that might be making your serial code execute in the user interface thread, for example use of control references or attribute nodes. I think this can also be a problem if you are calling any DLL's. You might try and avoid it by e.g. putting your serial comms loop in a subVI that doesn't show its front panel and uses queues to send data to/from the rest of the program.