LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to quickly generate PDF file using report generation toolkit

Hello Everyone,

 

I'm collecting a data and updating it in an excel file (.xlsx) using Report Generation Toolkit. Later I'm saving the same as PDF file using the function Save Report to File.vi to get the data in PDF format.

 

Vijy_0-1648969513728.png

 

But this above code is taking approx 8 to 10 seconds to complete the file creation. 

Our requirement is to minimize the execution time and complete more boards testing in a day.

Whether this is the efficient way to generate PDF report or is there a better way to do ?

Kindly suggest.  

 

0 Kudos
Message 1 of 20
(2,852 Views)

If the test software were coded properly, it wouldn't matter if the files took 8 minutes to write instead of 8 seconds.  The file writing should be put in a loop separate from the testing so that the tests can run at the speed they need to run and the file writing can take its time writing the file.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 2 of 20
(2,840 Views)

You could also go a very different route and build your PDF file yourself!

 

Here https://www.carya.nl/en/products/ is a library that lets you build the PDF file directly and I have used this Toolkit in the past for a project (when it wasn't free) and it was very quick in execution to generate a calibration report form that contained a graph and some other calibration specific information values. Development of the report was a little more work than just dropping in the Report Generation Toolkit VIs though. And if the customer has continuing evolving requirements about the layout, which most do have, it is each time again some work to do that.

 

You really build the page yourself programmatically, specifying where each element should go on the page. That can be a bit tedious as you need to calculate the right coordinates as you build the entire thing. On the plus side, the creation of that report page was by far the fastest thing in terms of execution, compared to the rest.

 

That all said you also should of course not serialize the creation of a test report in your test routine. The correct thing to do is to have your own task (LabVIEW loop) in you program that simply sits there and waits for a message to start do its job of creating the report. Your actual test routine simply collects the data and then sends it off to this task through a queue or a more elaborate producer-consumer message framework and then goes on to do the next test. It does of course mean that your test itself shouldn't be much faster than your consumer loop, or you definitely have to look into more complicated solutions such as above mentioned PDF Toolkit.

Rolf Kalbermatter
My Blog
Message 3 of 20
(2,819 Views)

Another option is the Custom PDF Generator for LabVIEW from Simplicity AI which I personally prefer. Seems to me that this Toolkit is more flexible when it comes to difficult page designs.

 

 

 

Message 4 of 20
(2,791 Views)

 Excellent advice from others ( your test flow should not be interrupted by report generation)

 

Now I will give you the bad news.  Portable Document Files use the PostScript language to create them.  PostScript is an interpreted language and you only get 1 instance of the interpreter.   It is designed to feed into a printer so, speed is limited by the cartridge motion and PostScript language developers never concerned  themselves too much about speed.

 

You can't create a PDF quickly.  You chose the wrong tool.

 

 


"Should be" isn't "Is" -Jay
0 Kudos
Message 5 of 20
(2,779 Views)

@JÞB wrote:

 Excellent advice from others ( your test flow should not be interrupted by report generation)

 

Now I will give you the bad news.  Portable Document Files use the PostScript language to create them.  PostScript is an interpreted language and you only get 1 instance of the interpreter.   It is designed to feed into a printer so, speed is limited by the cartridge motion and PostScript language developers never concerned  themselves too much about speed.

 

You can't create a PDF quickly.  You chose the wrong tool.

 

 


It literally prints to the file?  That's crazy.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 6 of 20
(2,769 Views)

@billko wrote:

@JÞB wrote:

 Excellent advice from others ( your test flow should not be interrupted by report generation)

 

Now I will give you the bad news.  Portable Document Files use the PostScript language to create them.  PostScript is an interpreted language and you only get 1 instance of the interpreter.   It is designed to feed into a printer so, speed is limited by the cartridge motion and PostScript language developers never concerned  themselves too much about speed.

 

You can't create a PDF quickly.  You chose the wrong tool.

 

 


It literally prints to the file?  That's crazy.


No, that's what it's for! To embed all the fonts, vector graphics, bitmap images links and objects.  Data and display portability are key, speed of creation is of minimal importance. 

 

There are no Screw-Hammers.


"Should be" isn't "Is" -Jay
0 Kudos
Message 7 of 20
(2,765 Views)

@JÞB wrote:

 

You can't create a PDF quickly.  You chose the wrong tool.


Define quickly! Yes if you want to create many PDF files per second, it is certainly not the most perfect format to choose. However the Print PDF through Excel approach the OP was using suffers from many other bottlenecks, where the PDF format itself is just a small fraction of it. First you generate a formatted Excel spreadsheet through Excel ActiveX interface, then send that to Excel to have Excel translate it to a PDF style format. That's a lot of overhead.

 

A PDF file can get fairly large and does consist of embedded Postscript text commands and there are more efficient although seldom more accurate formats to achieve a similar result. But saving a PDF file that you built with one of the mentioned Toolkits directly does not need to take 8 seconds ever (unless you save it to a floppy disk or one of those low quality USB sticks that you used to get thrown dead with at trade shows).

Rolf Kalbermatter
My Blog
0 Kudos
Message 8 of 20
(2,757 Views)

@JÞB wrote:

Now I will give you the bad news.  Portable Document Files use the PostScript language to create them.  PostScript is an interpreted language and you only get 1 instance of the interpreter.   


That's only remotely factual.

 

Of course you can use PostScript to generate PDFs.

 

You can (probably, haven't tried) use embedded PostScript in PDFs.

 

The PDF page streams are have some similarities with PostScript.

 

Neither our toolkit (nor SimplicityAI's AFAIK) use PostScript.

 


@JÞB wrote:

You can't create a PDF quickly.  You chose the wrong tool.


That depends on what you consider 'quickly'.

 

PDFs are build of data, most of it compressed string data. That won't be as fast as saving raw binary data.

0 Kudos
Message 9 of 20
(2,734 Views)

@Martin_Henz wrote:

Another option is the Custom PDF Generator for LabVIEW from Simplicity AI which I personally prefer. Seems to me that this Toolkit is more flexible when it comes to difficult page designs.


I doubt that.

 

Not sure what you consider 'difficult page design', but I'm sure I'd manage just fine.

 

But I don't need to sell our toolkit anymore...

Message 10 of 20
(2,728 Views)