stepper precision
-
@fcwilt said in stepper precision:
You FAILED to mention the most IMPORTANT part they provide - a nice little 30 mm Yellow Rubber Duck!
yes, my kids took all four and they love them 
but I was not doing a review of S42B as major part of the review would be how the firmware works, how it can be changed etc etc... none of what I tried out
What does the DIP switch on the board control?
first two are the microstepping selector
third is open loop (off), closed loop (on)
fourth is "enable calibration data write" (on - yes, off -no, basically when off it will not allow you to calibrate)I have 1.0, I see 1.1 is available now but I don't see 1.1 firmware on the github
I'm doing some analysis of the stepping files these days and S42B stepping files just make zero sense, like ZERO sense, something is superbly wrong there, either my reading of the encoder (some crap with profibus) or something else, there's no way s42b can be this bad ... we'r not talking .1degree errors this is serious f*up ... don't have time now to go trough the other files (started with s42b) but I'm sending this encoder to be tested out
-
@alankilian said in stepper precision:
Documents are here: https://github.com/bigtreetech/BIGTREETECH-S42B-V1.0
Thanks - I found them.
Frederick
-
@arhi said in stepper precision:
yes, my kids took all four and they love them Thanks.
The graphs you have generated are very interesting but I have no idea how to interpret them in terms of how printing would be affected.
So I am just going to install them on the printer I use for testing just to see if they impact actual printing - for better or worse.
I have no expectations - I am just curious.
After that I am going to install some of those moderately priced "two piece" setups and see what happens.
I may well end up restoring the printer the way it was before these tests.
But I'm pretty sure I am going to have some fun - even if only with the little ducks.
Frederick
Printers: A FT-5 with the 713 upgrade bits, a custom MarkForged style, a small Utilmaker style, a small CoreXY from kit and a E3D MS/TC setup. Various hotends. Using Duets (2 and 3) running 3.4.6
-
@arhi said in stepper precision:
something is superbly wrong there
The sensor they are using says it can do 0.6-Degree of precision and you've demonstrated results that are close to that. I'm not seeing the problem.
Bigtreetech says this when describing their system: "The closed-loop drive can completely overcome the lost step of the open-loop stepping motor, and can also significantly improve the performance of the motor at high speed."
They make no claim of being able to control the precise stopped-position of a stepper motor to a fraction of a step like you are expecting.
I just think you are trying to use this product in way it is not designed to be used and getting frustrated with it.
-
@alankilian said in stepper precision:
Bigtreetech says this when describing their system: "The closed-loop drive can completely overcome the lost step of the open-loop stepping motor, and can also significantly improve the performance of the motor at high speed."
I will let you all know what, if anything, I discover with my "real world" tests.
There will be no graphs or math.
Frederick
-
@fcwilt said in stepper precision:
install them on the printer
I will be doing the same but not any time soon, some deadlines are ... life ..
I have no expectations - I am just curious.
I do have expectation that I will learn something and that I'll have fun. Fun is here, learning, not so much but weird things happening always at the end of the day make you learn something
-
@alankilian said in stepper precision:
@arhi said in stepper precision:
something is superbly wrong there
The sensor they are using says it can do 0.6-Degree of precision and you've demonstrated results that are close to that. I'm not seeing the problem.
I'm looking at some other data and I'm seeing 10+ degree error .. something is wrong big time just need to figure what pieces (if any) are erroneous and why did I linked them wrong
...example, I have a list of values "stepNo, encoderValue, A, B" where:
stepNo - every time I do 1 step this one increments (so 0 is before we did any stepping)
encoderValue - raw data from encoder
A = encoderValue*360/65535(angle encoder is reading)
B = (360/(200*16))*stepNo + "angleForStep0"("360/200/16 should be angle of a single microstep, I multiply that with how many steps we made and add angle we started at, I assume this is angle we should be at now)but after 80 steps error is more than 2 degrees ... if the movement is that bad this motor would never work on 3d printer so I'm 100% sure something is wrong, just not sure what
... but either the setup or a standard problem between chair and keyboard0 55060.6 302.4615244 302.4615244 1 55061.9 302.4686656 302.5740244 2 55079.1 302.5631495 302.6865244 3 55095.1 302.6510414 302.7990244 4 55113.2 302.7504692 302.9115244 5 55123 302.804303 303.0240244 6 55143.6 302.917464 303.1365244 7 55156.9 302.9905241 303.2490244 8 55175 303.0899519 303.3615244 9 55189.7 303.1707027 303.4740244 10 55205.1 303.2552987 303.5865244 11 55224.6 303.362417 303.6990244 12 55240.1 303.4475624 303.8115244 13 55264 303.578851 303.9240244 14 55285.5 303.6969558 304.0365244 15 55288.5 303.7134356 304.1490244 16 55315.2 303.8601053 304.2615244 17 55319.3 303.8826276 304.3740244 18 55348 304.0402838 304.4865244 19 55351.1 304.0573129 304.5990244 20 55381 304.221561 304.7115244 21 55384.3 304.2396887 304.8240244 22 55407.6 304.3676814 304.9365244 23 55423.9 304.4572213 305.0490244 24 55439.7 304.5440146 305.1615244 25 55454.2 304.6236667 305.2740244 26 55466.4 304.6906844 305.3865244 27 55479.3 304.7615473 305.4990244 28 55495.3 304.8494392 305.6115244 29 55504.7 304.9010758 305.7240244 30 55526.4 305.0202792 305.8365244 31 55538.6 305.0872969 305.9490244 32 55560.7 305.2086976 306.0615244 33 55576.5 305.295491 306.1740244 34 55597.5 305.4108492 306.2865244 35 55618.2 305.5245594 306.3990244 36 55621.9 305.5448844 306.5115244 37 55651.3 305.7063859 306.6240244 38 55653 305.7157244 306.7365244 39 55684.9 305.890959 306.8490244 40 55699.8 305.9728084 306.9615244 41 55701 305.9794003 307.0740244 42 55719.8 306.0826734 307.1865244 43 55737.4 306.1793545 307.2990244 44 55754.3 306.2721904 307.4115244 45 55766.6 306.3397574 307.5240244 46 55781.2 306.4199588 307.6365244 47 55797.2 306.5078508 307.7490244 48 55815.5 306.6083772 307.8615244 49 55828.2 306.6781415 307.9740244 50 55841.6 306.751751 308.0865244 51 55857.4 306.8385443 308.1990244 52 55874.6 306.9330282 308.3115244 53 55889.3 307.0137789 308.4240244 54 55919.6 307.1802243 308.5365244 55 55938.1 307.2818494 308.6490244 56 55941 307.2977798 308.7615244 57 55969.5 307.4543374 308.8740244 58 55971 307.4625772 308.9865244 59 56000.2 307.6229801 309.0990244 60 56003.5 307.6411078 309.2115244 -
Thanks for posting the values also with the "```" -code brackets here because there are so many virus for excel so I rather copy and past your plane values in my own program, and tada:
So judjing by the picture I would vote for your 2nd suggestion, that the problem sits somewhere between the chair and computer
(unless of course there was another problem here on my side between my chair and computer )-> Looks like your error is a constant drift "apart" so something e.g. wrong in your calc... OR maybe somthing wrong how you issue the stp/dir/en and how the motor/driver-combo is set up
-
@LB said in stepper precision:
so many virus for excel
no macros in this so should be safe, I normally have that disabled in excel.. I use open/libre office since they came out almost exclusively but when I need graphs with many numbers I run excell as calc is dog slow with those
here are the "safe" files
S42B-ClosedLoop-16mstep-FixedCoupling-3220-3220.csv
S42B-ClosedLoop-16mstep-FixedCoupling-3220-3220.odsSo judjing by the picture I would vote for your 2nd suggestion, that the problem sits somewhere between the chair and computer
(unless of course there was another problem here on my side between my chair and computer )exactly the same as what I got, but if you are using my calculation it's expected
if you used only the same input data (first two columns) and made the calculation yourself and came to the same conclusion...-> Looks like your error is a constant drift "apart" so something e.g. wrong in your calc... OR maybe somthing wrong how you issue the stp/dir/en and how the motor/driver-combo is set up
something is wrong 100% as there's no way something like this would work in a printer with an error like this so ... either "microstepping" of 1/16 that I assumed is wrong (as it's the question of what the darn thing reads, a dip or menu) or my math is wrong or ... no idea at this time
-
This post is deleted! -
I would go with simple first to validate your experiment.
Skip the closed-loop mode completely, set for full steps and do 200 steps and see if you get the same encoder reading.
Do 200 steps, encoder read, 200 steps, encoder read.
If you cannot get the same (+/-2) reading, then there's something to look at.
-
@alankilian said in stepper precision:
Skip the closed-loop mode completely, set for full steps and do 200 steps and see if you get the same encoder reading.
I have the file with "less" steps but I have no clue "how much exactly" as source and documentation does not coincide so probably 1/4 steps
S42B does not support full step
so I'll concentrate on TMC2088 driver as this one is just too ...
-
raw data that "should" make sense
-
something is wrong in my math here... look how straight these two lines are only different angle .. maybe it should be /65536 not /65535
-
Yes, the encoder counts 65536 steps per revolution.
-
damn
now they align
error is rather big still but.. at least not as messed up as with /65535
-
@arhi That's a Moire pattern (beat pattern) between the stepper steps and the encoder steps. When both have fixed integer resolution, and they are incommensurate, you will see something like this.
-
@mendenmh isn't moire supposed to be much more subtle, these are rather large values ?! I originally assumed that pattern like this will have bottoms (less error) at full/half ste positions but since this is halfstepping already all positions should be at full/half step... and the whole graph is ~250 steps so tad more then half of full rotation it makes me wonder. Also, one step is 0.9 ° (halfstepping a 200 step/rev motor), 0.2 ° error here is imho huge and the peaks at over 0.4 ° are innecceptable. I believe there's some offset here when the motor "started moving" so between the reset, not started stepping and first step, see that jump from 0 to 0.25 - I think there's a 0.12 ° offset from somewhere, I might ignore first few steps and regraph from there as it's impossible to have error that is that much offsetted to either side, if the error is only on one side of zero there's a problem in setup IMHO and I'm not using ABS() here
-
@arhi There's no particulars limit to the amplitude of a Moire pattern. You can get 100% modulation. Usually, when talking about the surface of a 3d print, it is subtle because it is heavily attenuated by things like the frequency response of the filament flow. Reading an encoder, with an offset between steps and encoder period, has no such limits.
-
@arhi
As you already pointed out yourself: if you shift the offset on the left to 0 in the middle of the "wave", then you have only +-0.1 which would be not that much for a 1.8° Stepper?
