-
Notifications
You must be signed in to change notification settings - Fork 151
$slop used incorrectly for threading and screws, or $slop doesn't work at small scales #1679
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
That $slop value of 0.22 is huge. I have used 0.05 on my Prusa mk3s. And with the screws in screws.scad, they already have clearance created by the screw tolerances. Whether the slop tester correctly predicts the slop, well, that I don't know. It could be that at different sized holes, and especially for small circles, the printer's over-extrusion is not the consistent. However, when I printed the slop tester, it clearly indicates that 0.05 is where I get a slip fit. At 0.2 it's a very sloppy, loose, fit. It does appear that the slop tester isn't consistent with how screw sizing is done, because if I'm reading the code right, it creates a 2*slop adjustment to the hole width where as the screws code does it to the radius. |
I think so. I'm going to make something to measure this on my printer and share it soon.
The slop tester is a square and not a circle, which might also make it worse. |
Maybe @revarbat can comment on this, since he's the one who designed the What do you mean about "how it affects the call to threaded_rod"? All the threaded_rod calls apply There's the other question which is: is your printer really so bad that you get a snug fit on the tester with |
Uh, right, I forgot. So non-threaded measurements -- clearance/tap holes and shanks, shoulders, and heads -- use I would think they should be the same if you were, as in my case, intending to use a metal machined screw with fairly tight tolerances; but with your low slop value it may not have been noticeable.
My flow rate is a bit higher than normal (1.045), but it's what was best using the top surface calibration with Orca Slicer. I also inadvertently printed the slop test with random seams which may have added excessive slop; I'm going to reprint and will update and document. Even so, I updated my chart in the first post. With I'm also going to print the following to try to fit a curve to model hole size => actual hole size and whether it is dependent on hole diameter and/or orientation.
|
Look more carefully: threading.scad sets the RADIUS to use |
In general, you look at the cross section of the object you want to insert into another, and use one $slop for each place they would touch along a given axis. That should give a snug fitting. If you need a loose fitting, you add 2*$slop instead. Since screws need to rotate within their threaded hole counterpart, the diameter of said threaded hole gets adjusted by 4*$slop. That's the theory, at least. This seemed to work for the large parts of my printable printer (30mm 8pitch), but I never tried to make small (3mm) threaded holes. I always assumed that was beyond the resolution of my printer. |
What does "snug" mean? I could probably force the test piece together with $slop=0, but I wouldn't be able to get it apart again without a hammer. At 0.05 it slides together easily with no play. A clearance hole for a screw, if it is to receive a metal screw, would presumably need only two $slop factors, because the metal screws is presumably not oversized. You'd only need the full four factors if you wanted to mate a printed screw with a printed hole. But also, in the case of screws, the objects themselves have built-in clearance. It's not like trying to fit a 5mm object in a 5mm hole. |
DataHere are my modeled and measured dimensions with
InterpretationsAbove a certain diameter (~8mm), ID and OD of cylinders/holes shrink a fixed amount (0.2mm). A fixed As diameter shrinks, the ID continues to be a fixed amount smaller, but the OD becomes accurate. As diameter shrinks further, vertical holes go non-linear and collapse (polyholes documents why; I could retry the print after enabling polyholes). Horizontal holes eventually stabilize at an accurate ID (~2mm) down as small as I could see. ConclusionsIt seems |
Your last guess was correct, my corners have significant overshoot like this person. Looking at my collected data, for a 14.4mm round hole my
D'oh. I get it now.
I see, polyholes and horiholes. So the size and shape of every hole is dependent on diameter, orientation, nozzle width, and layer height. Whew!
I'm sorry, I don't follow why rotating implies an additional doubling.
I think this makes sense with the data I collected. |
I wonder if the slop tester should be modified to have rounded corners on the plug portion. Yeah, polyholes and horiholes are complicated, and don't seem to be generally accepted practice. It seems like some of what horiholes is supposed to accomplish is done by creating a small corner on the bottom of your horizontal hole. (The hole needs to be teardrop shaped to be printable.) And I also found polyholes uncompelling because for all of the fancy theory behind them, it didn't actually work on my printer. Also you are getting undersized cylinders. My slop tester is measuring about 10.03mm x 10.00mm, so I'm not seeing that undersizing that you are. For larger objects you are getting the same size for both holes and cylinders. Is this due to PET shrinkage? My print is in PLA. I have no clue how different materials may vary with respect to printing accuracy. We haven't yet heard from @revarbat about what a "snug" fit is. If a snug fit means that you can insert the part while encountering a small but nonzero resistance then that would be too tight for screws. Rotating means loose enough to move freely. But the whole screw business is complicated by the existence of a separate tolerance system for screws. You only need screw related parts to print at their exact modeled size, not to print with extra clearance, because clearance is built in already. There's also the issue of mixed materials that I previously noted, where a clearance hole gets Another point: if you get a snug fit at If you would like the either submit updates to the documentation, or perhaps an updated slop test fixture, I would welcome either one. But it does seem important to clearly identify the story here, as it's not clear that your printing experience matches mine. Perhaps you avoid absolute statements about the behavior of holes---maybe other printers are different than yours---but draw attention to the possibility that things could get messy when the holes are small. Does material make a significant difference? Might be interesting to include a test fixture for vertical and horizontal holes that people could test with drill bits---probably would need a metric and USA version. Also holes should use |
The term "snug" is for this purpose defined as "As snug as the fit of the plug in your $slop test print when you have it inserted into the hole corresponding to your chosen $slop value." ie: it should be insertable without applying high pressure, and it should be removable without breaking. |
But "snug" is tighter than desired for screws? |
The theory is that the screw hole should be increased by 2*$slop for BOTH sides, as that will make it loose enough that you can screw in your screw without breaking your screw head off along a layer. (Assuming both a printed screw and screwhole.) |
The concept of making a hole with plastic that can be screwed into with a metal bolt, having its threads biting into the plastic, is not (AFAIK) addressed by $slop, or by tolerances in the threading library at all. |
I have no idea about smaller parts, but the 4x was what worked for making my 30mm diameter 8mm pitch lifter rods in my printable printer. |
What was your $slop value? Was it as large as 0.2? |
My $slop value for the printer I had at the time, was exactly 0.2. |
I thought he was mostly interested in clearance holes. But yes, this issue is addressed by an ad-hoc adjustment to the hole size. so the one exception to the case of exact sizing with tolerances. |
Suppose you had a printer that had horrible but very accurate over-extrusion so every hole was 1mm undersized. The slop tester would tell you you needed 0.5mm of adjustment for a snug fit where it applies double the slop. But four times that slop value---2mm---for a sliding fit is going to be ridiculous. For a sliding fit you need something like .6mm of adjustment. The extra amount needed is not proportional to the error due to overextrusion. It's additive. |
I was considering whether we could calculate a slop based on hole size, but I believe over-extrusion on small holes will be a combination of hole vertex count, extrusion rate, print controller speed, and GCode queue saturation / print stutter. Basically, I think it's too complex to make a simple correction for this. |
That's exactly what I'll make a PR for.
I think vertical cylinders are expected to be undersized unless using slicer compensation (I'm not). The cubic slop tester plug I printed measures 14.94 x 14.94mm on the flats using my cheap digital calipers. I haven't calibrated for shrinkage, but I read PETG is about the lowest.
I have both clearance and "self tap" holes for my
Agreed. There's no simple adjustment or single additional parameter that can make small holes usefully more accurate. The print-then-adjust loop is much better than complicating the code, I'll just document this. |
Why are vertical cylinders expected to be undersized? And why wouldn't I expect the slicer to do what's needed to produce the most accurate possible result? My tests was with the out-of-the-box slicer settings, and the error is <0.03mm. |
@coryrc Do we need to keep this issue open? |
Up to you, I still plan to make the changes. Here's my updates so far:
Because I planned to incorporate any decision into my PR.
Without working arc compensation you would expect them to be slightly undersized and I haven't done anything to ensure they are correct -- there's also Arachne and inner/outer order and more that can affect final dimensions. But we're also talking about 0.2mm when line width is over 0.4mm. Are your cylinders exactly as correct as the cube you mentioned?
|
I didn't directly address this before. The purpose of |
I printed an M7 buttress screw and nut to meet actual standards diameter for "standard" tolerance as if The screw works; being buttress thread and riding on flat surface, the layer line transitions can be felt, but it does work just fine as a bolt and nut. I think [0] I printed by my M7 buttress screw and nut with |
Incorporating findings from Issue BelfrySCAD#1679 Describing why based on the diff on my screen, starting top to bottom: Removing XY vs Z axis, because the printing direction isn't known for the parts. Even precise CNC machining still has tolerances and I tried to write a simple way of passing that along. Adding the limitations we talked about in issue BelfrySCAD#1679. Added some more written examples of where slop should be added. Now that I'm writing this, these would be better as an example. I can't add a new line to the first "Calibration" line because that'll make a new number. I thought this was good info to add though. Moved caveat to Limitations section. Added line about filleting/chamfers now that I made the tester cut off corners, so you can test both ways. Also fix a typo later in doc
Per [my argument](BelfrySCAD#1679 (comment)), I believe this is the proper method. There is only one mating surface for each radius, so by following the documentation for `$slop`, we should only be adding one `$slop` for radius and not two.
Incorporating findings from Issue BelfrySCAD#1679 Describing why based on the diff on my screen, starting top to bottom: Removing XY vs Z axis, because the printing direction isn't known for the parts. Even precise CNC machining still has tolerances and I tried to write a simple way of passing that along. Adding the limitations we talked about in issue BelfrySCAD#1679. Added some more written examples of where slop should be added. Now that I'm writing this, these would be better as an example. I can't add a new line to the first "Calibration" line because that'll make a new number. I thought this was good info to add though. Moved caveat to Limitations section. Added line about filleting/chamfers now that I made the tester cut off corners, so you can test both ways. Also fix a typo later in doc
Per [my argument](BelfrySCAD#1679 (comment)), I believe this is the proper method. There is only one mating surface for each radius, so by following the documentation for `$slop`, we should only be adding one `$slop` for radius and not two.
Per [my argument](BelfrySCAD#1679 (comment)), I believe this is the proper method. There is only one mating surface for each radius, so by following the documentation for `$slop`, we should only be adding one `$slop` for radius and not two.
No, "When making your own parts, you should add $slop to both sides of a hole that another part is to fit snugly into. For a loose fit, add 2*$slop to each side." If I had to guess I'd say lots of people probably fiddle with $slop until the model fit is good. And changing it now from 4 slops to 2 slops is going to break everybody's code, so that's a concern. |
As I noted above, I printed my M7 nut with normal tolerance (0.8mm increased ID) and it worked fine with
I don't understand -- if you took a bolt in a nut and sliced it through top and bottom, you could draw a single path up each side, so there's only one mating surface per radius and two mating surfaces per diameter.
I thought you were making the argument that is the wrong thing to do? I was persuaded.
That's true, but as the main page says it's still beta code, I think it would be worth it to fix now if it's decided it's wrong. |
It seems easy to get confused here about the nomenclature. It doesn't really make sense to talk about surfaces "per radius" or "per diameter". If you look at a cross section of a cylinder fit into a hole there are four surfaces that mate, two on the inner cylinder and two on the hole. Yes, I did make an argument that Revar's strategy is wrong, because it should be We are trying not to break things too much if we can avoid it right now, and since the screws stuff is about 3 years old and a lot of people use BOSL2 just for the screws, I think it's a significant concern to break all outstanding code. |
In almost all cases |
I would argue that a too-loose result doesn't really count as "working". I'm not sure what your point is, though---that it's OK to break all existing code because overly tight threads are easy to detect? Are you imagining that all the extant code features threads that are too loose and this will be improved by reducing the 4 to 2? When I printed threads I selected $slop by testing MY THREADS not using the slop tester, and I would imagine that others have done that as well. |
Ideally I should be able to calibrate a For the following model and all the threaded rods and nuts should mate with each other with the same overlap and the cubes should fit snugly in each other's sockets, even for widely-varying slop values. For example, issue #1485 shows 0.0, 0.10, and 0.15 for slop values for 3 filaments on the same printer; the bolts are all going to be looser in the third nut than the first nut, but with
This doesn't work if the reason for slop is due to oversized plug parts or if the holes are too small (as documented in this issue and in #1699 ).
You shouldn't have to do that, and I think you wouldn't, except for the documented caveats, if we fixed this now. |
For anybody who blindly followed the
It's possible for you and me and others to be broken -- this is a breaking change. At the very least screws will be tighter than before, some to the point they may not work. But if we don't expect a global |
This is Revar's infrastructure, not mine. As I've noted, the notion that you get a snug fit at It seems to me that the real way to handle printer overextrusion is in the slicer, not in the CAD model. And if the goal is to just manage overextrusion, then the correct setting would be when the hole is exactly 1 cm wide. That seems to happen for me with $slop=0 in the Y direction, but my hole is slightly undersized by 0.04 in the X direction, at least on my old slop tester print. A reason to have $slop as a global $variable independent of universality is that you can adjust screws (or other things) that are 12 levels deep in your model. Otherwise you have to explicitly propagate that information all the way down through the hierarchy. In fact, I've been pondering the user of teardrop for screw holes and how I need to introduce $ variables to give more control over them. The old slop tester gives me a slip fit at 0.05 with very little play. It took me a while of fiddling to realize that the play was not zero. I do usually start with $slop set around 0.05. My expectation is that if I cut the slop values in half for screws like you are effectively suggesting, none of my test cases are going to go together at all. I took my diamond threading example from the docs, which has a slop value of 0.075 and divided it in half and printed it. The resulting model is totally unusable---too tight for the nuts to engage at all. The jammed and immediately and I can't get them to advance or come off (without tools). This is the likely result of the change you are proposing: a bunch of working models are going to be rendered unusable. Since I had 0.05 from the old one it seemed like I didn't really know the right slop value, so I printed it in 0.01 increments. Note that to include a cylinder version you should have a global variable that controls it, not tell the user to comment and uncomment code. With the new rectangular tester I found a $slop value from that test of 0.01. However...the male end of the slop tester is undersized, being 9.92 mm x 9.97 mm. My old one is 9.98 mm x 10.03 mm. If I insert my old one it fits snugly but without a struggle into the 0.03 hole on the new tester. |
It's not just over-extrusion that slop was for. Some printers are inexact at layer-to-layer alignment, too. The way slop was derived goes something like this:
At no point did I ever really analyze why slop was needed, or if the size of the hole affected the slop needed. I just experimentally found that for what I was doing, I had to add slop to make parts fit. |
It should be. If I made it out of metal, it probably would not work either. The design is bad because Another problem is So is If it's the latter, the former still seems like something you would want to have, for reasons including making parts which mate with precision metal parts and work with parts printed across printers. And for the purposes of the latter, is |
Uh oh!
There was an error while loading. Please reload this page.
Describe the bug
Following the $slop calibration does not result in properly-sized holes for
#6-32
holes orM7
nuts.I have a Bambu A1 Mini, using PETG, and am printing some self-tap and clearance holes for
#6-32
screws. I have the following diameters:In both cases, the calibrated
$slop
value resulted in holes far too big.Yesterday I printed the slop tester and calculated 0.22 for slop. Using the raw threading.scad and with a printed M7 buttress thread and
$slop
= 0.22, I created working nut and screws printed vertically. Some numbers from that print:However this just happened to work, because the
tol_gap
for a normal M7 in thescrews.scad
library would be about 0.8, which is passed toscrew()
asshaft_undersize=-0.8
so a normal fit would be 6.33mm innermost diameter and setting$slop = 0.22
coincidentally got a working value. (Thethreading.scad
library does not have any tolerance adjustment besides$slop
). Had I correctly compensated diameter for fit, then the nut would have been far too large.This also resulted in holes too big having followed the calibration procedure and applying it.
Code To Reproduce Bug
Printed in PETG, 0.2mm layer, 0.4mm nozzle.
Expected behavior
Following the documentation at https://github.com/BelfrySCAD/BOSL2/wiki/screws.scad and https://github.com/BelfrySCAD/BOSL2/wiki/threading.scad should yield holes with the intended diameter, or at least warn when the instructions are incorrect for certain edge cases.
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: