Merge (Combine) PDFs

Merge (Combine) PDFs

emanuel.c
Collaborator Collaborator
6,250 Views
24 Replies
Message 1 of 25

Merge (Combine) PDFs

emanuel.c
Collaborator
Collaborator

Hi! I would like to Merge PDFs (drawings) with Inventor. I would have, for example, an Assembly which contains parts and / or Sub-Assemblies. I would open the Drawing file of this Assembly and would read each line of the Parts List (probably the largest parts list on the drawing, if there are more Parts Lists) and confirm the existence of a PDF drawing of each part. Next would be to attach to the PDF of this original drawing all the PDFs of Sub-Assemblies and Parts and save it with an additional "Compiled" name or something, in a Compiled folder etc.

 

It seems difficult to use some kind of PDF compiler with ilogic, though I see it done with VB in Excel, Adobe Acrobat plugins etc.. I think I would prefer doing it from within Inventor, but I may have to jump to VB in Excel if I must.

 

I started with code from this post here, using the itextsharp.dll. It works well, it compiles a PDF of all PDFs it finds it the given folder and does this for its subfolders also. This it does well, but I have a hard time editing this piece of code to suit what I need, for example even changing not to read from subfolders, to compile only certain files. But I  might have to dig in a bit deeper here.

 

I can read the Parts List, see if each part has PDFs etc. but the compiling I'm struggling with a bit. I'll begin working on it, but wanted to ask in case someone more knowledgeable can give some input.

 

There are many ways to batch print PDF drawings including this little app drawing porter but for us, we would like to keep PDFs as manufacturing history etc.

 

Thank you!

0 Likes
6,251 Views
24 Replies
Replies (24)
Message 21 of 25

NachoShaw
Advisor
Advisor

Hey

 

i havent thoroughly read through the code but at a glance:

 

you're writing in iLogic. My experience with iLogic is that its limited and best used for component tasks. That said, you can obviously use external references. I would create a wrapper in .net to handle the PDFs and reference that in instead of referencing iTextSharp and coding it in iLogic.

 

you can replace the Function ProjectName with this

Public Function ProjectName() As String
   Return "ND " & DateTime.Now.ToString("YYYY.MM.DD")
End Function

 

In some functions you are using System.IO.Directory.CreateDirectory() & System.IO.Directory.Exists()

In others you are using FSO Scripting

 

Is there a reason you are looping your occurrences? 1 Assembly containing 500 identical occurrences will do something 500 times vs 1 Assembly containing 1 leaf reference that will do something once. It doesnt matter about suppression, thats only for BOM. Occurrences i guess if there are specific differences like finishes but if not, leaf occurrences / BOM.

 

Create a List

iterate the BOM instead, get your component from that and process it only once

 

use the list to hold all of the component info to save persistent assembly looping. You said you have 500 drawings. thats probably 500 components. Quick math on the WorkOnAssemblies function that is looping occurrences

 

500 occurrences (1 occurrence per component lets say)

 

for Each oCompOcc In oCompDef.Occurrences

   'Call ProcessAllSubOcc

            For Each oSubCompOcc in oCompOcc.SubOccurrences

                   'If Assembly

                    'Call ProcessAllSubOcc

            Next

Next

 

lets say you have

Top Level Assy iterations(TL) = 500

Sub Assy iterations(SA) = 100

Sub Sub Assy iterations(SS) = 2

 

TL = 500

SL = 100

SS = 2

 

Total iterations = TL + (SL x SS) + (SS x SL) = 20,700.

This function is roughly 20,700 iterations because of your nested For Next within sub functions. This will definitely crash Inventor. Each component opened in the loop has a check of features, lets say 10 per part x 20,700 it soon adds up to 200,000 things inventor is trying to do.

 

Make a list of all leaf reference components from the BOM

iterate the list.

 

There is also many methods counting, checking folders etc, do that on demand.

Your code looks more complex than what it needs to be.

Set up your paths

check folders on the fly within your list loop

create your pdfs

merge pdfs together

 

 

 

Nacho
Automation & Design Engineer

Inventor automation Programmer (C#, VB.Net / iLogic)
Furniture, Sheet Metal, Structural, Metal fab, Tradeshow, Fabrication, CNC

EESignature


Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.


0 Likes
Message 22 of 25

g.georgiades
Advocate
Advocate

Since you are having trouble combining massive files, you could try combining in batches of ~100, then combining the couple resulting files into the final single file.

 

Even if Inventor fails to combine the big files - it is less effort for you to manually combine the few resulting files - if they came out right...

 

There could be an issue in itextsharp where it has some caching issue, or too many objects. I know in my pdf merge code - I am combining in a different way than you are - and I am closing unused objects which helps with memory management. I have successfully combined PDFs with over 500 pages using this method.

Using stream As New FileStream(pdfFile, FileMode.Create)
			Dim document As iTextSharp.text.Document = New iTextSharp.text.Document()
			Dim pdf As PdfCopy = New PdfCopy(document, stream)
			Dim reader As PdfReader = Nothing

			Try
				document.Open()
				For Each file In pdfresults
					reader = New PdfReader(file)
					pdf.AddDocument(reader)
					reader.Close()
				Next
			Catch __unusedException1__ As Exception
				errors.Add("Failed to combine pdfs for review")
				If reader IsNot Nothing Then reader.Close()
			Finally
				If document IsNot Nothing Then document.Close()
			End Try
End Using

 

Message 23 of 25

emanuel.c
Collaborator
Collaborator

@NachoShaw  Thank you so much for all this feedback!!

 

I'm sure the code can be simplified to speed up the process. I'll try as you were saying, using leafs rather than occurences and using a list. Unfortunately I can't always take the time to work on coding 😞 and my experience is limited...

 

But aside from that, when compiling only ALL Loose Components (so no itterations) it tends to crash with the 500 PDFs. Basically, all it had to do was copy the PDFs to that one folder and compile them in one massive file. It would be 250MB or more. That's why I was wondering if it's a limitation of the .dll. I suppose you were mentioning that in the beginning, the wrapper in .net etc.

0 Likes
Message 24 of 25

NachoShaw
Advisor
Advisor

Hey

 

i mentioned the wrapper as it keeps the functions in a class dll and iLogic only needs to call the class as New() and then run the functions from there. It may be a limitation of iLogic. If you are familiar with Visual Studio, you could create a console app (exe) making the PDF process stand alone on a separate thread. You can still reference the project in iLogic.

 

Inventor PDFs arent too heavy but i guess 500 of anything is a lot. As suggested by another user, try first batching them together in groups of 50 or 100 then try to merge the batch. 

 

 

Nacho
Automation & Design Engineer

Inventor automation Programmer (C#, VB.Net / iLogic)
Furniture, Sheet Metal, Structural, Metal fab, Tradeshow, Fabrication, CNC

EESignature


Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.


Message 25 of 25

emanuel.c
Collaborator
Collaborator

Yes agree. I appreciate the idea. That should work out well. Can count the files and if there are more than 200, do batches of 200 and then rerun to finally compile those. Thanks a lot!

0 Likes