Ok, now I was able to recreate it, and the first problem is because you are using imperial units, and I had a stupid bug.
The second problem is due to a rounding problem that I need to think through how to fix. It’s caused by switching back and forth from calculations within Fusion360 and within the plugin. I need to do all of the calculations in F360, but that’s giving me even stranger results.
Here is a bugfix for the imperial units issue. I’m still trying to figure out how to resolve the second issue.
0.51.001 is working the best to date, give me time, I’ll find something. 
And here’s another bugfix that tries to minimize the chance of the rounding error that leaves the little sliver of material in the cuts.
I don’t think I can completely eliminate the possibility of that error occurring, but this version tries to set some more sensible defaults (depending on the units of measure) that should prevent it occurring; although, if you really want to, you can force the error.
And, yet another fix, to fix a couple of bugs I created with the switch to using F360 for the majority of the calculations.
Well, phooey.
One of my plans for keeping myself occupied while recovering from ankle surgery (again) was to learn F360 in time to help @markevans36301 find more ways to break your plugin. 
I’ve been going through @Secret_Sauce’s Fusion360 tutorials, and was all excited to get started, but my Mac App Store version of F360 kept yelling at me about not being supported any more, and I figured, heck, I’ve got plenty of time right now, might as well install the supported version…so of course now that I’ve wiped out the version that worked, the new one refuses to install, and I’ve got nothing to play with. sigh
I’ve posted on their support forum and am awaiting help…I hope it’s as responsive as ours!
I’ve had that problem before too. I had to completely delete the “~/Library/Application Support/Autodesk” folder from my user directory in order to reinstall the download version of Fusion 360.
Ohmygoodness, that did it! I had even downloaded and used their automatic deinstaller thingy to make sure I had deleted everything that needed deleting. Yay!!!
May be litteraly comparing apples to PCs but when I had F360 jam up cleaning every sign of it off and doing a clean install fixed it.
Yep, that’s what fixed it. Supposedly their “cleaner” app does that for you, but it didn’t!
@geek2nurse, so glad you got it fixed. That was FAST! Had you not already fixed it, I would have sent you instructions on what to do. Glad our Glowforge members are on top of things and respond even faster than I do.
TabGen v0.53-alpha is up, with a few bug fixes.
TabGen v0.54-alpha fixs the ability to select a secondary face of a different length. The fingers that are created on the primary face will be copied to the secondary, but no fingers will be created or removed on that secondary face. See below for a couple of example screenshots.
One more update here for TabGen v0.55-alpha which adds initial support for defining the number of fingers to place on the face. In this case, the finger sizes will be calculated automatically. This has not been tested as much as the other two–automatic and constant width–finger types.
This will be the last update for at least the next week or so.
Love the plugin, but ran into a pretty nasty bug when working on a box. I’m not really sure what causes it, but here are the steps that reproduce it every time for me (v0.55).
Create a sketch on the x-z plane (top-down).
Make a rectangle with dimensions 4.855in, 5.56in
Add 2 right angle lines contained within the rectangle as if you were making the two walls of a box.
Give them distance of .25in from the sides of the rectangle (e.g. 1/4in material thickness).
Extrude one, then the other 5.56in creating 2 new bodies.
Hide one of the bodies, when attempting to use the plugin to make a finger joint on the vertical edge it will error “Error configuring parameter: body_1_1_default_width – abs(0.125in)”. With a traceback saying it failed creating a coincident constraint.
Thanks for the awesome bug report. I was able to track this down quickly. I’ll try to get a fix out later this evening.
Can confirm that it fixes the problem. Thanks for the all the work on the plugin.
Okay… put the TabGen-055-alpha-fix-1 into real use for the latest project.
Big time savings. 
One thing that I might have been doing wrong, (or I’m not sure how it’s supposed to work with a parametric change), is that after I changed some of the starting parameters for the box size, the tabs didn’t update automatically in the final model.
Are they supposed to? (If not, that’s fine. I just need to make sure I understand what parameters are being impacted. Oh, and I did not have the Disable Parametric box checked when I did it.)
Screen shots:
Well, heck. Now it’s updating them. Swear to God, I had to re-create two of them this morning…now it’s working fine. 
I’ll see if I can duplicate it…maybe it was the order things were created before.
Okay…there it went… apparently shrinking a parameter is okay…expanding it is not.
Original:
Tabs created and cut out.
Parameter change - reduced width - everything still okay - tabs recalculated.
Parameter change - expanded depth measurement. Tabs did not recalculate, and slots popped up.
If it’s not supposed to be used that way just let me know. I wasn’t sure if anyone else was trying to test parametric boxes.
Interesting. I’ll have to do some more testing. Usually, the exact opposite has happened to me; increasing parameters is more reliable than shrinking them. There are quite a few scenarios where the parameter values end up to small and things get funny; and, I haven’t figured out how to protect against them all in a predictable way.
