Triggering an iLogic Form when Placing a Component in an Assembly

“One person can trigger a million thoughts.”
Anonymous

Earlier this week, KETIV presented the Autodesk Manufacturing Academy.  As always, the event was fantastic, and I got to see a lot of fellow Inventor users, and friends as well.

One question that was posed during the session was: "Can I set up an iLogic trigger in such a way, that when I start a new file from a template, the iLogic form will show up automatically?" 

The short answer.... Yes!

Here's how it works.

First, the background.  I have a template for sizing a wooden board, and determining if it's got a tenon joint or not.  The parameters are driven by an iLogic form named "Board Options"

An example of the form and the board it drives

Since I place these parts in an assembly, and want to resize them, I want the dialog to pop up when I create a new component in an assembly when using this template.

I can't just trigger the dialog box directly, but what I can do is create a rule with a single line of code that opens the dialog box.   And I can trigger that rule to run when I start the assembly.

The first step is to create a rule, in this case I named it "Trigger Dialog", and add the following line:

iLogicForm.Show("Board Options")

An example of the iLogic rule with the required code.

This simple line will open the dialog box, but in order for everything to work as intended, one more thing is required.

An event trigger needs to be added by choosing the "Event Triggers" icon from the iLogic panel.  This is found on the Manage tab.

Set the Trigger Dialog rule to run when a new document is started. 

Setting up the Event Trigger

 Now, when the file is started from a template, the dialog box, fired by the rule, will open. 

And the resizing can begin!

P.S. If you'd like a copy of this file to take a look at, it's available on GrabCAD!  Click on this link!

Making Sense of File Numbering Systems - Why do they have to?

“We put forth a very strong number. It's always hard to know, it's impossible to know what numbers are out there.”
Tim Purpura

This weekend has been a busy one, so this weekend's blog post is a short one.  But it's reflecting something that I've been thinking of doing for some time though.

File numbering schemes.  Users spend hours and hours trying to figure out which one to use.

Is it better to use a sequential?  One where the numbers have no meaning with regard to the files they're associated with? 

Or is it better to create one where the file name has a meaning.  A given portion of the file name tells the user this an assembly, or this component is made out of stainless steal, or is a custom part.  The different meanings can go on forever, and are different from company to company.

In my own, personal file structure in Autodesk Vault, I've done what so many are guilty of doing.  I've ignored it.

My own Vault file names are an example of what I'd tell someone not to do.

They have a mishmash of names.  Most have some sort of meaning.  Some are just names I threw in because I needed a name in a hurry. 

Others are names that I changed with Vault's Rename command because I needed to make room for another file with the same name (I have "Enforce Unique File Names" checked).

An example of my similar, but not consistent file names.

I've wanted to clean that up.  I would like more consistency in my file names.  But I just haven't had the time or desire to create one. 

So I decided to steal a number scheme from someone who's already created one.  I'm going to use the one the FAA uses for their Air Worthiness Directives! 


How does the FAA do it?  They start with the year, then count which two week period in the year the document was issued.  Then finally, number the documents in sequential order.

For example an Air Worthiness Directive numbered 2012-20-06 would mean the document was issued in the year 2012, in the 40th week of the year (20th two week period), and that it was the 6th document issued in that time.

I'm going to give it a try in my own Vault, and see how it works out!  I'll use the file naming scheme, and for searching, I'm going to search for keywords and properties associated to the files. 

An example of the properties I've added.  I'll probably adjust them, but it's a start.

It will require discipline to make sure I fill out my properties, but it's something I should already be doing!

I'll keep you posted on how it goes.  There will be benefits, there will be drawbacks.  The real question is, which will outweigh which?

So what do you think?  Are you a fan of meaningful, or non-meaningful file names?

Lesson from the Real World - That's not Supposed to Look Like That!

“Those who do not read are no better off than those who cannot.”
Proverb

As part of my engine maintenance class at Mount San Antonio College, we had to disassemble and measure and reassemble a Lycoming O-320 4 cylinder engine.

The assembled engine

 It was an interesting, and educational exercise.  Taking the engine apart, labeling components to make sure that they all could be easily returned to their locations when reassembling.  

The ultimate experience for a geeky engineer type.  Taking mechanical things apart!

The engine disassembled

The fascinating and frustrating portion was the inspection.  We checked parts with micrometers and feeler gauges, compared tolerances, and recorded everything.

One of the most interesting things we found was one of the pushrods. 

We removed it, and the conversation between myself and my lab mates went something like this.

Me (Holding up pushrod): What the......!

Lab Partner #1: Dude!  That's getting replaced.

Lab Partner #2 (standing about 5 feet away):  I can see that from here!  If you throw it, it'll come back to you!

The pushrod, which should be arrow straight, was visibly bent.  It was so badly bent, that it was rubbing on the inside of it's shroud, and had polished itself in places!

The pushrod laying on top of a cubical wall. The daylight can be seen underneath!

jj

Polish marks on the pushrod

How did it happen?  I'm not exactly sure.  Perhaps the push rod was too long.  Maybe the valve stuck, and the push rod had nowhere else to go but to bend. 

But what was my lesson?  The care that had to go into our checks.  The labeling of part, the measurements. It was painstaking, it was meticulous. 

It was necessary!

There was table upon tables of values listing the acceptable limits that our parts had to be within.  Anything outside of that should be replaced.

Example from the overhaul manual.  The "Table of Limits"

There were gaps measured in ten thousandths of an inch.  That's right. .0015 inches was a gap I had to look for!

I did realize that sometimes, in the sanctity of my 3D modeler, I sometimes don't think about things beyond "net fit".  It can be easy to forget about manufacturing tolerances, what happens to a part when it's heated to operating temperature. 

These are all factors that have to be considered. 

One miscalculation, or even a little bad luck, can result in a bent, or broken part. 

Migration Errors Moving from Autodesk Vault 2012 to 2013 - Scary! But an Easy Fix!

“It was tough. We have some experience on our side, which is nice.”
Paul Testa

One thing about my job, is I learn something new every day.

Friday, I was upgrading a server from Autodesk Vault 2012 SP2 to Autodesk Vault 2013. 

This should be easy.  I've done it a dozens times. 

But this time, it's different.  Instead of the usual upgrade magic, I get this error.

What?!?  What does this mean?!?

Database not supported?!?!? 

How can a 2013 not be able to migrate a 2012 database?!?!?

It's Friday, 2PM.  I am not looking forward to fighting a database into the wee hours of the night. 

I call a couple of colleagues.  We puzzle over it a bit. 

Then.. The solution comes from an experienced Vault user.

"Bring Vault 2013 up to the latest service pack." 

I do it, and it works. 

I breath a sigh of relief.  As a matter of fact, I breath a couple of more sighs, just to be sure.

Finally, I ask "What happened?  I've never seen that before".

My colleague explains that he's run into cases where an older version of Vault (in this case 2012) gets a service pack that's issued after a new release (2013 in this case).

Since 2012 install I was working on had Service Pack 2 installed, and that service pack came out after Vault 2013's release.  The Vault 2013 Service Pack 0 install didn't know what to do. 

Service Pack 1 for Vault 2013 had the updates to the migration process that were required.

I'm grateful for the experience of that colleague.  Without that, I probably would have tried to rebuild the 2012 installation.  This would have worked, but it would have taken hours instead of minutes.

I would have never thought to try the service pack.  

Now I know, should I ever run into this again!

And for the rest of you out in the 'Verse, I hope this tip helps you, should you ever run into the same thing!

Lessons from the Real World - Using Non Destructive Testing!

“It is our imagination that transforms itself into reality, through our physical strength and endeavours.”
Helen Araromi

This week, I didn't get a chance to come up with a good CAD related topic to blog about.  My schedule just stole my mind share.

But what I did get, was a solid exposure to how the real world works, thanks to my aircraft powerplant classes at Mount San Antonio College.

In the course, I had to perform some "non-destructive testing".

Of course I've seen how the computers do it.  I've heard how computer software simulation can "accurately predict how many cycles a component can take before it reaches it's fatigue life".

I've seen heads move up and down knowingly, about how the computer can help make more accurate predictions. 

But I also read a real world "Air Worthiness Directive".  This document is issued by the FAA when there's an incident that warrants a notification that could affect other operators.

In this case, the directive resulted from an incident, where an aircraft had a propeller "separate from the aircraft" due to crack propagating in the crankshaft! 

I don't think that the pilot of that aircraft was thinking "the simulations didn't predict a failure at this time" when he was watching the propeller leave without him!

The result of this?  Someone has to perform a real world test. 

In class, we performed a "Zyglo" test on non-ferrous parts.  In this test, a dye suspended in a penetrating oil is used.  It penetrates cracks, and when illuminated with a black light, it glows, revealing the cracks.

Below is a video describing Zyglo.



We tested for pistons, and found cracks in the skirts of three of the four pistons, probably where they had been dropped.

An example a piston in Zyglo.  It's a blurry picture, but there's a crack near the bottom

Example of parts undergoing Zyglo test.  Courtesy "Safari Helicopter Construction"

 Could a computer simulation predict that the pistons would be dropped, and crack long before their service life had been reached? 

For our ferrous components we conducted a "Magnaflux" test.  In this test, a ferrous component is magnetized and an oil with fine iron filings is sprayed on the part.  In this case, we had better luck.  no cracks in the parts we tested.

Connecting rods getting magnetized for a Magnaflux test

Image of a crack revealed in Magneflux.  Courtesy J&M Machine Co

 And check out the video below describing Magnaflux in detail.




But there's a lesson here.  How much can a simulation predict?  Can it predict that a part might get dropped and receive invisible damage?  Can it know how many parts might be improperly manufactured?  Can it predict that it's own inputs didn't reflect the forces the component would exist in the real world? 

No.  It can't.  That doesn't mean simulation isn't a valuable tool, it's an incredibly valuable tool.  But in the end.  It's just that.  One tool among many.

And it shouldn't be used to the exclusion of other tools.

That's the lesson I learned!

Cutting the Wire - Introducing the Space Mouse Wireless

“Many a live wire would be a dead one except for his connections”
Wilson Mizner

I've been a fan of 3DConnexion Devices since I first used one in Autodesk R10.

That's right, not 2010, Release 10.  That puts that around 2005 or so. 

A while, in other words.

I've gone through a SpaceTraveler, which they don't even make anymore, and I now alternate between a SpacePilot Pro and a SpaceMouse Pro.

And now, a new member joins the 3DConnexion family.  The SpaceMouse Wireless.

Courtesy of the 3DConnexion website

I've been told a few times "Why don't they make a wireless one?" 

Apparently I 3DConnexion was listening.  And now it's here! 

Check it out on the 3DConnexion Website here! 

I'm excited!