Phi: Open-source, Wi-Fi + Ethernet, RRF 3D Printer Controller

o_lampe

@likhalabs
Will there be a benefit from the dual processors? Will this board support all the foreseeable features of RRF (like input shaping, multi-stream gcode)
Is it possible to run daemon.g from the ESP flash (more frequently)?
Do the expansion ports have unique pins or do they share some pins and put us users in an either/or conflict? (eg. using an LCD on port x, blocks extension y)

Last not least, I couldn't find information about likhalabs. Who are you, where is your headquarter?

likhalabs

@o_lampe

Will there be a benefit from the dual processors?

To preface this, in a typical Duet board, networking, GUI, kinematics, stepping, etc. are normally done in a single microcontroller. In Phi, these tasks are split across two microcontrollers.
Networking, GUI, and other stuff not related to sensing/driving something in the machine runs on the ESP32, the rest runs on the SAME51. The benefit is that less tasks share processing resources in each microcontroller. This also means more room to grow for each part. For example, the networking and display stuff running on the ESP32 has more RAM, processing power at its disposal. I can allocate more RAM to network buffers, for example, to speed up network transfers without worrying about choking the kinematics/stepper driving part because the latter are in another microcontroller, the SAME51.

Will this board support all the foreseeable features of RRF (like input shaping, multi-stream gcode)

I was actually tracking official RepRapFirmware development since last year, when it was still 3.1.1. You can see my previous progress here: https://github.com/likha3d/Duet3D-RepRapFirmware. I'm now on 3.3. I've been merging new features from newer versions without much problem so far, as I ensure changes I make have little conflict with the official RepRapFirmware development as much as possible. So I'm confident in merging new developments from the official RepRapFirmware branch going forward.

Is it possible to run daemon.g from the ESP flash (more frequently)?

Behavior related to running daemon.g is unchanged from official RepRapFirmware.

Do the expansion ports have unique pins or do they share some pins and put us users in an either/or conflict? (eg. using an LCD on port x, blocks extension y)

EXP1/EXP2 ports share pins with PanelDue 10-pin/4-pin port. This means that you cannot use EXP1/EXP2 and PanelDue at the same time. However, as far as I know, using multiple types of displays is not even supported in firmware, so this pin sharing should not matter.

All other pins are unique pins, as far as regular end-users are concerned (a couple of debug pins are shared, should only matter to developers). I'll share a pin diagram closer to launch.

Last not least, I couldn't find information about likhalabs. Who are you, where is your headquarter?

Fair point. Finding information about Likha Labs is going to be difficult, since I just started (as a full-time commitment) and I'm basically a one-person-team at the moment. I'm an embedded software engineer from the Philippines. I used to work for Espressif, as a developer on ESP-IDF (renzbagaporo).. I decided to try my hand at integrating an ESP32 on a 3D printer controller to assume the same functions an SBC would, as nobody was doing it.

droftarts

@likhalabs said in Phi: Open-source, Wi-Fi + Ethernet, RRF 3D Printer Controller:

I decided to try my hand at integrating an ESP32 on a 3D printer controller to assume the same functions an SBC would, as nobody was doing it.

Interesting work! Does the ESP32 run your own custom firmware, or is it running a form of dsf (like a Raspberry Pi does)?

Ian

likhalabs

@droftarts Its a partial port of RepRapFirmware to run on top of ESP-IDF, actually. I've mentioned that the ESP32 is in charge of networking, sd card, displays, usb, etc. so I've ported only the relevant parts to these functions and disabled or excluded from build others.

zapta

@likhalabs, can it use the Duet Mini5 binaries or will you release your own binaries for RRF and Klipper?

likhalabs

@zapta No, it can't use Duet 3 Mini 5+ binaries, so I will be releasing Phi's own RRF binaries.

RepRapFirmware will be the 'official' firmware, so I will not be maintaining a Klipper port and releasing Klipper binaries. However, there is nothing preventing members of the community from porting other firmware like Marlin or Klipper to Phi, as like I've mentioned, full schematic + PCB layout will be released.

likhalabs

The campaign is live! Please check it out if you're interested.

likhalabs

I've been trying to improve upload speed for Phi. Finally broke the 1MiB/s barrier!

There's still some room for improvement, though.

oliof

@likhalabs is that on Ethernet or Wifi?

jay_s_uk

@likhalabs the STM port gets 1.6Mib/s with an ESP32

bot

When can we have one with 6 steppers?

likhalabs

@jay_s_uk Usually, small 'b' denotes bits and big 'B' denotes bytes. Just to clarify, is it bits or bytes in the case of the STM32 port?

likhalabs

@oliof Hi oliof, this is on Wi-Fi. Ethernet is a little slower, around 900 KiB/s - 1 MiB/s so far. Ethernet is slower because it's not native (ESP32-S3 does not have an Ethernet peripheral, is using a W5500 Ethernet <-> SPI chip).

likhalabs

@bot Unfortunately since I'm a one-man team, it will be after the current board gets off the ground. Though it's possible to add https://duet3d.dozuki.com/Wiki/Duet_3_Expansion_Mini_2plus for a total of 7 steppers (like the Duet 3 Mini 5+).

jay_s_uk

@likhalabs sorry. B not b.
So 1.6MiB/s

likhalabs

@jay_s_uk Thanks for the clarification! Looks like I have a new benchmark. (There still some room for improvement, like I said). I have an SKR pro and lots of ESP32's lying around to test and see how its achieving that speeds.

In theory at least, I should be able to achieve faster speeds since the data does not have to travel between microcontrollers through an SPI link (same theory why ethernet is slower as mentioned in the reply to @oliof).

bot

@likhalabs fair enough. I love the path you're on so I'm excited to see you progress.

o_lampe

@bot said in Phi: Open-source, Wi-Fi + Ethernet, RRF 3D Printer Controller:

I love the path you're on so I'm excited to see you progress.

When the thread started I thought it was a good idea to have an ESP32 as RasPi replacement. The RasPi4 felt like 1000x overkill for the few tasks it had to do as SBC.
But the task list will grow in the future and I'm not sure how much headroom there is for the ESP32?
Could we program post pocessing scripts for it? I know there's MicroPython for ESP32, would it run on your environment?

@likhalabs If I'd be you, I'd look for Linux driven alternatives for new projects. (eg. header for RasPi Zero 2W)

likhalabs

@o_lampe Although the ESP32 is much less powerful than the Pi's, it still packs some grunt. People have been running image and audio processing on it, after all.

It's hard to quantify how much headroom there is for ESP32 (one thing that is sure is that it's much less than the Pi). However, to get some idea, the current 'heaviest' workload would be networking, particularly uploading a G-code file. It hovers around 8% of CPU time when uploading a file.

Anything super computationally expensive would be out of the question for the ESP32, I think. One example I can think of is on-device 'spaghetti detection'. However, even the RasPi4 is not recommended for that.

Could we program post pocessing scripts for it? I know there's MicroPython for ESP32, would it run on your environment?

I mean, there is a MicroPython/CircuitPython port to the ESP32, but it would need to be integrated into RepRapFirmware. Again, anything super computationally expensive might be out of the question. But for simple custom manipulation of pins & peripherals, it could conceivably run. For example, sending out a custom color animation on Neopixels when a print is finished.

o_lampe

@likhalabs said in Phi: Open-source, Wi-Fi + Ethernet, RRF 3D Printer Controller:

It's hard to quantify how much headroom there is for ESP32 (one thing that is sure is that it's much less than the Pi). However, to get some idea, the current 'heaviest' workload would be networking, particularly uploading a G-code file. It hovers around 8% of CPU time when uploading a file.

So the bottleneck is not the CPU. That's already good news. Then there's enough CPU-time left to do simple post processing on gcode files.
How much RAM/flash is left over on the ESP32, when running RRF?