⏸️[FEATURE REQUEST]🦄Use better serial protocol communication

[luc-github]

Current protocol between printer and ESP3D use raw serial which is ok for GCODE communication but no really efficient for file transfer
More over if some output come from printer board due to auto send it bring some trouble on file transfer which is already slow

Current MKS protocol encapsulate each command in a frame with specific header, it also use 2 additionnal pins for notification/ack ,and different headers for GCODE / File transfer / Error, which make coexistance easier
This protocol allow 110KB/S transfer vs 0.4KB/S M28/M29 transfer and handle GCODE even during transfer.
That said current MKS protocol miss 2 things:

• CRC to ensure data are correct
• resend process in case of corrupted data

I think add a CRC32 should improve reliability and will only use couple of byte on each frame, and calculation should not affect too much performances. if done when data is received
Based on this crc, if any error happen then do a resend, if more than 2 resend is needed on same packet, then automaticaly ask for decreasing baudrate to do more secure transfer.

This would need to add some code in Printer FW but will ensure communication for file transfer as well as commands
This will be between esp3d and printer like on MKS Wifi so external progam won't be affected.

I am considering to write a library that could be used to hook the serial wifi port, but this also means need a dedicated wifi port like BTT do for board or TFT or an available UART port
If Serial port is same as USB one, it won't work (e.g: Mega/Ramps and aux 1), so I need to see if can handle raw serial in same time or consider it as limitation= no support of shared solution, may add custom GCODE to switch from one mode to another ?
In addition it need 2 additional pins available.

This would allow to remove the need of supporting the slow and unreliable M28/M29 protocol but bring more work on ESP3D part by adding a daughter library / Serial protocol accross FW (Repetier / Marlin / Smoothieware/ TBD...)

Any feedback /comment is welcome

[elproko]

Please consider few things before start bigger work:

1. measure if SD write routines on printer's side are not bottleneck (afaik - it is big part of the problem)
2. additional pins for ack - imho - they will not help - ack can be successfully send via serial line not degrading performance
3. there is too much line by line parsing on printer's side and too long timeout set for transfer - they kill performance even if we have set serial baudrate at 250k or 500kbits on 32-bit motherboards

for 1. it would be benefitial doing a speed benchmark for writing raw/binary data to SD card on printer's FW e.g. in 512 byte chunks. (the bigger - the better, but 512 would be a good chunk size - because this buffer size should be possible on every printer's HW)

for 2 & 3 - similar benchmark can be done but just for receiving serial data - but without saving it anywhere - just receive

I agree that on printer's side - should be special command introduced, which will just simply get 512 bytes via serial and write it to SD. on ESP side it should be just sending 512 bytes of data to serial

Protocol could look like this:

esp -> printer: Mxxx [filename] [number of 512byte chunks] [number of bytes in last chunk]\n
printer -> esp [ack]
esp -> printer [crc][512 bytes chunk]
printer -> esp [ack]
.
.
.
esp -> printer [crc][last chunk less than 512]
printer -> esp [ack]

in case of crc mismatch:
printer -> esp [nack]
esp -> printer [crc][last 512 bytes chunk again]

What is crutial condition to success: transmission timeouts should be always calculated depending on expected data length and actual baudrate plus few percent of margin. It is true for both sides: ESP & printer

[luc-github]

if you consider M28/M29 protocol vs currentMKS protocol
M28/M29 upload speed: 0.4KB/s
MKS protocol upload speed: 110KB/S
So SD Write is definitly a parameter but protocol transmission is a big one

For transfer WebServer vs other server is also a parameter, as well a SD library used like I have rased here : #383 (comment) that is why I would like to do #576

I disagree : pin ack is faster, read a pin state is faster than read a frame content and when you need a lot of ack it is an important parameter

Serial is easy to get noise during transfer - especially on DIY project, so it must be taken in consideration : checksum+ retry
Also I wish transfer can do binary as well text - because transfer should not handle content - just data integrity, but keeping good performances

I do not pretend I have solution, I would prefer to not put my hand on this, because it will be needed on several FW and so it imply some work in each on,
last but not least: I am lazy - I would like to avoid to reinvent things 😸 , M28 binary protocol is still experimental after several years, when MKS protocol is already used for several years - That is why I think it is not bad starting point.

[netzmark]

Hi @luc-github , may I know if you've tried to talk to anybody of Marlin community about the protocol improvement (meaning replacing M28 with some faster one) ?

[luc-github]

@netzmark no I did not, and do not have any plan, why ?
and to clarify I do not plan to replace M28/M29 which is limited to file transfer but use another protocol for communication that include file transfer but not only.
My approach will be more an external lib that will hook second serial port in same way MKS do but without filtering answer and allowing check sum and retries which are not present in current MKS protocol

[netzmark]

I've meant replacement M28/M29 protocol with another more powerful, or adding the second protocol for files upload. But It would make sense if there were some Marlin developer interested to apply your protocol there. And this is what I have asked for... because I have tried to ask there on the Discord if someone thinks about it - not answered.

[luc-github]

I am not focused on Marlin - this feature is for repetier / smoothieware / etc ... any FW supporting Serial communication and even not supporting M28/M29 protocol

I have tried to ask there on the Discord if someone thinks about it - not answered.

When I ported ESP3D for Marlin used on ESP32 board I did the approach to ask - was useless - no Marlin Dev answered, I was told that the marlin mindset is: just push your code and let see, that is why my code in Marlin is limited to some entry points but code is often broken so I only fix for release not bugfix, that is why ESP3DLib is limited compare to ESP3D standalone - I wanted to see the impact before spend too much time on it.

Again the protocol I propose is not focused on file upload, file upload is part of protocol not the protocol itself

[netzmark]

Gotcha, but it looks like nobody there (Marlin comm) is interrested in it :-(.

At occasion, I don't want to highjack the topic so shortly only:

• "Pannucat stand alone module" (the one with ESP8266 and SD card), I understand your ESP3D can be loaded there. But is there any way to connect it to SKR? If it is - what files transfer speed is possible then? Sorry I ask you not them but I count you have played with it maybe.
• MKS wifi modul connetcted to TFT28: ESP3D can be loaded there but I understand that won't get 100kB files upload to the TFT SD card, correct?

[luc-github]

I do not have the Panucatt wifi backpack standalone module yet, I have ordered some but still waiting.
Then you hook it on EXP1/EXP2 like there is a TFT with SD card - the last time it was checked the speed was around 280KB/S I think but it depend also on SD card and SPI speed

about ESP3D on MKSTFT and MKS WIFI module - I got 110KB/S for file upload - same as existing MKS firmware because I use same protocol

[netzmark]

Pls let know somehow when you have the standalone tested. It looks like promising stuff.

So I understand I can upload your ESP3D to MKSWIFI or into ESP01 - both should work connected to MKSTFT (properly wired of course). Great!

[luc-github]

I do not have the standalone but the others and it works well
FYR: MKSWIFI is an ESP12 not ESP01 and it is MKS module - several people got transfer issue using another modules instead of MKS one FYI

[netzmark]

I have assumed that if ESP12 contains ESP8266 inside so it is pissible to easy use ESP-01 either...
But I will get ESP12 in the next week anyway so will play with this :-).

I do not have the standalone but the others and it works well
You told "I have ordered some but still waiting." so I guess you will get it finally. I'm curious what the upload speed to its onboard SD it will reach.

[luc-github]

MKS TFT WIfi Connector is same as ESP01 but the pins are not matching so it won't work unless you use dupont cable and doing this you won't reach the speed of 110KB/S because of EMI issue, also ESP01 use GPIO 0 and GPIO2 which are both bootstrap pins when on ESP12 they use GPIO0 and GPIO4 for communication - I am guessing the GPIO4 is put low at start which can not be with GPIO2
Additionnaly ESP12 has 4MB flash when ESP01 only have 1MB so OTA is no more possible with ESP3D as FW start to be big

[netzmark]

I have fast 8MB Winbond on my ESP01 (I have soldered it instead of original 1MB CFeon). But now I see GPIO is complicating it a bit more than I feel up to do it. I will wait for MKSWIFI so :-).

[luc-github]

I have started to drop some notes https://github.com/luc-github/ESP3D/tree/3.0/to_do/CommunicationProtocol

[ETE-Design]

@luc-github Will it be possible to use the "MKS Protocol" - But on the ESP32-Cam and use lets say GPIO0 + GPIO4 like MKS use on their MKS Wifi Boards... That way is should be possible to to up the transfer speed?

[luc-github]

yes but you will likely have emi noise on serial wires and the upload will failed I guess because there is no retry on fail in mks protocole.
the mks wifi module are designed to avoid emi noise , I got feedback of people doing their own and some succeed but also some failed...

[ETE-Design]

@luc-github If I use "MKS Protocol" with a ESP32-Cam Board, what pin's would be used for IO1 + IO2 "GPIO0 + GPIO4"? I know it mabye will fail cause EMI Noise ;-)

[luc-github]

Did you tried GPIO0 + GPIO4 ?

[ETE-Design]

@luc-github No, would like to connect it correct from the start, that's why I asked.

[luc-github]

I have only used MKS Wifi modules with MKS protocol, but I know ESP32Cam is pretty noisy per experience - that said I never used it for MKS protocol, GPIO 4 is the flash so it may need to change it - but at first I would try the basic : GPIO0 + GPIO4

[luc-github]

I have checked the octopus and seems a good candidate for fast upload as it allow to connect GPIO0/GPIO4 like MKS boards

Additionnaly as it connect ESP SPI pins to SPI_2 pins of octopus to be used by RRF - it is also a good candidate if try to port SPI drivers of RepRap to Marlin