Micropython support?

[pixelpieper]

Hi there,

I am aware of plans to add conditionals and variables to the gcode interpreter, but, just to throw in an other idea:

Instead of inventing a new turing complete language, what about adding micropython support instead? There is a rich library of existing code and it would lower the bar for newcommers to implement complex functions.

Gcode could tightly interact with python code by adding the ability to call python functions via custom codes and there could be an API which allows python code to issue gcode to be executed. Additional APIs could allow for simple GPIO access (Polling?) and maybe even access to peripherals as SPI. One could even allow to override gcode, i.e. a custom complex python bed leveling procedure could replace the standard implementation of G29. Finally, if network access is enabled users could use python hooks to integrate a single printer into a large print farm, notifying a server about finished prints, missing filament, critical errors, ...

Best,
Christoph

[dc42]

We are already considering something similar for Duet 3. However, Python and similar garbage-collected languages are fundamentally incompatible with real-time systems operating with limited memory, so not possible on Duet 2.

[fma]

I like Python, and use it at home and at work for more than 15 years, but I'm not sure it is the best solution, here.

Maybe Lua would be a better option (http://www.eluaproject.net?)

[pixelpieper]

@dc42 I understand that there are limitations, but I would have assumed that it would be possible to run the interpreter as an rtos tasked with a fixedly preassigned memory budget, enforced by the mpu of the cortex m4. The micropython web page lists a minimum of 8kB of ram, I don’t know however how much pressure there is on the 128 kB available.