search

bigtreetech / BIGTREETECH-S42B-V1.0

The closed-loop drive is to feedback the rotation angle of the stepping motor to the control panel, compare the distance that needs to be rotated with the distance of the actual rotation, calculate the error value, and then compensate, so as to prevent the problem of multi-step and lost step. 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
109 stars 53 forks source link

Change of Filament (Homing) not working #22

Open copperfield74 opened 3 years ago

copperfield74 commented 3 years ago

I'm using a Sidewinder X1 and Repetier Server! Before installing the S42B there was no problem to change the filament during a print. When I hit PAUSE the nozzle would raise 5mm and X/Y would home! Then I could change the filament, hit CONTINUE and the print would continue where it stopped. Normal behaviour! WITH the S42B I've tested it maybe 12 times in the beginning of a print and it worked like I was used to, BUT everytime I had to do it during a longer print, the beaviour was like this: PAUSE: Nozzle raises, X and Y are homing! Perfect. CONTINUE: X goes to the right position but Y (S42B) rushes completely forward so that the print can't be continued. I think that I'll get rid of the S42B when this project is done. In my case it's not reliable enough and has killed 3x 30h prints with that problem. I now have to buy 4.5kg spools so I can print 3 parts without having to change filament.

Quas7 commented 3 years ago

You could also try a filament fuser block. But I never tried this - sticking to 3.5kg (where do you get 4.5kg spools?!)

swanepoeljan commented 3 years ago

Do the time you take to change the filament make any difference? For example, when it's in PAUSE mode for a short time (few seconds) it works but if it's paused for a longer time (more than a minute) then it doesn't work?

The times that it fails, could you notice the OLED maybe restarting? Just thinking if the S42B restarts for some reason (watchdog, hard fault, etc.) and then forgets its last position...

When in PAUSE mode, are the motors enabled?

Quas7 commented 3 years ago

Also, there is a discussion on max step frequency and pulse width as it seems not all boards behave identical. https://github.com/bigtreetech/BIGTREETECH-S42B-V1.0/issues/13

You can join and test with increased pulse width and see, if this corrects your error. Here a proposal, what you could try out before discontinuing:

Configuration_adv.h: /**

It might also be, that your direction signal is decoded fast enough and it runs off in the opposite direction.

/**

And, of course, the max freq. has to be limited as well /**

and one more thing as @swanepoeljan pointed out would be to disalbe stepper timeouts either in firmware or with M18 or M84 commands. Older S42B firmware seems to try to get to its first power-up position after re-enabling (https://github.com/bigtreetech/BIGTREETECH-S42B-V1.0/issues/3).

/**

copperfield74 commented 3 years ago

Do the time you take to change the filament make any difference? For example, when it's in PAUSE mode for a short time (few seconds) it works but if it's paused for a longer time (more than a minute) then it doesn't work?

The times that it fails, could you notice the OLED maybe restarting? Just thinking if the S42B restarts for some reason (watchdog, hard fault, etc.) and then forgets its last position...

When in PAUSE mode, are the motors enabled?

That's a very good question! The successful tries were all done in a short period of time. The real chnage of filament took obviously more time. I'll check next time. If I'm not mistaken the motors should stay enabled during PAUSE.

copperfield74 commented 3 years ago

Also, there is a discussion on max step frequency and pulse width as it seems not all boards behave identical.

13

You can join and test with increased pulse width and see, if this corrects your error. Here a proposal, what you could try out before discontinuing:

Configuration_adv.h: /**

* Minimum stepper driver pulse width (in µs)

* 0 : Smallest possible width the MCU can produce, compatible with TMC2xxx drivers

* 0 : Minimum 500ns for LV8729, adjusted in stepper.h

* 1 : Minimum for A4988 and A5984 stepper drivers

* 2 : Minimum for DRV8825 stepper drivers

* 3 : Minimum for TB6600 stepper drivers

* 30 : Minimum for TB6560 stepper drivers

* Override the default value based on the driver type set in Configuration.h.
  */
  **#define MINIMUM_STEPPER_PULSE 10**  // 10us long step-pulse (7 was experimentally the lowest for in one test for one board)

It might also be, that your direction signal is decoded fast enough and it runs off in the opposite direction.

/**

* Minimum delay before and after setting the stepper DIR (in ns)

* ```
  0 : No delay (Expect at least 10µS since one Stepper ISR must transpire)
  ```

* 20 : Minimum for TMC2xxx drivers

* 200 : Minimum for A4988 drivers

* 400 : Minimum for A5984 drivers

* 500 : Minimum for LV8729 drivers (guess, no info in datasheet)

* 650 : Minimum for DRV8825 drivers

* 1500 : Minimum for TB6600 drivers (guess, no info in datasheet)

* 15000 : Minimum for TB6560 drivers (guess, no info in datasheet)

* Override the default value based on the driver type set in Configuration.h.
  */
  #define MINIMUM_STEPPER_POST_DIR_DELAY 10000 // I assume, this means "wait 10us before sending steps"
  #define MINIMUM_STEPPER_PRE_DIR_DELAY 10000 // I assume, this means "wait 10us after last step to send direction change"

And, of course, the max freq. has to be limited as well /**

* Maximum stepping rate (in Hz) the stepper driver allows

* If undefined, defaults to 1MHz / (2 * MINIMUM_STEPPER_PULSE)

* 5000000 : Maximum for TMC2xxx stepper drivers

* 1000000 : Maximum for LV8729 stepper driver

* 500000  : Maximum for A4988 stepper driver

* 250000  : Maximum for DRV8825 stepper driver

* 150000  : Maximum for TB6600 stepper driver

* 15000  : Maximum for TB6560 stepper driver

* Override the default value based on the driver type set in Configuration.h.
  */
  #define MAXIMUM_STEPPER_RATE 150000  // how many steps/s max.

and one more thing as @swanepoeljan pointed out would be to disalbe stepper timeouts either in firmware or with M18 or M84 commands. Older S42B firmware seems to try to get to its first power-up position after re-enabling (#3).

/**

* Idle Stepper Shutdown

* Set DISABLE_INACTIVE_? 'true' to shut down axis steppers after an idle period.

* The Deactive Time can be overridden with M18 and M84. Set to 0 for No Timeout.
  */
  #define DEFAULT_STEPPER_DEACTIVE_TIME 0

Qua7, it seems that you are really digged deep into this topic. I'll take a look if anything helps with my problems. Most of the time the motor is "humming" when I move it forward and it seems as if it's working against something so that it doesn't shut off and gets quiet. Never thought that it would be this hard to get it to work correctly. :-(

copperfield74 commented 3 years ago

You could also try a filament fuser block. But I never tried this - sticking to 3.5kg (where do you get 4.5kg spools?!)

I got my 4.5Kg Filament from Material4Print they also have 8Kg spools but that would have been overkill. ;-)

Quas7 commented 3 years ago

You could try one more thing to check, if this is related to this issue https://github.com/bigtreetech/BIGTREETECH-S42B-V1.0/issues/3

  1. Printer power off
  2. Move everything manually to the center of your print area
  3. Power on and send the printer the following commands (via Pronterface or Octoprint, etc.):

G28 ; home all axis G1 X30 Y30 Z30 ; All move 30mm M18 ; (or M84) disable steppers

  1. Try to move the motors just a little bit to be sure they are all really "offline"

M17 ; enable steppers again

If the Y-axis jumps to the center after this you have a board with the older firmware as I did. Reflashing with the binary mentioned in the issue #3 solves this.

copperfield74 commented 3 years ago

G1 X30 Y30 Z30

I did what you told me to do and you were right. It jumps back to the center of the printer. So the first thing next time should be to update the firmware. I've already bought a STLink to do that.