Autodesk Inventor Engineer-to-Order

[#1]

OK, all you folks who normally ignore these discussion group messages, can you weigh in on this?  

What is the largest Inventor ETO model out there in terms of:

   # of parts?

   # of unique parts?

   With or without constraints

We are struggling with models over ~2500 parts and maybe 100 unique parts using FBP (no constraints).  Anyone out there got a bigger one? 

[#2]

FWIW, this is about the same size that you reported.  It uses constraint-based positioning.  It ran to completion in a minute or so, changing from a smaller model to this size.

[#3]

Interesting.  If you double the number of parts does it run in 2+ minutes?  Although the parts/unique parts numbers look similar to our smaller models, the model itself looks like a simple quantified part.  How deep is the rule set?  How deep is the assembly tree?  

I've found that with our model the cliff seems to be above 2500 parts.   Actually, for most of the tests we've done so far, the problem is with models that are much bigger  (say 10K+ parts), but Inventor seems to create the first 2500 parts relatively quickly then bogs down.  We haven't done tests yet with part numbers that are greater than 2500 and say less than 3500. 

[#4]

While we're talking about performance, this looks like a good time for me to throw in my request for someone to fill out this page: http://wikihelp.autodesk.com/Inventor_ETO/enu/2013/Help/0148-Inventor148/0307-Inventor307/0324-Tools...

It's been under construction for 2 versions of ETO now.  

My best guess is that you meant to include these functions on that page:  writeAllDesignsMemoryUsage, writeAllMapsMemoryUsage, and writeAllPartsMemoryUsage.

When I export the files created by those functions, it would be useful to know what units those numbers are in.  I was hoping for it to at least be in the wikihelp.

The writeAllPartsMemoryUsage function seems to have a problem.  You can see in the image below that it does not label the column headings for some of the numbers it outputs.  I'm unsure of how to use the data if it doesn't have somethign to describe what the numbers are for.

More relevant to your question, there's 2 things my team tried.  First, switching to ETO 2013 was a large help.  2013 seems much faster than 2012 when opening large assemblies. 

Second, just through a large amount of code optimization we were able to create the same assembly using half the memory(and in half the time).  That's a harder thing to teach, especially without an ETO debugger, but is probably your best bet for increasing performance.

Definitely take a look at the ETO function writeAllDesignsMemoryUsage.  It will help you find your innefficiencies. Export it as a .csv file.

Hope some of this helps!

-Brandon

[#5]

Thanks Brandon.  We'll try some of your suggestions. 

You don't mention the number of parts your models have or whether you are using FBP or constraints?   My gut feel (which could very well be wrong) based on the fact that there seems to be an exponetial slowdown over ~2500 parts is that the issue might be related to the number of parts/assemblies and how ETO is dealing with that many parts/assemblies more than the basic memory useage.   Our parts, by they way, are mostly simple blocks.  

I'm not certain, but I think that there are a number of regular Inventor customers who have models well over 2500 parts that load and unload in a reasonable time (at least not hours...).  Which to me would indicate that the memory issue for the basic geometry isn't the problem.  But like I said, we will certainly run some tests with the tools you mention to check it out. 

[#6]

I didn't mention it because you're on a totally different scale than we are.  I'm running ETO on a computer intended for 2D design (Hoping to upgrade soon).  Everything we have uses constraints. Our parts are more than simple blocks. I can't really give more detail because I don't know. I'm a programmer, not an engineer.

In 2013 it takes 56 seconds to open 103 total occurrences in the active document with 34 open documents in the session.

Also using 2013, it takes 3 minutes even to open 664 total occurrences in the active document with 76 open documents in the session.

It's too bad the process of opening our assembly only uses a single core.  At least in my case, the cpu seems to be the limiting factor.

I can't test with 2012 because things get complicated when moving a project to prior versions, but I can say it was slower.

One more thing to add is that if you plan to develop your own user interface, Inventor OEM seems to run faster than the main version of ETO.  However, I'm in the process of putting together a UI now, and I can say it definitely is not a small task.

[#7]

FWIW:  Here are some quick results, just timed on my watch, by eye:

Total   Unique            minutes:seconds
557     121               0:30
1479    [less than 217]   0:46
3041    167               1:18
12729   387               4:35

For each iteration, I changed some of the key "configuration" parameters, as well as the ones that directly affect the quantity.

For the last two, both # of occurrences and elapsed time increase by about 4x.  For the first two, there's probably some "noise" in the numbers.  

These were all obtained sequentially in the same session, with lots of other apps running in the background (but not actively).  This is on a MacBook Pro, running Windows 7 on Parallels.  ETO 2013.  The model has some patterned occurrences, but overall it is not a simple child list.  The trusses vary in length, depending on where they fall against a "bounding curve".  However, the model uses shared assemblies extensively (exclusively).  So many of the subassemblies eventually prove to be identical to other subassemblies.  And because I round the lengh of the trusses to the nearest 3", it makes it easier for them to be reused.

Anyway, take this FWIW.  I know mine is a simplistic model.  If you can give us a model that shows the "bogs down after 2500 parts" behavior, we'd be happy to look into it.

[#8]

---

bsee1 wrote:

Second, just through a large amount of code optimization we were able to create the same assembly using half the memory(and in half the time).  That's a harder thing to teach, especially without an ETO debugger, but is probably your best bet for increasing performance.

---

Some of the code that we did was to consolidate as much of the code as possible.

An example is the use of child lists in place of multiple child rules. In our case, we can place multiple instances of a piece of conveyor (for talking purposes lets say up to 50) into an assembly which are then constrained together. The user is prompted for a flavor of conveyor and then the quantity required. Initially I had a child rule for each possible instance of transport and then two child rules for constraints for each piece of conveyor to attach it to the previous piece of conveyor. The math works out that 148 (50 conveyor instances + 98 constraints) child rules where being evaluated every single time the user place a new section of conveyor regardless of the actual quantity that the user entered. To eliminate the extra child rules, I used a child list to place both the conveyor and constraints and reduced the written code down to only three child rules. See below for simplified before and after code snippets.

'Before optimization
Child Conveyor_1 As :Conveyor
		grounded? = True
		origin = Point(0.0, 0.0, 0.0)
		xDirection = Vector(0.0, 0.0, -1.0)
		yDirection = Vector(-1.0, 0.0, 0.0)
	End Child

Child Conveyor_2 As (If ConveyorQty? > 1 Then :Conveyor Else :nullDesign)
		grounded? = False
	End Child

Child Conveyor_3 As (If ConveyorQty? > 2 Then :Conveyor Else :nullDesign)
		grounded? = False
	End Child

         'etc... all the way up to Conveyor_50

Child ConveyorInternala_1 As (If ConveyorQty? > 1 Then :IvInsertConstraint Else :nullDesign)
		part1 = Conveyor_1
		entity1 = "Conveyor3a"
		part2 = Conveyor_2
		entity2 = "Conveyor1a"
		axesOpposed? = True
		distance = 1.0
	End Child

Child ConveyorInternalb_1 As (If ConveyorQty? > 1 Then :IvInsertConstraint Else :nullDesign)
		part1 = Conveyor_1
		entity1 = "Conveyor3b"
		part2 = Conveyor_2
		entity2 = "Conveyor1b"
		axesOpposed? = True
		distance = 1.0
	End Child

         'etc... all the way up to ConveyorInternala_99 and ConveyorInternalb_99 

'After optimization	
Child Conveyor As :Conveyor, Quantity = ConveyorQty?
		grounded? = (If Child.index = 1 Then True Else False)
		origin = Point(0.0, 0.0, 0.0)
		xDirection = Vector(0.0, 0.0, -1.0)
		yDirection = Vector(-1.0, 0.0, 0.0)
	End Child

Child ConveyorInternala As :IvInsertConstraint, Quantity = ConveyorQty? - 1
		part1 = evaluateString("Conveyor_" + stringValue(child.index))
		entity1 = "Conveyor3a"
		part2 = evaluateString("Conveyor_" + stringValue(child.index+1))
		entity2 = "Conveyor1a"
		axesOpposed? = True
		distance = 1.0
	End Child
	
Child ConveyorInternalb As :IvInsertConstraint, Quantity = ConveyorQty? - 1
		part1 = evaluateString("Conveyor_" + stringValue(child.index))
		entity1 = "Conveyor3b"
		part2 = evaluateString("Conveyor_" + stringValue(child.index+1))
		entity2 = "Conveyor1b"
		axesOpposed? = True
		distance = 1.0
	End Child

[#9]

James and Jon, thanks much for the submissions.  I think this information will be useful for a lot of other developers out there. 

James, I don't think your specific suggestion applies to my particular application since it is more of a black-box application and is not interactive at all.   I'm sure that suggestion will be useful for others and for us on future applications.   But the general suggestion to work toward better code in general is dead on (see below).

Jon, your experiments help a lot by pointing out that the underlying performance of Inventor is probably not our problem.    

Our project started in the early spring and continues on Release 5.1 from last November.   Right now I suspect a major part of our problem is that we got caught up in copy-list bug on that release.   We are investigating that now by converting some very large lists to maps (hash tables).  I'll report back when we are done, but anyone out there working on the previous release and having performance issues with large models should be reminded to read this:

http://adndevblog.typepad.com/manufacturing/2012/08/list-referencing-performance-problem.html