[Question] Is printing from a macro a supported usecase?

[mauriciojost]

Hello,

I think the project is awesome first of all, so thumbs up :)

I have a Marlin 2.0.7 firmwared RAMPS 1.4 TriGorilla board as 3D printer. It is connected via UART3 to an ESP8266 that runs a relatively recent version of ESP3D (UI: 2.1b67 / FW: 2.1.1.b8). To improve communication I use 19200 bauds and I connected the TriGorilla with the ESP8266 via a 10cm shielded adapted USB cable. I am no electrical engineer but at such low speed I don't expect much communication errors there.

I am having some issues with my 3D printer SD card reader (I think it's mechanical, I already ordered a new piece), and I was wondering if the ESP3D project could be a complete replacement for the SD cards at all. What do I mean? Instead of uploading .gcode files to the SD card via ESP32 WEB UI (which turns out to be slow, even at 500k bauds), just upload them to the FLASH memory of the ESP8266 (as we do for macros) and use it from there (the size of the flash is a limitation, but there could be alternatives here).

However there must be something I am missing. I have tried printing via SD card a .gcode (attached): all went fine. I upload the same .gcode to the ESP8266 filesystem (via the UI), and I create a macro to launch it via WEB UI. I launch it, and it seems the first commands are correctly interpreted (G28, G29 at least, I can tell my printer starts doing those at least). But then to start it starts printing completely off Z offset, and the feed rate is incredibly high (it consumes about 1 CM of feed stock per second!). Something is different from the .gcode as executed from SD card compared to the one as executed from the macro.
What is it? Could it be that when a byte is transfered from ESP8266 to the board, and its parity bit is wrong the message is simply discarded and that's it? (instead of retried).

Thanks for your help,

Mauricio

[mauriciojost]

Here the attachment (a tiny cube with skirt).
PIM2.zip

[luc-github]

currently macro is not designed to manage any error any buffer any printer response - it just send gcode one by one without waiting neither checking each response- in 3.0 there is a start of gcode host manangement but it is very basic and blocking so need lot of improvement before to be reliable
So no, it is not currently yet supported that would explain the behavior you get I guess

FYR: #243

[mauriciojost]

Thanks for your reply and for the reference issue. I will keep in sync then, however I don't quite understand the proposal written there :/ I am a newbie :)
I have more questions, as I may be interested in contributing to ESP3D.

1. Your comments made me wonder up to which point the SD is written with correct data. I have enabled a CRC_XX macro for SD checks in Marlin, is that enough to guarantee that my SD will receive non-corrupt files from ESP3D UI?
2. What kind of host management do you refer to? Why unreliable? Something like you only move forward in case of "OK" replied or something like that? (I was thinking that if this is the case, nothing prevents the ESP3D to (through serial communication) send commands that get corrupt over the wire but still yield an OK as reply, messing up the full print, for instance a G28 sent that arrives to Marlin as G1XX for instance). I guess what's needed is a stronger CRC check per command or batch of commands or smth like that.

[luc-github]

1 - not sure, the crc in Marlin is only for reading as far I know , also be aware the checksum used in file transfer is not fullproof - as calculation allows several values #296 (comment)

2 - I am refering to error management if wrong check sum - ok is not sent, pause management, etc... - delay in answer (like when heating and wait for temperature reached) or G4 command, be not blocking and also send commands for temperature / position/print status when streaming GCODE to control job process

I guess what's needed is a stronger CRC check per command or batch of commands or smth like that.

That would mean a Marlin modification which is out of ESP3D scope, the target is to be at least, as reliable as normal host like repetier or pronterface
Being a reliable GCODE Host streamer is not as simple as it looks

[luc-github]

@mauriciojost is your question answered ?

[mauriciojost]

Yes it is, thanks a lot for the answer and the great work.

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