Printer not working after first print

[00InDeX44]

Hello everyone,

I am new here. We have a very old software written in LabView that has been recently recompiled from the old 2011 version to a newer LV version (2019 SP1). The software is extremely complicated and vast. I tried to locate the printer VI or at least where it is being triggered to print, but couldn't find it. But directly to the question I wanted to aks along with a brief description of the isses:

After the printer prints once after the software had generated a report, it does not print anymore. I have to restart the whole software to print once again. This repeats.

Had anyone had any such issues after recompilation? Could it be a driver? 

I would gladly post the VI that controls the printing IF I can find it.

Thank you very much for any hints or tips!

George

[altenbach]

How does the "report" look like?

If there is no printing code anywhere, one possibility is that at last one of the VI is set to "automatically print panel every time the VI completes execution".

Still does not explain why it only prints once. Once you can find the relevant code, we can look at it.

[alexderjuengere]

---

@00InDeX44 wrote:
once after the software had generated a report,

---

are you using the report generation toolkit?

---

@00InDeX44 wrote:

Could it be a driver? 

---

you are using the 2011 and 2019 version on the same computer respectively operating system, or have there been changes too?

when the second print failed: 

do you see an entry in the so-called "Open queue"?

[Bob_Schor]

When I think about LabVIEW, I don't usually think about printing, unless I'm "writing a Report", which I prepare with LabVIEW's Report Generation Toolkit, which can generate "Reports" using either Microsoft Word, Microsoft Excel, or HTML.

Does this sound like what you are doing?

You've provided us with almost no information.  Are there LabVIEW experts in your area whom you could contact to "look at your code" and help you figure out what is going on?  When you installed LabVIEW 2019, did you install the Report Generation Toolkit?  Can you attach a Screen Shot (because we need to see the images of the sub-VIs) of the Block Diagram of the "Main" routine?  Can you tell us what this software is supposed to be doing, and what the "Reports" represent?

You should probably also attach the top-level VI itself.  While we won't be able to "see into" the sub-VIs in your Project, we will be able to see all the "Cases" and top-level parallel loops, some of which might contain Report Generation Toolkit VIs we'd recognize and could spot problems (like failing to close an Excel Report after printing it).

Bob Schor

[00InDeX44]

Finally I found the VI. I am sending a screenshot. I hope this would be sufficient for some help.

[GerdW]

Hi Index,

---

@00InDeX44 wrote:

I am sending a screenshot. I hope this would be sufficient for some help.

---

Generic comment: we cannot edit/run/debug images in LabVIEW...

Specific comment:

• What have you done to debug this VI?
• Does there some error occur in the VI?
• What is different from 1st to 2nd call?

What's the purpose of that FOR loop where the filenames are checked/filtered?

[alexderjuengere · Accepted solution]

---

@00InDeX44 wrote:

Finally I found the VI. I am sending a screenshot. I hope this would be sufficient for some help.

---

 ActiveX was already considered obsolete by the early 2010s.

it was regarded as outdated, even though Microsoft officially disabled the technology only in 2024

use .NET instead

[Baguvixx]

I’d check if the print VI keeps its reference open after the first run. Closing the printer ref each time or forcing a reinit of the report usually fixes this.

[rolfk]

Well, it does close most of the object classes but not all. As ActiveX, aka DCOM, is reference count based, that does keep the references open and for sure could cause subsequent executions from properly initializing the respective class object. That PageSetup reference is left happily dangling!

Another potential problem, although not likely to happen in this specific case, respectively if it does you get other problems downstream, is the refnum going into and out of the loop when enumerating the sheets. If the document would have 0 sheets, the loop executes zero times and the outgoing refnum is the canonical notARefnum value and can't be closed later on anymore, leaving another dangling object in memory. This refnum should enter through a shift register and exit through that shift register to avoid loosing it in case of a zero iteration loop.