Community
Inventor Forum
Welcome to Autodesk’s Inventor Forums. Share your knowledge, ask questions, and explore popular Inventor topics.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

ATTENTION Inventor Developers! This part has repeatable crash

58 REPLIES 58
Reply
Message 1 of 59
Anonymous
773 Views, 58 Replies

ATTENTION Inventor Developers! This part has repeatable crash

Open this part, unsuppress fillet12 (just above EOP). This action causes features 25 steps previous to fail. How does a fillet reach back in time to corrupt other features?

I couldn't find the email address for anyone to just send this to. If you are a developer who deals with this kind of problem, please post your email or an email I can just send parts to rather than posting. This time I will write the email down on my monitor with sharpie.

Okay- I cannot post the part here!

"The content type of the file 'Corrupt Part.ipt' is not allowed"

So if someone wants to reply with their email contact, I will be happy to send the corrupt part.
Thanks
Phil
58 REPLIES 58
Message 21 of 59
Anonymous
in reply to: Anonymous

Does anyone have the originally posted model ?
Message 22 of 59
JDMather
in reply to: Anonymous

You should see it attached to the third post. If not, send me a email and I'll forward to you. I have examined the file in some detail and will post a lengthy synopsis when I get a chance. It is trivially easy to get the fillet in if the suppressed fillet is deleted and the EOP rolled up to just under Extrusion15 and the fillet added at that point in the history. Unroll the EOP and the part rebuilds without errors. But that doesn't answer the question of why it fails in the original attached. Edited by: JDMather on Oct 28, 2008 9:02 AM

-----------------------------------------------------------------------------------------
Autodesk Inventor 2019 Certified Professional
Autodesk AutoCAD 2013 Certified Professional
Certified SolidWorks Professional


Message 23 of 59
Anonymous
in reply to: Anonymous

"But that doesn't answer the question of why it fails in the original attached."


That's what I'm interested in as should Autodesk.
Message 24 of 59
Anonymous
in reply to: Anonymous

It doesn't seem to be available anymore.... I get "Error An general error occurred while processing your request."
Message 25 of 59
JDMather
in reply to: Anonymous

>That's what I'm interested in as should Autodesk.

I would caution the apparent assumption by the OP that I was suggesting a cause and effect between the unconstrained sketches and the failed fillet. The unconstrained sketches were just my observation as an obvious to see symptom of deeper problem in the overall technique. And I did agree that Autodesk should be interested in the file because it causes features earlier in the history to fail.

-----------------------------------------------------------------------------------------
Autodesk Inventor 2019 Certified Professional
Autodesk AutoCAD 2013 Certified Professional
Certified SolidWorks Professional


Message 26 of 59
JDMather
in reply to: Anonymous

>It doesn't seem to be available anymore.... I get "Error An general error occurred while processing your request."

I just downloaded it again a couple of minutes ago.

-----------------------------------------------------------------------------------------
Autodesk Inventor 2019 Certified Professional
Autodesk AutoCAD 2013 Certified Professional
Certified SolidWorks Professional


Message 27 of 59
Anonymous
in reply to: Anonymous

Andy, Loren and I had a discussion about this thread yesterday.

There are design scenarios that require you to try things and start over...

...if we all knew where a design was going when it was started, life would
be a lot easier I suspect.

Like Phil, I will routinely rely on "sloppy design practices" and usually
get away with them. I would hate to send any of my work to JD because a
majority of my sketches are under constrained and poorly dimensioned.

That said, if I know that I'm building something that will more than likely
need to be edited again later and/or given to another designer as an example
or as a foundation to build upon, I really try to nail things down. I have
also been bitten by my own sloppy assumptions - spent way more time that
warranted looking for a problem that was the result of sloppy habits.

Loren has already grabbed the original file and he has logged it for QA and
Dev review. Getting these sorts of issues to us is important and
appreciated.

Thanks Phil!

--
Gary R. Smith
Autodesk Manufacturing Solutions Division
Technical Publications - Subject Matter Expert
Portland, OR
2.33GHz 2GB IBM ThinkPad T60p; XP pro SP2
ATI Mobility FireGL V5250 driver: 8.293.1.0
Message 28 of 59
Anonymous
in reply to: Anonymous

Just re-read the first few responses and have to admit, you didn't .... this time. It was Dennis who suggested it was related.

I still can't download the file either (???). Tried with Internet Explorer, Firefox, and Chrome. Oh well, I'm not gonna worry about it anymore.
Message 29 of 59
JDMather
in reply to: Anonymous

>You see- funny thing here- by constraining all my sketches, and doing my best to have a clean part, I SAVED NO TIME.


In my experience all the evidence I have seen is that constraining most sketches and using a disciplined modeling technique saves time.

I took a look at the file. As indicated earlier in the thread no other changes other than adding the fillet after Extrusion15 the part would rebuild without errors. I don't believe I ever indicated that there was a cause and effect between the unconstrained sketches and the fillet. I believe I did indicate that this was an interesting file because a fillet feature caused errors earlier in the history tree.


I frequently take interesting problems from this discussion group and analyze them see if I can reproduce the geometry in a more efficient manner - particularly those problems that might reveal a re-producible bug or feature missing from Inventor. I identify with the book iWoz by Steve Wozniak on how I enjoy these challenges.


It was pointed out recently that while I might post a more elegant, robust solution I never take the time to explain why it is more robust or elegant. It would probably take a book to go much beneath the surface, and I am basically a machinist, ill equipped for the task. The first thing a machinist does when making a part is identify data for reference.


I checked iProperties and it indicated the file was started in Inventor 2008 and last saved in Inventor 2009.
I opened your file and created a new user Workplane Inventor assigned Workplane23.
On the workplane I created a new sketch Inventor assigned Sketch107.
In the new sketch I created a rectangle and added a dimension, Inventor assigned d872.
I Project Geometry a Loop, Inventor assigned Project Loop60.
I Project Geometry a Cut Edges, Inventor assigned Cut Edges28.
I extruded the sketch and Inventor assigned Extrusion87.

When I go through a problem I try many many iterations in quick succession getting to understand the geometry. I start many new files rather than building on top of the earlier garbage that I have accumulated and then discarded. A couple of interesting reads along this line are Seymour Papert's Mindstorms: Children, Computers, and Powerful Ideas, and The Children's Machine: Rethinking School in the Age of the Computer. To paraphrase Papert, "I need the unsuccessful early trials to get a feel for the later successful solution."

Workplane23
In your file there remains 9 user workplanes. Three of these are duplicates of the origin workplanes.
The only time I duplicate the origin workplanes is if I need to Flip Normal or if the design indicates that I might want to offset later for some reason. In other words, very very rarely. I feel like I might be mis-interpreted here, I didn't say I don't create user workplanes, I said I don't duplicate workplanes that already exist.

Sketch107
In your file there remains 42 sketches and 3 suppressed sketches. Many to most are under constrained, often lacking auto constraints or any dimensions at all. It would actually take me more time rather than less time to do the unconstrained/undimensioned sketches. To me this is the "quicksand" that can lead to even inadvertent changes to the model even if you were very careful in the initial construction. Even if you will have absolutely no need to change later. Within those sketches is evidence that is of more concern to me than the dimensioning/constraining - after all we didn't have constraints or driving dimensions on the drawing board or even AutoCAD.

Project Loop60
I failed to record how many projected loops you have remaining, but I almost never ever use projected loops. They are particularly prone to failure if the underlying geometry changes too much. Do an experiment. Project a loop on a face and then sketch a circle. Extrude the circle. Now try to Copy the cylindrical extruded feature. You cannot copy a feature that contains projected loop. (Projected Loop is generated when the Project Geometry is used on a part face rather than on the edges.) It gets even more fragile if build a child feature whose parent has a projected loop. Only use projected loop on top level features that will never change and no use as iFeature or Copy in the future.

Cut Edges28
I failed to record how many projected cut edge sketches you have remaining. Similar to projected loops, projected edges are prone to failure if the underlying geometry changes too much. But unlike projected loops which can be entirely avoided in any case that I can think of off-hand, projected cut edges are sometimes very valuable. They should be used only where absolutely needed and with caution. Until recently they weren't eve associative in Inventor. (I feel the need to point out to the less experienced Inventor user that Cut Edges28 does not mean there are 27 previous entities created - each instance of a project cut edge usually (always) results in multiple entities created - each of which could fail).

Extrude87
In your file there remains 31 extrusions and 3 suppressed extrusions. I estimate that I could model the same part with about half the number of features. That is less important than the sketch concerns already indicated, but as much as (efficiently) possible I try to avoid parent/child relationships. The more complex the part the more I try to avoid these relationships. On a simple part it probably isn't worth the effort. In Billy Vaughn Koen's, Discussion of the Method: Conducting the Engineer's Approach to Problem Solving he has an interesting discussion on the difficulty of programming the game of chess. The board has only 64 squares and the initial possible moves are known. The rules are well defined. I would argue that design is far more difficult than chess with many more possible interactions. I am a machinist, not a software programmer. My views are simply based on observation and experience.

-----------------------------------------------------------------------------------------
Autodesk Inventor 2019 Certified Professional
Autodesk AutoCAD 2013 Certified Professional
Certified SolidWorks Professional


Message 30 of 59
Anonymous
in reply to: Anonymous

>Like Phil, I will routinely rely on "sloppy design practices" and usually get away with them.

This is an attitude that reflects your company's culture. If you are sloppy in one aspect of your work, you will usually be sloppy in others. This also affects the work of your peers. This is nothing more than laziness.

It is has become very obvious that ADSK does not practice continuous improvement or Six Sigma and relies on "good enough and lets hope they don't notice". The release of sloppy code and half-implemented features is a regular occurrence. Features are not fully documented. Websites are updated with broken interfaces. It is all connected.

I would suggest reviewing your attitudes and culture otherwise you will continue to lose customers to other companies that continually strive for excellence.
Message 31 of 59
Anonymous
in reply to: Anonymous


I'll stand by my brief analysis. I din not dig any deeper
after viewing all the garbage in the file. I agree with JD's final analysis of
this file dated today.


--
Dennis Jeffrey, Autodesk Inventor Certified
Expert
Autodesk Manufacturing Implementation Certified
Expert.
Instructor/Author/Sr. App Engr.
AIP 2008 SP2, AIP 2009-SP1
PcCillin AV
HP zv5000  AMD64 2GB - Geforce Go 440, Driver: .8185
XP
Pro SP2, Windows XP Silver Theme

href="http://teknigroup.com">http://teknigroup.com
Message 32 of 59
Anonymous
in reply to: Anonymous


JD, I totally agree. If others realized how many hundreds or
thousands of BAD files that instructors see in 22 years of working with
parametric relationships they would understand that sloppiness invites problems.
I did not even bother to spend more time on the file to try to unwind the
dependencies with the final fillet. Total waste of time, even if I were getting
"paid" for the analysis, which I'm not.

 

PTC - Pro/E used to require that sketches were fully
constrained before creating features, otherwise, the part might become
unstable.  I understand that the newer ones fully "autoconstrain" if you do
not do your job. Inventor has that option. You just have to use
it. 

MDT - Best practice from day 1 was that all sketches
"should be" fully constrained.

SW - Same as MDT

IV -  Same as MDT

 

In fact all parametric programs RECOMMEND fully constraining.
There is a reason.

 

Kinda like smoking while fueling your vehicle. I see people
doing that every day also. Sometimes there's an explosion......

 


--
Dennis Jeffrey, Autodesk Inventor Certified
Expert
Autodesk Manufacturing Implementation Certified
Expert.
Instructor/Author/Sr. App Engr.
AIP 2008 SP2, AIP 2009-SP1
PcCillin AV
HP zv5000  AMD64 2GB - Geforce Go 440, Driver: .8185
XP
Pro SP2, Windows XP Silver Theme

href="http://teknigroup.com">http://teknigroup.com
Message 33 of 59
Anonymous
in reply to: Anonymous

I don't do part/assembly design for a living. The models that I make are for
illustration purposes only - nobody sees the IPT or IAM files, so my
modeling practices are completely appropriate for their purposes.
Message 34 of 59
Anonymous
in reply to: Anonymous


Let me poke in here if I may

 

I do agree with Josh that we have seen lots of half
implemented features and some sloppy interface designs with the release of IV
over the years, but I don't for a second think that we all can and will have
drawings that are textbook perfect, and pass JD's inspection. (sorry to point
you out JD) It's just not economically possible or appropriate to go back and
redraw a part just because you made some changes on it later on in the process.
We design a large variety of different equipment here, and not a lot of each
either. So when a change is made it may be a year or 2 and IV has improved, our
own skills have improved, the way we would have modeled it may have changed
depending on the change, but it's still not economical to redraw the part. Why
well that would require us to re-constrain the part in the assy, or assy's We
have lots of parts in multiple assy's. It might then require us to readjust in
an ipn file, and then we might have to re-balloon, and reattach measurements in
an idw. I mean changing one part could literally take up my entire day, when it
was really only budgeted to take up 1/2hour. I am not saying that we should be
careless in our drawings, or sloppy, but I don't think all our drawings will be
perfect and that is just life.

 

I don't think I am lazy Josh for drawings that not perfect,
instead I like to think that I am doing the best job I can in the time allocated
to me. Would that not just make me efficient.


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
>Like
Phil, I will routinely rely on "sloppy design practices" and usually get away
with them.

This is an attitude that reflects your company's culture. If
you are sloppy in one aspect of your work, you will usually be sloppy in
others. This also affects the work of your peers. This is nothing more than
laziness.

It is has become very obvious that ADSK does not practice
continuous improvement or Six Sigma and relies on "good enough and lets hope
they don't notice". The release of sloppy code and half-implemented features
is a regular occurrence. Features are not fully documented. Websites are
updated with broken interfaces. It is all connected.

I would suggest
reviewing your attitudes and culture otherwise you will continue to lose
customers to other companies that continually strive for excellence.
Message 35 of 59
Anonymous
in reply to: Anonymous

JD, for the record, I agree pretty much with all of your "bold" points. Things like Projected Loops, I *never* use. I do, very rarely, use "Project Cut Edges, but I always turn it all into construction lines and then "draw over" the bits and pieces I need. Creating workplanes right on top of the existing ones ? See it all the time (here) and NEVER understand why people do it !
Message 36 of 59
Anonymous
in reply to: Anonymous


Troy,

 

I don't think that JD or I ever have said that
underconstrained geometry is the cause of all problems. However, when a part
goes "South" for no apparent reason, it's one of the first places to look. We
had a term when I was doing and teaching computer programming back in the 70's
and '80's, called "Spaghetti Code" which described coding ( programming) that
became so convoluted that it was next to impossible to locate the real cause of
a problem. The solution to that issue was to teach a "structured" programming
workflow.  When code is simplified and structured, it is more stable,
faster, and generally easier to troubleshoot.

 

The same applies to modeling techniques..... BTW, the term
GIGO (Garbage In Garbage Out) was coined by programmers who finally realized
that it takes LESS time to properly program ( "model" ) than to fix issues
later ( that is IF you can unravel the problem ).

 

I'll agree, that an issue like this rarely rears it's head....
but as I stated in another post:

 

"Kinda like smoking while fueling your vehicle. I see people
doing that every day also. Sometimes there's an explosion......"


--
Dennis Jeffrey, Autodesk Inventor Certified
Expert
Autodesk Manufacturing Implementation Certified
Expert.
Instructor/Author/Sr. App Engr.
AIP 2008 SP2, AIP 2009-SP1
PcCillin AV
HP zv5000  AMD64 2GB - Geforce Go 440, Driver: .8185
XP
Pro SP2, Windows XP Silver Theme

href="http://teknigroup.com">http://teknigroup.com
Message 37 of 59
JDMather
in reply to: Anonymous

> It's just not economically possible or appropriate to go back and redraw a part... ....but it's still not economical to redraw the part.

I agree, in some cases, but not this one. I'm commenting on this particular part. This is a challenging part for Inventor. I see plenty of evidence that only leads me to wonder why it didn't fail much earlier.

-----------------------------------------------------------------------------------------
Autodesk Inventor 2019 Certified Professional
Autodesk AutoCAD 2013 Certified Professional
Certified SolidWorks Professional


Message 38 of 59
Anonymous
in reply to: Anonymous


I don't think that I ever said the you said that under
constrained geometry was the cause of all the problems.

 

I completely agree that the simpler a part is modeled the
greater the chances are that the part will never see an issue. I am just saying
that its not always efficient to re-make the part simple.

 

You need to balance the pros and cons of redrawing a part
before you do it. Will the results be worth the work?

 


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">


Troy,

 

I don't think that JD or I ever have said that
underconstrained geometry is the cause of all problems. However, when a part
goes "South" for no apparent reason, it's one of the first places to look. We
had a term when I was doing and teaching computer programming back in the 70's
and '80's, called "Spaghetti Code" which described coding ( programming) that
became so convoluted that it was next to impossible to locate the real cause
of a problem. The solution to that issue was to teach a "structured"
programming workflow.  When code is simplified and structured, it is more
stable, faster, and generally easier to troubleshoot.

 

The same applies to modeling techniques..... BTW, the term
GIGO (Garbage In Garbage Out) was coined by programmers who finally realized
that it takes LESS time to properly program ( "model" ) than to fix
issues later ( that is IF you can unravel the problem ).

 

I'll agree, that an issue like this rarely rears it's
head.... but as I stated in another post:

 

"Kinda like smoking while fueling your vehicle. I see people
doing that every day also. Sometimes there's an explosion......"


--
Dennis Jeffrey, Autodesk Inventor Certified
Expert
Autodesk Manufacturing Implementation Certified
Expert.
Instructor/Author/Sr. App Engr.
AIP 2008 SP2, AIP 2009-SP1
PcCillin AV
HP zv5000  AMD64 2GB - Geforce Go 440, Driver: .8185
XP
Pro SP2, Windows XP Silver Theme

title="http://teknigroup.com/ CTRL + Click to follow link"
href="http://teknigroup.com">http:/...
Message 39 of 59
Anonymous
in reply to: Anonymous

T{font:Times New Roman}{size:3}otal laziness... I always get around to relaxing my standards and bringing down my workmates right after writing manuals, designing tradeshow booths, building the booth, qualifying vendor parts, creating new designs, documenting those new designs, translating them to SW for the Chinese, troubleshooting returned product, unloading trucks... yeah, total laziness. Must be nice to work somewhere you only have to push the right buttons all day.{size}{font}
Message 40 of 59
Anonymous
in reply to: Anonymous

> Creating workplanes right on top of the existing ones ?
> See it all the time (here) and NEVER understand why people do it !

With no attempt to make a case one way or the other;
>
[1] Redundant work features are consistent with so called
'horizontal modeling' techniques, which are sometimes a good
idea.
>
[2] If (a) unsure, due to lack of query functions or
indications, of existing work features' dependencies and
orientations, where applicable, or (b) relatively sure
a reroute will never be required, the safe thing to do
is create new ones dedicated to the purpose at hand.

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Technology Administrators


Autodesk Design & Make Report