S42B Closed loop stepper inaccuracy

[NZ-Nitro]

Well I cant be the only person with this problem. Tried the 1.1 version first then the 2.0 version with exactly the same issue. SETUP SKR1.4 turbo connected using the direct adaptor to the board current 1600 steps 16 once calibrated (if does a full 360 deg turn both ways) if you send a command to the machine of 10mm it moves only around 7.8mm

Machine steps are accurate for an ender 5 plus

if I disconnect the motor and run it with a 2209 drive I get 10mm, change back I get the 7.8mm

My understanding of calibration is first run you turn on sw1 and sw2 plus sw4

when set up for 16 pulses is dip switch 1 on, 2 off 4096

I have tried every combination possible lol

Who else has had this?

[NZ-Nitro]

More testing as I have seen comments about the 5v missing, I am getting 24v and also 3.3 v at the motor so that should be fine

[NZ-Nitro]

Testing cont changing dip sw 3 and 4 makes no change to the length of movement changing #define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 800, 100 } makes no change to the distance

[maracMB]

Same issue here. V1.0

Multiplexing tmc2100 and this s42b. So the input is THE SAME. Tmc2100 moves correctly, s42b does not.

No matter the pins, no matter the 5 or 3.3v, nothing. It just fails to move correctly.

The calibration does rotate 360 degrees tho...

At total loss.

[NZ-Nitro]

https://github.com/bigtreetech/BIGTREETECH-Stepper-Motor-Driver/blob/master/S42B/V2.0/42%20Stepper%20Motor%20Closed%20Loop%20Driver%20Control%20Board%20Manual.pdf Just been sent this by BTT

[NZ-Nitro]

BTT reply to me and my problem

hello Please operate according to the instructions first. And your pulse number setting is wrong. If the default number of pulses per millisecond for the X axis in the firmware is 80 and 16 subdivisions are used, you need to change it to 102.4. Number of pulses per millimeter = one revolution of pulses Number/Length of one circle of machine gear

[maracMB]

yes there is a step/mm correction needed. we get that BTT, yet that's the issue; correcting step/mm is just... weird and wrong. all 1.8° degrees have 200 steps per rotation. it's HARDWARE BASED! "operate according to the instructions first"... :D no comment needed. i won't even sell these, i'll throw them away!

It's not just us two, there are more people, but predominantly, there are users of this that just don't find this weird. "oh i have to correct my steps, ok".. it's not that i have issues with it not knowing how to use it. It is that it does not operate to common sense and in sync with anything we know.

[NZ-Nitro]

I am away from home for a few days, my guess is there are 1000s of these that have been chucked in the bin, a degree is a degree a mm is a mm

[NZ-Nitro]

I will study and test this on Wednesday

[GhostlyCrowd]

I will study and test this on Wednesday

If youre looking to fix any stepping accuracy, this project is working to redo the firmware in its entirety and addfeatures worth checking it out its in early stages https://github.com/CAP1Sup/Intellistep

[maracMB]

@GhostlyCrowd now that looks proper! Thanks. I'll watch that.

[NZ-Nitro]

Yeah I will watch this too, it's a pity BTT has let this one slip

[NZ-Nitro]

102.4 is it coincidental 102.4 = 1024?

[NZ-Nitro]

4, 8, 16, 32, 64, 128, 256, 512, 1024

[NZ-Nitro]

Here is the true calculation for an Ender 5+, so where on earth did BTT get their figure from?

[NZ-Nitro]

I think I am onto something? 1024, 2048, 4096, 8192 are their micro steps as listed in the manual, this does not corelate to real world settings like I listed above

[NZ-Nitro]

And if we use their setting..............................

[maracMB]

@NZ-Nitro so they got the stepper pitch wrong? This is easy fix in firmware right?

[NZ-Nitro]

I am not sure, will look tomorrow as im knackered, last two days on a course learning how to relocate venomous snakes, was a lot of fun, lets see what everyone else thinks? all motors should be either .9 or 1.8?

[NZ-Nitro]

Well some success at last I couldnt sleep so went out to test some things, I changed Marlin to #define DEFAULT_AXIS_STEPS_PER_UNIT { 102.4, 102.4, 800, 100 } Uploaded this to the printer and still got my crappy 7.8mm on a 10mm move Decided to check the settings with Pronterface after seeing the popup in Marlin saying "override with M92" well checked and for some strange reason the setting didnt go into the printer!!, put the Gcode in M92 Y 102.4 and hello got my 10mm movement, anybody got some clues about this?

[NZ-Nitro]

Follow up comment from BTT hello Generally speaking, the motherboard firmware is set to 16 subdivisions. If the motor is 1.8 degrees, the number of pulses is 16200=3200. If you use our S42B motor and set 16 subdivisions, our S42B pulse number is 4096, so 4096/3200=1.28. You need to use the original number of pulses per millisecond 1.28 to get the correct number of pulses per millisecond. If S42B is set to 8 subdivisions, our S42B pulse number is 2048, so 2048/3200=0.64. You need to use the original number of pulses per millisecond * 0.64 to get the correct number of pulses per millisecond. Similarly, if 32 subdivision is used, the calculation method is the same as above. Sincerely, BIQU customer service

[CAP1Sup]

@NZ-Nitro I have read all of your comments and BTT really did a horrible job on this firmware. I am in the process of redoing the firmware with actual gcode commands, a whole CAN bus configuration method so you'd only have to connect to one to configure them all, as well as a full menu rewrite and a correction of the stepping algorithm. I hope to support a wide variety of motors and configurations on things like serial baud. Is there anything specific you'd like to see from the rewrite? I'm happy to implement anything that you think might be beneficial.

[TazerReloaded]

Decided to check the settings with Pronterface after seeing the popup in Marlin saying "override with M92" well checked and for some strange reason the setting didnt go into the printer!!, put the Gcode in M92 Y 102.4 and hello got my 10mm movement, anybody got some clues about this?

Marlin saves changed values to EEPROM, which is not overwritten by flashing firmware. So it does not matter what you specify in the firmware config as long as you have the old values in the EEPROM. Still, the steps per mm should not change by switching drivers.

[NZ-Nitro]

Thanks TazerReloaded I only just worked this out after countless hours trying to fix stuff, CAP1Sup I will probably use your firmware, its currently working and printing Pretty poor show by BTT that what I have discovered is not covered on any documents anywhere

[CAP1Sup]

Decided to check the settings with Pronterface after seeing the popup in Marlin saying "override with M92" well checked and for some strange reason the setting didnt go into the printer!!, put the Gcode in M92 Y 102.4 and hello got my 10mm movement, anybody got some clues about this?

Marlin saves changed values to EEPROM, which is not overwritten by flashing firmware. So it does not matter what you specify in the firmware config as long as you have the old values in the EEPROM.

Still, the steps per mm should not change by switching drivers.

It can if the microstepping is different I believe.

[maracMB]

Decided to check the settings with Pronterface after seeing the popup in Marlin saying "override with M92" well checked and for some strange reason the setting didnt go into the printer!!, put the Gcode in M92 Y 102.4 and hello got my 10mm movement, anybody got some clues about this?

Marlin saves changed values to EEPROM, which is not overwritten by flashing firmware. So it does not matter what you specify in the firmware config as long as you have the old values in the EEPROM.

Still, the steps per mm should not change by switching drivers.

It can if the microstepping is different I believe.

Sure, it can be, but multiplied 2x, 4x, 1/2x, etc. Not 1.24x 😁

[CAP1Sup]

Decided to check the settings with Pronterface after seeing the popup in Marlin saying "override with M92" well checked and for some strange reason the setting didnt go into the printer!!, put the Gcode in M92 Y 102.4 and hello got my 10mm movement, anybody got some clues about this?

Marlin saves changed values to EEPROM, which is not overwritten by flashing firmware. So it does not matter what you specify in the firmware config as long as you have the old values in the EEPROM.

Still, the steps per mm should not change by switching drivers.

It can if the microstepping is different I believe.

Sure, it can be, but multiplied 2x, 4x, 1/2x, etc. Not 1.24x 😁

Fair enough, you're right. I really don't know why it's different.

[jlmxyz]

Follow up comment from BTT hello Generally speaking, the motherboard firmware is set to 16 subdivisions. If the motor is 1.8 degrees, the number of pulses is 16200=3200. If you use our S42B motor and set 16 subdivisions, our S42B pulse number is 4096, so 4096/3200=1.28. You need to use the original number of pulses per millisecond 1.28 to get the correct number of pulses per millisecond. If S42B is set to 8 subdivisions, our S42B pulse number is 2048, so 2048/3200=0.64. You need to use the original number of pulses per millisecond * 0.64 to get the correct number of pulses per millisecond. Similarly, if 32 subdivision is used, the calculation method is the same as above. Sincerely, BIQU customer service

what the F**K? "16 subdivisions. If the motor is 1.8 degrees, the number of pulses is 16x200=3200" => ok I understand this, 1.8degrees stepper have 200 steps for a turn.... right "16 subdivisions, our S42B pulse number is 4096" => whaaaat? why 4096? why not Pi x AgeOfCaptain/squareroot(2)????? ok, I don't get anything of the rest... if I knew this was sooooo bad, I wouldn't bougth thoses..... too bad the makerbase ones are not supporting 3.3V control power level... I chosen theses because they were 3.3V....

[CAP1Sup]

What an interesting reply @jlmxyz I'm doing a complete rewrite, which I'm going to be finishing soon. I'm hoping to finish over this weekend. My version is not only better commented but it actually make sense. Check it out once you get the chance. The only thing that I need to finish yet to have it basically 100% operation is writing the communication for the encoder and making sure that the stepping method is correct.

[maracMB]

@CAP1Sup is there a way for you to make factored steps? since you're rewriting firmware?... Theory: the s42b is recalculating steps that the mainboard gives it. X number of steps that s42b board has to recalculate either way. Soooo, if s42b firmware would have an option to factor these steps, then one could use one output on the mainboard and drive these motors at virtually different step/mm from a single output of mainboard. It's complicated and at first stupid, but i'll try to explain why this would be god-like to have:

i did an IQEX machine (quad - 4 independant carriages), the logical evolution is to do six... because why not. I now need 15 individual stepper motors. Duet3 is not an option. And using klipper also a no-no. so to achieve that i am expanding duet2+duex5 driver capacity via demultiplexing existing 2 external stepper driver pins. that will give the theoretical 10+10 native steppers PLUS 2x16 multiplexed stepper driver count/stepper driver channels. The demultiplexed steppers will serve as extruder motor drivers. Factored steps on s42b side would enable me to use different extruders and not be bound to same toolheads used at the same time or having to change esteps each time the toolchange happens. For now, i wait your firmware like a godsend because it will give me an option of "forced" enable and thus holding torque on otherwise non-enabled drivers that will enable to use this principle not only for E motors but on Z motors as well...

So, if you could just input a tiny little additional factor for steps that we can then change via gcode.. That would be out-frickin-standing :)

PS: if you want to know more about my IDEX build, later Quad and further stuff about demultiplexing, my FB group is here: https://www.facebook.com/groups/237163797566846

THANK YOU IF YOU CAN IMPLEMENT THIS CRAZY IDEA! ;)

[jlmxyz]

What an interesting reply @jlmxyz I'm doing a complete rewrite, which I'm going to be finishing soon. I'm hoping to finish over this weekend. My version is not only better commented but it actually make sense. Check it out once you get the chance. The only thing that I need to finish yet to have it basically 100% operation is writing the communication for the encoder and making sure that the stepping method is correct.

humm too badly I don't have any hardware to reprogram the chip... I finished to make it work somehow... but compared to the maker base ones I have, they are 10x more noisy in closed loop and 2x more in open loop... and for some reason on closed loop mode, the movement never end (or maybe it ends, but I fear too much for my board to burn that I switch power off)... at the end of movement, the motor behave as if there was something blocking the movement... it make an awfull noise like an oscilation... as if a hammer was hurting a wall at high frequency... so I guess I will drop theses drivers, there is no schematics, noisy, poorly documented...

[CAP1Sup]

@CAP1Sup is there a way for you to make factored steps? since you're rewriting firmware?...

Theory: the s42b is recalculating steps that the mainboard gives it. X number of steps that s42b board has to recalculate either way. Soooo, if s42b firmware would have an option to factor these steps, then one could use one output on the mainboard and drive these motors at virtually different step/mm from a single output of mainboard. It's complicated and at first stupid, but i'll try to explain why this would be god-like to have:

i did an IQEX machine (quad - 4 independant carriages), the logical evolution is to do six... because why not. I now need 15 individual stepper motors. Duet3 is not an option. And using klipper also a no-no. so to achieve that i am expanding duet2+duex5 driver capacity via demultiplexing existing 2 external stepper driver pins. that will give the theoretical 10+10 native steppers PLUS 2x16 multiplexed stepper driver count/stepper driver channels. The demultiplexed steppers will serve as extruder motor drivers. Factored steps on s42b side would enable me to use different extruders and not be bound to same toolheads used at the same time or having to change esteps each time the toolchange happens.

For now, i wait your firmware like a godsend because it will give me an option of "forced" enable and thus holding torque on otherwise non-enabled drivers that will enable to use this principle not only for E motors but on Z motors as well...

So, if you could just input a tiny little additional factor for steps that we can then change via gcode.. That would be out-frickin-standing :)

PS: if you want to know more about my IDEX build, later Quad and further stuff about demultiplexing, my FB group is here: https://www.facebook.com/groups/237163797566846

THANK YOU IF YOU CAN IMPLEMENT THIS CRAZY IDEA! ;)

This actually isn't that hard to implement. I'll have it implemented by tomorrow afternoon. It's actually only like 25 line changes to enable this. All I have to do is add a multiplication factor and an OLED menu. Any specific multiples you want?

[CAP1Sup]

What an interesting reply @jlmxyz I'm doing a complete rewrite, which I'm going to be finishing soon. I'm hoping to finish over this weekend. My version is not only better commented but it actually make sense. Check it out once you get the chance. The only thing that I need to finish yet to have it basically 100% operation is writing the communication for the encoder and making sure that the stepping method is correct.

humm too badly I don't have any hardware to reprogram the chip... I finished to make it work somehow... but compared to the maker base ones I have, they are 10x more noisy in closed loop and 2x more in open loop... and for some reason on closed loop mode, the movement never end (or maybe it ends, but I fear too much for my board to burn that I switch power off)... at the end of movement, the motor behave as if there was something blocking the movement... it make an awfull noise like an oscilation... as if a hammer was hurting a wall at high frequency... so I guess I will drop theses drivers, there is no schematics, noisy, poorly documented...

The programmer is quite cheap. You can get one here. They only cost $10 so I think it's worth it. I'm going to be fixing the programming to hopefully reduce the noise down

[maracMB]

@CAP1Sup is there a way for you to make factored steps? since you're rewriting firmware?...

Theory: the s42b is recalculating steps that the mainboard gives it. X number of steps that s42b board has to recalculate either way. Soooo, if s42b firmware would have an option to factor these steps, then one could use one output on the mainboard and drive these motors at virtually different step/mm from a single output of mainboard. It's complicated and at first stupid, but i'll try to explain why this would be god-like to have:

i did an IQEX machine (quad - 4 independant carriages), the logical evolution is to do six... because why not. I now need 15 individual stepper motors. Duet3 is not an option. And using klipper also a no-no. so to achieve that i am expanding duet2+duex5 driver capacity via demultiplexing existing 2 external stepper driver pins. that will give the theoretical 10+10 native steppers PLUS 2x16 multiplexed stepper driver count/stepper driver channels. The demultiplexed steppers will serve as extruder motor drivers. Factored steps on s42b side would enable me to use different extruders and not be bound to same toolheads used at the same time or having to change esteps each time the toolchange happens.

For now, i wait your firmware like a godsend because it will give me an option of "forced" enable and thus holding torque on otherwise non-enabled drivers that will enable to use this principle not only for E motors but on Z motors as well...

So, if you could just input a tiny little additional factor for steps that we can then change via gcode.. That would be out-frickin-standing :)

PS: if you want to know more about my IDEX build, later Quad and further stuff about demultiplexing, my FB group is here: https://www.facebook.com/groups/237163797566846

THANK YOU IF YOU CAN IMPLEMENT THIS CRAZY IDEA! ;)

This actually isn't that hard to implement. I'll have it implemented by tomorrow afternoon. It's actually only like 25 line changes to enable this. All I have to do is add a multiplication factor and an OLED menu. Any specific multiples you want?

Omg! Yesss!

Well the multiple would need to be a variable (So that's couple of lines more...)... But one would set it via gcode like M93 F1.34

[CAP1Sup]

@maracMB I can definitely do that, there's only one concern. The stepper coil calculations only work with whole micro stepping values. So I'm going to have to round it to the nearest step, which might cause minor inaccuracies. However, considering that the board should be able to achieve 1/32 microstepping, I estimate that the accuracy will be rounded to 0.05625 degrees. Probably not really something to worry about, but it's something that's going to have to be kept in mind.

[CAP1Sup]

@maracMB I spent all of my time today working on the encoder's SPI interface. I was, of course, unable to get it working so I didn't get to your idea. If you wouldn't mind posing your idea under the new idea discussion page on my repo, it would be greatly appreciated so we could keep everything in one place. Other than that, I will make your idea top priority for tomorrow morning's coding time.

[CAP1Sup]

@maracMB all done! I only implemented the value over the serial and CAN bus. I left it out of the OLED menu just because I figured it wouldn't really be used that much from the panel. The only remaining issue is the motor's encoder, which I will be finishing up hopefully very soon.

[maracMB]

@CAP1Sup yeah, OLED does not matter at all. i will find you and buy you a beer. That's a promise. Thank you VERY much. Once i publish the build, you will be named. I'll test it after the weekend probably

[CAP1Sup]

@maracMB No problem, happy to help. It only took me a couple of minutes to implement. The only issue left is the encoder. I worked on it today, but I still can't seem to get any values out of it yet.

[jlmxyz]

What an interesting reply @jlmxyz I'm doing a complete rewrite, which I'm going to be finishing soon. I'm hoping to finish over this weekend. My version is not only better commented but it actually make sense. Check it out once you get the chance. The only thing that I need to finish yet to have it basically 100% operation is writing the communication for the encoder and making sure that the stepping method is correct.

humm too badly I don't have any hardware to reprogram the chip... I finished to make it work somehow... but compared to the maker base ones I have, they are 10x more noisy in closed loop and 2x more in open loop... and for some reason on closed loop mode, the movement never end (or maybe it ends, but I fear too much for my board to burn that I switch power off)... at the end of movement, the motor behave as if there was something blocking the movement... it make an awfull noise like an oscilation... as if a hammer was hurting a wall at high frequency... so I guess I will drop theses drivers, there is no schematics, noisy, poorly documented...

The programmer is quite cheap. You can get one here. They only cost $10 so I think it's worth it. I'm going to be fixing the programming to hopefully reduce the noise down

ok thanks, will give it a try!!! CAN bus can hopefully be a nice option in my case, I'm considering making a "intelligent" closed loop controler, with 2 end stop connectors, thermal sensor connector... and having communication done by CAN protocol instead of STEP/DIR control.... maybe the firmware rework can be a base for this project?

[jlmxyz]

any news about the new firmware? I bought a programmer so I should be able to test it... BR

[CAP1Sup]

any news about the new firmware? I bought a programmer so I should be able to test it...

BR

@TazerReloaded and I have been working on implementing encoder readings. We where able to get the angle values from the motor (now nicely padded on the LCD) and speed is right around the corner (probably later today). Other than that, we have some minor values to fix and I need to redo how the coils are calculated because how I have it is wrong. After those are done, the board should be functional enough for use. More features are planned once we get it working on a basic level, so stay tuned for that. I'm thinking we can get the board working by the end of this week or the next.

[jlmxyz]

I've a question since you're working on the firmware, how is the communication DIR/STEP/EN handled? according to the doc, the timings have to be quite bigs, MKS closed loop model is by far faster, but have a huge issue on the CEM (the device control system is hugly, in fact it's able to burn small buffers or unprotected GPIO of CPU O_o) the bigtreetech S42B and nema57 version use optocouplers which is by far better (EL0631 if i'm correct, according to datasheet https://datasheet.lcsc.com/lcsc/1809291513_Everlight-Elec-EL0631-TA-V_C110806.pdf, Output rise time can be as low as 40ns, but with different values of resistor/capacitor) so how do you perform the "sampling" of pulses? if I correctly understood what BIGTREETECH programmed, they perform polling like sampling and not gpio interrupts based measurements... I really look forward your firmware... because BIGTREETECH one is just buggy and unusable... and MKS closed loop require to create an adaptation board... so my project is stuck

[CAP1Sup]

@jlmxyz The step pin is setup with an interrupt to handle the stepping. The stepping function checks the direction pin while calculating the stepper coils. The enable pin is checked every time the stepper correction updates (around 10-50x a sec, haven't decided on frequency yet). I didn't see a use for having to deal with an extra interrupt on either the enable or direction. I'm working on the final touches of the stepping algorithm and step correction now. I'm hoping to finish within the next week or two, but unfortunately I can't promise anything