I was wondering about the feasibility of using an ESP32 for running a 3D printer.

[espressif.com]

It is 32bit, runs at up to 240Mhz, has 32 GPIO pins, and costs right around 4 USD for the chip itself. There are multiple companies selling development boards for it with all the necessary support circuits for right around 20 USD.

My only concern is if the number and types of GPIO pins it has will be enough for a 3D printer. If they are not enough by themselves would using a SPI GPIO expander work or would that add too much of a performance hit.

Edited 1 time(s). Last edit at 05/19/2017 04:49PM by CthulhuLabs.

I did some analysis when the ESP32 was first announced, and I came to the conclusion that with a few tricks (not involving an I/O expander), the ESP32 had enough I/O to build a basic 3D printer controller around. But I've been so busy with the Duet WiFi and Duet Ethernet that I haven't had time to develop those ideas.

Bear in mind that the processor is a small part of the overall board cost, unless you choose to use an expensive processor heading towards end of life, as many controller boards do.

---

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

Thanks dc42!!! I know your assessment is sound.

Ultimately what I want to design is something to be a replacement for the RAMPS board. It would have five sockets for stepper motor drivers (X,Y,Z,E1,E2), three endstop pins (X,Y,Z), three mosfets for two hotends and a heated bed, a built in SD card slot, and a header for a dumb LCD (not like your super smart LCD).

I like the low cost / minimal feature set of the RAMPS board. It is a really good starter board for people building printers. The issue I have with it is how under powered the Arduino Mega is. I feel like this is one of the major limiting factors in printer performance and feature sets.

By making a similar board that accepts one of these:

[espressif.com]

It will greatly reduce the cost of entry for printers running 32bit code. They are also cheaper than official Arudino Megas and I feel that cost is going to be going down as their production increases.

I want to make the board fully open source like the RAMPS and I fully expect cheap Chinese knock offs to follow.

My preliminary design included software-settable stepper motor current too. Having to twiddle pots to adjust stepper motor current is an abomination that no novice 3D printer builder should have to endure.

---

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

While I fully agree with your assessment of the pot adjustments, making the voltage adjustment software based requires the stepper drivers to be built into the board. This raises the cost of the board itself and reduces the molecularity of the design. As someone who has fried multiple stepper drivers when starting out, having the ability to change them out without replacing the whole board is a blessing.

It would be nice if there were stepper driver daughter boards that could take an external voltage adjustment source. Might be something to look into making as well.

Users fry plug-in stepper drivers precisely because they are plug-in (hence inadequately cooled and with too long a path to the supply capacitor) and because they don't get the current setting right. Stepper drivers properly mounted on a PCB with precise current setting in firmware are at least an order of magnitude more reliable. Ask Think3DPrint3D, they used to sell kits with RAMPS and plug-in drivers, then they switched to the Duet.

It would be perfectly possible to design a plug-in driver with digital current setting. I designed one a couple of years ago. It used an extra pin on one end of the carrier to pass Vref. But that doesn't get around the other issues with plug-in drivers.

---

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

The Trinamic Stepper Drivers can be "sort of" voltage adjusted by SPI. I designed a stepper driver daughter board that uses a trinamic stepper driver. Problem is that due to the SPI needed it is impossible to do it plug-in compatible to the pololu boards. Therefore it only makes sense if you also come up with your own base board for those stepper daughter boards.

It might also make sense to move the stepper controller chip to the motor. In industrial applications you often see a PCB attached to a stepper motor that carries the driver and an encoder. This would remove a lot of EMI from the printer controller board. wiring these things is then another issue,...

If you are building your own pololu/RAMPS compatible stepper driverboard and want to replace the potmeter adjustment:

1. Set enable signal to disabled. This tells the driver to be in config mode
( not the driver chip itself, but an interface chip acting as digital potmeter )

2. send steps and dir signal to be interpreted as " current up" or "current down". ( relative mode )
(eg. 1 step = 1mA) ( might require a new gcode or extra parameter )
2a. Same procedure, but steps are interpreted as absolute value.

Current adjustment would then look like: G1 S1 E1300 X500 Y500 Z1200 F[full speed], where S1 is the new adjust-mode parameter

Edited 2 time(s). Last edit at 05/23/2017 02:35AM by o_lampe.

I've been into ESP32 for a bit, after I did an ESP8266 Marlin port, and smashed into the tricky problem of limited number of pins.
I looked at it from firmware point-of-view.

So, diving into the ESP32, first thing:
Seen many complains about the Arduino core for it. It is far from complete.
If you'd like to use some Arduino-based code like Marlin, then it will be a huge headache.
Even its own SDK, the esp-idf is far from complete, constantly being updated, and the Arduino core is based on that. Many-many low-level accesses with not compatible registers, non-existing EEPROM, and stuff like that.

And it would be a waste to use standard "8-bit Arduino"-based code for this thing, which is a tad bit stronger, and has more peripherals, like native SD card interface.
It's on the level of 32-bit ARM processors, so something like RepRapFirmware or Smoothieware would be worthy for it. Problem is, they are very much not alike, especially the Smoothie.

There is another thread here where a new, FreeRTOS-based firmware was suggested by lhartmann (for ESP8266), and is also good for the ESP32, because esp-idf is FreeRTOS-based.

Now onto the next problem, which is before the potmeter adjustment problem. Let's put that aside, and use the old fashioned method.
How will you drive the stepper controllers?

There is the timer-based standard method, but ESP32 has some HW-accelerated solutions, like:
- PWM with modifiable frequency. Set it to 50%, and just adjust the frequency when needed. Also set a pulse counter on each output, so they can be HW-tracked, and set interrupt for them to adjust when needed. Well, there are more than enough channels, but the main problem is they can use up to 3 different timers for frequency. Meaning up to 3 steppers.
- Motor control PWM. It is specifically designed to drive different kinds of motors. Not steppers though... And there are only 4 of them, if I remember correctly.
- I2S with shift register, as lhartmann did. Clever idea. ESP32 has a parallel mode for I2S which would exclude the need for additional ICs, but well... the shift register version uses up less pins on the ESP32 itself. This way it is the ultimate method if you need pins. This could be considered.
- SPI. ESP32 has 3 SPI interfaces each with up to 3 HW-controlled CS pins. One SPI is used for flash and external ROM. The basic pin positions of another one share the SD card pins, but if I'm correct then with the GPIO matrix they can be used on separate pins, so we can have SD pins, and 2 SPI interfaces. That means 6 HW-controlled CS pins, but it would kick out everything else SPI-related. Unless for one SPI we use SW controlled CS pins, dedicated to stepper controllers, and have the other SPI for LCD and stuff. Maybe this could be it, but needs to be tested.

I'm into it, but have other things to do. At least I can tell you that it most likely needs its own firmware.
Or wait for the Arduino core to catch up, and have lots of headaches.

My ESP32 dev board finally came so I am getting back to this.

@Hubberthus - Pretty much figured it would run RepRapFirmware. Among other things it is the firmware I am familiar with on my existing RADDS board. Also dc42 is pretty much the maintainer of it, which is why I was happy to see him saying that the ESP32 should work. I do need to dig more into the HW acceleration capabilities of the ESP32.

@dc42 - Again while I agree that software settable voltages is a great thing, I think it is a luxury and not a necessity. Among other things it locks you into the stepper drivers that come with the board. Also when I fried a stepper board it was because of a problem in my wiring and not with my voltage setting. I do like the idea of extra pins to supply an external Vref for daughter boards designed to support them though. With regards to your concern about cooling, one of the design constraints I wanted to put on the board was making sure that there was plenty of air flow around the stepper driver boards. I realize that most of these chips are designed to be cooled from the bottom and not the top. As such I wanted to design the board so that air being blow across it has an easy path under the stepper drivers. If you look at a RAMPS board there are those stupid jumpers and capacitors in between the socket for each stepper driver. As for the distances to the supply capacitor, I may be misunderstanding what you are referring to, but this sounds like an issue with the design of the actual board and not with using daughter boards.

There already exists Pololu like driver with addon Pins for digital Vref, from panacutt
Also the fitting board for that is available there.
They also have a ARM Upgrade for the Ramps Board
Unforunately all in the USA, so not really orderable for me.

I´m also for a simple new 32 Bit board for long time, also had a couple of discussions here at the forums with DC42 about simpler and lower cost boards.
For me the conlusion is that DC42 with his Duet boards is willing to only adress the "Apple-Like" users with big money pockets and not want to be annoyed with users who want to tinker around on their machines and do not have that big money pockets ...

@ Cthulhulabs do you have some more information about your board ? i`m looking since long time for a good 32 Bit Entry class board

Chri

---

[chrisu02.wordpress.com] Quadmax Intel Delid Tools

@chri - The board is just a concept at this point. I am currently finalizing what I think should be on the board.

As for those SD5984 drivers, it is a good concept, but the position of those extra pins means that will restrict airflow under the board. Might not be a problem for this specific stepper board, but for stepper driver chips like the DRV8825 are designed to have thermal vias bring the heat to the underside of the board so airflow under the daughter board is very important. However the design I have in mind would be very easy to route a jumper wire from the socket to the external Vref on the SD5984.

As for that 32bit board to make the RAMPS 32bit, that board is too specialized. It basically only has one purpose which is to make the RAMPS board 32bit. It also has to have a large number of 3.3v to 5v level shifters for the processor they are using to communicate with the RAMPS board. As such it will always be expensive. It looks like the KickStarters has those boards at 39 dollars. Generally when KickStarters go into production they charge even more than what they charged the backers. The ESP32 is a general purpose IoT board that just came out. The actual chip costs just four dollars (lower in bulk). The Development board costs just 15 dollars. As the production and popularity of these boards increases for all sorts of IoT devices the costs will go down.


Currently I am planning on having 5 external stepper driver sockets. These sockets will be compatible with the Pololu A4988, but have an additional 6 pins. 1 for Vref, 1 for GND, and 4 for SPI. There will also be a one pin space between these extra pins and the standard A4988 pins so people using A4988 and compatible boards do not accidentally stick them in the wrong location. So it would look something like this:

Enable *       * VMOT
   MS1 *       * GND
   MS2 *       * 2B
   MS3 *       * 2A
 Reset *       * 1A
 Sleep *       * 1B
  Step *       * VDD
   Dir *       * GND

  Vref *       * GND
  SCLK *       * MOSI
    SS *       * MISO

I want it to also have an MicroSD card slot, three MOSFETs, three thermisters pins, three end stops pins, headed bed control, and at least one servo hook up. The question is can all of this be done with the I/O on the ESP32 or do I need to get an external GPIO chip.

The board in general will be larger than the RAMPS board and most other boards out there. I want the components setup so a fan blowing across the board has easy air flow under the stepper drivers as well as around the MOSFETS. The MOSFETS I want to have plenty or room for an external heatsink as well.

The initial board will be designed around having one of the ESP32 Development boards socketed into it. This will make revising the board easier. In the future though might move the ESP32 directly onto the board to reduce overall cost.

So yeah that is where I am at, and I am still very open to suggestions.

Subscribed.

So far this is what I have come up with for GPIO needs:

X-Enable
Y-Enable
Z-Enable
E1-Enable
E2-Enable
X-Step
Y-Step
Z-Step
E1-Step
E2-Step
X-Dir
Y-Dir
Z-Dir
E1-Dir
E2-Dir
X-Vref
Y-Vref
Z-Vref
E1-Vref
E2-Vref
X-EndS
Y-EndS
Z-EndS
H1-PWM
H2-PWM
HB-PWM
T1-ADC
T2-ADC
TB-ADC
SRV-PWM
SPI-MISO
SPI-MOSI
SPI-SCK
SPI-SS-SDcard
SPI-SS-AUX
SPI-SS-X
SPI-SS-Y
SPI-SS-Z
SPI-SS-E1
SPI-SS-E2

That is 40 different GPIO pins which is more than the ESP32 has. Now with some advise from dc42 I have started to get creative.

Enable - The XYZ enable pins can get tied together. E1 and E2 I want to keep as separate as being able to disable the stepper on each independently to switch filaments is a good idea. This saves 2 pins.
Direction - All of the DIR pins could technically be tied together. It would just mean that the firmware would have to step the stepper motors in two passes (one pass for one direction, flip the DIR pin, one pass for the other). This obviously cuts down on speed though which I'd like to avoid. The extruders though do not normally run at the same time (unless you are using a mixing hotend) so tying them together can work. This saves a pin.
End Stops - Most firmware only actually use the end stops when homing. After that it is just counting steps to and from the 0 position. As long as X, Y, and Z home separately having a shared End Stop pin should not be a problem. This saves 2 pins.
Slave Select - Now if I am willing to use an external address decoding chip, I can save 4 pins and pick up an extra SPI device. These chips are cheap and very easy to interface with.

So with the optimizations I have come up with this:

XYZ-Enable
E1-Enable
E2-Enable
X-Step
Y-Step
Z-Step
E1-Step
E2-Step
X-Dir
Y-Dir
Z-Dir
E1:E2-Dir
X-Vref
Y-Vref
Z-Vref
E1-Vref
E2-Vref
EndS
H1-PWM
H2-PWM
HB-PWM
T1-ADC
T2-ADC
TB-ADC
SRV-PWM
SPI-MISO
SPI-MOSI
SPI-SCK
SPI-SS-ADR1
SPI-SS-ADR2
SPI-SS-ADR3

This takes the GPIO needed from 40 pins down to 31. The ESP32 dev board has 33 GPIO pins available so in theory this is very doable and allows for some leeway in the optimizations. Now the pins on the ESP32 are capable of multiple functions, but none of them can do all of the functions. The question is are there enough pins of each type of pin to do what needs to get done. That is my next task to research.

I am very much open to advise / opinions / questions on these optimizations.

Edited 1 time(s). Last edit at 07/26/2017 04:43PM by CthulhuLabs.

A few comments:

- If you want to get a good file upload speed to the SD card, you need to use a 4-bit bus to the SD card (which the ESP32 supports) instead of using SPI.That means you need 6 pins dedicated to the SD card, assuming you don't bother with a card detect pin.
- From a firmware perspective, once you share two direction pins, you might as well share them all.
- Consider sharing the X and Y Vref, also the E1 and E2 Vref.
- Don't share endstop switch inputs, it's no good for delta printers and some other types.
- You might be better off dropping support for the 2nd extruder. Single carriage dual nozzle printers are falling out of favour. The trend is towards IDEX (2 carriage) or Diamond (3-input mixing) extruders, both of which need 6 stepper drivers.
- You need at least one PWM-controllable fan, and preferably a second controlled fan too although you don't necessarily need PWM for that one.
- I don't see a Z probe input.
- Do you intend to support a display + encoder? If so then you need 3 output pins to control a 12864-type display and 3 input pins to read an encoder+switch. OTOH as you have WiFi then a display could be considered unnecessary.

HTH David

Edited 5 time(s). Last edit at 07/26/2017 05:03PM by dc42.

---

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

Whilst 2 extruders is better than 1, 3 is better than 2 since it allows use of the increasingly popular Diamond 3 colour nozzle. And there's also the newer Diamond 5 colour nozzle too.

I have LED lights on my printer (controlled by OctoPi)... it would be convenient to have that directly on the printer.

To get some extra pins, you could also control the stepper motor direction and enable via the SPI. Say 8 steppers max = 16 bits so a 2-byte digital output buffer. That would give you 8 CPU pins back, 3 of which you would use as step outputs for the extra steppers, 1 for the light, and couple of spares for whatever (e.g. Zprobe).

You *could* make the heated bed control external (my system came like that) to save a couple of CPU pins, although that's probably not a great idea.

So, taking David's suggestions above into account, I'd see

X-Step
Y-Step
Z-Step
E1-Step
E2-Step
E3-Step
E4-Step
E5-Step
X-Vref
Y-Vref
Z-Vref
E1-Vref
E2-Vref
E3-Vref
E4-Vref
E5-Vref
X-EndS
Y-EndS
Z-EndS
Z-Probe input
H1-PWM
H2-PWM
HB-PWM
Fan1-PWM
Fan2-PWM
Light
T1-ADC
T2-ADC
TB-ADC
SRV-PWM
SPI-MISO
SPI-MOSI
SPI-SCK
SPI-SS-Stepper enable
SPI-SS-Stepper direction

SPI
Byte 0: Digital output stepper enables
Byte 1: Digial output stepper directions

@frankvdh - While I appreciate the ideas, this is supposed to be an entry level replacement for the RAMPS board. I am trying to include essential features and keep costs as minimal as possible. If this board turns out well I will look into creating more advanced boards including things like 5+ extruders.

@dc42 - Ugg. So many things I forgot....

ESP32 ADC has non-linear response and lookup tables have yet to be provided by espresiff.

Quote
newbob
ESP32 ADC has non-linear response and lookup tables have yet to be provided by espresiff.

Well that could be a problem.

Quote
CthulhuLabs

Quote
newbob
ESP32 ADC has non-linear response and lookup tables have yet to be provided by espresiff.

Well that could be a problem.

Why? Take a lab Power supply. and create your own loop up Table,...

Each ESP32 batch has different characteristics. Considering that repeatibility is more important than accuracy (i.e. if printing works well at 220 setting - it does not matter that it really is 210degC as long as it's maintained) having no lookup tables it's not a showstopper (and I don't think non-linearity is significant to throw PID off) but something to keep in mind (in case you need GPIO for example, maybe going with i2c ADC chip would 'kill two birds with one stone').

EDIT: I found another thread and non-linearity appears to be an issue only at specific settings.



Edited 3 time(s). Last edit at 07/27/2017 01:35PM by newbob.

I am seriously considering a GPIO / ADC / DAC chip on the board. Just wanted trying to keep costs down and easy enough to construct by someone in their house if they wanted to.

I am more worried about the noise they mention in the thread. Up to 5% apparently. That could be really bad for temperature readings.

Well looks like I need to setup the ADCs on my dev board to test how noisy the various dB levels are.

Is Vref output analog (DAC), PWM or someting else?

Edited 1 time(s). Last edit at 07/28/2017 11:03AM by newbob.

Not sure. Their documentation is still a bit sparse. To put it into perspective googling "esp32 DAC Vref" has this thread as the 4th link right now.

From what I can tell Vref signal is for software control of stepper current - correct?

I can find few ways to do it (I could not find how panucatt does it):

native DAC - problem with those is that there are only two on ESP32
PWM - as suggested by TI doc here
multiplexed DAC - more difficult to implement PWM, but save on GPIOs
8 channel DAC such as MAC5258 controlled via SPI - saves on GPIOs but requires SPI and adds $2
digital pot IC with non volatile memory (this seems like a simple way also but digital pots are 20% tolerance and do not compensate for temperature change)

To keep it simple PWM seems the best way to go - I just wonder what steppers/drivers would do when Vref is 0 (during boot) and what happens when ESP32 locks up?

Edited 1 time(s). Last edit at 07/31/2017 10:03AM by newbob.

I am sorry, I misunderstood your question. Not enough caffeine for a Monday morning.

Right now I am leaning towards PWM for the stepper Vrefs.

@CthulhuLabs - If you can port the RepRapFirmware to ESP32 then I won't be in your way It's a really nice firmware, I like browsing through the code (and drooling over images of DuetWifi)

Just saying that it won't be an easy run. Prepare for thinking about alternatives for example in "Platform.cpp" the ARM specific registers, assembly codes, interrupts, etc.

I'm looking into the Arduino core for ESP32. It is pretty usable now, most of the basic stuff already in. There are ESP-related things missing, but the devs are working hard on it.
Took a peek in the SPI code, and saw what I expected to see. It is blocking, not using the DMA. Would be nice of them to add that in. But well, even the whole I2S code is not there yet.

And on HW side:
There may be 34 pins on the module, but not all of them is actually fully available.
- 6 pins are used up for the QSPI flash. Even in the future version of the chip with internal 2MB flash these pins will be connected to that. It is highly not recommended to try using this SPI bus for other than external flash/pSRAM. Not impossible to use, just pretty hard, far away from a simple "SPI.begin()"
- 2 pins are used for UART0. This means that if you want to have USB printing through a host SW, these can't be used for printing. Or no support for USB serial and have these extra 2 pins. ESP32 is wireless, so why not? Of course you'll have to put the server stuff there. (WebServer and SPIFFS are not yet officially in there, but slightly modifying the ESP8266 code they can be used until then.) Or simply use an SPI module with LCD to start SD printing. And for flashing maybe have a jumper, and/or use OTA.
- GPIO36-39 have special functions, and on the ESP-WROOM-32 module you can see only 2 of them (36 and 39). The 2 hidden ones are connected to these via capacitors. On the "SparkFun ESP32 Thing" 37 and 38 are accessible. So if we're really desperate, 2 additional pins can be used.
- If native SD card interface is used, then GPIO2 needs to be pulled up, but for flashing it needs to be pulled low. So either a jumper, or some way to automatically pull low when flashing. SD can be used through SPI also, so it's not a must. Especially that it would use up additional pins.
- And of course don't forget about this: http://jiahuang.github.io/images/esp32_boot.png

All in all, there are by default 26 pins available. By disabling UART0 it is +2, and by accessing "37 and 38" also +2.

I really recommend using external GPIO IC. I'm thinking in either 74HC595 or MCP23S17. Have both of them, just no time to test.
Damn work. Why can't I get money for having fun at home?

The 2 DACs in it are only 8 bit ones. PWM is much more precise.

Edited 2 time(s). Last edit at 08/01/2017 09:28AM by Hubberthus.

deleted

Edited 1 time(s). Last edit at 08/01/2017 10:02AM by newbob.