Question about PrintCtrl()

[hendra@ngms]

I am using PrintCtrl() to print Strip Chart datasets.  The idea is to save all data going to a strip chart in an array, then when the operator wants to print the entire dataset, write the array out to a strip chart control, one screen at a time, print it, etc.

I have not investigated this fully, but what I am seeing is that when PrintCtrl is called (with No Dialog Box selected), the function goes away for 5 full seconds and everything freezes for those seconds until the function returns.  The call is in a thread separate from the main thread to prevent the main thread from being locked out.

The Function Help says, "While this function is printing, it blocks any other thread in your program that attempts to print."  Nothing else in my app is trying to print.  But this blocks all events and all panel updates in all threads.

I'm using CVI 8.5.1 under XP Pro.

What is going on in PrintCtrl? 

Is there a way to prevent this kind of lockup?

Does this have anything to do with the Sleep Policy?

Or is this entirely bogus, and only behaves like this when executing in Debug?  Just tested a .exe, and the behaviour is exactly the same...

[LuisG]

HI Gary,

PrintCtrl should block only the thread that is doing the printing, but it's possible that something that's going on in the main thread might need other threads to respond to it, in which case the main thread might also be blocked. I tested printing a chart here with a quick example, and for me it didn't block the main thread, but I suspect this might have something to do with a difference in what our respecitve main threads are doing.

There are a couple of tests you can do that might shed some light on this:

1. If you pass the option to the PrintCtrl function to display the properties dialog, and you essentially leave this dialog there indefinitely, is the main thread blocked during that time? Note that even though it looks as if the dialog is a modal dialog that would disallow interaction with other panels, because modality is thread-specific, you should still be able to interact with your other panels.

2. I assume that you're using a temporary panel to hold the chart that you are printing. I don't know if you are creating this panel in the main thread or in the printing thread. Regardless of which thread you're creating the panel in, can you try creating it in the other thread instead, and see if it makes a difference?

Thanks,
Luis

[hendra@ngms]

Luis,

Thanks.  You have brought up thinkgs to think through, and things to try.

I am not using a temporary panel, but a child panel created in the main thread.  I'll try doing a temp panel in the printing thread. 

I will also try the dialog box thing you brought up.   What I noticed in my app is that panel updates from another thread, that should occur at 1 second intervals, is blocked.  Their is no interaction between these threads.

I'll get back to you....

[hendra@ngms]

Luis,

This is what I've done:

1.  I did a PrintCtrl call with the dialog box enabled.  The dialog box does not block anything, which is what you would expect since it is just sitting there waiting for input.  Once answered affirmatively, screen updates are blocked for 5 full seconds.

2.  I have a simple tester app, that has two threads:  Main and a separate thread which formats a date/time string and puts it on the screen.  I did a PRINT ALL  from within the main thread, which creates a panel, copies a strip chart control to it, populates it from an array, then calls PrintCtrl.  Screen updates are blocked for 5 seconds.

3.  I added another thread to the app, where the PRINT ALL stuff is now located. Same behaviour -- screen updates are blocked for 5 full seconds.

This is ugly and I'm baffled.  I don't want to have to warn my operators that every time they print a strip chart page, the application will appear to freeze for 5 seconds.

The one thing I don't know is whether it is just screen updates being blocked, or all execution.  That is the next thing to test.

Hey, NI, we need a little help here...

[LuisG]

Hi Gary,

I can see from your other forum thread that this is an urgent problem for you. In general, whenever you need immediate assistance, your best bet is to call NI phone support directly to speak to an engineer. That usually makes things go faster. In the forum, you're somewhat dependent on the availability of others. For example, I tend to only check the forums once a day or so, which is why I didn't see your last post on this thread until now.

Having said that, I'd be perfectly happy to continue trying to resolve this with you, if you like. But it might take several back-and-forth tries, since I haven't yet been able to reproduce the same problem you're having.

You mentioned that you had been able to create a tester app that reproduces this problem. One thing I'd like to do is to find out if this issue is at all dependent on the printer that you're using. Could you try printing to a file, instead of to the printer, to make sure that the problem still happens? If it does, then you could post your test app here, and I should be able to reproduce it. Even if I don't have the same printer that you're using, I can download the driver, and also print to a file.

Luis

[hendra@ngms]

Luis,

I will try writing to a file as you suggest.  My next task is to see if I can determine if it is just screen updates, or if the whole RTE execution is blocked during this 5 second period. 

I'll get some results, get back to you and also send the simple app.

Thanks... Gary

[hendra@ngms]

Luis,

Writing to a file is instantaneous, no blockage.  Writing to a printer blocks everything for 4 - 5 seconds.  The app I am sending you has a button to populate the strip chart, a button to print the page visible, a button to print all pages (2) to file, and a button to print all pages to the printer.  The date/time string a the bottom is generated in a separate thread.  The actual control printing happens in a separate thread.  The counter should increment 3 times a second continuously.  If ONLY screen updates were blocked, the counter should jump about 15 counts when PrintCtrl() returns.  It does not, which means that execution in the other thread is blocked.

Now this whole thing may boil down to an XP problem with a printer driver.  I'm running XP Pro on a Core 2 Duo HP machine, sending the print job via 100BaseT Ethernet to a print server,  which routes it to an HP8150N.

But I'm astonished that the CVI RTE stops execution for 5 seconds.

Luis

[LuisG]

Hi Gary,

Thanks for submitting this test program. This does make things easier.

I tried it in two different computers, with two different printer setups. I was able to reproduce the 5 second delay in one of them, and not in the other, which makes me suspect that it does have something to do with the printer driver (both computers were Windows XP).

I debugged the delay and found that it was happening in a particular call to the printer driver. Unfortunately, it's happening at a point in our internal code in which we're holding on to the UI lock. This means that other threads are, in fact, blocked from performing UI operations, including function calls to the User Interface Library, or responding to low-level messages, such as mouse clicks, or redraw events. This explains why the other threads are blocked. They're blocked, probably, at the point where they need to call SetCtrlVal, or some other function.

Assuming that your main thread needs to perform UI operations, then you'll need a different solution in order to print your charts. I took the liberty to take your test program and modify it a bit, such that printing now takes place in a separate process altogether. I still create a separate thread in the main program, but this thread does not do any UI, so it should not interfere with the main thread. This thread writes the data to a file, then launches the separate process, waits for it to finish, and then deletes the file. This separate process starts up, reads the data, loads the main panel and copies the chart to a separate panel for printing, and then performs the same plotting/printing loop as before. I'm attaching this program here.

In the meanwhile, we're going to research the feasibility of releasing the UI lock around the specific call that is causing the delay. I'm not sure what exactly causes the delay, but as long as the thread isn't holding the UI lock, it will not block other threads from making UI calls during the delay. Assuming that there is no problem with doing this, we should have it ready in time for the beta program of the next CVI version, which should be available soon. If you'd like to try it out, sign up for it in ni.com\beta.

One last thing: in your example, the chart is overlapped by the legend (as you described in the other forum thread) and by the control label. You should know that the plotting speed of charts and graphs are significantly impacted when the plot area is overlapped by other objects. If overall plotting speed matters to you, you might want to consider moving these items to a different location.

Hope this helps,
Luis

[hendra@ngms]

Luis,

Again, thanks very much for this continued investigation.  So, there's a new version coming out soon.  Cat's out of the bag!  I've been in the beta program for the past several releases, and will sign up again.  Thanks for that info.

What you have done in the test program, which I have not looked at yet, was my next question -- how to push the data into a second application that just prints.  I did not have that knowledge, and will look closely at what you have provided.

I was unaware that overlays like the legend would slow down plotting, but it makes sense.  In my real application points are plotted once per second. The strip chart controls to print are filled from an array as fast as possible, but since it is done in the background, one page at a time, speed is not much of a consideration.  Thanks for that information.

Best Regards... Gary