Mirror Reverses Thread Direction - Is This Intended?

[mikahb]

Just about got caught out by this on a design I'm sending off for manufacturing...

If you create RH threaded holes on a face, then mirror them to another face, Fusion reverses them so that the "mirrored" threads are LH (left-handed).  I tested with all 3 mirror options (Optimized, Adjust, Identical) and got same results.

Is this how it's supposed to work?  Seems like dangerous unexpected behavior to me, but I'm relatively new to Fusion so perhaps there's a use case where this is preferred behavior.  Couple pictures of my simple demonstration example:

[John_Wright]

By definition, a mirror of a thread will reverse the thread in the real world so I assume this is why it's Fusions behaviour. However, I feel that their should be an option as a tick box that will not create an actual mirror on threads for the reason you highlight above. 

A work around is to do a circular pattern of 2 about the centre of your part. This will keep the treads as RH.

[mikahb]

Thanks @John_Wright for the thoughts - agreed on all points.

I have years (decades now?) of experience with Inventor, so I just tested in that application and the Mirror feature behaves as expected (threads keep their specification).

I realize that "it behaves this way in another application" isn't a valid argument, but at least makes it clear to me why this surprised me like it did.

(Inventor 2023 screenshots)

[TrippyLighting]

---

@mikahb wrote:

Thanks @John_Wright for the thoughts - agreed on all points.

I have years (decades now?) of experience with Inventor, so I just tested in that application and the Mirror feature behaves as expected (threads keep their specification).

---

What that means is that the developers have implemented functionality that is illogical from a pure geometry standpoint, but very helpful for mechanical engineers. Compared with tools like Autodesk Inventor (which I have very little experience with) or Solid Works (which I have 20+ years of experience with) is Fusion's mirror functionality is not  developed to that point. 

If you model a hole feature with a thread and mirror the timeline feature for the hole, the mirrored thread will be OK. Sometimes that helps! 

[mikahb]

---

@TrippyLighting wrote:

---

[snip]If you model a hole feature with a thread and mirror the timeline feature for the hole, the mirrored thread will be OK. Sometimes that helps! 

---

To be clear, I DID mirror these as (timeline) Features - that's part of why I got surprised.  And, as previously noted, changing Compute Type has no affect - all 3 options give LH threads.

[TrippyLighting]

I cannot reproduce that behavior. When I try it, it works as I described.

Please share your design. 

[mikahb]

Attached.

[TrippyLighting]

The thread handedness of the mirrored threads is correct on my computer. 

[mikahb]

Well that's even more concerning then.  My PC is running Windows 11 and the latest version of Fusion (updated a few days ago I believe).  Not sure what difference would be locally that would affect that behavior.

And to confirm - when you drop views into a drawing and add a callout, you don't get any "LH" in there?  Not sure exactly the mechanism that connects from feature to callout (token presumably) to drawing, but maybe it's in there.

Thanks for taking a look - I wish it worked for me like it does for you!

[John_Wright]

Just done a quick test and I can't get anything but left hand threads from mirrors. Modelled or otherwise.

John

[TrippyLighting]

---

@mikahb wrote:

Well that's even more concerning then.  My PC is running Windows 11 and the latest version of Fusion (updated a few days ago I believe).  Not sure what difference would be locally that would affect that behavior.

And to confirm - when you drop views into a drawing and add a callout, you don't get any "LH" in there?  Not sure exactly the mechanism that connects from feature to callout (token presumably) to drawing, but maybe it's in there.

Thanks for taking a look - I wish it worked for me like it does for you!

---

That "my computer" statement was a joke.

Obviously this doesn't have anything to do with what machine you re running Fusion 360 on 😉

[mikahb]

Ahh sorry - missed the joke.  But is it true that you do NOT see threads flipped from RH to LH when mirroring?

[TrippyLighting]

Ha, the way I modeled it, in the 3D viewport the threads on the top side are right-handed.

The mirrored threads on the bottom visually are also right handed, regardless if I use modeled or cosmetic threads.

However If I create a drawing from that object, the bottom threads are now labeled as left-handed.

[mikahb]

Ahh - the plot thickens!!  Thanks for testing that, I should've taken the time to check what modeled threads look like.

A mismatch between modeled and specified threads makes this feel - to me - like it's definitely a glitch in the matrix and not just a quirky feature.

Really appreciate the time and energy in taking a look -neither of those are free! 🙂

[TrippyLighting]

@ClintBrown3D @Phil.E could you look at this please?

[Phil.E]

Recently discussed, and almost the same discussion entirely. https://forums.autodesk.com/t5/fusion-support/repeatable-bug-joints-connect-to-wrong-points-after-di...

Logged FUS-145172, because the only "bug" I can find is that the model shows RH graphics, when Manufacturing and Drawings both show LH mirrored threads. To be consistent, the model should show LH graphics/physical threads when downstream processes are going to call this out as such.

And yes, there needs to be an improvement to have a tick box for mirroring threads/keep original, so I logged one. FUS-153309

[mikahb]

Thanks Phil for recording these and adding more context from another conversation.

As a long time MCAD guy, it's hard for me to think of a scenario where the expected behavior of mirroring a threaded hole across any plane would be to invert the thread direction.  From that (made up, personal, almost useless :D) perspective, I'd argue that the bug is really the downstream processes reporting a thread direction inversion.

But, as a software person too, I recognize your statement about wherein lies the bug is probably much more rooted in "current state reality" than mine. 🙂

Regardless, happy that these are noted and on useful lists somewhere.  Thanks again for taking a look!

[Phil.E]

Yes, sorry, I did resort to software semantics. I'm a fan of "the bug is where you find it" and yes, in that light it's in the strange drawings callouts and the manufacturing workflows getting confused, because the model "is the model", the single source of truth. The development team can find where the issue lies and work to get a consistent result, one way or the other.

[TrippyLighting]

---

@Phil.E wrote:

Recently discussed, and almost the same discussion entirely. https://forums.autodesk.com/t5/fusion-support/repeatable-bug-joints-connect-to-wrong-points-after-di...

Logged FUS-145172, because the only "bug" I can find is that the model shows RH graphics, when Manufacturing and Drawings both show LH mirrored threads. To be consistent, the model should show LH graphics/physical threads when downstream processes are going to call this out as such.

And yes, there needs to be an improvement to have a tick box for mirroring threads/keep original, so I logged one. FUS-153309

---

Ha, thats' what I thought, but I could  could not remember details. Thanks @Phil.E !

[HughesTooling]

@Phil.E  This thread and the other one linked only dealt with mirroring holes in a body but what about components? If you mirror a component 99.99% of the time you will want the threads the same in both, not reversed in the copy.

Even mirroring a body with threads is only going to be very rarely you would want to end up with a LH thread. So really the default behaviour should be to maintain the source thread's direction. 

This question about mirrored threads has come up quite a few times because of the revered threads, doubt it would have been questioned if the threads where not mirrored. The behaviour now might be correct but it's not what works in the real world.

Mark