Controlling a RepRap with ESP8266 and no Arduino

I believe I found a way to use just an ESP8266 module to control the stepper drivers directly. This post explains how.

Background:

1. Other projects show how to use ESP01 as a wifi-serial bridge to the arduinos, but serial is still a bottleneck and wifi uploads are impractical.
2. Altough ESP8266 does 160MHz at 32bits processing (versus 16MHZ 8-bit from most Arduinos) it has insufficient realtime GPIO for controlling printers.
3. Raspberry pi shared the realtime gpio limitation, but wallacoloo still did reprap control using DMA. Nice! [www.youtube.com]
4. CNLohr did a really cool WS2812 led driver (weird one-wire serial protocol) using ESP8266 I2S audio output and DMA. [www.youtube.com]
5. I2S and SPI look very much alike, and SPI can control shift registers. Hey! Opportunity!

I got the code from CNLohr on github, modified it to output a 32 bit counter (16 bit left + 16 bit right channels) via a circular DMA buffer, and created a small PCB with four cascaded 74HC595 shift registers. wiring is simple:
- I2S Data to '595 input data
- I2S Bitclock to '595 shift clock
- I2s word clock (left/right) to '595 buffer clock.

This is what RAW I2S output signals for the counter look like: word-clock (yellow), bit clock (cyan), data (purple). Notice how LSB of data is output after the word clock rising edge. [www.youtube.com]

Fixed the offset (software shifing) to match the parallel outputs, raised the frequency a bit (just cause), plugged in the shifter board. Now this is what word-clock (yellow) and the 3LSBs (cyan=1, purple=2, blue=4) look like:


The code and the PCB: (https://github.com/lhartmann/esp8266_reprap)

What this does:

- Allows realtime bitbanging of 32 data bits via I2S and DMA.
- Demo code just outputs a 32bit counter at 185kHz sample rate.
- Reference shifter board is provided.

Limitations:

- 1MSB is actually delayed by 1 sample due to I2S signaling standard. This delay is constant so it could be compensated, but I didn't bother.

Hopes for the future:

- No extra arduino necessary, ESP would control the drivers directly.
- SDcard uploads over wifi would be feasible for large files, no more serial connection bottleneck with wifi-serial bridging.
- Browser-side slicing with slic3r and (http://www.skulpt.org). No software install required on the client!

Edited 1 time(s). Last edit at 12/10/2015 05:34AM by lhartmann.

I only understood half of it, but it sounds interesting.

How would you read thermistors and where would you translate the gcode? Is it all done in the ESP? Or would a permanent PC connection be required?
-Olaf

... the Arduinos does a pretty good job at realtime-clocking of the steppers, what's a gigantic overhead needed, to do this on a 'common' OS, not specifically programmed for RT operations.

The 'real' problem starts, when you try to control more than 2 or 3 axes at higher sppeds than some ten kHz from Windows ... and if you want some sort of lookahead ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Quote
o_lampe
How would you read thermistors and where would you translate the gcode?

As far as I know ESP8266 has a single analog input, so some kind of mux would be required:
1 - Maybe a CMOS analog mux IC, probably the best option.
2 - Maybe use a GPIO driving the low-side of each thermistor, and a single resistor pulling all thermistors up. Something like a Y upside-down. Switching the GPIOs between LOW or High-Z one could select which thermistor one would control ADC voltage, at the center of the Y. The GPIOs o the '595 have no individual High-Z control, so either a direct ESP8266 IO or an open collector IC vould be required...
3 - Wallacoloo used DMA inputs and slope ADCs. ESP8266 has a I2S input, so maybe this could work using the I2S ouput clocks to drive the I2S input and paralel-in-serial-out shifters, but I have not testes. Also I have never seen docs on the I2S input module for ESP8266.

Quote
o_lampe
Is it all done in the ESP? Or would a permanent PC connection be required?

The arduino on my melzi handles SD printing nicely, and it is a 16MHz 8bit processor. I don't see why the 160MHz 32bit CPU of the ESP8266 would behave otherwise.

Quote
VDX
... the Arduinos does a pretty good job at realtime-clocking of the steppers, what's a gigantic overhead needed, to do this on a 'common' OS, not specifically programmed for RT operations.

The 'real' problem starts, when you try to control more than 2 or 3 axes at higher sppeds than some ten kHz from Windows ... and if you want some sort of lookahead ...

I know about the realtime limitations of regular OSs. Did you see the raspberry pi GPIO+DMA video from wallacoloo? It uses regular linux to create a large memory buffer, and DMA ensures the correct timing. ESP8266 MP3 player example from EspressIF does realtime nicely for audio, and I really don't believe stepper control can be more computing intensive thar MP3 decoding. :-)

... single tasks are not problematic ... single motor axes neither ...

The problem starts, when you try to calculate synchronous movements with 4 axes (XYZ+Extruder), push them in a buffer, and then start the timing for 4D-Bresenham to do some smooth positioning with Acc-/Decceleration with 100mm/s and microstepping

I'm in cooperation with two companies, that develops RT-cores (and DLL's on Windows to drive them), where the cores are STM32F4 boards with 200MHz clocking speed ... and they are only capable of 100kHz synchronous moving with some lookahead for XYZ and time-syncing for only a single I/O-pin! -- I'm driving some of my laser-engravers with this boards ... they did the "pin-syncing" after I've notized, that the lookahead separated the moving clocks from I/O-switching, so the laser-pulses were off some milliseconds, what's clear visible in the start/stop-positions of engraved lines or single dots

They plan actually (or are developing) to switch for much faster processors or change for DSP to get this faster.

Now estimate the complexity level for 4 axes and some more pins synced with the positioning ...

Edited 2 time(s). Last edit at 12/10/2015 11:24AM by VDX.

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Maybe I'm just too stupid, but...
There is Arduino IDE working with ESP.
The ESP does have the pin limitation, I agree, but you can use shift registers - with 10 times the clock speed, one should be able to simply recompile the firmware with something like digitalWrite to digitalPush...
Maybe I'm just too optimistic.
But whatever I did with ESP-12 was WAY faster than Arduino, including GPIO operations. Perhaps the DMA is just overkill...

It's a very creative approach, but if the esp32 arrives soon that may provide a far easier route for a new 32 bit printer controller.

I agree, wait for the ESP32. You don't want to be using a single processor for both WiFi comms and stepper motor timing, especially when the source code for the WiFi comms part is not available. You could consider the ESP-13F which has a second processor on board; however you would still be short of I/O pins, whereas the ESP32 has just about enough I/O pins already.

---

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

There are FreeRTOS ports for ESP8266, and apparently there is already an official FreeRTOS SDK released for the ESP32... I guess developing/porting firmware for FreeRTOS could solve several issues at once:
- Legacy support (ESP8266).
- Future proofing (ESP32).
- Realtime versus TCP/IP stack concerns.
- Potentially portable to other CPUs supported by FreeRTOS.

Is there any progress here?
For me this is still very interesting...

I evolved a little on the software side, very little in the hardware.

- created a subchannel driver for slower outrputs (direction, enables, led lighting) that can change only once per move. This let's me use up to 30 outputs for fast outputs (pwm, step, delta-sigma modulators).

- wrote modular motion drivers which should allow for up to 30 steppers (bresenham line drawing and acceleration). Tested only in software for now.

- wrote a laser driver which basically considers it as another stepper with no direction (constant output power/mm, even while accelerating).

Then when I was about to try the stepper and acceleration driver on the actual hardware I ran into a toolchain issue I have yet to fixed.

As I was reading, though, I noticed the Espressif's MP3 player example (the one from which cnlohr had derived his code from) has basically all the features I need to make it work, namely FreeRTOS, network and DMA-I2S output in a continuous loop. I still need to spend some more time there, though.

Edited 1 time(s). Last edit at 06/13/2016 07:31AM by lhartmann.

Wow, this looks amazing. One stupid question - what's the possible frequency you can achieve with this DMA approach when just setting one pin on and off using the 595?

Not sure where the ESP would limit you, in my case it is the shift registers who are limited to <6MHz bit clock.

In the screenshot up there you can see 185kHz for the yellow channel, but that is for word clock. Bit clock is 32x higher, 5.92MHz. If you are using a single data output it can be updated at this rate (actually higher since you are not using the shifter), which means that you would be able to create ~3MHz signal via the data line.

If you need only the data line then ESP01 modules are your friends. Bit clock is not available on them, though, which is why I am using a NodeMCU board.

6MHz? I thought you are using 74595 for that - if you make a simple resistor-based voltage shift, you can use clock with 595 at cca. 31MHz.

But still, 185kHz is plenty even for PWM signal!!!
I have to try this at home - I have few ESPs lying around. Just not sure if a breadboard can handle 6MHz signal

Hi lhartmann. I read your article for hours, almost read all related blog, forums, videos, even some source code at github. But I can't see the whole picture. So I assume the system should be like this:

1) Firmware (Should be named Wallacoloo, am I right? )Runs on PI.
2) FIrmware read gcode from USB , or SD-CARD. (Possible from ESP?)
3) Firmware translate gcode to stepper driver signal. But when firmware access GPIO(Here is write), They don't use command/function GPIO_WRITE (), They use DMA. (am I right?)
4) You remapped DMA to ESP module (I name it ESP-A).
5) -------------------- All wires cut here ----------------
6) ESP-B received GPIO mapped data. (I can't find any information you mentioned you have 2 ESP, I just guess)
7) SPI/I2S output the signal.
8) HC595 convert serial to parallel data. (From now, I confirmed I am on the right way)
9) Stepper driver get the GPIO data from HC595.

May I ask you to show us a diagram of the whole system? even a very draft sketch will be helpful .

Thank you so much for sharing a so excited idea.

Nope, no Raspberry Pi involved either. Just an ESP8266.

As far as I can tell there is no currently released firmware that can do this.

The big picture would be something like this :

1 - generate the gcode on your computer with your favorite slicer.
2 - have an sdcard connected directly to the esp8266 (see node mcu for it has a lot of io)
3 - copy the file to the sd over wifi. Should be fast, since the sd is connected directly to the esp there is no uart bottleneck limiting to 11.5kB/s.
4 - from this point on the esp is the only processor involved.
5 - esp loads gcode from SD, interprets it and generates step/direction and PWM in memory buffers.
6 - esp's dma is used to ensure constant rate of feed from memory to i2s.
7 - Several miliseconds of buffers and freertos ensure no hiccups.
8 - shift registers break i2s data into 30 fast data bits updated at 200kHz, and 32 slower subchannel bits updated once per move.
9 - fast data is used to drive step signals, and pwm or Sigma delta for analog outputs.
10 - subchannel data can change once per move, and carries direction bits and on/off controls for lights and fans.

Except for freertos I tested the steps 6-10, then I got stuck with sdk changes I could not solve and a desk job taking all my time...

I feel the best way to get this done is to start from the duet port to the esp8266, and replace the serial-arduino backend with our own interpreter and dma driver. Unfortunately esp-duet runs on top of the arduino-esp stack, and we need freertos for the real time motion control.

I also developed reasonably modular code for bresenham, pwm, sigma-delta, laser pulsung and acceleration management that should allow steppers+lasers+pwm+sigadelta=30 on the described hardware. Unfortunately this was after I messed up my ESP development environment, so I could only validate this by simulation, not on hardware... I'll upload this to github once I get to test it.

Just a hint of what I see as the huge picture: kill step 1 from above.
- Esp server a page from the sdcard.
- the page contains openjscad, so you can model your stuff in-browser.
- the page also contains slic3r and a skulpt, a python interpreter written in javascript, so your browser can do the slicing.
- the page contains jscut, if you are using it for laser or milling.
- no more software is required on your computer, you have a cloud printer in a cloud you own and control, and can run your full workflow from a chromebook if you wish.

I'd suggest a bit different approach.
I spent quite some time reading and trying to understand the Repetier firmware. And, I have to say, it's written beautifully.
It uses routines for outputing all signals (steps, direction, ...).
So the modification from port write (used by registers in the firmware for AVR) to DMA address should be "relatively simple".
However, where I would struggle to do something reasonable is the inputs - and it uses quite a lot of them. The minimal set includes endstops (3-6), rotational encoder for input, additional input buttons, etc.
The outputs are quite OK - you need 4 pairs for steppers (8 together), 3 PWMs (extruder, bed, fan), ~8 for LCD and some for SDcard, for sure.
I'd also strongly suggest to keep the serial port from ESP available.
All in all, 16 fast outputs + 3 PWM outputs should be no problem using the DMA. You'd have still plenty to spare for controlling a LOT of things (e.g. additional extruders, servos, ...).
Current firmwares, as far as I understand, output stepper/direction at MAX 20kHz, if I read the code correctly, so 200kHz seems plenty fast for this sort of firmware.
It looks to me much simpler - especially considering you can use Arduino environment to build, compile and upload it to ESP.
And, when combined with wifi firmware update - this can be a market killer

Hi lhartmann ,rklauco
I clearly know what you are going to do now. Seems you have a good idea. But, I am afraid the step #5 you mentioned as below:
5 - esp loads gcode from SD, interprets it and generates step/direction and PWM in memory buffers.
This is totally rewrite a 3d printer firmware, Again, you need to confirm these are not the barrier of your project
1) How open is the MCU chip (Sorry, don't know anything about it, Is that a ARM-CM3?).
2) To make a firmware workable might be easy, But there are huge of works to do to make it to be stable,

And one more thing: What is the benefit of your solution? So far as I known,
3) Cost down by removing a ATMega.
4) More compact PCB size.
5) Higher performance (I am not sure).

But be honest and reasonable, I don't think these factors can be a killer in future market.

Roughly:
- cost benefits - although this is questionable when counting 595s and ESP
- adding wireless by design (!!!)
- faster CPU (80MHz chip)

For me this is a quite clear choice - right now both my printers are using much slower ATmega CPU to drive the printer while using ESP (way faster and more capable chip) to only communicate - and even this is done using serial port, so it is SLOW.

On the reliability - I am running multiple ESPs, one of them constantly connected and reporting values for 8 months in a row for now. And, the chip is working with basic arduino ide, so the code that works OK on ATmega should (in theory) work OK on ESP, too. So far I did not run into issues with Arduino code compiled for ESPs, but I only tested devices with 1-wire, i2c, PWM and general I/O, nothing nearly as complex as i2s and mirracles like lhartmann does

Oh and I forgot to mention - you can run web interface directly on the chip and do firmware upgrades wirelessly - seems like 2 more benefits

It is not an ARM, it's a xtensa lx106 (if memory doesn't fail). I've never heard of it before ESP either.

Current ESP8266(wifi-serial) + ATMEGA1284(Marlin):

+ It is ready to use, I do.
- Serial link limits interaction of wifi and sdcard.
- completely useless for wifi uploads, 6 minutes for 1.5 MB of gcode...
- Weak motion control CPU: 8 bit 16MHz. Not that big of a deal, though, as it does what it is supposed to.

Proposed ESP8266 + 74HC595:

+ Extra cpu horsepower: 32bit 160MHz (still no float, though).
+ high bandwidth between SD and wifi:
+ uploading 1.5MB could take about 1s.
+ could download gcode back to the browser without stopping print.
+ would enable chillipeppr on the esp to monitor print real-time.
- Long way to go before it is ready...

Check the chilipeppr tinyg workspace, load a gcode, and imagine that accessible through your printer's webpage.

I am (slowly) reading through repetier firmware, trying to find out how hard would it be to use it as a starting point...

P.S.: There is another way to get fast uploads, I called it SD takeover [http://forums.reprap.org/read.php?2,582444,641553#msg-641553]. Basically a digital multiplexer would allow the ESP to take control of the sdcard during file upload, but let the atmega handle it the rest of the time. This would not allow for the nice 3D realtime monitoring, though, as ESP would not be able to get to the sd during print... Unfortunately I lack the time or skill to make it work. :-(

P.S.: Another option would be to permanently couple the SD to the ESP, and implement a gcode sender on the esp. This way we could use a regular atmega for motion control, but still have the high throughput between wifi and sd, so we could still use nice web interfaces sua as chillipeppr.

Hi all,
I read a lot about applying ESP8266 to a 3D printer. So excited. It's really cool of taking over SD concept. I am trying to compare the two solutions:

ESP8266 nodemcu                      FTDI232 + USB cable + USB socket + SD card + SD socket.  
BOM cost                  2$+                                                  15$+
Upload Speed           1MByte                                          250Kbit (250,000bps)
Distance to host        Internet                                          meters
UI SW                        Web browser                                one of PrintRun, Cura,Repetier-Host,etc
Remote Update FM   Could be                                       No.        (long distance remote, like from manufacture side)

Okay,Let's come back to rethink about removing AT-Mega (Arm-CM3 ) firmware host. Essentially we are talking about migration Marlin(or Repetier etc) from AT-Mega to LX106. Yes, It is really great that ESP is supported by ArduinoIDE, But nobody can grantee two things:
1. All functions inside lib.h (and tons of other libs) can be launched correctly.
2. Some low level functions in Marlin(include all the others) is written by assembly language, not C/C++. Will the owner of LX106 support us to do that? Is the information enough from datasheet of LX106?



An alternation of ESP266 is (I didn't know its exsiting)
[www.dx.com]

This guy is a little bit higher price than ESP, but have more parallel interface, more GPIO pins(at least is available on the chip ).even SDIO. More important, If we want to migrate firmware from which based on CM-3 like Smoothieware(is there other option else?), It can be quite smooth.

Comparison table
                                  ESP                   NL6621
Price                          2$+                     5$+
GPIO                         Few                     Sufficient
Cost to ext GPIO       2$+                     0$
Migration                    very Risky          Smooth

Right now, I realized the solution is not doing migration from Marlin to ESP. It should be a migration from LPC1768(or STM32) to an WIFI-able CM-3 chip.

Edited 1 time(s). Last edit at 07/06/2016 01:06AM by voicevon.

I have to say that NL6621 seems very interesting. But I have a slight problem - although the specs mention 32 GPIOs, the only modules I can find for reasonable prices ($3-$5) only have 8 pins (same as ESP-01 module).
Do you, perhaps, have a link to something better which really has the mentioned number of GPIOs and still costs within reasonable numbers?

Searched for hours, couldn't find any board pin out 32 GPIO. Maximum one has 16 pins connected to out of board, but must be V+, Gnd,etc.
One useful link is here:
[www.hotmcu.com]
I am not clearly understand discription of : "Five Wi-Fi networks operating modes: 1.BSS STA 2.Soft BSS AP 3.WIFI direct (SDIO card mode) 4.Ad hoc 5.DirectConfig a key shortcut configuration." Please pay attention of #3, Are they saying the 8 pins board can connect SD card and work at SDIO mode directly?

Noted the board has SPI interface?Great!

Short term solution:
1) Modify marlin communication with host from UART to SPI. Marlin handle the SD card, should be faster than UART.
2) NL6621 is the host, web server.
3) UI is browser.


Long term solution:
Only one head, the NL6621, Handle everything. Since it's a CM-3 core, Should be smooth when migrate firmware.

Honestly, without more direct GPIOs this is not even comparable to NodeMCU - especially if you consider the i2s dma output of esp as described by the black magic above

Progress on the I2S output idea, though not on ESP8266: [forums.reprap.org]

Got the steppers to run on the ESP alone: [www.youtube.com]

4 steppers are being rendered at 192kHz, 32k steps/s, synchronized.

Will release the code soon.

I love it. Can't wait for the code. I'll try to implement it later into Repetier firmware - it's very nicely written and therefore quite easy to abstract from HW, so this should not be an overkill. Great work!

Code is up: [github.com]

Nowhere near as nice as repetier, though. :-)

I also got an idea for a sigma-delta ADC but first I need to figure I2S input. If it works this should need / provide at most:

4x 74HC164 ==> 32bit digital input.
4x 74HC373 + 8*TL84 ==> Changes 32 digital to 32 analog inputs, with software controlled resolution.

Obviously we don't need to assemble it all.

Hi Ihartmann,
I think this could be a solution for you, how to read multiple Analog signals with one ADC input -> http://www.instructables.com/id/ESP8266-with-Multiple-Analog-Sensors/