M600 - not working properly

[Rebel3D-CZ]

M600 function

I currently have:

• V3.0.27 for TFT50 v3.0
• M600 emulation deactivated config.ini > emulate_m600:0

I tested it on the same printer with a classic GLCD and it works properly, so:

1. in gcode is M600 or is triggered by a filament sensor.
2. nozzle is raised Z and parked at defined coordinates in the FW Marlin
3. ejects the fiber (I have 90 mm in the configuration) and waits for its replacement and confirmation on the LCD
4. After confirmation, load fimalemt and wait for confirmation again
5. After confirming on the LCD, it returns to the print position and starts printing

However, when printing from a BTT TFT50 USB / SD card, it behaves as follows:

Item 1.-4. works properly

5. after confirmation on the LCD it returns to the print position and stands, it is necessary to press "Resume" on the LCD again - the icon in the "Pause" position
6. perform retraction with a length other than for replacement (less than for fiber replacement in FW approximately 60 mm ) and immediately the fiber is re-inserted by about 60 mm and starts printing. config.zip

Thus, point 6 has nothing to do here and, in addition, causes the printout to deform due to the time required to execute point 6 at the beginning of the printing position.

Is it an error or am I misconfigured?

I apologize for my translation, maybe you understand.

[digant73]

From my side everything is Ok also printing from TFT SD/USB. Try to use current Marlin bugfix version

[Rebel3D-CZ]

I tried Marlin-bugfix and the behavior is exactly the same. Can I request your configuration files?

[digant73]

I will send it tomorrow

[digant73]

attached my Marlin bugfix conf. Follow the comment // DIGA-Tech for the changes made by me

Marlin.zip

[Rebel3D-CZ]

Thanks, but I didn't find the problem :( are you using a precompiled TFT bin? Or are you compiling some modifications? Can I get your configuration file for TFTxx?

[digant73]

Here my config.ini file for MKSTFT28 v4.0. However the problem is not on TFT for sure. If you are using UBL on Marlin try to reduce the grid size to a max of 7x7. With UBL, Marlin is reaching the max of resources (RAM > 93% and FLASH > 90%). I had many bugs using UBL 10x10 (also with M600 not working at all). Try to use a 7x7 grid. If you stay below 90% for RAM and FLASH, maybe you will not have the problem with M600

config.zip

[Rebel3D-CZ]

I use FYSETC S6. As I wrote, I will have the configuration tested using a GLCD and DGUS serial LCD. It works as it should on both M600s. The described error affects TFT50 and TFT70. The bug is the same in Marlin version 2.0.7.2 and in the bug fix version. I don't know where to look anymore :(

[oldman4U]

Hi Rebel

Could you please provide a test gCode with M600 code and 30 degrees for nozzle and bed which causes the issue reproducible on your printer and I will try to reproduce the issue on my printer.

[Rebel3D-CZ]

I'll send in the afternoon. But it's nothing specific. I test on a small fast print, cube 20x20x20mm. I have manually inserted M600 into gcode for each layer change (G21 Zx.xx).

[Rebel3D-CZ]

If I run the included test print (with filament temperatures) via the USB port from Repetier-Host, the M600 works fine. M600-30.zip

[oldman4U]

But it does not work properly when printing from TFT SD/USB...? So I can test with this file.

[Rebel3D-CZ]

Yes. When printing from USB TFT, the same file works very strangely :D

[oldman4U]

OK. So I will test it with and without M600 emulation turned on, printing from BTT TFT SD card slot. Let you know asap.

[oldman4U]

Hi.

It works great when using emulated M600 It works great when using NOT emulated M600 but printing from Marlin Emulator. I can confirm strange behaviour when using NOT emulated M600 but printing from Touchscreen. In contrast to Rebels printer, my SKR E3 DIP based printer does not resume to the print position and also does not purge additional filament, but remains at the parking position and does nothing after clicking Resume. The button changes to Pause and pressing it again the TFT becomes unresponsive.

The SKR is based on STM32 chip, like Rebels mainboard and we had a STM32 related Marlin problem at exactly the same position before, which is only fixed in the bug fix version of Marlin. Because of this I use this version.

I recorded the whole progress using Printrun and can see that there is still communication once the TFT freezes. Here is the whole progress:

T:31.00 /30.00 B:31.00 /30.00 @:0 B@:0 //action:paused//action:prompt_end//action:prompt_begin Pause//action:prompt_button Dismiss//action:prompt_show T:31.00 /30.00 B:31.00 /30.00 @:0 B@:0 T:31.00 /30.00 B:30.00 /30.00 @:0 B@:0 T:30.00 /30.00 B:30.00 /30.00 @:10 B@:0 T:31.00 /30.00 B:30.00 /30.00 @:0 B@:0 //action:prompt_end//action:prompt_begin Nozzle Parked//action:prompt_button Continue//action:prompt_show T:30.00 /30.00 B:30.00 /30.00 @:11 B@:0 T:31.00 /30.00 B:30.00 /30.00 @:0 B@:0 //action:prompt_end//action:prompt_begin Paused//action:prompt_button PurgeMore//action:prompt_button Continue//action:prompt_show T:31.00 /30.00 B:30.00 /30.00 @:0 B@:0 T:31.00 /30.00 B:30.00 /30.00 @:0 B@:0

@Rebel3D-CZ Could you please try emulated M600 activated to see if it solves the problem on your side.

@digant73 I know that I have been testing the filament runout a lot. Do you think it makes sense to test it again to see if this makes a difference?

[digant73]

@Rebel3D-CZ, @oldman4U M600 with M600-30 gcode file perfectly works from my side even from TFT SD card

[Rebel3D-CZ]

ok, I'll try the emulated M600

[Rebel3D-CZ]

when emulating M600

TFT-SD printing: Works correctly, the nozzle parks at the defined position, performs the specified retraction and after recovery returns to the print location and prints.

TFT-USB printing: TFT-SD printing: Does not work properly, the nozzle does not park in the defined position, remains at the pause point, ie performs only the specified retraction on the printout and starts printing after resumption. It does not park.

[oldman4U]

So with emulated M600 activated, you get a different result when printing from TFT SD card or TFT USB?

Will verify this asap.

[oldman4U]

I get the same results using emulated M600, does not matter if I print from TFT SD or TFT USB.

[Rebel3D-CZ]

So I don't know, the printer is probably enchanted :( I've tried several versions of Marlin and various LCDs. The only thing my M600 doesn't work with is the TFT50 and TFT70. I'm definitely not going to buy another for testing :D

[Rebel3D-CZ]

Unemulated M600 from TFT-SD Video News...... this test file will also start moving to XY0 after a break. For the same file with G34 and G29, this transition to XY0 is not. I'm already desperate about TFT :(

[oldman4U]

I thought it does not work unemulated?!

Rebel3D-CZ @.***> schrieb am Di. 13. Apr. 2021 um 22:14:

Unemulated M600 from TFT-SD Video https://photos.app.goo.gl/z9jNhooGMcoCdc9r5 I'm already desperate about TFT :(

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bigtreetech/BIGTREETECH-TouchScreenFirmware/issues/1829#issuecomment-819023139, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM6XKZBQDY4U3V5UX5OA4RLTISQ3JANCNFSM42XVD7WA .

[Rebel3D-CZ]

But yes, see above. Emulated does not work properly from USB.

[oldman4U]

digant Would you please be so kind and test it also from TFT USB with emulation turned on. I will do the same again.

[Rebel3D-CZ]

To make everything clear. I would like to have a working M600 in Marlin FW = emulate_m600: 0

[bigtreetech]

@Rebel3D-CZ Hello， According to the phenomenon in your video, have you enabled the #define ADVANCED_PAUSE_CONTINUOUS_PURGE function in Marlin？ Can you comment out it and try again?

@digant73 Have you tested whether #define ADVANCED_PAUSE_CONTINUOUS_PURGE function can work normally?

[Rebel3D-CZ]

@bigtreetech Hi, I'll try tonight. But with the ADVANCED_PAUSE_CONTINUOUS_ PURGE function, I tried it with other LCDs, see above, and it works properly.

[oldman4U]

I did my tests with standard settings so continuous purge is not activated on my printer.

[bigtreetech]

@bigtreetech Hi, I'll try tonight. But with the ADVANCED_PAUSE_CONTINUOUS_ PURGE function, I tried it with other LCDs, see above, and it works properly.

@Rebel3D-CZ I looked at ADVANCED_PAUSE_CONTINUOUS_ PURGE in marlin. This logic needs M108 to interrupt the extrude, which does not match the current logic of TFT. If it is confirmed that this is the reason, we need to make this compatible in the TFT firmware. Thank you very much for your time.

[Rebel3D-CZ]

Great, I understand and I'll try.

[oldman4U]

I use this setting and had the issue while using UNemulated M600 and printing from TFT.

[Rebel3D-CZ]

Tested. There was no change in the strange behavior :( Only the "Purge" option in the dialog has been added.

[bigtreetech]

@Rebel3D-CZ Hello, can you check whether #define EMERGENCY_PARSER feature is enabled in your Marlin? Can you compress your configuration.h and configuration_adv.h of Marlin and send them to me for inspection?

[Rebel3D-CZ]

@bigtreetech The #define EMERGENCY_PARSER function is enabled.

Configuration here Marlin_BFX_2.0.x-conf.zip

Thank you for the check

[oldman4U]

First I have to apologise for leading into the wrong direction.

Usually I take care that all of the functions needed are really enabled before I start a test, but somehow my configurations have been mixed up so there was the Emergency_Parser disabled in my firmware. I enabled it, and now the print continues after M600. If it helps somehow. I can make a movie which shows it.

Rebel, I checked your configs and it seems to be perfect, so I really do not know why you have this problem. There was a problem with M876 in Marlin and I hoped this would be somehow related, but if you use a current bug fix version of Marlin I do not know where the problem could come from.

Kind regards

Oldman

[Rebel3D-CZ]

It has happened to me several times that due to poor filtering of the power supply and the long cable to the SD card on the GLCD, uncontrollable axis shifts occurred during printing, which always returned to the place of printing. It reminds me a bit that at the end of the M600 from the SD card I go to XY0 and a long move with deretation. But with the wrong source, it wasn't always the same. Since I replaced everything on the printer except the power supply and the cable to the LCD, I will try these last 2 variants, I can't think of anything else. For TFT50 I used the original unshielded cable with RS232 line. I'll use a shielded cable, but I don't give much of a chance. I'll check it over the weekend, if it doesn't work, I'll probably throw it away :D

[bigtreetech]

@Rebel3D-CZ Hello, I've found out exactly where the problem is. If you can enable #define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER in configuration.h. All of M600 can be used normally. This is a problem of marlin compatibility https://github.com/MarlinFirmware/Marlin/blob/58cc4b7043a9ff3b60df6c8f08591cb58213fbab/Marlin/src/feature/pause.cpp#L271 If there is no LCD, Marlin will send “resumed” directly, jump out of M600 and cannot to PurgeMore normally. TFT is currently parsing "Resuming" not "resumed" of marlin, so TFT can't get the normal state of M600 You can solve this problem quickly through enable #define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER for the time being

I'll start to solve this problem and add parsing "resumed" to the TFT. This part can solve the problem that TFT will not resume printing automatically. And improve the compatibility of ADVANCED_PAUSE_CONTINUOUS_ on TFT. But the problem of PurgeMore need to be fixed by Marlin(I will also submit a PR to Marlin to fix it).

[Rebel3D-CZ]

@bigtreetech Okay, I'll try. I just have FULL_GLCD off because I have RX/TX output and TFT reset from the EXP1 connector. I will configure it to another port and try it.

[Rebel3D-CZ]

@bigtreetech Unfortunately, uncommenting #define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER did not solve my problem. I have no problem with the pause sequence - stop - park - eject the filament - insert the filament - continue / clean - continue printing. My problem is that after the last confirmation, when the nozzle should return to the place of printing, a continuous process happens: the nozzle is raised - approx. 60 mm retraction - parked in X0Y0 - it returns to the printing area and during that it introduces the approx 60 mm filament back and continues printing. All this alone and for an unknown reason, see the video :(

[bigtreetech]

the nozzle is raised - approx. 60 mm retraction - parked in X0Y0 - it returns to the printing area and during that it introduces the approx 60 mm filament back and continues printing. All this alone and for an unknown reason, see the video :(

When the M600 is sent to Marlin to pause, we need not to click the resume button in the lower left corner of the TFT to resume printing. Marlin's M600 communicates with TFT through HOST_ACTION_COMMANDS protocol. We only need to click PurgeMore or Continue in the HOST_PROMPT_SUPPORT pop-up menu. We don't need to click resume button in the bottom left corner of TFT.

[Rebel3D-CZ]

Really. I was impatient. If I do not press "Continue" in the lower left corner of the LCD, printing will continue correctly. However, when pressed, it performs this strange cycle with a long stroke. Sorry, I didn't think of that. It would be good to fix it.

[oldman4U]

@bigtreetech

In case a button can be pressed it has to work. As far as I know,there has been a popup window avoiding this before - which finally did a great job.

[bigtreetech]

In case a button can be pressed it has to work. As far as I know,there has been a popup window avoiding this before - which finally did a great job.

In fact, this is a known limitation at the moment. When M600 is sent to Marlin, Marlin will inform TFT through HOST_ACTION_COMMANDS now it is currently in a paused state, and then TFT can only communicate with Marlin through HOST_ACTION_COMMANDS(popup window in TFT). The resumed state can only be notified by Marlin to continue because the state of pause is notified by Marlin‘s M600.

Therefore, the pause & resume of M600 can only communicate with Marlin through HOST_ACTION_COMMANDS(pop-up window). Maybe TFT needs to enter a notification screen without buttons in the process of waiting for Marlin notification, such as: a black screen with string "waiting for Marlin to perform an action" to limit the illegal click. Instead of returning to the printing menu because there is some buttons that cann't be click in printing menu.

[oldman4U]

Exactly. If we wait for Marlin we should let the user know and prevent that he does things he should not do. If this needs a new screen!? I would prefer a popup window without buttons. My2 cents

[kisslorand]

Does the TFT''s FW really has to babysit every user? Anyway, I see it as a Marlin issue. It shouldn't execute a resume command until M600 is finished.

[oldman4U]

Especially when it comes to new features this definitely has not to be the case. But in this case we allow to do something which causes an error. I am sure you agree that we should avoid this does not matter what the root of the is. Or we say we do not take care what Marlin does, but at least in the past, this was not the case.

[GrahamJB]

Yes it does have to make it as easy as possible for users. Something like the BIQU B1 is an entry level printer and the vast majority of users will not be capable of reading code, definitely not configuring it and compiling it. In fact it will probably be their first 3D printer. As such IMHO the firmware needs to be robust and to protect the users as far as possible.

[oldman4U]

I agree. And even the stability and functionality has been increased dramatically over the last few months there is still some fine tuning which has to be done. But where is this not the case.

[arminth]

Previous post deleted. Missed a configuration option in Marlin. Sorry.

[fiveorders]

I was having the same issue and now I learned that I shouldn't click the Resume button. But a warning or a blackout of the buttons with a waiting indicator would be very nice to have.

I am having another issue now, I leave it and it goes back to its position and stops after a 1mm movement on the print direction. The last toast message on the screen was "Printing"