[FR] OctoPrint and TFT comunication.

[ReubenBTalbott]

Is your feature request related to a problem? Please describe.
I use my TFT along with OctoPrint, but the TFT and OctoPrint don't communicate which makes things a bit fragmented.

Describe the solution you'd like
I connect my RaspberryPi to my TFT E3 via the Rx & Tx pins so could there be a new Gcode command that the RaspberryPi and the TFT use to tell each other what they are doing? For example, if I started a print on the TFT Octoprint would be able to show a print is running and how much time was left, or vice versa. I am guessing a plugin would be needed for Octoprint for this to work.

[hfog]

There is no way for an external computer (which the TFT is when operating in touch mode) to reliably know when another external computer is printing. The best you can do is hook Octoprint to the TFT through one of the UART ports and then rebuild the TFT firmware with CLEAN_MODE_SWITCHING_SUPPORT enabled (in config.h). That will allow the TFT to pass through and monitor serial commands from Octoprint which will allow it to keep location and temperature date updated but it still won't automatically switch to the printing screen because neither Marlin nor Octoprint will tell it that the printer is actually printing something.

[ReubenBTalbott]

I realize this, I was thinking perhaps a new Gcode command could be made that the TFT could use to send or receive printing information from octoprint, this would probably require a plugin on octoprint.

[SonBroku]

@hfog How reliable is this pass through scenario? Can the TFT keep up with passing the gcode through to the printer well? I would think that any problems in the TFT could cause print stuttering. Octoprint > printer already can sometimes have reliability problems, and introducing another party to the situation seems like it's inviting blobby prints from micro pauses and stutters.

[paul-1]

It doesn’t work with current firmware, and when I tried a build from @hfog‘s branch....it was extremely laggy.

I’m sticking with LCD mode and Octoprint over the USB. Make sure you disable “Clean mode switching support” as that causes lag in LCD mode.

[hfog]

@SonBroku Any time you introduce a middle man, as you're doing here, you run the risk of introducing some lag. I've found that I get the best results when I increase baud rate as high as I can go. Also, I had problems using linear advance but I'm not convinced those problems were from going through the TFT as I saw similar problems when the TFT was removed from the equation. Without linear advance, I didn't see a significant amount of lag and print degradation but on prints with lots of short and fast moves, I did see some. It certainly isn't perfect. YMMV

[craigistired]

Others have done it.

https://plugins.octoprint.org/plugins/m73progress/

[kind3r]

With the latest commits from https://github.com/guruathwal/BIGTREETECH-TouchScreenFirmware I have succesfully used DisplayLayerProgress plugin to show information about the print status, ETA etc. (it's configurable) via M117 commands on the home screen of the display:

While this does not trigger the 'printing mode' of the TFT I don't think it's really needed as OctoPrint controls the printing anyway and you can still use the TFT to issue other commands like babystepping, changing the feed rate, flow rate, temperatures, fan speed etc. There are still some communication issues once in a while which I'm trying to pinpoint but it mostly works fine.

Also see #281 for progress on this feature.

[oldman4U]

Could you please be so kind and close this ticket. Your feature request is covered in the pinned Feature Request ticket #1170

Thank you

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ReubenBTalbott]

Could you please be so kind and close this ticket. Your feature request is covered in the pinned Feature Request ticket #1170

Thank you

No, as someone else mentioned in that issue, having one issue for all the issues makes it hard for people discussing an issue to talk about only the issue they are interested in.

[oldman4U]

Besides my own comment, there has been ZERO activity for almost half a year, not sure what kind of discussion you are talking about?

And what makes you believe that a ticket can not be used anymore, once it is closed?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ReubenBTalbott]

Please go away bot

[ReubenBTalbott]

Besides my own comment, there has been ZERO activity for almost half a year, not sure what kind of discussion you are talking about?

And what makes you believe that a ticket can not be used anymore, once it is closed?

An issue especially a feature request isn't urgent so having it open will allow people who want the same thing to see it and chime in. By putting all the issues in one issue it makes it hard to find the issue and makes having conversation about the issue or feature request more difficult.

GitHub designed the issue system the way it is for a reason, a better option for what you seem to want would be to create some sort of trello board and track the issues (still open) there perhaps.

[lightmaster]

Little brainstorming here. I see all the anti-octoprint devs saying that its just flat out not possible anytime its brought up, but I don't think that's the case. The Octoprint plugin DisplayLayerProgress already exists to send M117 notifications to the printer, and is already heavily relied upon by other plugins and software. Also, the TFT does receive these notifications and shows them on the main page. DisplayLayerProgress is capable of sending basically whatever information you want to send:

Use the following keywords as a placeholder:
[progress], [M73progress], 
[current_layer], [total_layers], [estimated_end_time], [printtime_left],
[last_layer_duration], [average_layer_duration],
[current_height], [total_height],
[feedrate], [feedrate_g0], [feedrate_g1], [fanspeed],
[changefilamenttime_left], [estimated_changefilament_time], [changefilament_count],
[printer_state],
[current_print_filename]

Mine is currently set to [progress]% L=[current_layer]/[total_layers] ETA [printtime_left], and this could easily be tailored to send all the information to the TFT. All the TFT would need to do is have a trigger such that when it receives a M117 update that looks something like a printing status message, it triggers the print screen. It then extracts the information from the M117 notification to receive the printer progress, layer information, etc.

Only real hiccup I see left is sending commands like Pause and Cancel back to Octoprint. M118 Action Commands don't seem to be received from TFT => Octoprint, at least not that I can tell. However M117 notifications are received like //action:notification TEST. Perhaps an Octoprint plugin could be created that sees these notifications and acts on them accordingly?

Besides the actual coding, which is over my head, this feels like it covers about every sort of 2-way communication that would be needed between Octoprint and the TFT to get a fully functional and controllable print screen going for prints that are initiated by Octoprint.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lightmaster]

Let's not close this, hoping a dev can look into this eventually.

[ghost]

I am somewhat bewildered by the UART ports. you cant print through them, in fact just asking for mesh and sending a few simple commands causes total stall. I see that the TFT is just sending junk back throught the UART's, like fr:xxx and some other rubbish, no actual busy/ok responses from the printer. so the UART's are pointless, what are they actually for? They cant be used (as the documentations suggests they might be) for octoprint, or anything else really. Cant PID, MESH, PRINT!!! LOL, eerrmm well anything, I think M115 does send the printer info back, but stalls everything cos no OK after.

I notice that there is only one actual UART, UART4 , the others are SUART? Documentation suggests so. Given we dont know anything about what mode they are in and have no way to set them, they are useless, could be the cause of the rather rapid demise of any connection you do make using them, despite the lack of printer responses. I keep meaning to try UART4 see if it works at all? Got fed up already and gone back to a stock Creality CR-10 12864 cos it works. Octoprint is connected to the SKR E3 Turbo TFT connector (running a meter across it shows it to be TTL 3.3V) and works flawlessly. I asked my grandad about the USB connector on the E3 turbo, something about back in the day and summer of 69 etc, seeing as it back powers it is unusable anyway. Similar to the 'SDCARD' on the TFT35 E3 V3.0, though I do seem to have a vague memory of those. Can you still get them? So I am all out of ports to connect the TFT35 E3 V3.0. And cant get anything else to work with it if I did.

I mostly wanted the wifi, but cos it has the same problems all the UART's have of not sending back anything useful then remote printing is a complete flop with this display. wifi just as useless as all the other ports. remote is not an option. Even if I was not trying to print , just monitor and control does not work. A simple pre-heat stalls the entire system cos the display filters out any feedback from the printer like OK, or BUSY. just about any command through the UART's brings the system to a stop because of this.

Lets hope the firmware can fix the BTT TF35 E3 V3.0 cos right now it is in the box of 'make sure anyone who asks you about it knows it is pure landfill'.

SKR E3 Turbo is a good board though., despite having an unusable USB port only my Grandad has ever heard of.

Regards
BaDboD

[ghost]

As to the issue of having multiple devices on different ports all working and know when printing is occuring etc, hm..

That would rely on all parties receiving the same printer feedback from the printer. and as pointed out above, then you could use any custom method or even M117 etc to trigger things. But more simply if all devices receive the same data from the printer
then all have the opportunity to work in the same way as say, octoprint for example.

To know if the printer is printing should not be too hard considering the conversation that takes place and the activity and content of the printer messages you do get normally. advanced_ok could be useful here? Say,,, 5 minutes with an empty buffer and nozzle temperature below 50 could suggest the printer is idle? You get busy for most things, so no brainer there. also there is report_position (whetever ti si called), which should be not moving and preferably at the homing position to suggest also it is idle, etc also ask it for something when it passes those tests to see if you get a busy . in case it is mesh bed leveling or some other activity you don't want to disturb, or conversly decide it is not idle, thus (possibly) printing, in which case your only option is to allow babystepping and emergency stop and maybe a couple other options as you are not the one printing so aborting would be kill anyway. hmm pause? err dunno, those are just details :-)

It really only relies on all partiers getting all the normal printer messages ok,ack,busy,position,temperature etc etc one would normally expect.

So just getting the printers output side of the conversation is a good starting point (hence the ramble in my first post, the point being, that is exactly what I thought the UART's on the TFT were for. As it stands they are pointless and I still dont know what they are for as you dont get the printers output)

[digant73]

Could some of you please summarize all the use cases (already working and not yet working) so I will see if and what could be improved to support some use cases?

[lightmaster]

Could some of you please summarize all the use cases (already working and not yet working) so I will see if and what could be improved to support some use cases?

My use case is this:

I have a SKR Turbo v1.4 control board.
I have a OctoPrint running on a Raspberry Pi 4 that's connected to the SKR Turbo's USB port as SERIAL_PORT -1.
I also have a BTT TFT 4.3" that's connected via the the LCD and TFT wires, set in Marlin as SERIAL_PORT_2 0.

All of my prints are loaded up in OctoPrint and prints are initiated either from the OctoPrint website or mobile app installed on my phone. I use the pretty, normal display of the TFT screen for tweaking my bed leveling when I notice the bottom layer isn't looking as good as it should, and also for sending M701 and M702 commands to load/unload via the load/unload menu. When I start a print, I switch to the emulated LCD screen to view progress and pause/stop prints using custom gcode with action commands.

I would like to use the nicer normal print screen of the TFT firmware for the local print screen, but there seems to be essentially 0 desire from developers here to get this ball rolling. There must be some way to do this, though I suspect it would have to be a joint effort between the TFT's firmware and the Marlin firmware.

[digant73]

Thanks for the info. The TFT fw could easily intercept some Marlin "action" ack messages to be aligned with current Marlin/Octoprint state (e.g. printing, paused etc...). In order to allow it, Octoprint could simply use a protocol similar to that reported in #2180 (based on use of M118). There are a lot of Octoprint plugins. If There is a plugin providing something similar to that, it is very easy to intercept state commands (such as print, pause, cancel etc...) on the TFT fw. That protocol will work also connecting Octoprint to one of the serial ports in the TFT (instead of mainboard). I don't have/use Octoprint/Raspberry in this moment so I don't know if a plugin using M118 already exist. If so I would simply need to know the commands used (the protocol) so I could intercept them in the TFT fw

[lightmaster]

#2180 basically what I was thinking, have TFT respond to the action/host commands that are sent when prints start from the marlin side, and send back commands to pause, stop, etc when needed. I will follow that one as someone has already started on it.

[digant73]

Once PR #2241 is merged, please test it and open a new thread in case of further enhancement requests or bug reports

[github-actions]

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.