ESP32 Printer Board

I forgot to include URT0 in my pin count thank you for pointing that out.

At this point I am certain I am going to have to use an external GPIO chip. I am currently looking at the MCP23S17 as well as a few others.

Hubberthus, thanks for that analysis. A few comments:

- The ARM specific assembly code in RRF is only there to provide a register and stack dump if an exception occurs, to help identify the cause. So it can be left out, or equivalent ESP32 code substituted.
- Even if a USB interface isn't needed, it's well worth keeping the UART pins available for debugging purposes, and to update the firmware when OTA isn't working.
- An 8-bit DAC provides enough resolution if it is used to feed Vref pins to set motor current.
- The problem with using I/O expanders is the increase in latency. They should not be used for signals to stepper motors. OTOH an I/O expander such as the SX1509B with built-in PWM capability that we use on the DueXn expansion board could be used to drive heaters, fans and Vref pins. The main limitation of that chip is that it can't do the low PWM frequencies that some SSRs and some fans need, or to generate a servo signal.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

I want to stick to SPI chips as it means only having to worry about pins for a single bus. Probably going to go with a general GPIO chip and a PWM chip with a high enough frequency. That is assuming the ADCs will work for the temperature readings.

Seems to me that these two boards could go together if someone wanted to work on firmware for ESP32:

https://www.aliexpress.com/item/Hot-Sale-1PC-TTgo-ESP32-WiFi-Bluetooth-4MB-Flash-UNO-D1-R32-Board-Module-For-Arduino/32820463407.html?spm=2114.search0104.8.55.iPBR3I

https://www.aliexpress.com/item/Free-shipping-cnc-shield-v3-engraving-machine-3D-Printer-4pcs-A4988-driver-expansion-board-UNO-R3/32582748664.html

Here's the above mentioned CNC SHIELD connected to ESP8266 (Wemos D1) board:

https://www.youtube.com/watch?v=Ii7Cn1PlVFY

Thats certainly an interesting board (+ standard cnc sheild) for testing any esp32 based firmware, just needs something to provide thermistor input and mosfets outputs

the magic keyword to find them on google seems to be "Wemos UNO R32"

Edited 2 time(s). Last edit at 10/18/2017 05:23AM by Dust.

Quote
Dust
Thats certainly an interesting board (+ standard cnc sheild) for testing any esp32 based firmware, just needs something to provide thermistor input and mosfets outputs

Thermocouple:

[www.ebay.de]

for thermistors you just need two resistors (a cap might help also)

mosfets outputs:

[www.ebay.de]

Disclaimer: I have bought these things on ebay, but other than that I have no connection to the people selling this stuff on ebay

I suspect that the ESP8266 is only used as a serial-to-WiFi interface, and the hardware is being driven by the ATMega 328
[www.robotics.org.za]
[www.aliexpress.com]

In which case you would have to do quite a lot of work to move any firmware functionality to the ESP8266. But perhaps a useful platform for something like klipper @KevinOConnor which already divides up the functionality.

@frankvdh

There is no atmega 328 on the board listed, only on the board you found.. (at least its not listed, and I cant see one)

See [www.cnx-software.com]

Ah, thanks @Dust.My mistake.

Found the right one (I hope) at [www.aliexpress.com]

Downside is

Quote

Note that if you have shields using the Analog input they may not work properly since there’s only one input supporting up to 3.2V, as Arduino UNO board support 6 analog inputs up to 5V.

Perhaps the Noduino Quantum would be a better choice?

But they're about 3 times the price.

From what I read stepper drivers will run on 3.3V and cnc shield has separate voltage input for stepper motors.

TTGO board appears to be a clone of DOIT board, espduino 32 (@Dust posted it's pic above)

Here's espduino-32 schematic and pin-out.

[github.com]

CNC Shield pinout:


From what I can tell there's no issue with the way pins are mapped between ESP32 and CNC Shield except for GPIO2 which CNC Shield is pulling up where it should be low for ESP32 to boot. (GPIO2 high enables normal boot)

espduino (DC plug side) /// cnc shield
GPIO39 reserved
GPIO36 reserved
GPIO34 coolant enable
GPIO35 cycle start/resume
GPIO4 feed hold
GPIO2 reset/abort

espduino32 (usb side) /// cnc shield
rx
tx
GPIO26 step pulse X
GPIO25 step pulse Y
GPIO17 step pulse Z
GPIO16 Dir X
GPIO27 Dir Y
GPIO14 Dir Z
GPIO12 Stepper Enable/Disable
GPIO13 Limit X
GPIO5 Limit Y
GPIO23 Limit Z
GPIO19 Spindle Enable
GPIO18 Spindle Direction

Edited 4 time(s). Last edit at 10/19/2017 11:04AM by newbob.

Someone have designed board with ESP32 specifically for a 3d printer:

http://esp32robots.co.uk/index.php/hardware/3d-printer-controller

just to add to newbobs post i have also just completed the display board to go with it and sent them off to elecrow to get etched.
the boards are open source but i would wait a couple of weeks in case of hiccups on the board i will put an update when i have them back and done some basic tests.i have tried to keep costs down with a lot of parts available form chinese sites like banggood as well as ebay etc the boards are double side and 100x100 mm or less in the case of the display board so you can get them manufactured at 5 for $4.99 the display is a pi 3.5 inch display which you can pick up for about 12 - 13 bucks i have made a couple of compromise due to the pins available 1 extruder as my d-bot only has one 3 end stops which i intend to have set in software to determine min max , as mentioned in my article on my site i have not decided on firmware yet so having a look at the various offerings around and have sort of eliminated some such as smothie and may end up taking bits from one or the other , the display is also intended to be wireless and am going to have the main board running as station and access point with the display hooked into the access point. This is a work in progress so open to suggestions and do expect to have to do a rev 2 of the boards once i start hooking it.

Might I suggest you port Klipper, it uses a well structured HAL so should be easy to port.

It pairs with raspberry pi and if you run octoprint on the pi as well you can control everything from a smartphone or tablet.

[github.com]

Edited 2 time(s). Last edit at 10/29/2017 07:22AM by obelisk79.

Thanks for the suggestion obelisk i'll take a better look but the speeds look interesting, what i find interesting is the different solutions on offer with each current firmware implementation. one of my main goals is to be able to observe from anywhere in the house , Having had to take early retirement due to an old neck injury finally catching up with my second goal is to keep my brain active even if the bodies given up so looking at the firmware should do that while i wait for the boards to arrive.

I haver klipper running on my Kossel printer and compared to marlin klipper is so much better.

My issue with Klipper is the error handling. If something goes wrong it shuts everything down and just stops. Kevin is a very nice guy and is ready to help with every Klipper issue that might arise. And I did not have any issues for quite some time. So this might not be an issue for you.

And also I'm biased. I created a similar (Host+Client) Firmware and therefore naturally think that my version is better.

[github.com]

And just to be complete there is a third firmware of this kind:

[github.com]

So now you have 3 "firmwares" to look at.

Quote
paulbearne
Thanks for the suggestion obelisk i'll take a better look but the speeds look interesting, what i find interesting is the different solutions on offer with each current firmware implementation. one of my main goals is to be able to observe from anywhere in the house , Having had to take early retirement due to an old neck injury finally catching up with my second goal is to keep my brain active even if the bodies given up so looking at the firmware should do that while i wait for the boards to arrive.

Something kind of nice about persuing the Klippy option is that being hosted on a RPi, means you get wifi incorporated and adding a camera for remote monitoring should be a breeze.

Quote
JustAnotherOne
And also I'm biased. I created a similar (Host+Client) Firmware and therefore naturally think that my version is better.

Understand, now outside of error handling, is there anything your firmware does different or better than Klippy? I'm curious as I've never heard of it before.

I have not heard about franklin before - here's god presentation I found about it:

https://huskycast.hosted.panopto.com/Panopto/Pages/Viewer.aspx?id=feb39210-0629-4f95-b187-a452bf2588c9

https://openresearchsoftware.metajnl.com/articles/10.5334/jors.78/

From reading about franklin, peacamaker and klippy it appears that klippy is the most precise - from above link:

due to limits on the bandwidth of the serial port, this ideal situation only occurs at very low speeds (below 200 steps per second, which equates to around 4 mm per second, depending on the printer design). At higher speeds, the moves are interpolated in the same way as Pacemaker and most other firmwares handle non-Cartesian configurations. Franklin Firmware handles temperature controls, general purpose input/output (GPIO) pins, and control of stepper motors.

Edited 3 time(s). Last edit at 10/30/2017 01:25AM by newbob.

One thing that springs to mind with the mention of octoprint on the rpi is whether it would be possible to actually do a cut down version of it in the display module or controller food for thought i think i recall some work being done on this with an arm micro. thanks for all the suggestions will start looking through them.

Quote
obelisk79
Understand, now outside of error handling, is there anything your firmware does different or better than Klippy? I'm curious as I've never heard of it before.

Pacemaker is still in development. So Klippy is currently better feature wise. The main difference though is the split up between host and client and the communication between the two. Pacemaker moves all time critical stuff into the client. Whereas Klipper/Klippy has time critical stuff like temperature control and step calculations on the host side. Linux is not a Real Time OS. So if for whatever reason the Raspberry will not let klipper run for some short time then you print fails. If the pacemaker host stops communicating then the client can go on with temperature regulation. It will also continue moving/printing until the movement queue in the client has run out. The client should also handle this in a matter that it slows down and comes to a halt. So that if the host comes back again the print can continue. If the host is silent for too long then the client stops printing and shuts down the heaters so that it doesn't burn down the house. For details see the protocol specification here:
[github.com]

Quote
newbob
From reading about franklin, peacamaker and klippy it appears that klippy is the most precise - from above link:

I can not agree with this. As far as I can tell both Franklin and Klipper mess with single steps on the host side. Pacemaker doesn't do that. Pacemaker might split up one G-Code command into several move commands. But pacemaker does not change or influence the timing of the steps on the host. As Marlin and the other firmwares the Pacemaker client has a movement queue and calculates the steps and their timing. A client that implements the same step interpolation as marlin will obviously have the same quality as marlin. But pacemaker clients are free to do their steps as good as they can. For Pacemaker the serial bandwidth is not an issue here.

Quote
paulbearne
One thing that springs to mind with the mention of octoprint on the rpi is whether it would be possible to actually do a cut down version of it in the display module or controller food for thought i think i recall some work being done on this with an arm micro. thanks for all the suggestions will start looking through them.

Did you see this:
[github.com]

I used it on my printer and it works fine. One issue I have with it is that the current version can not handle sub directories. But as long as all your G-Code files are in the same folder this is a very nice solution. Especially with a touch screen ;-)

Quote
JustAnotherOne
I can not agree with this. As far as I can tell both Franklin and Klipper mess with single steps on the host side. Pacemaker doesn't do that. Pacemaker might split up one G-Code command into several move commands. But pacemaker does not change or influence the timing of the steps on the host. As Marlin and the other firmwares the Pacemaker client has a movement queue and calculates the steps and their timing. A client that implements the same step interpolation as marlin will obviously have the same quality as marlin. But pacemaker clients are free to do their steps as good as they can. For Pacemaker the serial bandwidth is not an issue here.

From pacemaker's doc:
Each segment will not trace a perfectly linear path but because the segment sizes are very small then this is usually not noticeable.[...]With Pacemaker, the movement planning is done on the host (typically much faster than the client) and so the number of segments which can be generated per second is likely to be higher (in this case)

From reading on both, klipper and pacemaker don't have much in common. One uses thin client, with most processing happening on the host and second does a lot more on the controller. Personally I like klipper's approach because controller firmware does motor control and GPIO read/write with everything else is done on much more powerful host, programmed with high level scripting language. Such combination should allow for rapid development and more features.

Edited 4 time(s). Last edit at 10/30/2017 12:32PM by newbob.

^I agree, one of the alluring aspects of Klipper is it's portability, and it's ability to offload most complicated and high level functions onto a host. That allows you to get better real-time performance on the same controller because it can focus solely on the low level stuff like executing commands. That headroom gained by this approach also means more complicated processing can be done without necessarily affecting speed performance of the printer.

having a had reasonable look at the various options i think that i can probably rule out marlin in its current form as imho i think that but trying to work with the many boards available it has become a bit dis jointed it performs well considering its 8 bit avr background but with esp32 we have a much more powerful beast and i don't think that marlin will harness that new potential. Now as obelisk79 says klipper manages the speed and real time stuff well i suppose this begs the question as i have 2 dual core 240mhz boards in the system so effectively 4 cpu's could the display unit be used as the host handling most of the higher level functions with a udp or tcp link between them feeding a buffer for the main control board to deal with as and when it needs it..

ESP32 still buggy so advantage to klipper, I think, is that majority of the code is running on raspberry pi. Besides, Python is not available for ESP32 and even if microPython was enough, it needs additional SPI RAM to run well.

If you are considering standalone firmware have you looked at MK4duo or RepRap?

Klipper really needs a host with a base operating system like Linux. So running it on your display board is not an option.

I'm not suggesting running Kevin's host software but taking a similar approach. if i take my current setup corexy running on rumba control board running marlin with a pc connected the pc has converted my model in GCode and sends them serial to marlin which then does all the calcs to move the motors to the new position. in its most simplistic form if i'm reading kevins code correctly and i'm not that familiar with python so may not be he has spilt the marlin bit so to speak into to two parts one part the host is doing the maths and that is sent to the controller in a form ready for it to do the move or adjust pwm on heater as well as request data back such as at readings and endstop state. so what i was thinking is that maybe the control end could use a port of klipper as is and the esp32 display have some new code to do what klippy is doing on the linux host the maths etc. i was also thinking that i would need a small pc app to upload the gcode file to the sdcard over wifi or this could be a web page built into the system that allows you upload the file and have some basic control.

That should be possible the way you are describing.

@paulbearne Your idea is probably more suitable for pacemaker or franklin. From what I read klipper requires low latency and jitter connection between host and client.

With that kind of hardware any approach should be more than adequate in terms of printer performance.

I originally suggested Klipper because it was specifically designed to be easily portable across hardware, pariing with a RPi would have meant that it would have been easy to pair with existing Pi displays and peripherals, it also brings wifi, ethernet and usb device support (ie webcams) to the picture with little additional effort. Since paulbearne has also designed a display board to pair with his controller, again, Klippy doesn't really seem like the appropriate choice anymore. While it could be adapted to work, I'm not sure the level of effort that would be required is justifiable. On the other hand, I can relate to wanting to do things the hard way sometimes as I find it both challenging and rewarding.

Taking all of that into consideration I think RepRapFirmware or Pacemaker might be viable options.

^I agree, klipper is a really interesting solution. I replied specifically to the idea of linking the two ESP32 boards over WIFI which I don't think would work well with klipper design.