Insert Fasteners Failed on Nuts: Failed to read thread data.

[alesser]

Has anyone else ever run into this issue ?  I've used fusion to insert screw fasteners before without problems, but i've never tried to use it to insert a hex nut until today.  When I tried, no matter which nut variation I tried, I kept getting refused with "Failed to read thread data" error as shown here.  It just refuses to work at all.  Anyone got any advice for why this might be/how one can fix this ?

Update a couple hours later:

After totally blowing away everything in fusion Application Support and reinstalling (cache reset and utility reset did not help).. it does seem to work again, but re-installing the useful ThreadKeeper add in seems to break this for reasons I cannot understand.  It does seem to be specific to that add in.. but if I replicate the add-in's actions manually (copying thread files over) it does seem to work fine.  It seems more investigation is necessary about precisely what is happening here.. but it would appear there may be a bizzare ThreadKeeper conflict with loading thread data. 

I suspect ThreadKeeper may be loading corrupted thread data in somehow that is causing fusion to choke when calling the insert fasteners function, but I cannot quite tell how yet.

I should note that none of this hackery would be necessary if Fusion360 properly supported storing and restoring custom thread definitions instead of blowing them away on every update, which is super-frustrating.  Perhaps implementing that would remove the need for add-ons that break things inadvertently....

[Roman_Vesely]

Hi alesser,

you have to contact owner / creator of ThreadKeeper add-in to resolve this issue. Without this add-in Insert Fasteners work fine without any problems.

Regards

 Roman

[MRWakefield]

Before your post update I did wonder at first whether this was something to do with custom threads but I just dismissed it as unlikely.

Anyway...That’s odd about ThreadKeeper. I wouldn’t have thought it would do anything beyond checking for a folder change when Fusion starts, then if necessary, copying the custom thread files to the new location. I would usually highly recommend it as it just seems to work. I've not experienced your issue but then again, I've not been doing much Fusioning recently.

---

I should note that none of this hackery would be necessary if Fusion360 properly supported storing and restoring custom thread definitions instead of blowing them away on every update, which is super-frustrating.  Perhaps implementing that would remove the need for add-ons that break things inadvertently....

---

I agree — this has come up several times before. My custom threads app (linked in my signature) can copy your custom thread files to the current Fusion ThreadData folder, saving you from manually navigating there to do it yourself. It’s not as hands-off as ThreadKeeper, but I’ve never had any problems with it.

That said, the app does include an option to automatically detect a Fusion folder change, though I don’t recommend enabling it — it can get confused if it’s running during a Fusion update. When triggered manually, however, it has always worked fine for me.

It would be interesting to find out whether you find a solution.