print progress on TFT

[Paradisebaker]

I got the connection working, movement, heating, baby-stepping, bed-level, that all works.
But for some reason I do not get any printing information on the screen when I print from Klipper.
When I had Marlin with Octoprint connected in parallel to the display via UART (TFT was on serial2), the M75 signalled to the display the start of a print and the progress was taken from the M117 status messages.
My gcode from superslicer still contains the M117, but I had to drop the M75 as Klipper does not understand it.
Now I do not see any progress on the TFT.
Any idea how to do this?
Would another makro translate the M75 to klipper speak?
Thanks for any idea

[freakydude]

Currently the macros work with a combination of two things.

• Enable emit M73 progress support in slicer
• Add the mainsail custom code suggestion, described also in the Readme here (set layer info....)

Check if the serial-btt-bridge.service is running, install socat if missing, adapt the service file itself if needed.

Please do that first, maybe it's already the missing magic

[Paradisebaker]

thats what I wanted !even flow adjustment worksSent from my mobile phone, please excuse brevity and/or spelling errors  -------- Ursprüngliche Nachricht --------Von: freakyDude ***@***.***> Datum: 19.04.23 19:19 (GMT+01:00) An: freakydude/klipper-serial-btt ***@***.***> Cc: Paradisebaker ***@***.***>, Author ***@***.***> Betreff: Re: [freakydude/klipper-serial-btt] print progress on TFT (Discussion #2) Currently the macros work with a combination of two things. Enable emit M73 progress support in slicer Add the mainsail custom code suggestion, described also in the Readme here (set layer info....) Please do that first, maybe it's already the missing magic —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[Paradisebaker]

Hi Freakydude
Sorry for the cryptic reply above, tried to send you a pic from my mobile with a perfectly working display of a print in progress. :)
So here it is:

Anyhow, found two little things today where I would need some information.
First thing, I used the cancel button on the TFT and the print stopped, as I expected. But then Z moved up in some (I believe 3) steps of ~ 50mm each (not sure). After that, the printer went into the homing sequence and I needed to press the emergency stop in Mainsail, so it would not crush into the remains of the cancelled print.
So here my question: which file is the one translating the TFT commands into Klipper/Mainsail commands? And in reverse, which one is modifying the notifications into the gcodes for the TFT?.
The second thing is, after this emergency stop, obviously I had to restart Klipper after turning the printer back on. Then I started a new print (currently doing the "manual" input shaping calibration). The TFT does not get the status as before, but only shows the message "klipper restarted".
any ideas?
Thanks
BR
Markus

[freakydude]

There are more known and unknown issues with it. That's why help is welcome ... or be patient.
Thinking about write known issues here myself to make them transparent for all and fixable...

The behavior of the stop (cancel) button is doing fine. It runs the CANCEL_PRINT in fd-macros-example.cfg (or if you have overwritten, yours). Itself it calls subscripts ... Its moving x a view mm away back,right and up. While it retracts the same time by currently -3mm. (i see a little bug, but it will not explain your behavior, i will fix that)

Then it presents you the print. Means your bed is coming in front of you, the toolhead goes up by 25mm.

Are you sure it will crush into anything? You could test that by printing a object without filament ...

Your second question.
There are 3 "internal" macro files.

• bigtreetech-support.cfg has all the implemented Marlin commands as far as tested and needed by the touchscreen. Also the sending of information to the btt
• klipper-modules has all modules needed from klipper to support the touch screen and mainsail features
• mainsail-support has the gcode macros which have the logic needed for mainsail, and also trigger commands from bigtreetech-support for the display

fd-macros-example is the one you could replace, but make sure you call the "internal" fd macros anyways. This macro file is more or less a facade, Enables the user to replace that and hopefully adapt to his needs without modifying the other files ...
As far as I know, there is no way to replace a macro twice - so it's the only solution

Emergency Stop. Yes. The display will be dead after an Emergency stop. I did not found a the reason yet or if it is fixable. Think it's because klipper dies hard ... and maybe the serial connection with it.
I decided to pass the emergency anyway - because thats what it is. At the moment you have to restart your printer after that. Sorry ;-)

Grüße

[freakydude]

My blog post is online

[Paradisebaker]

Hi Freakydude

I hope you did not misunderstand me, this was NOT any kind of complaint or accusation.
I only wanted to report my observations, so you could either point me in the right direction to solve the problem myself and report back to you, thus helping you to make your project perfect, or let me know if it is a known thing already.
Might as well be that I did something wrong or that my setup showed differences.

Anyhow, I just tried the thing again: print, then use the cancel button on the screen. The print gets cancelled, the print head moves up (several times), then the homing sequence starts. since I didnt really print anything this time, I let it finish and collected the console output.
One thing is funny, even though the homing went trough and the coordinates confirm that, Mainsail does NOT recognize the printer as homed.
The console output states at one point "unknown command: M524", which is Abort SD print.
Anyhow, here is the console output, maybe you see something that can be adjusted to make this just cancel the print and not initiate the homing sequence.
Thanks a lot

16:25:58
X:150.000 Y:150.000 Z:10.000 E:1.325
16:25:56
ok
16:25:55
ok
16:25:55
ok
16:25:55
M106 S0
16:25:55
M420 S1 Z0.0
16:25:55
M851 X34.0 Y-18.0 Z1.3
16:25:55
M206 X0.0 Y0.0 Z0.0
16:25:55
M201 X3000.0 Y3000.0 Z200.0 E798.2432411074329
16:25:55
M203 X250.0 Y250.0 Z50.0 E66.52027009228607
16:25:55
ok
16:25:55
ok
16:25:55
Not SD printing.
16:25:55
ok
16:25:55
ok
16:25:55
X:150.000 Y:150.000 Z:10.000 E:1.325
16:25:55
ok
16:25:13
ok
16:25:13
X:150.000 Y:300.000 Z:108.200 E:1.325
16:25:13
ok
16:25:13
ok
16:25:13
ok
16:25:13
Not SD printing.
16:25:13
X:150.000 Y:300.000 Z:108.200 E:1.325
16:25:13
ok
16:25:13
Unknown command:"M524"
16:25:13
ok
16:25:13
action:cancel
16:25:12
M106 S0
16:25:11
//action:cancel
16:25:11
ok
16:25:11
action:cancel
16:25:11
M106 S0
16:25:10
//action:cancel
16:25:10
ok
16:25:10
action:cancel
16:25:10
M106 S0
16:25:07
//action:cancel
16:25:07
ok
16:25:07
M106 S0
16:25:06
//action:cancel
16:25:05
X:90.557 Y:88.057 Z:0.200 E:0.000
16:25:05
X:90.557 Y:88.057 Z:0.200 E:0.000
16:25:00
ok
16:25:00
X:216.239 Y:87.500 Z:0.200 E:12.122
16:25:00
X:216.239 Y:87.500 Z:0.200 E:12.122
16:24:54
X:87.811 Y:213.342 Z:0.200 E:5.025
16:24:54

[freakydude]

No, I understood that right. No worry. I just want to explain what happend and where you can find information.

Maybe you are able to nail down the root cause by yourself.

Your output seems very strange to me... (there are coordinates xy 3000 before cancel.... That cannot be)

Also, cancel action ist triggered more than once...

You are printing with the artillery, right? Could you give me this gcode file?
did you initiate the print from mainsail or from the SD card?

[Paradisebaker]

I initiated the print from Mainsail, then cancelled from the tft screen of the Artillery Sidewinder X1.
I dont think that the xy3000 refers to the position, more likely to my acceleration. the multiple cancel is strange, I fully agree.
That is why I wanted to understand how the commands from the tft are being translated into klipper gcodes.
The gcode file is nothing special, I started the calibration print for input shaping again (without filament and without the test tower command), but cancelled for testing right after the start, so I do not think it has anything to do with this.

[freakydude]

Ah sorry, yes that's right. It's the acceleration. Should not read while eating 😬

Hm

You could stop the service an start the serial sevice and start the execstart command in the service file instead manually. Add the -v Option. You should see what's sended from display to Klipper and vice versa

Display is a gcode streamer. Just sends marlin compatible commands.. Has a 'wild' response behavior. Could be better solved, but isn't.

[freakydude]

Printed and stopped right now some thing again and it went as expected. So you may have a problem somewhere else... Suggest you start with my scripts 1:1. Try it ...
If it works, you are can be sure ...

[freakydude]

Did you find the reason?

[Paradisebaker]

no, didnt have any time lately. the little I had, I used to get my input shaping tuned.
anyhow, I think it might have to do with the TFTs config.ini file. It could be that there are some settings different between yours and mine.
I did now download the newest tft firmware (from Digant) and adjusted the config.ini according to what I think should be correct.
It is attached (had to change the extension to txt), so you could point out anything that jumps at you.
Alternatively, please send me your config.ini and I will look at the differences.
Thanks
config.txt

[Paradisebaker]

ok, after removing includes for mainsail.cfg and fluidd.cfg and further cleaning out of redundant macros, the problem is gone.
so that part is clear.
one thing I dont understand is that pause works just fine, but pause_at_next_layer pauses the print, goes to park, then resumes immediately, but restores only x and y, z stays up at the z-hop height, the print goes on in the air.
any ideas?

[freakydude]

I will retest that...

[Paradisebaker]

one more thing, for some reason pause and stop dont work from the screen, I get "busy processing". I could swear that it used to work. can you tell me the pieces of code needed for that, so I can verify if they may have become victims of my cleaning?
thanks a lot

[freakydude]

Stop-> [gcode_macro M108] in fd-macros/bigtreetech-support.cfg
Pause/Resume/Cancel -> [gcode_macro M118] in fd-macros/bigtreetech-support.cfg

If you need to know, what's going on, watch your serial connection per ssh console on your pi ...
If you press a button on the display, it will send a gcode command there ... in my configs the entry point is always the bigtreetech-support.cfg in this cases.

[Paradisebaker]

Freaky, thanks for the quick answer.
since I did not mess with the macros, I thought it might be the TFT.
So I checked for bugs with the firmware I installed the other day (because I thought it might help with the weird behaviour) and found indeed some people complaining about the "busy processing" thing. Then I saw that Digant has come out with a brand new firmware 5 days ago, I installed it and all is good again. Stop works, pause works, after triggering the filament sensor, I can resume directly from the TFT, I am one happy camper.

This leaves the weird pause at next layer thing. but I am sure I will find the reason for this as well...
Keep you posted

[freakydude]

Found something. After press cancel the display sends M108 as long as it got no response from klipper.
this happens on any longer current gcode print command.
so the display resends M108 again and again.
this triggers a lot cancel print command. They are queued.

So, this results in moving the print head several times upward.

Don't know how to solve this yet...

[freakydude]

@Paradisebaker I did a update of the scripts. And the pause/resume/stop scripts are now implement a little bit different. Try it again if you like - maybe your problem with the layer change is also gone.

[Paradisebaker]

Hi Freakythanks, I will try, will take a little,, am pretty busy right now.will let you know....Sent from my mobile phone, please excuse brevity and/or spelling errors  -------- Ursprüngliche Nachricht --------Von: freakyDude ***@***.***> Datum: 09.08.23 00:16 (GMT+01:00) An: freakydude/klipper-serial-btt ***@***.***> Cc: Paradisebaker ***@***.***>, Mention ***@***.***> Betreff: Re: [freakydude/klipper-serial-btt] print progress on TFT (Discussion #2) @Paradisebaker I did a update of the scripts. And the pause/resume/stop scripts are now implement a little bit different. Try it again if you like - maybe your problem with the layer change is also gone. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>