Gears STL files have a wrong scale? - V2.3

[GregLukosek]

Noticed 2.3 allGears.stl are too big. causing the excesive loose between gear and a m8 nut.
Video illustrating the issue https://www.dropbox.com/s/prcmcj2ue2snl6q/File_000.mov?dl=0

2.3 version have about 13.6mm nut space
2.0 version have about 13.3mm nut diameter

Both 2.3 and 2.0 are too big. M8 nut is about 12.9mm.
http://imgur.com/DZFrtAF

[DKfraDK]

@GregLukosek did you solve this?

[kaiwety789]

Leave a comment

[kaiwety789]

Comment on issue

[kaiwety789]

Desktop version

[p2baron]

Also the hole for the stepper shafts is too big.
I notices that the holes for the M8 nuts and stepper shafts are only incorrect on the four bigger gears. The smaller ones are OK.

Is this fixed in the development repo?

[lasicmk2]

have you checked printer calibration?
I hot the same issue but after checking all steps/mm everything is fine

[p2baron]

Yes the printer was fully calibrated. (i3 mkII)
Solved this by editing the configuration for the Openscad model. l've decreased tolerances for the nuts, bearings and smoothrods. Now everything has a tight fit.

[JohanBraeken]

I was bitten by this issue as well and believe, the tolerance for the nuts and bolts should be "0" and not "screwHoleTolerance". This is done correctly for the Z-Carriage (Small gears), but not for the X/Y carriages. (Big gears.)
I believe pull request #55 should be reverted as it is the complete opposite. (58bdfc8)

The reason is that the nut/bolt sizes that are used, are looked up in the "nuts_and_bolts.scad"-libary. If you follow the references there, you'll notice the sizes are already the maximum allowed according to the specifications for nuts/bolts.
By adding an extra tolerance, you will always end up with a generated design (STL file) that is too large to fit a bolt/nut snugly.
(If using tolerances, they should be negative.)

[farhan711]

Sorry for interruption but might this information i should share with u all i hope it might help
Let me sum it up:
There are several steps in the toolchain that could theoretically cause a shrinkage of holes:

1. CAD: Exporting to STLs (Low resolution reduces inner diameters if no compensation takes place)
   This is known to be an issue, nophead has put quite some time into investigating it. If this is your problem, you can simply fix it by exporting the model with a higher angular resolution.
2. Slic3r: Wrong toolpath
3. Printing: Shrinkage due to the way the plastic is deposited

IMHO If the assumption for the correct toolpath (2) is any good, then printing a high resolution STL file should result in a dimensionally accurate object. To my experience this is NOT the case. Therefore I would challenge the current assumption for the creation of the toolpath. (AFAIK this toolpath simply traces the outlines of the 3d model?)

Solutions:

1. "Change the CAD Model":
   It is often suggested to change the model, i.e. the inner diameters of holes, to compensate the shrinkage. This is a workaround, which might be ok for very simple CAD models, for more complex projects it becomes a nightmare. From the professional mechanical engineering viewpoint this is just wrong.
   In the CAD stage you define functionality: can a part rotate around another, how much resistance is there to the rotation, etc. You chose nominal sizes and tolerances so they result in the correct fit for the application: Is the bolt in the hole a snug fit, can it be slid in and out, or is it a loose fit with some play. The CAD-Model reflects the functionality though the chosen dimension and the tolerances of paired parts. Manufacturing has then to respect those.

The printed object should have the exact dimensions of the CAD model/STL file. To my and others experience this is currently not the case for vertical holes.
2. "Toolpath Compensation"
For concave toolpaths the extruded plastic seems to be squished more towards the inner radius. The effect becomes obvious in vertical holes where the diameter shrinks. As this is a phenomenon specific to the FDM method, the solution should be implemented in the tool that creates the specific machine code (Slic3r). Maybe the effect could be compensated by moving the toolpath depending on local curvature and extrusion width.

[JohanBraeken]

Hi Farhan771,

I agree with all you are saying. The holes are actualy too large and not shrunk. :-)

I do believe that for this use case, the play between the bolt and the printed gear should be minimised in order to have good accurancy when using Cyclone.

I think in this case "Change the CAD model" is a good solution as the issue is not caused by effects in the toolpath or printing process, but by wrong dimensions used to generate the model that should fit an M8 bolt.

The library used to generate the holes and hexagonalshapes for the bolts already uses tolerances and by changing this tolerance in Cyclone, the generated model is outside of tolerances and too large to fit a bolt snugly.

Let me explain in detail:

The bolts in question are M8 bolts and these are standardised.
The hexagonal shape for such a bolt is suposed to be 15mm from corner to opposite corner and if the generated model is (more or less) like that, you can say it is according to the specs for M8 bolts.
(See http://www.roymech.co.uk/Useful_Tables/Screws/Hex_Screws.htm)

By default, the Nuts and Bolts library, used by Cyclone, generates the hexagonal shape by creating a cylinder with $fn=6 with the correct diameter for the bolt (+ a neglegible tolerance of 0.001mm added to the radius if no tolerance is set).

The smaller (perfectly working) gears are generated for the Z-axis in Cyclone with a hardcoded tolerance of "0", resulting in an accurate part.
So far, so good.

However, for larger gears (used in the X and Y-axis) instead of doing it like for the Z-axis, the Cyclone openscad code uses a tolerance of (standard) 0.4mm.
Because the "nuts and bolts" code adds this tolerance to the radius, the result is that twice this tolerance (0.8mm) is added to the diameter of the generated cylinder.

By adding this tolerance, the generated hexagonal shape to hold the bolt is 15.8mm instead of 15.0mm which is larger than it is suposed to be for an M8 bolt and therefor such bolts will never fit snugly and will always have some play.

I did notice the extra play when trying to fit the bolt. I measured that my printed result was too large, but verified by measuring directly on high resolution STL- files. That is how I discovered the generated design was not according to standard M-bolt sizes and the code contained an error.

So changing the code to omit this extra tolerance as already done for the Z-axis is not a workaround, it is fixing a bug. ;-)

[Cuningan]

Hello I have the same issue, but not only on big gears, all the m3 nuts holes are much more bigger than the nut and gears axis are bigger than motor axis leading to loosen fit.
Only Z gears are OK.

[scottsask]

I struggled for a long time with the same issue, just found this thread after finally sorting it out.

I also had to set the tolerance to 0 to have the gears snugly fit over the stepper shafts.

My printer is calibrated, it's definitely this tolerance value. Hopefully anyone else who is starting a Cyclone CNC project finds this -- the tolerances are in the config.h file.

[CarlosGS]

I'm so sorry for this issue, when first designing the parts my printers did not have proper calibration and quality was very low. Hence it was necessary to have large tolerances, and the gears did fit OK.

If somebody has the time, please share the corrected STLs. You can create a pull request that updates the problematic STLs and maybe fixing the "double tolerance" issue in the source code for the gears (kindly pointed out by @JohanBraeken). Thank you in advance.

[CarlosGS]

By the way you can check out as well this nice fork by Engineer2designer:
http://engineer2designer.blogspot.com.es/2017/02/cyclone-pcb-factory-thingiverse.html
It is likely the tolerances have been fixed by our friend! :)

[scorpion83]

I really like the design of this project and a lot of thought went into it but now that I have finished printing all the parts, I'm extremely disappointed how loose some of the pieces fit due to incorrect tolerances. I was just bit by this tolerance issue! @CarlosGS you should update the files here on github with the correct versions so others like myself don't waste a whole weekend printing and a spool of plastic to find out the whole thing needs to be re-printed. If you don't have the time to update the files with the correct tolerances then I suggest you put in big bold writing that there is an issue with the files so others don't waste their time and money like me and I'm sure many others have

[CarlosGS]

Sorry for the inconvenience. I've just added a warning in the front readme pointing to this thread.

There are many possible combinations of 3D printers and slicing software, so it is very difficult to provide one single set of STLs that works properly for everybody without requiring some sort of tuning.

Since I do not need to print these parts again, I would appreciate if someone can create a pull request that updates the tolerances in the STLs.

[JohanBraeken]

Carlos, I don't completely agree with your view on STLs. For me, the STL's should always have the correct (desired) value. This is how it "should" be, the design, the reference. It is up to the person printing the part to make sure the printer is calibrated correctly, or to play with slicer settings to off-set potential shrinkage of material. (This actually depends more on the filament/material being used, and not on the printer.) I know it is an easy solution to change the STL. However, as I see it, you should never fiddle with STL dimensions for issues that are caused by sub-optimal slicer settings or an un-calibrated printer setup. I strongly believe issues should be resolved where they are occurring, and not hidden by compensating for them elsewhere. Best regards, Johan. P.S. I'll try to do a pull request. This could take up to a few days due to other commitments. Citeren Carlos Garcia Saura <notifications@github.com>:

Sorry for the inconvenience. I've just added a warning in the front readme pointing to this thread. There are many possible combinations of 3D printers and slicing software, so it is very difficult to provide one single set of STLs that works properly for everybody without requiring some sort of tuning. Since I do not need to print these parts again, I would appreciate if someone can create a pull request that updates the tolerances in the STLs. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub[1], or mute the thread[2].  

Links: ------ [1] #57 (comment) [2] https://github.com/notifications/unsubscribe-auth/AFYrcMNA9kMItjiaTQo01Yxsc9y8tUOAks5sa1AhgaJpZM4ITbXx

[CarlosGS]

Thanks for your comments Johan.

You are right, for some reason I had a misconception regarding printing tolerances. I think it may be related to having learned CAD/printing at a time where slicing software was in very early stages and difficult to configure.

Now I see that the scad code could have been much more simple by removing the (redundant) code lines that account for tolerances.

Regards,
Carlos

[CarlosGS]

Thanks to @JohanBraeken and Martin Prochnow (@mprochnow) this issue is now solved.

The other STLs still have many unnecessary tolerances, but the gears must have been the most annoying for sure.
Again, I'm very sorry for the issues caused by my mistaken understanding of tolerances in 3D design.