Bugfix 2.0 short movements problem

[Bergerac56]

As already reported some times ago in the Marlin 2.0 refactor tread, when using a re-arm with any bugfix 2.0, the X and Y motors are shaking on small moves (when doing a circle for ex.) on my 2 printers. (different printers but same re-arm). This problem does not occur with a mega2560. As none of the new releases solves the issue, I investigate a bit more.

It seems to be an interaction between motors movements and fan0. When I print a gcode file (created with Cura) with fan0 at 0% or at 100% (max), all is fine. No strange small movements. When I print with fan0 at another speed, the problem occurs. (I normally print with fan0 at 70%. This is why I got the problem)

It is the same if I change (tune) the speed during the print: when at max or stopped, all is fine but not with another value.

Another strange constatation: I noticed that the emergency stop button did not work when printing but well at other moments. Here again: when fan0 at 0 or 100%, it works. And not when at another speed.

Somebody else having noticed this?

[AnHardt]

Fans are mostly driven by software-PWM. In the special cases of 0 and 100% there is nothing to do. So - maybe ... .

[GMagician]

When fan is not 0% or 100% pwm is doing its job...an electrical noisy job and maybe your issues are related to EMI. Have you tryed to change cables positions (stepper far from guilty fan)? Maybe re-arm is less protected from EMI

[Bergerac56]

@GMagician - EMI is indeed a problem with re-arm. I fighted already a lot with the temperature problem (added selfs, recabling the printer,...)

In the case of fan and emergency stop problem, I tried even without fan connected. Same result. Moreover, on the test printer, all cables are far from each other and certainly those going to the stepper motors (consequence of the tests for the temp problem).

It is a bit like the pwm generation would slow down the loop controling the motors. Or have a higher priority. Strange as it does not happen with the mega2560 and the re-arm is more powerful.

Yes, it can be EMI but I am not totally convinced. All what I tried in this field did not improve even a bit.

[GMagician]

Consider that it can also be a MB weak design. If so you can do whatever you want with cabling but you can't solve it

[Bergerac56]

Still not convinced ;). I used 2 different RAMP boards from different sources. The only "common" componant is the RE-ARM. I have only one piece.

I tried something I did not yet do: activate FAN_SOFT_PWM. If this option exists, I suppose that it is because fan0 is normally Hard PWM.

When the soft-pwm is activated, there is no problem anymore. The fan can be used all over its range without noticable interaction with stepper motors. And emergency stop works fine at any moment.

Strange ...

[GMagician]

Not so strange....FAN_SOFT_PWM changes pwm frequency as I know... lower frequencies generate less noise

[GMagician]

Just because I faced this issue (bltouch burned) do you have flyback diode on fan? or better do you have flyback diodes on pwm commands?

[GMagician]

I talked to a person who manages electonic development and he said that missing flyback diodes on pwm load is not a very good choice. I read some document on the web about such argument, the guy said that on a 12V system, without such diode, you can have till 100V that have to be discharged somewhere...

[Bergerac56]

Yes I tried that. And also varistances and capacitors. No changes. As it works absolutely fine with soft PWM, this is why I was a bit puzzled about EMI.

[Bob-the-Kuhn]

I think the problem is the hardware PWM ISR is running at the same priority as the stepper ISR.

The hard PWM for P2_7 (D8), P2_4 (D9) & P2_5 (D10) are generated using interrupts. That was done because running the PWM ISR lower than the stepper ISR resulted in large variations in the PWM duty cycle.

Please go into LPC1768_PWM.cpp and comment out line 174 (sets priority to zero) and un-comment line 173 (sets priority lower to 10).

If that solves the problem then we'll make the lower priority permanent.

The other thing we can do is use the LPC's built in PWM controller for pins D9 & D10 (D8 doesn't have this option). When I wrote the PWM code I just assumed that a soft PWM would be used for those outputs.

---

I noticed that the emergency stop button did not work when printing but well at other moments. Here again: when fan0 at 0 or 100%, it works. And not when at another speed.

I'm going to have to scratch my head on that one.

Are you printing from the host or from the SD card?

[Bergerac56]

@Bob-the-Kuhn - Thanks Bob. Yes I print, in fact, always from a sdcard. (but I have tried once to print from the host. Same results)

I still believe that it is not as such a EMI problem.

I just tried what you suggested. It improves a little bit the "shaking" of the stepper motors when fan lower than 255. But it is still not good at all compared to soft PWM. And all other effects are still there.

I believe that you are right. The problem comes from priorities and perhaps some incompatibilities between the management of motors (very important I guess) and other stuffs like fan (less important).

When using hard PWM for fan, there is another side effect. The LCD is really not responsive (slow, bad refresh and lines appearing here and there). To the point that it is very difficult to chose an option. Knowing that what you proposed did not solve at all the emergency button problem and the LCD side effect, I believe that, when the fan requires PWM management, there is a strong interaction, not necesseraly related to priorities, with some other stuffs: Motors, lcd and emergency button at least.

The interesting element is that activation of soft PWM for fan solves all problems.... Lcd is fluid (except some lines appearing, it seems, when accessing the sdcard), stepper motors are working good and emergency button is immediately reactive.

[Bob-the-Kuhn]

Try these two file & let me know if they fix the problems.

LPC1768_PWM.zip temperature.zip

[Bergerac56]

@Bob-the-Kuhn . Hello Bob, Unfortunately, it does not compile when I add your 2 files. I get this: Compiling .pioenvs\LPC1768\src\src\libs\hex_print_routines.o In file included from Marlin\src\lcd\ultralcd.cpp:95:0: Marlin\src\lcd\ultralcd_impl_DOGM.h:173:75: warning: large integer implicitly truncated to unsigned type [-Woverflow] U8GLIB_ST7920_128X64_RRD u8g(LCD_PINS_D4, LCD_PINS_ENABLE, LCD_PINS_RS); // Number of stripes can be adjusted in ultralcd_st7920_u8glib_rrd. h with PAGE_HEIGHT ^ Marlin\src\lcd\ultralcd_impl_DOGM.h:173:75: warning: large integer implicitly truncated to unsigned type [-Woverflow] Marlin\src\lcd\ultralcd_impl_DOGM.h:173:75: warning: large integer implicitly truncated to unsigned type [-Woverflow] In file included from Marlin\src\lcd\ultralcd.cpp:95:0: Marlin\src\lcd\ultralcd_impl_DOGM.h: In function 'void lcd_bootscreen()': Marlin\src\lcd\ultralcd_impl_DOGM.h:316:17: warning: unused variable 'show_bootscreen' [-Wunused-variable] static bool show_bootscreen = true; ^~~~~~~ Marlin\src\lcd\ultralcd_impl_DOGM.h: At global scope: Marlin\src\lcd\ultralcd_impl_DOGM.h:316:17: warning: 'show_bootscreen' defined but not used [-Wunused-variable] Compiling .pioenvs\LPC1768\src\src\libs\least_squares_fit.o

And this: Compiling .pioenvs\LPC1768\src\src\module\tool_change.o Marlin\src\module\temperature.cpp:505:6: error: redefinition of 'static void Temperature::updatePID()' void Temperature::updatePID() { ^~~ In file included from Marlin\src\module\temperature.cpp:27:0: Marlin\src\module\temperature.h:438:34: note: 'static void Temperature::updatePID()' previously defined here FORCE_INLINE static void updatePID() { ^~~~~ Marlin\src\module\temperature.cpp: In static member function 'static void Temperature::isr()': Marlin\src\module\temperature.cpp:1723:70: warning: suggest parentheses around '+' inside '>>' [-Wparentheses] soft_pwm_count_fan[0] = (soft_pwm_count_fan[0] & pwm_mask) + soft_pwm_amount_fan[0] >> 1;

*** [.pioenvs\LPC1768\src\src\module\temperature.o] Error 1
 [ERROR] Took 99.80 seconds
Environment LPC1768                     [ERROR]

Here are my config files in case of...
[Configuration.zip](https://github.com/MarlinFirmware/Marlin/files/1463918/Configuration.zip)

[Bob-the-Kuhn]

The problem was caused by 2.0.x having been updated after I started working on the PWM so the temperature.cpp file I gave you was out of date.

Here's one that's compatible with the today's 2.0.x

temperature 2017-11-12.zip

[Bergerac56]

It compiles fine now. (Just to be sure I did well: =>LPC1768_PWM.cpp in HAL_LPC1768 and temperature.cpp in module.)

Unfortunately, it does not solve the problem. Still "shaking" motors when fan is activated, still not nice lcd and no emercency button when #define FAN_SOFT_PWM is not enabled.

Zut ;) I was already dreaming...

[fiveangle]

If you print very slowly does the shaking stop (and the shaking increase the faster you print) ?

[Bergerac56]

@fiveangle - Using the modifications done by bob? With a "normal" version, the shaking is less hard when printing veeeeeery slowly, but still there. And the other manifestations (LCD and emergency button) are also there.

With the modifications proposed by bob, it is quite the same.

It gives the impression that all actions are "serialized" at a very slow rate at the moment the fan starts (1<fan<254) (a little movement of x, a little of Y, and that at a very slow tempo,etc...)

In other terms, what does "hard" pwm do that #define FAN_SOFT_PWM doesn't (or vice versa ;) )

[Bob-the-Kuhn]

Here's another version of LPC1768_PWM. LPC1768_PWM 2017-11-13.zip

As far as I can tell it's well behaved when printing with a LCD controller attached. The LCD controller is responsive & the fan speed is fairly steady.

If there's still problems then I'll need your config files and your gcode file.

[Bergerac56]

Hello Bob. Still not ok from my side. Sorry. I know that you work hard to help. The movements are less slow, but still very shaky, still poor LCD reactions and still no emergency button. I join here the full directory used to compile (including my config files) and add a test gcode file. The "problem" occurs at layer 2, when Fan starts to run.

My config: Real printer. RE-ARM with temps on RE-ARM and not on RAMP. Temps are filtered with selfs. Ramp 1.4 with X Y Z and extruder. Endstops at pos 0 on X & Y. Inductive probe for Z. LCD is: REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER. Heated bed.

This config is working nicely with a mega2560. Or with RE-ARM and FAN_SOFT_PWM activated. I printed multiple objects with re-arm and FAN_SOFT_PWM activated without problem.

Marlin-bugfix-2.0.x BF24 (12-11)-Bob.zip JOP cover.zip

[Bob-the-Kuhn]

Turns out that Marlin spends 90% + of it's free time setting the fan speed when FAST_PWM_FAN is enabled. When the fan is set to 0% or 100% it's no big deal because the PWM routine isn't being called. If it's set to anything else then the PWM routine is called. Because of the ISR synchronization, the PWM routine usually takes just under 40mS to run.

The solution is to change the synchronization method so the ISR does the updates. Now the PWM routine only takes 20uS to run. The ISR now takes an extra 15uS to run.

Please try the following file.

LPC1768_PWM 2017-11-14.zip

[Bob-the-Kuhn]

I ran into a compiler bug when I went to get it ready for a PR. It compiled just fine but wasn't functional.

Hope you don't run into it.

[Bergerac56]

@Bob-the-Kuhn - YESSSS. You solved it. The motors are running smoothly. LCD, even not totally perfect (still lines time to time, I guess when the SD card is accessed) is reactive and emergency button works perfectly. Thanks a lot. It is a huge improvement. EDIT. I did not see your last comment. No I could compile without problem. I tried 2 versions: 1> The files of Nov the 12th (with your temperature file and the last "pwm" of today: => It compiles fine and works 2> The very last bugfix of today with only your last "PWM" file: Compiles OK and run too.

[Spawn32]

I read this a little late, but i can confirm that the MKS SBASE had the exact same problem, as soon as i turned on the fan it started making funny noises in curves :) i guess this will be merged soon ? :) thanks @Bob-the-Kuhn

[Bob-the-Kuhn]

Here's what I've put into PR #8446. Please do a quick sanity check on it.

LPC1768_PWM 2017-11-15.zip

[Bergerac56]

@Bob-the-Kuhn - I tested your last "release" with the last bugfix of this morning. It compiles fine and works as expected. Movements, LCD and emergency button are working and reactive. I tested with a full real print of the test file. No problem. Nice job. For me, this means that the re-arm will stay in the printer for real printing for the future. The essential functions needed to print are there and are working (at least at my side). There are still issues but nothing preventing me to print. (I can make a list if you want ;) ). Thanks Bob. Olivier

[Bergerac56]

Last bugfix (Latest commit 3af7fc0) solves the issue. Thanks again

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.