[BUG] Printing from OctoPrint does not show up in touch mode #1673
Comments
|
This is not a screen or firmware issue. |
|
Would you be able to provide some basic information regarding the things necessary to make Octoprint work with the TFT? I would add them to the ReadMe then. Thank you |
|
Ok, that makes sense then since the print I was trying was a bed leveling test print and has no layer information, therefor DisplayLayerHeight doesn't do anything for this print. iirc, the MKS Robin Nano I was using before would still show the print screen regardless of whether or not DisplayLayerHeight was going. Could be wrong though. |
|
Just printed a temp tower that does have layer information in it and OctoPrint showed the layer information itself, but the display never reacted to it printing. Just kept showing the same information start page. |
|
Possibly related to whatever is keeping the display from showing any printing updates, but the fan is on at around 20% and the TFT says 0%. |
|
Didn't wanna mess with it while it was printing, but yes, Marlin mode is getting the printing updates:
XYZ are fine, they were flashing due to steppers being off. |
|
PR #1681 claims |
|
It will not do that until someone implements it in the FW. As it is at the moment the TFT doesn't "know" that someone from the outside is printing and not just sending gCodes. |
|
I'm 99% sure that Octoprint sends out a message as soon as it begins a print that the TFT could use as a signal that a print has been initiated. I'm in the middle of a print right now but will check when its done. |
|
No need to check anything. I said it is not implemented, not that it cannot be implemented. |
|
there also an feature request allready... #1170 and #810 i guess the main issue is as long as another print host is sending gcode, the tft cannot display the full "print-menu-Screens" because there would be buttons that just cannot work... and with that, there is quite some work todo, to achieve it.. but i've allready voted for that too, would be really ah great addition.. even though, as i started printing with octoprint lately, i see some potential, but still not fully commited to octoprint, rather it is the need to install 30ish plugins to get to the point what the btt tft can achive, and still missing one of the biggest features yet on octoprint is powerless return... even the simpliest version of it, as i found out recently :( |
|
i've even had another idea... i thought about having the Pi act as an USB Device to the TFT screen... so basically it would not be possible to start the print from the pi on the TFT (still on the board directly) but it would be possible to start the print from the TFT, reading from the Pi... didn't tested what happens when starting in normal condition now from TFT, if the pi is getting the correct info that some print is ongoiing... even can't imagine what would happen then when pi stops the print... anyway my idea also stopped immediatly as i just found out that the pi can't act as an USB Slave/OTG device :( |
|
@DaStivi Not sure what #1175 has to do with this... I understand this hasn't been implemented yet, but not sure what buttons would not be able to work. Even just being able to see the basic printing information screen and being locked out of certain critical functions (ie: can't start print while one in progress, can't use movement commands, etc). As far as detecting a print is in progress, Octoprint sends a And if Marlin on the main board can detect a print in progress and react accordingly, why wouldn't the TFT that's connected via serial to the main board? |
|
For example "Pause" would not work, "Stop" neither. |
https://docs.octoprint.org/en/master/features/action_commands.html Job percentage would just be showing the received M73 and M117 commands. The current information screen can already show those M117 updates. Admittedly, this is no longer a Bug Request as I had originally thought, but now a Feature Request. As for the reasoning behind it, I often look in on long running prints while they are printing and usually I do not have my laptop opened up. Being able to use the TFT to pause or cancel a print would be immensely helpful, especially if my wife looks at it while I'm not home and she sees its FUBARed the print. I also will sometimes initiate multiple prints from work with my wife removing the resulting parts in between print jobs. I have to assume that I am not the only one who frequently uses a host program like Octoprint and would benefit from being able to also have local control of the print without the need for logging into the web interface. |
|
Also, as far as stopping and pausing, sending custom gcode like |
|
I understand the need for such things but as I said, it needs another menu/screen. The present printing menu is not suitable for printing from outside from an outside storage. |
|
Custom Cancel GCode is already supported, which could stop Octoprint then, although there doesn't appear to be any Custom Pause GCode yet. I'll look into OctoDash and also into learning C/C++ to be able to implement it myself. |
|
Closing this since in hindsight its not actually a bug |
|
May I can ask two probably stupid questions?
Why would I like to do everything related to a print using the TFT but to
start the print?
As far as I know there is a screen available from BTT which allows to work
with Octoprint? Why not using this screen instead?
Thank you
lightmaster <[email protected]> schrieb am Mo. 8. März 2021 um 01:09:
… Closed #1673
<#1673>
.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1673 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AM6XKZH256OERESD7BMI45LTCQIUZANCNFSM4YWLL6XQ>
.
|
|
sorry looks like there was ah typo... have meant #1170 (Featurerequest List) btw. i still didn't understood what happens... i've re-read your posts, and do i understand you correctly that the "detailed progress" and "display layer progress" plugins doesn't show the updates in the "notification" window on the btt tft?? i also don't understand what the bugfix #1681 is now dooing? i've just tested this now, still with the #1680 commit compiled and i just have the M117 status update on (echo) tft screen: |
M117 messages do show up in that box in the middle. I mistakenly thought that PR was supposed to allow all prints started remotely to initiate the printing menu, whereas I guess it just means all SD card prints started remotely. I'm dropping this idea anyways, since clearly I'm in the minority that would care about this and don't want to get in the way of development of features that everyone will use. Sorry for wasting people's time. |
you're definitely not wasting anyones time, and its ah great idea, as i posted it has been requested ah couple of times allready :) i gonna test later something... the 1680 does fix something that caused the touch mode print display shows up when printing from marlin mode onboardSD when serial_always_on = enabled ... this has been fixed, and also there is bugfix now.. my idea is now, i go back to ah version with this bug again and like to see what happens when starting ah print from octoprint, in marlinmode display, would be interessting if the tft switches to touch print display then 🤣 |
|
I can not speak for the others but you are not wasting my time! There is always something to learn and just because I do not use it or understand what it is good for does not mean it should not be implemented. |
It's not a bug.... It's a feature 🤣🤣🤣 |
|
Sometimes it is hard to know.... And sometimes it is a feature for one and a bug for the others. 🤯 |
My thoughts about it were simply consolidation. It seems there are ways of communication between remote hosts like Octoprint and Marlin (action commands), so why not use that to allow easier control? Regardless of how a print is initiated, the screen physically attached to the printer could have at least basic control such as pausing, stopping, and resuming. The print screen would already be able to control fan speed and temp adjustments (at least until gcode applies new values for these). The printing source like Octoprint can send out M73 progress updates for the progress bar and time remaining type stats. I have basically no specific knowledge of programming in C/C++ and only understand a tiny amount of the code for this, so maybe it's just not possible, idk. But I feel like there has to be a way for the screen attached to the printer that has serial communication with it to be able to have at least basic control regardless of where the print commands are coming from. |
|
yes i definitely agree... and i really love the bTT TFT... evenmore as i just found out what everything does not work from octoprint (like powerloss recovery) i search of ah way to combine each other at possible best solution to assist my printing.. and i also have almost no knowledge about coding so i really can help finding bugs, this what i am good at looks like, because i try ah lot of things and really master into stuff :) |
|
It is possible to have a print status/control screen when printing from USB, it just have to be implemented. The current menu during print from TFT is not suitable for this. |
|
Not sure I remember right but some users used a UART connection for this I believe 🤔 |
|
and further more some interessting comment caught my eye...
there @kind3r is reports random freezes of the tft when octoprint is connected... interesstingly as i also still have random freezes and i've connected the ESP01s module to the uart port on the tft all the time! so this is still might be an issue and every user caught that just moved on and didn't use it anymore ?! |
i gotta tested this now... and its broken as hell... also printing from octoprint directly does not trigger the bug... so only printing from pi from the onboardSD have triggered it.. so octoprint did displayed the ongooing print job, and also the TFT did swicht from marlin to touch print display so far so good.. but of course everything else gooing crazy... as one of the first issues is that when printing fom onboardSD processing of adjustment commands is put into the queue, so octodash/print and TFT rather displays different thing when trying to change anything from on or the other side... interesstingly pausing the print did worked from TFT, strange thing is that the print head moved to ah position where i never saw it at pause?! 🤷♂️
unpausing didn't worked, neither from TFT nor Octodash... also canceling, TFT doesn't even do anything, octodash displayed canceling but looks like never do anything...
so funny little test but not to recommend in anyway 🤣 |
|
Indeed, there were issues when connecting via the screen ( I ended up connecting both the PI and the TFT directly to the Board as it has 2 serial ports. This does not allow me to monitor the printing status or pause/stop the print on the TFT (except in Marlin mode ... yuk), but I can still change most params on the fly while it is printing. What does bug me tho is that using the rotary encoder during printing changes the feed rate and if I'm not careful that could mess up my print sometimes. Now that I have a JTAG debugger I might be able to dig a bit deeper into the uart issue, as time permits. If this issue is fixed, there are 2 options:
Going one step further, as a crude version, I belive pausing can be achived by not forwarding OctoPrint's g-code to the Board and sending busy responses back. Stopping could just disconnect OctoPrint and cause it to abort printing. |
|
i really think that connecting something to the UART Port on TFT might freeze it... hopefully we can figure this one out.. as i said, i've connected an ESP01s module to the TFT since ah while... and i did got ah lot of freezes, but they're might have numerous issues, as there where some freezing bugs... and i ruled them out all by now... as i use octoprint for printing, and still i got once freeze of the TFT even with octoprint now... I'd might open an bug/issue report so that we can track that down?!
this works with Pi <-> Board <->TFT too... there are plugins on octoprint to send the M117 commands, and TFT does display it (as long as the status "screen" is enabled) |
|
In the case of |
that definitely works as expected! you can see my pictures in this topic here! #1673 (comment) |
|
@digant73 @guruathwal Do you think it's possible now to switch to printing menu when printing with Octoprint with this PR ? This PR adds cap:HOST_ACTION_COMMANDS:0/1 to the M115 extended capabilities report so hosts like OctoPrint can check for basic host-firmware interaction with //action: commands. For more complete interactivity you should enable HOST_PROMPT_SUPPORT and this will report cap:PROMPT_SUPPORT:1 to the host.
|
|
@Guilouz no. It only informs the host (TFT, Octoprint etc...) if host actions are supported (enabled) or not by Marlin. That information can be used by the host just to understand if it can use features requiring host actions or not |
Ok Thanks. |
|
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. |
Description
When I initiate a print from OctoPrint, the touch mode does not show any printing information and doesn't seem to notice that a print has been initiated. I can still control babystepping from the touch screen and I can see the hotend and bed temps during a print, so clearly there is still communication between the screen and board.
Steps to reproduce
Expected behavior
When a print is started from any source, including TFT SD card, main board MicroSD card, and main board USB, the TFT touch screen should show the printing screen with various bits of information about the ongoing print.
Actual behavior
TFT touch screen fails to detect that a print has been initiated.
Hardware Variant
Using TFT43 and SKR 1.4 Turbo
TFT Firmware Version & Main Board Firmware details
TFT Firmware compiled from
master, branch on 2021-03-05SKR 1.4 Turbo firmware compiled from
bugfix-2.0.xbranch on 2021-03-05Additional Information
TFT43 Configs 2021-03-05.zip
SKR 1.4 Turbo Marlin Configs 2021-03-05.zip
The text was updated successfully, but these errors were encountered: