[BUG] M109 causes servo of the switching nozzle to stop working

[geozoc]

Deprecated, see comment 5: Dear Marlin developers,

I'm sorry to bother you with my problems but there might be an issue with the current Marlin release. The problem might also sit in front of the computer. If so I'm really sorry.

I build my own 3d printer on the basis of a bigtreetech GTR. It's a dual extrusion system that switches it's extruders (switching_nozzle) via a servo (SunFounder SF3218MG). It is a coreXY system that is controlled via a serial connection to a raspberry pi4. The servo power is directly attached to a 5V-100W power supply (Meanwell) whereas the GTR is attached to a 12V-200W (Meanwell). I edited three files (Conf, Conf_adv, Pins), which can be found here:

https://drive.google.com/drive/folders/1ZsjcjbSM3vZkkdx-qWai0MyiaSPZ2PS2

On a first view. Everything seems to work properly. If I start the printer, I can switch between the extruders via T0, T1. Printer is doing the typical Z_raise, Switch, xy_offset, Z_down. I tested this in a loop of 100 extruder switched... No issue. It also does the switch, if the wrong tool is selected prior the upcoming print.

But now the issue: If I try a dual extrusion print, the extruder does not switch the extruders (sliced by cura 4.7.1, gcode seems fine and contains the T1/T0 commands). It looks like it would switch, but the switch is not executed. If I abroad the print, I cannot talk to the servo anymore. (T1/T0) is not working until I plug off the power from the board (relais via gpio of the pi) and reconnect. Than one can choose again the extruders. And switching works fine again.

I have to mention that exactly the same setup worked pretty well using a RUMBA Plus (8bit) board attached to the same Pi, same setup but using Marlin 1.1.9. The only reason I switched the board was due to performance issues on printing circles on the 8bit board and the CoreXY system of the printer.

Do you have any ideas that I can test?

I tried the latest bugfix-release but cannot compile as I got

Marlin\src\HAL\STM32\timers.cpp: In function 'void HAL_timer_start(uint8_t, uint32_t)': Marlin\src\HAL\STM32\timers.cpp:150:32: error: 'class HardwareTimer' has no member named 'setPreloadEnable' 150 | timer_instance[timer_num]->setPreloadEnable(false);

Sorry, if this might not be an marlin issue but there is nothing else that comes into my mind.

Thank you for your support, Georg

[ellensp]

I tried to compile you configs and pins file on bugfix. After changing #ifndef TARGET_STM32F4 to #ifndef STM32F4 in pins_BTT_GTR_V1_0.h It compiled without issues.

[geozoc]

Dear ellensp,

Thank you very much. So I will try the Bugfix right now and report back. But I doubt that this will solve the problem...

All the best, Georg

EDIT: That was an error I introduced by myself... sorry

EDIT2: Sorry, still get compile errors: EDIT3: My mistake, got it compiled and will test now, and report back

[geozoc]

Ok, pretty sure an Marlin issue. Bugfix-Release does not work at all.

I also tried to use the servo-Pin of the BLTouch to switch the nozzle. Same experience:

• Marlin 2.0.6.1 does switch nicely the extruder, as long as you do not print something
• Marlin-bugfix does not work at all switching the extruder

-Marlin 1.1.9 worked nicely (but too slow) with the RUMBA Plus Board. But by the way also had different issues with Marlin 2.x. Is there any chance that someone can have a look what changed from the working setup in 1.1.9?

I'm happy to run further tests if there are any suggestion.

All the best, Georg

[geozoc]

Dear developers,

I'm pretty convinced that this behaviour is really a marlin bug. Taken Marlin 2.0.6.1, I could track down the issue to be located somewhere in this starting gcode:

M140 S60 M190 S60 M104 S216 M104 T1 S216 M109 S216 M109 T1 S216

I know it has nothing to do with the servo (at least from the typical user site). But excluding this code from the cura produced gcode keeps the servo running.

If any further informations are needed, or if you would like to see a movie or anything else, I'm more than happy to give you support here. Unfortunately, due to very limited C++ knowledge, I can not further contribute to solve this issue.

All the best, Georg

[geozoc]

Dear Developer,

I could localize the problem of my servo issue:

When I remove the M109 command, e.g. M109 T0 S220, and do preheating in advance of the printer job, the servo keeps working and does a decent dual-extrusion print.

I really do not have any idea why these for me independent tasks (heating / switching) are related, but that's exactly what I observe.

All the best, Georg

[github-actions[bot]]

This issue has had no activity in the last 30 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 7 days.

[geozoc]

I just would like to add, that the issue is still present also in marlin 2.0.7. Therefore I would recommend to keep it open.

My current workaround is to manually remove the M109 and M105 codes at the beginning of the gcode file and do manual heating prior print start.

If there is anything I can support the developers please let me know.

Best Georg

[boelle]

Also in bugfix-2.0.x branch ?

[sjasonsmith]

@geozoc can you provide the configuration files you've used with the latest version of Marlin, preferably with bugfix-2.0.x?

Also, please provide some exact steps to reproduce the issue. This may require you to attach gcode files you use to reproduce the problem. Here is the portion of the Issue Template which we need, to know how to approach this:

Steps to Reproduce

1. [First Step]
2. [Second Step]
3. [and so on...]

Expected behavior:

Describe what you expected to happen here.

Actual behavior:

Describe what actually happens here.

[github-actions[bot]]

This issue has had no activity in the last 30 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 7 days.

[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.