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.

[Rebel3D-CZ]

Of course I understand that, but we are talking about TFTxx as a guest and printing from its SD or USB reader. In this case, TFTxx should behave properly and know what it does, right, don't you think?

[Rebel3D-CZ]

Among other things, TFT knows when to start printing after a pause, because the button has changed from "Continue" to "Pause"

[kisslorand]

Among other things, TFT knows when to start printing after a pause, because the button has changed from "Continue" to "Pause"

That's not true. Marlin sends "Resuming" that's how the TFT knows what to do, the TFT doesn't know if the user is allowed or not to press a particular button.

Of course I understand that, but we are talking about TFTxx as a guest and printing from its SD or USB reader. In this case, TFTxx should behave properly and know what it does, right, don't you think?

Yes, in that case you are right, the TFT "knows" what it does. But this case makes it a particular case, not a global one. So, in the case you are printing from the TFT USB or TFT SD, than it is possible to restrict the usage of specific buttons in specific cases. In the case of printing from onboard SD it is not always possible to determine what is Marlin doing hence to know what specific situation applies.

This discrepancy makes the request of prohibiting buttons a particular case request, not a global one.

If you wish, you can beat this dead horse as much as you like but I'm out of this topic, good luck.

[Rebel3D-CZ]

If you notice, this ticket is already closed a few posts above. there is no need to continue the discussion here. In addition, this release of the button is not a problem with this ticket and a new one will be created. I'm not a programmer, so I won't do it my way. I try to describe the problem from the user's point of view. It is up to the programmer to try to understand the problem and, if possible, to understand it. If you find it unnecessary, do not comment on it. I represent a whole community of users who have the same opinion, they just don't write here because they can't answer programming questions.

[oldman4U]

After installing Marlin 2.0.8 and the TFT firmware from April 11th (can also try the latest FW) I ran the M600-30.gcode file you provided.

Using Emulated M600: As soon as the first M600 is in gcode, the print stops, retracts filament and pauses the printhead at the position defined in the TFT firmware. The Pause button on the TFT changes to Resume. Pressing Resume filament is loaded, the printhead moves back to the print position, the print resumes and the Resume button changes back to Pause.

Turning Emulated M600 Off: As soon as the first M600 is in gcode, the print stops, retracts filament, pauses the printhead and retracts some additional filament, like defined in Marlin. A popup window is shown with Pause and one Button "Dismiss". Dismissed has to be pressed to continue. After pressing Dismissed it takes some seconds until the next Popup Window is shown with Nozzle Parked und one button "Continue". Continue has to be pressed to continue. After pressing Continue it takes some seconds until the next Popup Window is shown with Paused and 2 buttons "Purge More" and "Continue". After pressing Continue filament is purged and the print resumes. So far so good.

The problem I see is, that after pressing Dismiss or Continue in the Popup window, you can press the Resume button (which turns the button into a Pause button) and after that you can press the Pause button - which finally stalls the print and it s not possible to resume the print anymore.

Do you see the same behaviour or is this already different on your printer Rebel? Please let me know.

[Rebel3D-CZ]

Yes, the process can be done in the same way, except that the pause lasts a few seconds even after pressing the last "Continue" button, when the nozzle is waiting to reheat. For a 30 ° C file, printing starts almost immediately, so there is no time delay, but at the actual fiber print temperature, there is a time lag between pressing the "Continue" button and starting printing (end of waiting for the M600 cycle). At this time, the lower left button on the LCD is in the "Resume" state and will not change to "Pause" until printing starts. If I press this "Continue" button during this time delay, it will make a strange continuous pause movement. So now there are more problem areas with the possibility of unwanted control.

What command does the lower left LCD button send? M602? Is it not a problem that the end of the M602 pause is started in an unfinished M600 fiber change cycle?

Try setting the actual print temperatures in the test file and try it with the thread, the time delays are then slightly different due to nozzle temperature fluctuations.

[oldman4U]

Thank you. I already tested with your file changed to 200 degrees. Will try again.

[oldman4U]

Can you please test and let us know. Thank you

https://github.com/digant73/BIGTREETECH-TouchScreenFirmware/archive/refs/heads/bugfix-2021-05-03.zip

[Rebel3D-CZ]

Ok, I'll try tomorrow. Should I compile or are those bin files current for this bugfix?

[oldman4U]

I would recommend to compile the firmware. Using precompiled from a users repo did not work for me.

You have a reprap screen defined in Marlin. Right?

[Rebel3D-CZ]

Ok, I'm compiling. I don't understand the question well.

[oldman4U]

Test the firmware and let me know.

[Rebel3D-CZ]

It works great! Thank you very much, great solution.

In the Marlin configuration I have no LCD defined, only a COM port for the guest. I use pins on the EXP1-2 connectors, where the serial port and reset of the FYSTEC S6 board are output.

[oldman4U]

Great to hear it works.

Happy printing

[Rebel3D-CZ]

Thank you very much again :)

[digant73]

@Rebel3D-CZ it works properly with M600 but (as reported in my PR) a further PR must be merged on Marlin fw to fully support also the pause (M25). With your Marlin setup (no LCD etc...) if you press on pause button you should not be able to resume the print (you will get always the busy error message on the notification bar). Just wait the Marlin PR is finally merged

[digant73]

@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?

checked also ADVANCED_PAUSE_CONTINUOUS_PURGE. It is properly handled by the TFT

[Rebel3D-CZ]

for testing (after the video) I have a function commented (disabled) //#define ADVANCED_PAUSE_CONTINUOUS_PURGE

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