LabVIEW
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.
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.
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.
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.
@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.
@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).
@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.
Search LabVIEW like a graph!
@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...
