First, I am loving Octoprint, thank you so much.
I am using it on my (heavily modified) Tevo Tornado and recently also for my Artillery SW X1.
If there was not the issue with the choice between online control and the local one, mainly on the X1...
I do understand that only one device can "talk" to the printer via serial. So I have to choose to use the built in touch screen OR Octoprint.
Now I was thinking, what if there would be a way to send the serial data from the built-in display via GPIOs (?) to the RPI and "insert" it via terminal commands into Octoprint, which in turn sends it to the printer. You know, like G28, G29, etc....
Likewise, Octoprint could relay all status code via the same serial connection to the display.
This way, one could use both ways to control the printer.
I know that there are some UIs out there (Octodash, Octoscreen, Printoid (tried it with octo4a on a mobile phone), but none seems as structured as the built-in touch (on the X1 with custom firmware).
This could also save people some money, as the only thing needed would be some SBC to be hooked between the existing touch screen and the printer board.
If there is any way of doing this already, I apologize for posting this question, but I spent the last few weeks to find anything, no luck so far.
Thanks.
Markus
Basically a man in the middle serial connection approach. This is an interesting concept and would think it would be possible with a lot of hard work and programming. You would be adding another level of complexity with the serial connection which could lead to some issues, but for most stuff that you do from screen it probably wouldn't matter too much as those are typically simple commands. The challenge would probably be the two way communication and the additional latency imposed.
Something like this may be the approach to take though.
Thanks for the link, sorry for the late reply, was busy with some other project.
I have 2 problems with this serial proxy.
- I cannot install it, as I am running on Ubuntu 22.04 and the package dh-systemd has been completely deprecated, so the dpkg-buildpackage is aborting.
- I am not really sure if this would even help, as the underlying Ubuntu would have 2 physical RS232 and would have to pipe one through to the other while still using the one to the printer itself too.
There might be a way around that by putting a virtual serial port in between, but that would seem to complicate things even further.
Is there really nobody who has considered using both the build-in touchscreen of the printer AND octoprint in parallel?
Anyhow, thanks to all who have spent a thought on this.
Markus
The 'true' (at least in my opinion) solution to this is to have multiple serial ports on the printer. It's possible, implemented in Marlin and available in the wild. I think that's why nobody has thought of this issue in this way, because their screens can still be used alongside OctoPrint - as far as I understand how it works.
There was actually a rather annoying bug about 18 months ago in Marlin where messages would get sent to the wrong serial ports causing severe communication problems - at that time it seemed like everyone had multiple serial ports...
Thank you Charlie.
I actually didnt realize that the MKS GEN_L 1.0 does have more than 1 serial port.
I will check this out and report back.
This is to report that indeed, Charlies approach did work for me.
I now got Octoprint and the built-in display work side by side.
Had to move the filament runout sensor from the display to the board in order to get the M600 alerts in octoprint as well (also M75 needed in startup gcode).
Now I can pre-heat, change temp and babysteps during the print, even acknowledging the M600 works from both display and octoprint as I want.
The only thing which is a pity is that I do not see the print progress on the screen (understandable as the screen does not know about the print job).
But at least I see the x, y and z positions, so if I know about the total height, I can kind of guess.
@Charlie_Powell , thank you so much for pointing this out to me.
1 Like
One of the M73 plugins or display progress plugins might help in that regard.
Hi Jneilliii
I did look into M73, but that seems to work with LCD displays only (couldnt get Marlin to enable it).
M117 / M118 look promising, I am currently trying to get the tft to "accept" the printing status messages.
I think I saw some website saying something about host_action_commands and how the tft will change into the printing menu when Octoprint starts a print. That would be perfect, if I could use that interaction as well. Just need to find it.
Thanks to all that replied
Ok, got it working now. M117 was no good (seems to be a X1 / BTT TFT thing), but M118 came through.
So now I got the proper M118 statements in my start / end / cancel gcode and also in layer change.
The only thing left is the time remaining, I got a feature request in SuperSlicer to add M118 to the possible options in addition to M117 and 73.
This has been implemented in Cura via a plugin, maybe supermerril can do the same for SS.
Anyhow, got my setup working now as I wanted, many thanks to all that took the time to reply.