[FR] Standardising the communication between Marlin and an external LCD touchscreen controller

[mofosyne]

I noticed that there is cocoon create, Raise3D and wanhou i3 duplicator plus, all with their own implementation of communicating between a touchscreen controller to the Marlin firmware.

But a common factor I noticed is that they communicate to the Marlin firmware via a secondary uart.

So I think what would help is if we can somehow standardise this communication between a Marlin firmware to an external controller. Especially in such a way that is futureproofed (especially considering that LCD firmware do not really get updated all that much).

My proposal would involve sending CBOR messages between Marlin and the controller.

https://en.wikipedia.org/wiki/CBOR

It's a good candidate over say json, as it is much more compact and is an RFC standard. And also being like json, it is easier to add new data items or structures later on.

There is some references we can rely on to see how existing extension to Marlin firmware supports touchscreen controllers. For example you may want to reference https://github.com/andrivet/ADVi3pp-Marlin . An opensource mod to replace the Wanhou i3 plus 3d printer firmware.

Some capabilities to consider:

• Sending GCODE commands directly. E.g. Allow the touchscreen to send a simple calibration cube to 3d print.
• Allow for sending configuration commands to adjust the eeprom settings of the printer.
• Status reporting of current print behaviour, temperature, etc...

[Deneteus]

Related:

[FR] Remote Serial Display Functionality for External LCD Controllers C: LCD & Controllers T: Feature Request
#7790 opened on Sep 28, 2017 by Deneteus

[FR] Adding Nextion HMI Display support C: LCD & Controllers T: Feature Request
#7754 opened on Sep 26, 2017 by DaeMonSx

[aenertia]

Yeah - we basically need a full API - as most of these things have embedded stm32's in them which have to (in the case of the nextions) recompiled specifically for the various variants (touch/non-touch/form-factor etc).

Something along the line of a Document Data Definition - something an XLST transform could be applied to would mean only defining it once in the marlin tree and then running it through a processor to get the individual screen bits.

A base glyph set probably would be useful to include i.e from existing work i.e https://github.com/apballard/Marlin

The problem is for a lot of these serial displays there isn't a usable open build chain ; nextions require a closed up windows only editor/compiler to produce their binaries(which then have to be loaded from the screens inbuilt tft (to be done with any reliability).

[mofosyne]

Oh that's an interesting though. So by having a Document Data Definition kind of approach, are you saying this would allow us to abstract away the Human Machine Interface Controller from the main marlin firmware? (FYI: I don't totally get DDD yet)

If that's the cases, then we should look into that. I agree there will be more than just touchscreen HMI to deal with. Some may only be hardware buttons and cheap alphanumeric displays as well... so we need to be able to abstract that away indeed.

---

Don't know if CBOR has any recommendation on how to emulate the doc def that XML has however... we may just have to figure that out ourselves.

[thinkyhead]

Also related: #10610 PanelDue

[InsanityAutomation]

As a note, this is essentially what ExtUI is aiming to do in Marlin 2.0 and its becoming more robust constantly.

[InsanityAutomation]

At this point this should be closed. The LCD's mentioned here that are not already in ExtUI have specific issues open and this is arguably complete from an infrastructure standpoint.
@boelle @shitcreek

[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.