Insert derive doesn't insert joint origin?

[tomjulier]

In this example, Derived.f3d has a joint origin, but the joint origin is gone once the component is inserted into another design. Is that the intended behaviour?

The .f3z file of the assembly gives an error when I try to attach it unfortunately - The attachment's assembly.f3z content type (application/octet-stream) does not match its file extension and has been removed.

[lichtzeichenanlage]

@jeff_strater : This looks like a bug in the derived function.

[TrippyLighting]

Yep, I've come across this before and forgot report it.

@ryan.bales can you check this out ?

[jeff_strater · Accepted solution]

well, it's a bit debatable whether this is a "bug" or not.  There are aspects of the model that are not brought across in Divide.  We just decided what should/should not come over, and Joint Origins did not make the original cut.  I do agree that Joint Origin is very important and should be one item that is brought across, so I'll create an item to track this.

[jan.gunnelin]

Hello,

I really support all efforts to make Joint Origins come across when doing an Insert Derive operation! As of now I have to make a lot of workarounds to get what I need, if at all possible. Please put a high priority on this request.

Many thanks in advance,

BR Jan Gunnelin

[lure23]

@jeff_strater Is there a ticket number or something we as users could refer to, to give this more boost?

I learned about Derive today, and in my FIRST attempt to use it, there's no Joint Origin! I've created the component with one, in order for it to be easily placed. And now I have it... except for the placement bit.

In other words: please 🙂 what can we do to bring focus to fixing this?

[jan.gunnelin]

Hello again,

I have created a "physical joint origin" to be able to use the Align command on a component after an Insert Derive operation, please see the attached picture. It works well, also in component hierarchies, but the "physical joint origin" should preferably be removed before printing a part, if possible.

BR Jan Gunnelin

[lure23]

Hi Jan,

if I got your reply correctly, you are suggesting a work-around to the fact the Joint Origins are not brought in by derive.

That's cool, but I'm not looking for a work-around. A member of the Autodesk staff has mentioned (above) that they would work to change this (the change looks like a "one-liner" for me). That was in April, now we're in September.

I just wish to know the way to show interest in a bug fix that's been said to be in the pipeline. How can I make sure it gets deployed, say, within 6 months from the "go ahead" from manamgent?

[jan.gunnelin]

Hello again,

I have not investigated how requirements are handled in the Fusion 360 case. But as a seasoned former Product Manager I know that you have to distribute the requirements for new features, the need for improvements and important corrections over the available budget, resources/competence and time, all the time. The items with the best "business case" is always on the top of the backlog, and will thus normally be handled first. So I suggest we put together a strong business case for this improvement; what are the gains and losses for the users, what are the gains and losses for Autodesk, etc., for having and not having this request implemented. There can be complications with inherited joint origins I can imagine, for instance if a component with inherited joint origins is split into two or more pieces, which I regularly do, which part should the joint origin belong to if the split is exactly at its location?

BR Jan Gunnelin

[lichtzeichenanlage]

Spoke like a real manager. "I don't know how it works here, but here is a process how we do it now" 😉

The official, but frustrating and  not very transparency way to place a feature request is the IdeaStation. 

[TrippyLighting]

---

@jan.gunnelin wrote:

...for new features,

---

This isn't a new feature. the fact that the joint origin is not copied over is a bug that I reported a while ago. As such it is not intended.

When you split a component into subcomponents all subcomponent will have their own origin.

The original joint origin will remain with the subassembly and each new subcomponent should receive their own joint origin.

[lichtzeichenanlage]

I see the point. Is it a bug? Hard to know unless we don't know the specification. Did we expect something different? For sure. Can we agree on a change request? IMHO this might be placed in the IdeaStation, too.

Sure - you have better contacts and it's nice that you try to push things. But this is nothing everybody can do. 

[TrippyLighting]

---

@lichtzeichenanlage wrote:

... I see the point. Is it a bug? ...

---

It is a confirmed bug with a FUS number.

[edgemarston]

Just came across this issue. Looks like it still doesn't work as of Oct 11. Agree that it would be very helpful to have joint origins transfer along with a derive!

[lure23]

Was bitten by this again.

Had prepared a design with a Joint Origin specifically in mind, to be used as the integration point.

Insert Derive > ... no JO, then I remembered this entry that I *am* tracking. Any progress or estimate?

[Anonymous]

I would also LOVE to get this, It's essential in setting up preexisting components where they can attach! Like 80-20. I assumed it would bring joint origins about to derived part. Nope, I have to create new origins for each piece. Just creating all the possible joints was crazy, then using the "join" tool to "subtract" pockets, not intuitive at all. Solidworks is way easier than this. I thought this setup would be amazing, you know once I got it going, this lack of essential feature killed it dead in it's tracks. Spent hours making these parts and origins, now... Useless... I think more people get annoyed spending their time setting things up just to find out , again, fusion does not support this feature after extensive searching.