Controlling a RepRap with ESP8266 and no Arduino

Just tried a similar approach, but without the diodes.

On a regular printer we don't need to measure any voltages, just the variable resistances of the thermistors. So I tested the circuit below on the NodeMCU. Please bear in mind it has internal 3.3V -> 1V divider before the ESP12's ADC input.



The resistor to ground is my reference resistor, like the 4k7 one used on RepRap Melzi board to polarize the NTC. The resistors to the GPIO pins are my NTCs. The fixed resistor is connected to ground so that if a NTC break the voltage goes to zero, which is safe to the ESP even without the NodeMCU's voltage divider.

To measure resistor A I set GPIO_A high, other GPIOs high-Z, delay 5 ticks, then accumulated 256 samples of system_adc_read() for averaging.

I tested with 3 fixed resistors: 1kR reference, 330R NTC1, and 1kR NTC2. Got the line below following back from the ESP. Note that due to the oversampling the maximum reading of the ADC would be 256*1023=261888:

ADC: dt=16, CH0=204014, CH1=136157, R1=323, R2=983

This is really close to what I expected: R1=330 (-2%), R2=1000 (-1.7%), R1/R2=0.33 (+0.4%).

While this is incredibly simple there is a catch. The only GPIOs that can be used for this are those with neither pull-ups not pull-downs, for pull-x would interfere with measurements. However, if we allow ourselves to use some P-MOSFETs, like AO3401, then pull-x should be no longer an issue (untested, my P-MOSFETs are on their way).

Checking the node MCU we have:

• GPIO0: GOOD, requires P-MOS (pull-up).
• GPIO1: GOOD, may require P-MOS for less interference, we loose serial.
• GPIO2: GOOD, requires P-MOS (pull-up).
• GPIO3: GOOD, requires P-MOS (pull-up/down from the serial), we loose serial.
• GPIO4: GOOD for direct connect.
• GPIO5: GOOD for direct connect.
• GPIO6: Not usable, spi-flash (untested).
• GPIO7: Not usable, spi-flash (untested).
• GPIO8: unusable, causes WDT reset. SPI flash conflict?
• GPIO9: unusable, causes WDT reset. SPI flash conflict?
• GPIO10: unusable, causes WDT reset. SPI flash conflict?
• GPIO11: Not usable, spi-flash (untested).
• GPIO12: GOOD for direct connect, but you loose HSPI.
• GPIO13: GOOD for direct connect, but you loose HSPI.
• GPIO14: GOOD for direct connect, but you loose HSPI.
• GPIO15: GOOD, requires P-MOS (pull-down).
• GPIO16: GOOD, requires P-MOS (pull-up through a LED).

If we reserve the HSPI for a SD card, which we'll need in the future, we get:

• 2 available channels with no extra hardware: Good for a heated bed + single-heater. Diamond, cyclops and prometheus hotends included!
• 5 available channels with 3 P-MOSFETS: Good for bed + chamber + 3 independent extruder heaters.

Or you can connect the p-mos transistors to the 595 outputs and get as many acd as you'like

Hi !
really impressive project need helps?

Quote
lhartmann
While this is incredibly simple there is a catch. The only GPIOs that can be used for this are those with neither pull-ups not pull-downs, for pull-x would interfere with measurements. However, if we allow ourselves to use some P-MOSFETs, like AO3401, then pull-x should be no longer an issue (untested, my P-MOSFETs are on their way).

To me this seems not simple but complicated - if you use the diode-version with the output of 595, you can get any number of GPIOs to work as ADC inputs and not to worry about which one is usable For me this seems like a bit more relevant solution, while I would still prefer to use the i2c 12-bit ADC with 8 channels

@rklauco: I discarded the diode multiplexer circuit because the forward voltage drop of the diodes is temperature dependant, and this would require compensation... I wanted to avoid this if possible.

PMOS, however, can be approximated by a <1R resistor. Even if it changes 100% it should have almost no influence on the measurement. Still waiting for mine to arrive, though.

I also did not want to use an external ADC because most of them cost more than an atmega328 (or a nicer ARM M0 such as stm32f030f4p6), and it would be just cheaper to use an arduino helper... I kinda felt like it would defeat the purpose...

@exilaus: if you know of firmware parts that are RTOS (FreeRTOS) friendly that would be great... I really don't think a full rewrite is the way to go...

@lhartmann: what a great idea. I have tested the I2S interfacing stuff with a few 595 chips and some RGB LED's, and it works great. Thanks for bringing this to the table!

One of the nice things on the ESP8266 with I2S DMA is the buffering. Though buffering makes the I2S interface not real time (and hard to use with existing interrupt driven firmware code), it also enables the possibility of using scheduling code (in other words: multitasking). Running a webserver multi-tasked with a G-code interpreter could be done this way. Both the webserver and the G-code interpreter need quite some responsiveness to operate correctly. But I bet that a 160MHz 32bit MCU is well capable of handling both tasks.

(Re-)writing a simple G-code interpreter shouldn't be that hard as there are plenty of good starting points:
[www.marginallyclever.com]
[staff.bath.ac.uk]

If we agree on doing this as a community project, I'm more than willing to put some effort in getting it done!

Update: You got me inspired to a critical level: as soon as I'm back from my holidays, I will try to port the G-code demo (https://github.com/MarginallyClever/GcodeCNCDemo/blob/master/GcodeCNCDemo6AxisRumba/GcodeCNCDemo6AxisRumba.ino) in an ESP8266 and try to combine it with the I2S and webserver stuff...

Edited 1 time(s). Last edit at 10/11/2016 03:08PM by vajpeters.

---

Eppur si muove!

As promised I offered to through a some brain power on the ESP8266-I2S Reprap controller idea, I need some reality checks. So here I go:

The major difference between using the AVR or ARM processors (with direct access to interrupts) and the ESP8266 with I2S interface is they way timing is handled. Though the ESP8266 can do some kind of timing interrupts, the I2S interface works with buffers pushed out through a serial data stream.

If data is written to the I2S interface, the data could be either directly adjacent to the previous data written to the buffer, or in the next (8 x 32-bit word) buffer section.

To cope with this challenge, it came to my mind that the introductions of a virtual time axis to the Bresenham algorithm could help us to solve this. (And also add some added smoothness to the movements.)

Let me explain the idea (and I sincerely hope there are some people with serious background in math to check it!)

The normal (Marlin, Teacup, GRBL and others) approach to motion control is to use the Bresenham algorithm and let the finest stepping lead the others. The time delay between steps (accelerations etc.) is calculated using David Austins algorithm. The time delay is regulated by setting comparison value for the timing interrupt.

As already explained, this won work with the ESP8266. The idea would be to render the movement over a virtual time axis (the buffer time increments). Doing this right (combining the essence of the Bresenham with Austins algorithm), the step events could become more independent (the Y-step can occur in between two X-steps).

The crucial question is how to chose the time axis. To create a valid step, a step-pulse need to be accompanied by two 0-states adjacent in the buffer. This means that the amount of time-steps/sec need to be double the maximum amount of stepper motor steps/sec.. From this defined maximum speed point, all other speeds and timings can be calculated by using deceleration and accelerations from David Austins algorithm and Bresenham.

---

Eppur si muove!

While I am not familiar with David's algorithm, I believe most of what you mentioned is already in the code. Time domain is discrete at 192kHz, constant rate (as opposed to the variable interrupt frequency you said marlin uses).

Check stepper.h for my take on Bresenham's:
- First you call Stepper.prepare(D, T) when you want to mode D steps in T time samples. Consider just the maximum speed desired for this.
- Then you call Stepper.step() every sample, and if it returns true then you do a step.
- Stepper.step() will return true exactly D times over the next T samples, then false forever.
- After the movement is completed, i.e. step() returned true D times, then done() will return true to let you load the next move.
- As long as you keep D < T/2 (meaning under 96kHz stepping rate) it will work nicely.

Acceleration is implemented in the Throttle class, but I found it easier to distort just a single time axis instead of distorting 4 (or more) motion axis.
- Acceleration is implemented by changing the rate at which the "time" flows, i.e., changing how often we call Stepper.step().
- Slowdown is implemented as a ratio: 1/1 means 100% speed, 999/99900 means 1% speed. Any rational number works.
- Checking user/throttle.h you will find the r and rd variables, which are numerator and denominator of the speed ratio.
- The function Throttle.step() will return true r times every rd samples (bresenham again), and each time it does we call Stepper.step(). Basically if Throttle.step() returns false it behaves as if no time has passed for the Stepper class.
- In the throttle class there are also r0 and r1 which are the rate numerators for the initial and final speeds. Denominator is still rd.
- The rate numerator is initially set r=r0.
- Every time sample r is:
- Incremented if rr1 and the deceleration point is reached.
- Basically this means that changing rd you set how long (real time samples) you want the acceleration ramp to take.

See step() in reprap_core.cpp, it returns a uint32_t sample tto be buffered, and shows how to use throttle.step() and stepper.step(). Also make sure you read the comments in stepper.h and throttle.h.

Modern 32 bit firmwares don't use the Bresenham approximation or the associated approximate acceleration algorithm. There is enough processor power to calculate the step pulse timings using the equations of Newtonian motion. RepRapFirmware uses the calculated step pulse times to schedule interrupts at the corresponding times. Smoothieware is a little different, as I understand it, it uses a 200 kHz interrupt and checks what steps are due at each interrupt. A similar approach might be usable with I2S on the ESP.

---

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

Took some time to read smoothie... It uses a lot of floats everywhere but in the fast ISR, Good.

The decisions when to trigger steps for each motor are implemented in StepTicker, in the methods step_tick (set pulse pins) and unstep_tick (clears pulse pins). Actual control of GPIO is implemented the Pin class.

Perhaps creating a set of Pin instances pointing to a RAM variable instead of an actual GPIO register, and calling unstep_tick then step_tick several times while copying the pseudo-gpio variable to the I2S buffer?

Should be possible... Just a lot of arm-specific code to take away.

Also, there are a lot of abstractions in place... The code should probably be compiled as a single piece, with global optimization, or we could run into performance issues.

I guess another possibility is to start from RepRapFirmware and use the calculated step times to set bits in a pair of I2S buffers that you send by DMA. While one buffer is being sent, you can prepare the other one. Just keep calling CalcNextStepTimeCartesian or CalcNextStepTimeDelta for each active motor until the next step time is past the end of the buffer you are trying to fill. RRF also has a much more developed web interface than Smoothieware.

Edited 1 time(s). Last edit at 10/16/2016 03:52AM 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].

Hmm, interesting stuff. Though it is tempting to spend the computing power on higher precision or more convenient programming, I'm a supporter of efficiency and reducing the power footprint as much as possible.

One of the problems with the ESP8266 is the OS functions running in the background. The timers which are accessible to the programming interface are software timers. So the Wi-Fi can interrupt or delay the program flow (and disabling is possible but unwanted).

Too frequently running an ISR is quite costly, so using running less frequent and filling the DMA buffer seems an idea to increase responsiveness and save some power for the Wi-Fi.

A web interface is created easily enough. Is Smoothieware already working with a fixed time step? Then this the most likely contender to port to the ESP8266...

---

Eppur si muove!

If you are going to fill a DMA buffer, I don't see that you want a fixed time step. You would spend a lot of time on calls to what was the ISR function, only to find that on most calls there is no step to do. Whereas RRF tells you when the next step is due, from which you can calculate where to set the bit for that step in the I2S buffer.

You are unlikely to reduce the power consumption by doing less calculation unless you put the processor in sleep mode when it is not busy.

---

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

With power I actually mean the ammount of instructions spend... Sorry for my English, I'm a Dutchman...

---

Eppur si muove!

I also just read the Smoothieware code quite a bit. Seems a good starting point for implementing virtual I/O. I will nevertheless try to write a stepper implementation which is specifically written for the ESP8266 to squeeze the maximum out of the little ESP8266.

On the side, I will start designing a board for an ESP8266 + Stepsticks and all the interfacing stuff in between to have a platform to run on. (Did it once before for the TB6560: [forums.reprap.org])

---

Eppur si muove!

I also have thought about this concept, and played around a bit. (Before searching the net if anybody else have tried it, of course.)
I approached it from another direction at first:
Got the Marlin firmware to run on a NodeMCU. I had to change the pin access, and use the two ESP timer interrupts for thermistor reading and stepper movement.
The thermistor reading was stubbed out, sending a constant 25 degrees, and I could connect to it with RepetierHost and move a stepper motor with it. The homing was the best part, using a pin as an "endstop", then the stepper did exactly what it was supposed to do.
So if it can do this by barely modifying the firmware and using the ISR, no DMA, and was running az 80 MHz, then with optimization this is quite promising.

One note here: When connecting to RepetierHost, it expects "start" as the first thing it receives. But the ESP bootloader sends out data at an idiotic baud rate before entering the code. It can't be turned off. Maybe putting a hardware timer which disables the TX pin on the ESP after reset for a moment to filter out the bootloader's output could "fix" it. Or change the RepetierHost to deal with this "garbage".
Until then, RepetierHost will not recognize the ESP as a printer sometimes, and I need to press the reconnect button several times.

I also have extended the GPIO now, using 2 MCP23S17s and one MCP3008.
They were cheap as hell, and now I have 32 digital GPIO pins configurable as output/input, and 8 analog input channels. Hopefully they have enough speed to them as well, and the MCP23S17's interrupt pin is helpful as well for input capturing.

Not sure if it's the right choice, maybe yours is better.
I'll post code and hardware setup when I can prove that it is really working. For now it is just a piece of spaghetti on a breadboard.
Maybe we can help out each other with stuff.

I believe that using ESP as a cheap base could be a good choice.

Sounds fun. I wish they'd hurry up and make esp32 more readily available, that should simplify things considerably.

It sure is fun!
ESP32 will also make things a bit complex with its two cores, and God knows what else. There is always something.
I think we will need to play with it for a while.
Until then, the ESP8266 is good warm-up project.

By the way, I was thinking about the RepetierHost thing I wrote, and I realized how dumb I am.
It won't need a host.
For example, mixing in the ESPrinter firmware's web interface code could act as the "host".
This is also a nice advantage of a WiFi-based core.

Just got an email from SparkFun this morning advertising their ESP32 breakout board...

[www.sparkfun.com]

Although it looks like it's back-ordered at the moment...

My colleague pre-ordered the ESP32 module, and 2 months ago it was shipped. At least they said so. Now after complaining that it didn't arrive, he got back his money.
This ordering thing is not going smoothly for this module...

But thanks for the info! I'll subscribe for notifications from SparkFun.

Good news: CNLohr has released an I2S duplex I2S example, output and input!

Actually that is pretty old news, 9 months according to github dates, but I just found about the code now. :-D

Just tested my Shift-in board with it and got 16 bits working right away. Few things to keep in mind though:
1 - The I2S input is passive end expects external clocks to drive it.
2 - I2S word clock is used to parallel-load the shift-registers, but the word clock stays low for 16 clocks. There is no data shifting during this interval.
3 - As I was reading the input data bit D31 got to bits 16-0 (all of them) of the read value, and D29-D15 got to bits 31-17.
4 - I2S input pins are muxed with HSPI, so the second is lost. No easy SD cards here... :-(

Solutions:
1 - I just loop-backed both word and bit clocks from the I2S output to the input and it worked nicely.
2 - (untested) This should be easy to fix with an extra RC network (high-pass filter) between the I2S word clock and the 74HC165 parallel load signal, so that the load signal is active only a few hundred nanoseconds after the word clock falling edge. Unfortunately I don't have the proper R and C values at hand at the moment.
3 - (untested) Rotating the read values right by 2 bits, and delaying the 2 MSBs by 1 sample should correct the phase, as it did for the outputs before.

The 4th pproblem is a little harder... We still have SPI but it is shared with the flash. We can use the extra hardware chip-selects CS1 and CS2 to do SPI transactions, but these are only a few bytes long before CSn gets deasserted. MAYBE we can abuse the fact that SD cards are fully synchronous to the clocks and mask the card's clock while CS is disabled using an AND or OR gate. This would not work on any other type of device, but SD cards only read any inputs during the rising edge of the clock. This means that even if CS is disabled the card won't see it if we can guarantee that no clocks will reach the card in this period. Also the SD data output would conflict with flash data output if program is read in the middle of an SD read (very likely to happen). To avoid damage a single resistor between SD data out and SPI data in should be enough. SD data becomes a pull-up or pull-down.

I will have to test some of these solutions...

Quote
lhartmann
4 - I2S input pins are muxed with HSPI, so the second is lost. No easy SD cards here... :-(

The 4th pproblem is a little harder...

Do you *really* need an SD card? Apart from some initial testing, I've never used mine.

If you *do* *really* need an SD card, what about using a second ESP8266 to talk to it? After all, the ESP8266 is only a couple of dollars. You're going to have to make a lot of printers to recover any serious amount of work on this.

Why SD:
- I've had so many failures due to lost serial connection during long prints, now I always print from the printer's SD card.
- Useful for web interface storage (html and images), since the 4MB onboard would be pretty limiting.
- Timelapses with an IP camera (or old cellphone): I am currently using octoprint for timelapses and during the recording all it does is grab frames via an HTTP service. Most people run the HTTP service locally with an USB camera, but nothing stops you from using an IP camera or old cellphone (I do). I don't see no reason why not to grab frames directly through the ESP, granted it won't be able to encode it to video.

Obviously we can drop all the need for extra space if we print straight from the network, maybe store gcode in a site and get it via HTTP? Other storage services would be nice too, Dropbox / owncloud / google drive, but these feel like a far dream. Maybe our own reprap webservice? I'd still like the printers to be standalone, though.

Using a second processor would defeat the purpose of this project. The Duet-Wifi board is a dual-processor solution and is already available, I want to kill the second CPU entirely (just for the fun, not for the money :-)

Edited 1 time(s). Last edit at 11/02/2016 08:49PM by lhartmann.

Whille I totally shate your oppinion on second CPU, I have to say that for a year I am printing from OctoPrint, longest print for 23 hours straight and I've never had a failure due to serial port. In the begining I had USB problems with Melzi, but this went away when I switched from USB-serial to direct serial connection.
We finally moved, I'll have a new desk after the weekend, so I'll be able to experiment more. Looking forward to test what guys above me produced so far.

I'm also using SD printing, because I don't actually have a printer, it is at work in a small room.
I don't want to go there with my laptop and sit while it is printing.
That's why a WiFi-capable CPU would be just perfect. Send the stuff via WiFi to the SD, control/slice through a webpage, and see how it is going with a cam.

I know, we could buy a Raspberry Pi and use OctoPrint like normal people do. But...
Where is the fun in that?

Slicing on such CPU makes very little sense. Even slicing on OctoPrint (although working) is very questionable - you have to check the 2D path visualization manually, you have no control on object placement on the print bed, forget about slicing multiple objects for single print, etc.
However, to have the SD capability on top of wifi (upload once using wifi, print from SD) would be awesome. But for now, I am looking for just a simple ATMega replacement by ESP. For me, this is more "is it even possible" exercise

God no, slicing on ESP would be kinda impossible
Sorry, my bad.

However, maybe if the ESP's control page could use a web-based online slicer as lhartmann suggested, or if somehow it could communicate with a slicer installed on client, then you have a kind-of all-in-one package.
Accessible through WiFi (and Bluetooth on ESP32), and since it knows its own preferences, you don't have to setup any host software, it could tell the slicer the correct parameters, store the gcode on the SD card, see the process through a webcam, and all these provided by a small and cheap CPU.

It may be possible. I just now tried how fast my version is with the MCP23S17's output at 10MHz SPI with ESP set to 160MHz.
Well, it is somwhere between 14 and 15 microseconds per write. And a write can send out 8 bytes in parallel.
But it was just doing a blink in main loop. Will slow down with more code in firmware...

Oops, got it wrong, actually that was 14 and 15 milliseconds

But anyway, I got it faster and gave me 0 and 1 milliseconds.
So I did a for loop with 1024 digitalWrite()-s in it, and got ~8 milliseconds, which means a nice shy 128 kbps. If I use the whole port with 8 bits, then a parallel 1024 kbps is the maximum.
And as for frequency, it is around 128 kHz max, when you do nothing else, but a superfast blink.
Again, this is just an empty loop.

However, I found a rather big disappointment:
DMA can only be used for SPI if it is in slave mode. For ESP as master, no DMA. Should have looked deeper in the docs before anything... Well, I will have to try the best wih the SW limitations without the DMA.
For I2S it is supported. From this point of view the shift register is a better choice.

Here is the first version of the hardware:
https://github.com/Hubberthus/ESPExtra/wiki/Hardware
The code is forked from the Arduino core for ESP8266:
https://github.com/Hubberthus/ESPExtra/tree/espextra

The only feature implemented yet is the digitalRead(), digitalWrite(), pinMode() extensions for MCP32S17, and analogRead() extension for MCP3008.
Digital pins can be reached as D0...D31, analog pins A1...A8. (A0 is the builtin analog input)
Digital input is scanned when an interrupt comes from either of the MCP23S17s, not the best solution.
Working on how the heck I will work out avoiding collisions when using additional user SPI devices, and most importantly see how can I possibly bring PWM on the extended pins available.

Got a bit further with this, now also GPIO interrupts can be used on expanded pins.
PWM is also implemented and accessible via analogWrite() on a digital pin, but I rather not use it. Takes away a timer, and we have only 2 of them.

Also got Marlin to build on top of this "core", and uploaded it to the board. Looks good, blinks LEDs!

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

Hell of a job, Norbert. Can you share the marlin config?