Hi Autodesk I hope you can help us.
We routinely position our Inventor parts in our assemblies at Real World Coordinates (e.g. 527,000m east by 169,000m north).
We routinely export to .dwg for use in our downstream workflow e.g. Civils3D.
We find it helpful to use the correct coords as it makes import to the likes of Civils3D extremly simple as there is no translation/scaling/rotation to be done when we bring them in.
We are experiencing problems when we use Inventors>Export to dwg facility.
If the parts in the assembly are near to the origin (0,0,0) then the export of the assembly to dwg typically takes around 7 secs |6.18 MB
As the parts get further from the origin (e.g. x=527,000m, y=169,000m) the export of the assembly takes >1 hr | 5.67 MB.
I did some experiments and can report the following findings using the same model. I progressively moved the parts in the assembly away from the origin. Here's what i find ...
Interestingly, the dwfx export does not suffer the same performance hit - taking about 7 seconds to export all the variants above.
Dear Autodesk - can you shed some light on what is causing this problem with the dwg export method. It occurs both when we call the method via the API and when we trigger it manually.
We are using Inventor Professional 2016 SP2_x64 and the patch DL22744178_64-bit. The experience is the same across our various PCs. The above reported tests were done on a PC with Windows7-X64, Intel Core i7 Quad core, 24GB RAM, 35GB free space.
This is affecting a lot of our work.
Many thanks if you can shed some light.
Regards
Dan.
Solved! Go to Solution.
Hi Autodesk I hope you can help us.
We routinely position our Inventor parts in our assemblies at Real World Coordinates (e.g. 527,000m east by 169,000m north).
We routinely export to .dwg for use in our downstream workflow e.g. Civils3D.
We find it helpful to use the correct coords as it makes import to the likes of Civils3D extremly simple as there is no translation/scaling/rotation to be done when we bring them in.
We are experiencing problems when we use Inventors>Export to dwg facility.
If the parts in the assembly are near to the origin (0,0,0) then the export of the assembly to dwg typically takes around 7 secs |6.18 MB
As the parts get further from the origin (e.g. x=527,000m, y=169,000m) the export of the assembly takes >1 hr | 5.67 MB.
I did some experiments and can report the following findings using the same model. I progressively moved the parts in the assembly away from the origin. Here's what i find ...
Interestingly, the dwfx export does not suffer the same performance hit - taking about 7 seconds to export all the variants above.
Dear Autodesk - can you shed some light on what is causing this problem with the dwg export method. It occurs both when we call the method via the API and when we trigger it manually.
We are using Inventor Professional 2016 SP2_x64 and the patch DL22744178_64-bit. The experience is the same across our various PCs. The above reported tests were done on a PC with Windows7-X64, Intel Core i7 Quad core, 24GB RAM, 35GB free space.
This is affecting a lot of our work.
Many thanks if you can shed some light.
Regards
Dan.
Solved! Go to Solution.
Solved by DynamicObjects. Go to Solution.
Dan,
Just curious, why are you using Inventor for real world coordinates? I don't know much about Civil 3D, but is it not possible to just create the part/assemblies in Inventor, then import them into Civil? Inventor when it is spread out with the coordinates like you have them has a bigger area to calculate which leads to the time delay. I have seen this in my parts that are feet long.
If this solved your issue please mark this posting "Accept as Solution".
Or if you like something that was said and it was helpful, Kudos are appreciated. Thanks!!!!
Dan,
Just curious, why are you using Inventor for real world coordinates? I don't know much about Civil 3D, but is it not possible to just create the part/assemblies in Inventor, then import them into Civil? Inventor when it is spread out with the coordinates like you have them has a bigger area to calculate which leads to the time delay. I have seen this in my parts that are feet long.
If this solved your issue please mark this posting "Accept as Solution".
Or if you like something that was said and it was helpful, Kudos are appreciated. Thanks!!!!
Also to add...
This is mainly a peer to peer network where users are assisting other users like yourself. This is not Autodesk, although they do monitor these forums, it doesn't mean they will see and/or respond to your posting. If you're having issues and others on this forum are not able to assist, then log a case through your Autodesk Account or through a reseller if you have one.
Mark Lancaster
& Autodesk Services MarketPlace Provider
Autodesk Inventor Certified Professional & not an Autodesk Employee
Likes is much appreciated if the information I have shared is helpful to you and/or others
Did this resolve your issue? Please accept it "As a Solution" so others may benefit from it.
Also to add...
This is mainly a peer to peer network where users are assisting other users like yourself. This is not Autodesk, although they do monitor these forums, it doesn't mean they will see and/or respond to your posting. If you're having issues and others on this forum are not able to assist, then log a case through your Autodesk Account or through a reseller if you have one.
Mark Lancaster
& Autodesk Services MarketPlace Provider
Autodesk Inventor Certified Professional & not an Autodesk Employee
Likes is much appreciated if the information I have shared is helpful to you and/or others
Did this resolve your issue? Please accept it "As a Solution" so others may benefit from it.
Yeah, don't really want to be using real-world coordinates for mechanical engineering. Consider that its entirely possible for the entire object to be moved and/or rotated on site without an actual design change; that means you have to go back to Inventor and change it there, then re-export, rather than just changing the position and orientation in the Civil3D model (have to keep things accurate). And it's causing problems with the work process to boot.
Yeah, don't really want to be using real-world coordinates for mechanical engineering. Consider that its entirely possible for the entire object to be moved and/or rotated on site without an actual design change; that means you have to go back to Inventor and change it there, then re-export, rather than just changing the position and orientation in the Civil3D model (have to keep things accurate). And it's causing problems with the work process to boot.
Inventor has trouble modeling components that have features outside a 100 meter bounding cube centered at the origin.
Steve Walton
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.
Inventor has trouble modeling components that have features outside a 100 meter bounding cube centered at the origin.
Steve Walton
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.
Hi Cadmanto - Here at Atkins we work daily with Civils3D, Revit and vanilla AutoCAD. We have our reasons for doing it this way and explaining it is really a side issue that i don't want to distract the thread question with. In brief it relates to a workflow process where we automate Inventor to create assemblies in a way that is harder to achieve in Civils3D and automatically bring them in at the correct positions in C3D.
Your point about calculation delay for bigger areas. I understand and agree that Inventor calculations will become less accurate as coordinates increase (mathematical floating-point issue for all CAD packages to handle). Possibly they will take a little longer to compute (not sure the validity of that) .. BUT ... does that really explain why exporting to dwg takes >1 hr when exporting to dwfx = 7 seconds. ???
regards
Dan
Hi Cadmanto - Here at Atkins we work daily with Civils3D, Revit and vanilla AutoCAD. We have our reasons for doing it this way and explaining it is really a side issue that i don't want to distract the thread question with. In brief it relates to a workflow process where we automate Inventor to create assemblies in a way that is harder to achieve in Civils3D and automatically bring them in at the correct positions in C3D.
Your point about calculation delay for bigger areas. I understand and agree that Inventor calculations will become less accurate as coordinates increase (mathematical floating-point issue for all CAD packages to handle). Possibly they will take a little longer to compute (not sure the validity of that) .. BUT ... does that really explain why exporting to dwg takes >1 hr when exporting to dwfx = 7 seconds. ???
regards
Dan
Thanks Mark. I will post on the ADN as well. Perhaps some users of this forum may shed light in the meantime.
Thanks Mark. I will post on the ADN as well. Perhaps some users of this forum may shed light in the meantime.
Hi dgorsman. What we are doing in this automated workflow is unconventional by choice. -We could not find a single CAD application that could by itself achieve all that we wanted. We are aware of the limitations you point out.
Hi dgorsman. What we are doing in this automated workflow is unconventional by choice. -We could not find a single CAD application that could by itself achieve all that we wanted. We are aware of the limitations you point out.
Hi Swalton - thanks for that link.
I'm not sure that explicitly explains why export to dwg takes >1hr but export to dwfx = 7 secs?
regards
Dan
Hi Swalton - thanks for that link.
I'm not sure that explicitly explains why export to dwg takes >1hr but export to dwfx = 7 secs?
regards
Dan
Kudos to Don Warner of Autodesk who approached us and undertook to investigate this with us.
Firstly our findings did all seem to point to the difference in duration being caused by the number precision (floating-point calcs).
This is why DWFX was consistently achieving export within 7 seconds - it apparently stores data as 32-bit integers!
By contrast DWG stores data with 64-bit double-precision floating points.
Don discovered that we were using template assembly files (.iam) with the Document Settings> Units set to "mm".
We had presumed that this setting related only to how Inventor displayed the length dimensions (since Inventor uses its own fixed units under the bonnet - cm) ... but it turns out that it does more than this. This setting seems to control how geometry numbers/coords are stored in the document file.
So taking Don's advice we changed this setting to "metres" this effectively truncated all geometry numbers by 3 decimal places in the document.
When the dwg export method was called it translated this same geometry within seconds!! (Because the geometry numbers were no longer to 15 significant figures).
In summary here is our findings:
File name | Document Units | dwg export durations |
A mm.iam | mm | 110 min |
A cm.iam | cm | 8.1 min |
A metres.iam | metres | 9 secs |
B mm.iam | mm | 58 min |
B cm.iam | cm | 1.7 min |
B metres.iam | metres | 13 secs |
As you can see, changing the Document Units for our assemblies has solved the extremely long dwg export durations we were experiencing.
This is our accepted solution.
Thank you Don, and Autodesk.
Kudos to Don Warner of Autodesk who approached us and undertook to investigate this with us.
Firstly our findings did all seem to point to the difference in duration being caused by the number precision (floating-point calcs).
This is why DWFX was consistently achieving export within 7 seconds - it apparently stores data as 32-bit integers!
By contrast DWG stores data with 64-bit double-precision floating points.
Don discovered that we were using template assembly files (.iam) with the Document Settings> Units set to "mm".
We had presumed that this setting related only to how Inventor displayed the length dimensions (since Inventor uses its own fixed units under the bonnet - cm) ... but it turns out that it does more than this. This setting seems to control how geometry numbers/coords are stored in the document file.
So taking Don's advice we changed this setting to "metres" this effectively truncated all geometry numbers by 3 decimal places in the document.
When the dwg export method was called it translated this same geometry within seconds!! (Because the geometry numbers were no longer to 15 significant figures).
In summary here is our findings:
File name | Document Units | dwg export durations |
A mm.iam | mm | 110 min |
A cm.iam | cm | 8.1 min |
A metres.iam | metres | 9 secs |
B mm.iam | mm | 58 min |
B cm.iam | cm | 1.7 min |
B metres.iam | metres | 13 secs |
As you can see, changing the Document Units for our assemblies has solved the extremely long dwg export durations we were experiencing.
This is our accepted solution.
Thank you Don, and Autodesk.
Can't find what you're looking for? Ask the community or share your knowledge.