Unexpected origin with inserted assembly component

[Anonymous]

I am inserting an assembly into an assembly, linked and all. In fact I had already inserted one and the origins of that assembly were just as expected. When I go to insert another copy, it shows up with an origin that seems to be a sub component of the inserted assembly. Not the inserted assembly's or it's ancestors. I've confirmed inserting the assembly in a test file with the same resulting unexpected origin. I'm stymied and would be relieved if anyone can explain this behavior and or how to import an assembly with that assembly's origin in the same location in the file. I can move forward without explanation but I'm trying to do things right and think I must be missing something...

I made a screencast that makes more sense than what I've typed.

 - Dave

[Anonymous]

I've attached the file of the bolt assembly I'm inserting. The assembly I'm inserting it into has some linked assemblies in it so I'll see if I can...

[etfrench]

Use a joint to place the inserted component.

[TrippyLighting]

A few questions:

How often do you need this in your design ?

Do you really need fully modeled thread ?

What is your intention with the sider joint ?

Why would you nee the timeline  in this small assembly ?

All of those implied things above can have a significant effect on the performance of your design. Fully modeled threads create complex geometry. If you need a couple dozen of this assembly, consider removing the threads.

The last two in combination can lower the memory demands to 1/3. Timeline based designs are up to 3 times larger than non-timeline based designs. these are purchased components and the likelihood that you need to make parametric changes is very small.

Turn off the timeline, use the move and align tool to move the components into the correct location and orientation and then apply one rigid group joint at the top level including all children.

The move and align tool should be used ONLY in direct modeling designs (no timeline) to locate components. In timeline based designs they should really not be used at all.

[Anonymous]

All good questions. Thank you so much for your contribution to the forums TrippyLighting, I've read much of what you've posted and have learned some of your methodology and agree with the rest. Just looking at the contributions listed with your profile is informative and I've even referenced some of the content you've linked to outside of the forums (https://docs.google.com/document/d/11JxN3XLyVWVTwCPbGEFvPc9nE6kiqCvUTo84CpIIL5s/edit#heading=h.6q0ol...). I'll respond in order

I'll be using this simple bolt assembly in most of the setups I model for CAM. Once I've modeled the ops of a part I insert them into the various stations designated to be sure all is koscher. I'm starting to branch out into modeling the CNC environment, essentially a given machine's table with vises or fixtures for each station and other hardware like jawstops, adjustable workstops, holddowns, whatever. I would like to document the full setup for the operator and also account for fixture geometry in the CAM operations. I break the link on the vises so I can parametrically adjust the dimensions of the soft jaws, though I'm starting to lean towards leaving the jaws out of the vise file so I can leave the vises linked and keeping the broken jaws in the parent assembly, 'stationX'.

I certainly don't need modeled thread and think I will use some simplified bodies in the future. I'm still getting these different machine environments setup and economizing in the process. Modeled thread is unreasonable, but I also wanted to push the software, and McMaster Carr gave it to me like that for a quicky. Duly noted.

The slider joint is so I can 'drive' the rod up through the flange nut till the T-nut (rigid joint to rod) is in contact with the surface of the slot. This is almost entirely cosmetic, no machining takes place in the table slots of course but it serves to let the operator know about the hardware required to secure the vise and perhaps the flange nut and protruding rod could come into play with clearance on an odd move.

I don't need the timeline in this small assembly. I have learned how convenient direct modeling can be but I've gotten in the habit of turning on the history before I create the joints. I don't believe that is required for these types of joints (not as-built joints) and this is a great example of an unnecessary timeline I'll toss out.

Thanks for the response, much obliged,

 - Dave

[Anonymous]

No problem placing the component, and I do use a rigid joint between the bottom of the flange nut and the top of the vise base. I've noticed joints tend to leave the origin behind, perhaps I'm inconsistent with the hierarchy, I don't know, but I do try to move the assemblies into place before creating the joint so the assembly's origin remains where it is located in the inserted file.

And that's what this is really all about, understanding why the origin comes to be located where it is. I don't need to understand this to move forward but it could explain some of the behavior I encounter like that in the next screencast I've posted with this reply. Hrrrrm

[Anonymous]

I don't think the screencast was inserted.

 

[TrippyLighting · Accepted solution]

That "floating" origin is very easy to explain. 

Joints work on a component basis.

Each component, even an empty one has an origin.

Many user would argue that this design has only three components. I say it has 4!

The top level component is actually a component group and also has an origin in it.

Your 2 joints are managing the three components in the group, but not the group (origin) itself. Nothing is assembled to it.

What I usually do in such assemblies, which only contain imported geometry is one of two things. This is the reason I asked if you actually need the slider joint:

1. In a purely static assembly(component group) I select the top level and apply a rigid group with teh "include child components" check mark enabled. If you do this in your assembly you'll see that the counter include 4 because there are 4 origins in the design!
2. If something needs to move in the design I decide what the stationary component would be and create a rigid group between its origin and the top level origin. Then I assemble the other components in reference to that component (origin).

Not managing or mis-managing the origins of components and component groups is one of the main reasons why  assemblies in FUiosn 360 fail.

[Anonymous]

I'm not sure how that explains the 'floating' origin. We're you referring to the second screencast where the vise and hardware assembly is copied? Why would the original change? I'm guessing a joint reference is lost but then I would expect the assembly to move and the origin to remain. Or maybe I'm mixing up the vise origin and the 'station' (parent) assembly origin which are in the same place. Wait... it just occurred to me that the assembly that stays in the location might be the copy and the original moves? I suppose I could check this but I have switched up this file already after having greatly simplified the vise file as per our discussion. I found Fusions healing to be pretty intuitive and removed a lot of geometry.

I've still got some work to do with my origins, I'm getting more consistent though. Here's my process / understanding of origins.

Anything you want to have it's own origin must be a component. As mentioned, I find creating components early helps, though mostly for compartmentalization of history.
If an origin isn't where I like, I move a body. As above, origins move with components, a body must be moved inside that component to change it's orientation to that origin. I use the browser to select for the move.
Joints move components without moving their origin. I think. I like to move the component into it's resting position before applying the joint, and if I'm working stuff out as in the previous item, check to be sure a joint isn't throwing me off. I found it quick and simple to insert components and assemblies and place them with joints but this always left the origin coincident with the parent's. Sometimes this might be desired but usually wasn't what I was after.
I intend to put your second point to good use as well:

"If something needs to move in the design I decide what the stationary component would be and create a rigid group between its origin and the top level origin. Then I assemble the other components in reference to that component (origin)."
Seems like a good working method.

As a side item of discovery I will add that if you intend to adjust assemblies with parameters, no 'linked' designs should contain the assemblies you wish to adjust. This seems clear when I type it but it took me a while to realize it was fundamental to design structure. I digressed when I mentioned vises before but that was the work item that made this clear. If I've got two identical vises on a table I would like those to be linked designs. If those vise assemblies contain soft jaws or parallels I intend to adjust parametrically that's a no go. I will have to break the link of the vise assembly to make those adjustments, adding redundancy. I found a better structure is creating two designs. Something like 'vise core' and 'vise outfitted' that contains the vise core linked design as well as any other vise accouterments like jaws, parallels, stops, whatever you need to adjust parametrically. Basically,

A designs parameters will not be accessible in another design if that design or any of it's ancestors are linked.

That seems pretty clear but might be a consideration when organizing designs.

Also, designs cannot be linked across projects. I thought that was a biggy so I've organized my projects as files in one project to rule them all. Of course I would need to link to different designs in my 'setups' project in my 'NASA', 'CERN' and 'Initrode' projects 😉 Geeze Autodesk...

This may not be the right place for this information, apologies.

 - Dave

[TrippyLighting]

Could you share one of your assemblies ?

I understand if that's not possible for NDA and such reasons.