search

bigtreetech / BIGTREETECH-TouchScreenFirmware

support TFT35 V1.0/V1.1/V1.2/V2.0/V3.0, TFT28, TFT24 V1.1, TFT43, TFT50, TFT70
GNU General Public License v3.0
1.3k stars 1.65k forks source link

M600 - not working properly #1829

Closed Rebel3D-CZ closed 3 years ago

Rebel3D-CZ commented 3 years ago

M600 function

I currently have:

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

  1. 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
  2. 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 commented 3 years ago

@Rebel3D-CZ see also https://github.com/MarlinFirmware/Marlin/issues/21669 and the fix https://github.com/MarlinFirmware/Marlin/pull/21670

oldman4U commented 3 years ago

So what are we going to do that a user does not press a button in our interface which should not be pressed even it is there snd can be pressed..?!

digant73 commented 3 years ago

that is a minor improvement but not the cause for the problem

fiveorders commented 3 years ago

@bigtreetech when do you think this issue will be solved? I tried with marlin mode right now it works as it should be. when I move to touch mode it cannot resume after it goes back to its position and purges filament while going there although it is disabled in Marlin. So it creates a blob and stays on it like that. (M600 emulation is disabled) Any estimate will be appreciated. Thanks

digant73 commented 3 years ago

@fiveorders can you monitor the traffic between Marlin and TFT? if so, please provide us the output. Althougth I'm pretty much sure the problem is on Marlin (I had such kind of problems in the past and it was due to resource handling on Marlin). In my case, althougth Marlin properly sent the dialog "Purge more or Continue", the print was automatically resumed moving the nozzle on the print and purging on top of that. Also the pause was not working (the nozzle was parked and automatically moved again on top of the print and then paused on top of the print)

fiveorders commented 3 years ago

@digant73 I have ESP3D module installed and I can see the command line if that is what you are mentioning. In marlin mode, everything works flawlessly. What kind of resource problem do you think happens?

Normally only one button is enough on TFT to proceed. Rest is handled by marlin. So why it is going back to its point and stopping there? And also although the last purging while resuming is disabled on Marlin firmware, it purges again while resuming to its last position if the M600 process gone through TFT. So I believe there is something wrong with the signals that TFT sending to Marlin. I am not an expert just assuming. It looks like the failure is on TFT due to the last purge function although it is disabled.

digant73 commented 3 years ago

The output intercepted by ESP3D is enough. In my case I needed to decrease the UBL grid size to 7x7. With a 10x10 grid size Marlin had a 94% of RAM usage and a 91% of FLASH usage. With a 7x7 grid size RAM was 89% and FLASH 85%. Pretty much sure the problem was due to no more available (dinamic) RAM. With a BBL there never was any problem due to RAM and FLASH a lot below (65%, 70%). If you can, with ESP3D follow the traffic exchange during any M600 step. e.g. when the nozzle is parked, when you press on a dialog button, when the nozzle is moved on top of the print etc... From the dialog exchange, we can understand if the problem is on TFT (e.g. a dialog currently not handled by the TFT) or is in Marlin. If the dialog is the expected one but the behavior is not the expected one, the problem is on Marlin (as it was for me). E.g. I saw Marlin sending the dialog to "purge more/continue" but then it also immediately resumed the print without waiting for any reply from my side (without pressing on any button)

fiveorders commented 3 years ago

@digant73 This what exactly happening:

T:215.00 /215.00 B:60.00 /60.00 @:58 B@:21 T:214.00 /215.00 B:60.00 /60.00 @:97 B@:21 //action:prompt_end//action:prompt_begin FilamentRunout T0//action:prompt_show//action:paused filament_runout 0 T:215.00 /215.00 B:60.00 /60.00 @:53 B@:20 echo:busy: processing //action:paused T:215.00 /215.00 B:60.00 /60.00 @:56 B@:21 echo:busy: processing echo:busy: processing T:215.00 /215.00 B:60.00 /60.00 @:60 B@:21 echo:busy: processing X:150.0000 Y:10.0000 Z:20.0000 E:25.4821 Count A:12800 B:11200 Z:8000 T:215.00 /215.00 B:60.00 /60.00 @:61 B@:22 echo:busy: processing T:216.00 /215.00 B:60.00 /60.00 @:20 B@:22 echo:busy: processing T:215.00 /215.00 B:60.00 /60.00 @:61 B@:22 echo:busy: processing echo:Insert filament and send M108 //action:prompt_end//action:prompt_begin Nozzle Parked//action:prompt_button Continue//action:prompt_showecho:busy: paused for user T:215.00 /215.00 B:60.00 /60.00 @:65 B@:22 echo:busy: paused for user T:215.00 /215.00 B:60.00 /60.00 @:69 B@:22 echo:busy: paused for user echo:busy: paused for user T:215.00 /215.00 B:60.00 /60.00 @:64 B@:22 echo:busy: paused for user T:215.00 /215.00 B:60.00 /60.00 @:59 B@:22 echo:busy: paused for user echo:busy: paused for user T:215.00 /215.00 B:60.00 /60.00 @:58 B@:22 //action:prompt_end//action:prompt_begin Filament Purging...//action:prompt_button Continue//action:prompt_showecho:busy: processing T:215.00 /215.00 B:60.00 /60.00 @:57 B@:27 echo:busy: processing echo:busy: processing T:215.00 /215.00 B:60.00 /60.00 @:56 B@:40 echo:busy: processing T:215.00 /215.00 B:61.00 /60.00 @:57 B@:0 echo:busy: processing echo:busy: processing T:215.00 /215.00 B:60.00 /60.00 @:56 B@:43 echo:busy: processing T:215.00 /215.00 B:60.00 /60.00 @:54 B@:34 echo:busy: processing //action:prompt_end T:214.00 /215.00 B:61.00 /60.00 @:90 B@:0 W:? T:214.00 /215.00 B:60.00 /60.00 @:89 B@:45 W:9 echo:busy: processing T:214.00 /215.00 B:60.00 /60.00 @:87 B@:40 T:214.00 /215.00 B:61.00 /60.00 @:84 B@:0 W:8 T:214.00 /215.00 B:60.00 /60.00 @:81 B@:33 W:7 echo:busy: processing T:214.00 /215.00 B:60.00 /60.00 @:81 B@:29 W:6 T:214.00 /215.00 B:60.00 /60.00 @:81 B@:24 T:214.00 /215.00 B:60.00 /60.00 @:81 B@:27 W:5 echo:busy: processing T:214.00 /215.00 B:61.00 /60.00 @:81 B@:0 W:4 T:214.00 /215.00 B:61.00 /60.00 @:82 B@:0 W:3 T:214.00 /215.00 B:61.00 /60.00 @:83 B@:0 echo:busy: processing T:214.00 /215.00 B:61.00 /60.00 @:83 B@:0 W:2 T:215.00 /215.00 B:61.00 /60.00 @:48 B@:0 W:1 echo:busy: processing T:215.00 /215.00 B:60.00 /60.00 @:56 B@:25 W:0 //action:notification Print Paused T:215.00 /215.00 B:60.00 /60.00 @:59 B@:24 echo:busy: processing T:216.00 /215.00 B:60.00 /60.00 @:30 B@:19 echo:busy: processing echo:busy: processing //action:resumed//action:notification Printing...FR:100% echo:E0 Flow: 100% T:216.00 /215.00 B:60.00 /60.00 @:47 B@:12 FR:100% echo:E0 Flow: 100% T:216.00 /215.00 B:60.00 /60.00 @:47 B@:5 FR:100% echo:E0 Flow: 100% FR:100% echo:E0 Flow: 100% T:215.00 /215.00 B:60.00 /60.00 @:73 B@:0 FR:100% echo:E0 Flow: 100% T:215.00 /215.00 B:60.00 /60.00 @:63 B@:0 FR:100% echo:E0 Flow: 100% FR:100% echo:E0 Flow: 100% T:215.00 /215.00 B:59.00 /60.00 @:61 B@:76 FR:100% echo:E0 Flow: 100% T:215.00 /215.00 B:60.00 /60.00 @:61 B@:0 FR:100% echo:E0 Flow: 100% FR:100% echo:E0 Flow: 100% T:215.00 /215.00 B:59.00 /60.00 @:61 B@:83 FR:100% echo:E0 Flow: 100% T:215.00 /215.00 B:60.00 /60.00 @:61 B@:0 //action:notification ZLC Ready. T:215.00 /0.00 B:60.00 /0.00 @:0 B@:0 echo:busy: processing M106 P0 S0

fiveorders commented 3 years ago

and this is the result IMG_0815

digant73 commented 3 years ago

so you pressed on the "Continue" button in the dialog reporting "Filament Purging" and the print was resumed but the extra purge was done on top of the print, right? In that case, it seems the problem is in Marlin. I don't see any other dialog from Marlin to TFT

fiveorders commented 3 years ago

Not only extra purge, but also it stops there and does not move. It does not resume printing, I mean.

digant73 commented 3 years ago

ok, but the "resume" button on the botton left of the TFT is changed to "Pause" when the print is resumed, right? In that case the TFT is working properly and the bug is on Marlin. I already explained the problem I had and the cause of that on Marlin. If you are in a similar condition, try to switch to BBL in Marlin and verify if it works properly

fiveorders commented 3 years ago

Good point. No, it didn't change to II Pause, it stayed Resume

digant73 commented 3 years ago

that's happend because Marlin sent //action:resumed instead of "...:prompt_begin Resuming". It is not the cause of the problem. I can create a PR just to fix that problem and verify that even solving that problem, the bug persists.

digant73 commented 3 years ago

@fiveorders PR #1888 should fix your problem with the "Resume" button not switching to "Pause". I don't think this is the reason for ther main problem (purge on top of the print and print stopped) but you can use it just to verify it fixes the problem with "Resume" button. Please let us know the result

digant73 commented 3 years ago

@Rebel3D-CZ could you provide us the output you get (as did by fiveorders)? Also could you try PR #1888 and let us know the result?

fiveorders commented 3 years ago

@Rebel3D-CZ could you provide us the output you get (as did by fiveorders)? Also could you try PR #1888 and let us know the result?

I will respond with the results as soon as possible. I am just in the middle of a large print. Maybe @Rebel3D-CZ can respond earlier. Many thanks btw

digant73 commented 3 years ago

@fiveorders any update from your side (trying pr #1888)?

fiveorders commented 3 years ago

@digant73 I am really impatient to try but I had to disassemble the machine for a reason, and the next first thing is trying this fix. Sorry for the delay. I will be able to test it latest on Sunday.

oldman4U commented 3 years ago

You need more Printer

fiveorders commented 3 years ago

You need more Printer

I do but all others are Prusa style cartesian :) I can try on one of them as well however I need to assemble this first because I can't move in the room

oldman4U commented 3 years ago

So you need more rooms😁

fiveorders commented 3 years ago

moreover, I need a life 😄

oldman4U commented 3 years ago

More time....🤪

Rebel3D-CZ commented 3 years ago

@ Rebel3D-CZ mohl byste nám poskytnout výstup, který získáte (stejně jako u Fiveorders)? Můžete také vyzkoušet PR # 1888 a sdělit nám výsledek?

Na výsledky odpovím co nejdříve. Jsem právě uprostřed velkého tisku. Možná @ Rebel3D-CZ může reagovat dříve. Mnohokrát děkuji btw

But I don't have a BLOB problem. I had this problem if I used a pause emulated by TFT. Anyway, I upgrade the latest version of Marlin BUGfix, then I send a pause, I have an ESP module on TFT.

Rebel3D-CZ commented 3 years ago

In any case, with the latest version of the Marlin BUGFIX, the manual PURGE also works. However, the impatient person must not press the CONTINUE button in the lower left corner of the LCD (the nozzle must be reheated and the pause process then continues correctly), otherwise there will be a mysterious uncontrolled shift to the parking position and back and large filament extension and retraction before printing, see my video above .

digant73 commented 3 years ago

@ Rebel3D-CZ mohl byste nám poskytnout výstup, který získáte (stejně jako u Fiveorders)? Můžete také vyzkoušet PR # 1888 a sdělit nám výsledek?

Na výsledky odpovím co nejdříve. Jsem právě uprostřed velkého tisku. Možná @ Rebel3D-CZ může reagovat dříve. Mnohokrát děkuji btw

But I don't have a BLOB problem. I had this problem if I used a pause emulated by TFT. Anyway, I upgrade the latest version of Marlin BUGfix, then I send a pause, I have an ESP module on TFT.

It's just to check the dialog exchanged between marlin and TFT and see if it's ok, as done with fiveorders

Rebel3D-CZ commented 3 years ago

logged in to the serial port. for some reason ESP displayed only part of the listing. There is no difference between pauses (normal / with RESUME pressed). I replaced the extra lines with "." and shortened the protocol:

T:210.18 /210.00 B:60.17 /60.00 @:47 B@:18 //action:paused //action:prompt_end //action:prompt_begin Pause //action:prompt_button Dismiss //action:prompt_show T:210.21 /210.00 B:60.16 /60.00 @:45 B@:22 echo:busy: processing . T:210.52 /210.00 B:60.16 /60.00 @:39 B@:23 echo:busy: processing //action:prompt_end //action:prompt_begin Nozzle Parked //action:prompt_button Continue //action:prompt_show T:210.44 /210.00 B:60.19 /60.00 @:43 B@:21 echo:busy: paused for user echo:busy: processing . echo:busy: processing //action:prompt_end //action:prompt_begin Paused //action:prompt_button PurgeMore //action:prompt_button Continue //action:prompt_show echo:busy: paused for user T:209.62 /210.00 B:60.21 /60.00 @:49 B@:16 //action:prompt_end echo:busy: processing . T:209.93 /210.00 B:60.03 /60.00 @:42 B@:23 //action:resumed //action:prompt_end //action:prompt_begin Resuming //action:prompt_button Dismiss //action:prompt_show T:210.39 /210.00 B:60.06 /60.00 @:40 B@:15

digant73 commented 3 years ago

@Rebel3D-CZ the dialog is correct (it is properly handled by the TFT). If you are using UBL try to switch to BBL and verify if M600 will work

Rebel3D-CZ commented 3 years ago

The problem is not in the dialogue. The serial console does not display all commands. If you press "Resume" unintentionally (lower left LCD button), there must be communication between the LCD and Marlin that is not visible in this way (as well as gcode commands).

digant73 commented 3 years ago

but you know that the resume button has not to be pressed with M600 handled by marlin. If the dialog you provided is the whole dialog you saw before you have the problem it means the problem is in Marlin (that dialog is properly handled by TFT)

Rebel3D-CZ commented 3 years ago

I do not understand this logic. The option of pressing an option that results in an error is not correct. I dare say it's not Marlin's fault. Marlin only listens to what is being sent to him, and if a non-standard code is sent to him, he may not respond correctly. This false squeeze cannot be done when using GLCD or MarlinMOD TFT. I wouldn't throw a mistake at Marlin, but I would try to avoid non-standard situations. Don't you think?

digant73 commented 3 years ago

do not mix a possible improvement on the TFT like disable/make not visible some buttons (e.g. "resume") during M600 handled by Marlin with the real problem you have (the print is not properly resumed after M600). Referring to that problem, the dialog with the TFT is properly handled. There is no "not standard" situation. Marlin 2.0.8 is finally available. I would also update to it.

Rebel3D-CZ commented 3 years ago

I tested on the latest version of Marlin. I don't mix anything. From the logic of the matter, the M600 is a defined cycle that I should not be able to hit with TFT commands other than "Contine" and "Purge" before completing the M600 cycle. The same applies when using Marlin MOD TFT or with other line or graphic LCDs, so no command other than "Purge" and "Continue" can be sent from the LCD. I don't understand why Marlin FW should solve this, it's a TFT problem that allows you to send an unwanted command.

kisslorand commented 3 years ago

Anyone can send unwanted commands from various other sources too, like Octoprint, Pronterface, Terminal, etc. Noone ever complained about that.

oldman4U commented 3 years ago

Rebel. I agree 100% that the TFT never should show a button which can not be executed or which causes an issue.

Kisslorand. But here it is about the TFT and our responsibilities.

The initial reason for this ticket is solved. I would close it and open a new ticket, or I will open it.

Rebel3D-CZ commented 3 years ago

@kisslorand Most cars have 4 wheels and will work, but the question is how it works. @oldman4U I agree, I'll close the ticket. Please open a new one with a concise description? I'm not good at English.

oldman4U commented 3 years ago

First I will update Marlin and then I will open the ticket. Promised.

Rebel3D-CZ commented 3 years ago

Okay, thank you, I'm closing ....

digant73 commented 3 years ago

@Rebel3D-CZ as GLCD do you mean an LCD in Marlin mode only?

Rebel3D-CZ commented 3 years ago

I am thinking mainly of the way in which no unexpected command can be sent in TFT Marlin MODE or GLCD "REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER" or similar controllers. In addition, the M600 is a "change filament", so I always control it with a printer from the LCD and not from the Octoprint, etc.

digant73 commented 3 years ago

I meant if the GLCD you used, and worked with M600, was on Marlin mode only. In that case the handling is different.

Rebel3D-CZ commented 3 years ago

I take it in terms of the possibility of sending an unwanted command, which is not easy with the GLCD display. Unfortunately for TFT, yes, because the print screen with the lower left LCD button "Continue" is waiting for the hotend temperature to stabilize. If you press this button, a spontaneous PAUSE / RESUME cycle is performed after printing starts.

digant73 commented 3 years ago

it 's only a bug in Marlin (as there were many others) that will be fixed. Maybe you should open a ticket on Marlin repo.

Rebel3D-CZ commented 3 years ago

I really don't consider it Marlin's fault. We don't know what TFT is sending to Marlin and why this error occurs. Marlin can say the same thing that the TFT should not send him unexpected commands during the M600 cycle.

kisslorand commented 3 years ago

OK, Let's say you print from Onboard SD. In that case Marlin takes over the gCode from the onboard SD Card. When Marlin gets to an M600 gCode it sends an info to the TFT that it is paused but doesn't tell why it is paused. How should the TFT know that it is a real pause or a pause during a "M600 cycle"???

It's just a simple case where it is obvious that Marlin should ditch any incoming gCodes while in a "M600 cycle" or at least put those commands in a buffer and not execute them until whatever cycle he's in is not finished.

Rebel3D-CZ commented 3 years ago

Why should I use an onboar reader if I have a TFTxx with my own reader and a USB port? Personally, I would not even offer this option in FW TFTxx, but I believe that there will be someone who will use it, but I think it is a non-standard solution. Everyone has some opinion and experience, but some cases can be prevented at the FW TFTxx level.

kisslorand commented 3 years ago

Why should I use an onboar reader if I have a TFTxx with my own reader and a USB port?

I don't know, ask other users who do.

I just pointed out a single situation where it is not possible to implement the denial of resume when paused. There are more.

Personally, I would not even offer this option in FW TFTxx, but I believe that there will be someone who will use it, but I think it is a non-standard solution.

What you want is a personalized FW for your specific needs. Sorry, for personal FW you have to do it yourself (as many user here does).

Rebel3D-CZ commented 3 years ago

What is this nonsense? What specific need? You probably don't understand, but I can't explain it better.

kisslorand commented 3 years ago

Yeah, I probably do not understand :) But do you understand that there can be situations when the TFT cannot be aware if it is forbidden or not to press a button?