ESP32 Printer Board

True using a rpi may be the way i end up going. well an orangepi to be more precise as have one of them lying around, but that begs the question how there's no jitter with a linux based machine will multiple processes going on is jitter must be something going on that my very limited python knowledge is not letting me see. probably need to get it hooked up in my current set up to do some proper comparisons as i'm having problems visualising it in my head. i'm pretty sure that klipper will run on my rumba and the orange pi i have i think is a plus 2e 2g ram wifi but i think it only has 3 usb ports anyway i'll dig it and have a play

From how I understand the way klipper works, all of the step and control commands are calculated and timing scheduled on the host, the client board then receives that data and uses it's internal clock to execute the commands as calculated on time.

I believe Kevin explains it better somewhere in the klipper thread

Edit: Your orange pi should do the job as host quite well.

Edited 1 time(s). Last edit at 10/31/2017 03:54PM by obelisk79.

@paulbearne regarding jitter:

On all non synchronized(Systems that do not have a common clock) systems you will have jitter. The real question is: How big is the jitter?

So how long can messages be delayed. And more importantly how long can the client wait for the next message. In this case we talk about serial communication (115200 or 2500000 bit/s) and Klippers event time line (Kevin is the expert there) .

So second will definitely be too long, but µs will surely be ok. If we then look at the host side (RasPi/BanaPi) you have a system that runs on a GHz clock and co do a lot of stuff in µs. Klipper on a Raspi3 also only takes a few percent of cpu performance. So as long as no other tasks create huge(many µs as lest or even seconds) delays then the jitter is small enough to not cause a problem.

On a Wifi link there can be disturbances (microwave sending on the same frequency, another Wifi, .an faulty electronic device,...) so that certain data packets get lost or need to be retransmitted. This retransmission can also introduce jitter. Also other devices on the same wifi can block the channel as there can only be one transmission at the same time. These sources of jitter are probably (not an expert) in the µs to ms range. And with really bad interference there is no upper limit (connection loss). So that would be an issue.

Also when porting to host to a cpu with less performance the cpu will need more time to do the calculations and is also slower in reacting to events. Therefore the jitter of a slower CPU is (with the same software) always bigger.

Before porting/reimplementing the host part to run on a Cortex-M system you should do some estimates on what kind of jitter you can get away with. Or you go with a protocol that can tolerate a bigger jitter.

If Klipper is calculating well in advance due to the allowable cpu overhead and merely scheduling the sending of data to the client to keep it's memcache full wouldn't jitter be less of a concern?

Thanks for the info i think i better understand what klipper is doing particularly after reading through kevin's thread. obelisk from my understanding it would be less of a concern if you schedule sending data , i was going to set a small test system on the bench with 5 motors and some loads to simulate heaters etc to test the new board when it arrives i have a second rumba so i can use the test setup to test all of the pre mentioned firmware's and then should be able to make a better decision on which to port. one other thing came to mind last night when in bed not sure if it can be done in the arduino version of the esp32 but can be done using the idf and that is to tie a particular task exclusively to a CPU core. even if its not klipper but another firmware i do like the idea of synchronised data exchange between the two as i can this having huge benefits for smoother running of the motors, we know when the motors are moving and when they are fetching commands from the cache if you could synchronise the data transmission during the fetch cycle or pre-fetch cycle it could be seamless if for example the control is pulling the data off memory in one core we top up the data in the other. Now as for the calculations and use of a host if i think of the system as a whole that i would ideally like to to achieve we still have a host just not at the printer end. we have the controller which is controlling the mechanical operations of the printer , we have a second controller which has a display but maybe calling it the display module is the wrong name as it could just have an sd card its purpose was for somewhere to upload data to to eliminate the pc sat next to the printer but the pc won't be eliminated completely from the system as i will uploading from my laptop which could be thought of as the host and pre-calculate everything before sending up to the printer.

Quote
dc42
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.

SX1509B seems to be one the best (another one would be CY8C9520A for 2x the price). I am curious why led blink mode available on SX1509B would not drive an SSR?

Quote
newbob
SX1509B seems to be one the best (another one would be CY8C9520A for 2x the price). I am curious why led blink mode available on SX1509B would not drive an SSR?

Because DC-AC SSRs need low frequency PWM (or low frequency sigma-delta modulation) to give predictable results. RRF uses 10Hz for them.

---

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

Quote
dc42

Quote
newbob
SX1509B seems to be one the best (another one would be CY8C9520A for 2x the price). I am curious why led blink mode available on SX1509B would not drive an SSR?

Because DC-AC SSRs need low frequency PWM (or low frequency sigma-delta modulation) to give predictable results. RRF uses 10Hz for them.

Thanks for responding. From what I understand at 256 intensity (I'm assuming that's 100% duty cycle) IOx should be HIGH for the ON duration - duration is based on 4 bit RegTOnX register:


ON Time of IO[X]:
0 : Infinite (Static mode, TOn directly controlled by RegData, Cf §4.8.2)
1 - 15 : TOnX = 64 * RegTOnX * (255/ClkX)
16 - 31 : TOnX = 512 * RegTOnX * (255/ClkX)

Edited 3 time(s). Last edit at 11/07/2017 03:11PM by newbob.

I'm sorry, I forgot that the SX1509B has a blink mode as well as a PWM mode. It does appear that the blink mode may be usable for this purpose.

---

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

Quote
dc42
I'm sorry, I forgot that the SX1509B has a blink mode as well as a PWM mode. It does appear that the blink mode may be usable for this purpose.

Thanks. I sent a q to Semtech to verify that 256 value sets 100% duty cycle. I noticed that duet expansion board is using SX1509B for end stops. Do you think it would be ok to use SX1509B IO for end stops for homing considering extra delays due to interrupt generation/handling and i2c communication needed?

EDIT:
I'm thinking that, during homing, interrupts could only be enabled on endstop pins and all motion stopped when interrupt raised. That probably be no more 4us (interrupt generation) + 2us (time to get to ISR on ESP32) + 2us to stop the motion - 8us total. Seems like a nonissue?

Edited 2 time(s). Last edit at 11/07/2017 03:57PM by newbob.

That's not ideal because the interrupt doesn't tell you which endstop changed state. But probably workable in practice.

---

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

Earlier in this thread there was a discussion if ADC is accurate enough in the ESP32.

The issue turned out to be with inconsistent internal voltage reference which is affecting accuracy. Espressif has instructions how to correct it manually and planning on fixing in during production in the future. Some more info:
https://esp-idf.readthedocs.io/en/latest/api-reference/peripherals/adc.html#adc-calibration

Edited 1 time(s). Last edit at 11/08/2017 12:02PM by newbob.

Hey all. Sorry I have not been active on this thread for a while. I have had quite a bit going on the last few months. I still have been researching and working on this. Glad to see someone else is also working on a similar design.

During this time I have come to a few conclusions.

1. There is no good way of doing this with stepper driver daughter boards without compromising too much or using multiple GPIO chips. Even with the GPIO chips the ESP32's GPIO pins become limited due to constraints.
2. The programming around supporting multiple different stepper driver chips in firmware started making my head hurt.
3. Many of the GPIO pins are simply being used as digital outputs.

So what I decided to do is to instead focus on making multiple different boards with different stepper drivers. This will allow me to optimize the boards for the stepper drivers. The board I have been working on recently is based off the TMC2130 drivers. They are SPI configurable for things like microstepping, current, and their awesome advanced features. This cuts down on the GPIO and jumpers needed to control the stepper drivers. I can also route one of the diagnostic pins to the appropriate endstop and use their stallGuard2 tech to handle the endstop. Probably make a jumper for that so people can choose to use it or not.

Only issue this causes is the need for a bunch of SPI Slave Select pins, but those are just digital output. I can use a multiplexer for controlling that and they are dirt cheap. While I am doing so I can also use the other pins on the multiplexer for the various other digital outputs ( DIR, STEP, EN ). This takes 14 Digital Outs off the ESP32 and replaces them with 4 MUX address pins. On a 16 pin Mux that leave 2 extra pins that can do digital write for other things. Probably break those out in a header somewhere.

This has allowed me to fit in 2 fan PWMs, 2 servo PWMs, a Z_Probe, and 3 spare GPIO pins for AUX stuff. Plus those 2 Digital Out Pin from the MUX. It has also allowed me to use the 4 line SD card interface for much faster access to the SD Card. Here is how I have the pins mapped presently.

ESP-WROOM-32
1 - GND
2 - 3V3
3 - EN
4 - FAN_PWM1
5 - FAN_PWM2
6 - TEMP_1
7 - TEMP_2
8 - TEMP_B
9 - H1_PWM
10 - H2_PWM
11 - HB_PWM
12 - X_ENDS
13 - Y_ENDS
14 - Z_ENDS
15 - GND
16 - Z_PROBE
17 - SD_DATA2
18 - SD_DATA3
19 - SD_CMD
20 - SD_CLK
21 - SD_DATA0
22 - SD_DATA1
23 - SPI_SCK
24 - SPI_MOSI
25 - SPI_MISO
26 - MUX_ADDR0
27 - MUX_ADDR1
28 - MUX_ADDR2
29 - MUX_ADDR3
30 - SRV1_PWM
31 - SRV2_PWM
32 - NC
33 - GPIO21
34 - UART_RX
35 - UART_TX
36 - GPIO22
37 - GPIO23
38 - GND

MUX CHIP
1 - DIR
2 - X_STEP
3 - Y_STEP
4 - Z_STEP
5 - E1_STEP
6 - E2_STEP
7 - XYZ_EN
8 - E1_EN
9 - E2_EN
10 - SPI_X_SS
11 - SPI_Y_SS
12 - SPI_Z_SS
13 - SPI_E1_SS
14 - SPI_E2_SS
15 - DIG_OUT1
16 - DIG_OUT2

Let me know what you guys think and if I missed anything.

howdy all !

would the TMC2208 be an even better version to use or is it just easier/less costly to go for the TMC2130 ?

i had found out only recently about this IC and think its totally amazing for what today's tech can do so far, been in a really dark place last few years, so just surfaced again lol

also found out that its been cloned, i think

did you also account for an LCD/Touch Panel for on-machine output readouts/control, or have i missed that, sorry not great with coding at all, but good;/great with PCB Designing, sadly only in Eagle atm, have some spare time so might learn another platform but cadsoft Eagle is my fav, anyone need a hand with the PCB side of things, i have nothing but time....

i would LOVE to see this made for the masses !

---

Keeping As Many of my Designs As Open Source As Possible
LAZINESS is the MOTHER of INVENTION !
From 'Knowledge is Power' to 'Sharing Knowledge is More Powerful'
Today, 'knowledge' is considered to be a key resource that fuels society and drives innovation. The power of organizations & individuals comes from what they know, how efficiently they use what they know, & how quickly they learn to apply new knowledge. Mutual learning & collective action among individuals & groups foster innovation; when they collaborate and share knowledge, they are able to avoid repeating the same mistakes and use resources more effectively.~ Martina Spasiakova

My Github - Soon to Add Water-Chilling Peltier Control Board

sorry i just realised in the spec sheets that the TMC2130 is rated at 2.5Amps peak, where the TMC2208 is at 2amps, so kinda answered my own question there, no ? lol

I have looked into both. The TMC2208 and its relative the 2224 cost significantly less than the 2140. AFAIR the TMC2208 has a similar rated output current as the 2130 under the same conditions, however it has a lower driver output resistance according to the data sheet, so it should generate less heat. It uses a UART for configuration, which means you need an external multiplexer if you want to control several drivers from one UART. The 2130 supports stall detection, but the 2208 and 2224 don't.

The latest build of RepRapFirmware supports TMC22xx 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].

With regards to the LCD I had been putting some thought into that as well.

One of the cool things about the ESP32 is that the GPIO pins are not fixed in their functionality. They can be remapped to a large number of different on board peripherals including an I2C controller, a PWM controller, a SPI controller, and like 20 other things. I am actually thinking that the Z-Probe Pin and the two Servo pins should also just be general GPIO pins for a total of 6 GPIO. These pins could then be reconfigured for any number of purposes in the firmware config. This includes to be optionally configured for an I2C bus for an LCD / Rotary encoder. I will probably have them broken out on a header.

So I just ran into some snags on this design and am trying to figure out good solutions. First off the TMC2130 does not support SPI configurable current like I thought it did. This means I need to use PWMs to control them. At a minimum that means I need 3 pins for the PWMs. Second off the endstops and the diagnostic pins of the TMC2130 should be separate. So that means I need five digital inputs. This basically eats all of the GPIO and then some.

For the PWMs the easiest solution is to move them to an external chip. This adds three bucks to the board cost, but adds additional functionality. I figured I can move the Fan and Servo PWMs to this without much issue as well. If I use I2C for this it also gives me the I2C bus for things like LCDs. My concern here is if the chip has a fault that causes the hotend fan to stop. This would cause heat to creep up into the cold zone of the hotend which could be bad. Not sure if this would cause the hot zone to heat up enough to trigger a thermal stop or not. Now if there were TACHs for the various fans this could be detected plus this could be very useful information possibly allowing the firmware to set a target fan speed instead of a specific PWM duty cycle.

The endstop / diagnostic pins are not so simple. I am thinking of moving them to an external SPI GPIO chip like the MCP23S08. This way it will use a single interrupt pin on the ESP32 and the SPI bus. When any of the endstop or diagnostic pins trigger on the MCP23S08 it would raise an interrupt on the ESP32. The ESP32 would then need to check the MCP23S08 via SPI to see which pin triggered the interrupt and take the appropriate action. The problem with this is it adds latency. I am not sure how much it would add though. Too much and you could end up with an axis crashing past its endstop. One way to possibly save things is to have the MCP23S08's interrupt on the ESP32 temporarily pause all movement till the MCP23S08 chip can be read. This would prevent the crash but if this takes too long there could be a shudder in the movement for no real reason. Is this even really a concern considering the speed of the processor / bus / chip? How far could the axis move between when the MCP23S08's interrupt fires and the value from MCP23S08 is read and handled?

Assuming all of this makes sense here is my current pin outputs:

ESP-WROOM-32
1 - GND
2 - 3V3
3 - EN
4 - I2C-SDA
5 - I2C-SCL
6 - TEMP_1
7 - TEMP_2
8 - TEMP_B
9 - H1_PWM
10 - H2_PWM
11 - HB_PWM
12 - SPARE_GPIO
13 - Y_ENDS
14 - Z_ENDS
15 - GND
16 - IO_INT (MCP23S08)
17 - SD_DATA2
18 - SD_DATA3
19 - SD_CMD
20 - SD_CLK
21 - SD_DATA0
22 - SD_DATA1
23 - SPI_SCK
24 - SPI_MOSI
25 - SPI_MISO
26 - MUX_ADDR0
27 - MUX_ADDR1
28 - MUX_ADDR2
29 - MUX_ADDR3
30 - SPARE_GPIO
31 - SPARE_GPIO
32 - NC
33 - SPARE_GPIO
34 - UART_RX
35 - UART_TX
36 - TACH1
37 - TACH2
38 - GND

I2C PWM CHIP
1 - E-REF-PWM
2 - XY-REF-PWM
3 - Z-REF-PWM
4 - FAN1_PWM
5 - FAN2_PWM
6 - AUX1-PWM
7 - AUX2-PWM
8 - AUX3-PWM

MCP23S08
1 - E1_DIAG
2 - E2_DIAG
3 - X_DIAG
4 - Y_DIAG
5 - Z_DIAG
6 - X_ENDS
7 - Y_ENDS
8 - Z_ENDS

MUX CHIP
1 - DIR
2 - X_STEP
3 - Y_STEP
4 - Z_STEP
5 - E1_STEP
6 - E2_STEP
7 - XYZ_EN
8 - E1_EN
9 - E2_EN
10 - SPI_X_SS
11 - SPI_Y_SS
12 - SPI_Z_SS
13 - SPI_E1_SS
14 - SPI_E2_SS
15 - SPI_IO_SS
16 - DIG_OUT1

This leaves 1 Digital out free, 4 GPIOs free, and 3 PWMs free. Thoughts?

Edited 1 time(s). Last edit at 12/27/2017 03:14PM by CthulhuLabs.

OMG FANTASTIC ! well youre knowledge base is far superior to what i usually tinker with, sadl only an EE student and have alot to learn yet, but i already make my own PCB's so if you want/need any help populating boards or cadsoft eagle work, you let me know, i would be very pleased to be involved and to help.

Also for testing the theories for any movement delays, im again at a loss as i have a 3d pRINTER ON ITS WAY BUT ITS MY FIRST ONE ! LOL

But i do plan on making a 2nd 3D Printer the reprap-way of how these machines were meant to operate - replicate themselves

Nowadays everywhere i look its all aluminum extruded frames and even harder to make a 3D Printer at home without having these Aluminum extrusions - i live in rip-off UK so everything here is super expensive, not to mention i have no income atm lol

So i will definitely be printing parts for a 2nd Printer just as soon as i can and will have it for alsoo testing for an ESP32 based mainboard, sadly that wont be until at least after February next year, which is extremely irksome to me...

Going to take a little while to collect up some more PCB Connectors too, especially the high amperage ones, for PCB Servo motor connectors etc.

As for the TACH - there is some Arduino-Based code that can read the sensor wire from 3-pin fans but life got in the darn way and i didnt make much more progress on this testing the RPM Readouts like computer motherboards do, there is a signal usually twice per fan rotation and this can be picked up by any Arduino based code on the yellow sense wire, i will try to find the last research state i was in for this

But in the meanwhile, if you need any help prototyping, you got it

LOL. I love your enthusiasm. I am by no means an expert at this stuff though. I am relying on the community to check my work. I have already gotten a ton of help from dc42 through PMs on this as well as suggestions from others. I am also using other open source designs as reference for a number of things. For instance I am looking right now at the EINSY-RAMBO schematics to see how they are interfacing with the TMC2130s. That's how I realized the TMC2130 does not support SPI current settings. This is why I love OpenSource projects.

Now if you are hoping to help on this specific project I suggest looking into CircuitMaker. That is what I am using to design this. The interface on it seems far more intuitive to me than Eagle.

You can save some pins:

- The 2130 does support software-controlled motor current, it's the IRUN field of register 0x10
- You don't need separate ENN signals for each chip because you can disable drivers individually by setting TOFF to zero in the chopper control register. One ENN signal feeding all the stepper drivers is sufficient
- It may be nice to feed the DIAG pin of each chip to the MCU individually, but it's not essential. They are open collector outputs, so you can tie them all together. When one of them signals a fault, the MCU can read the status registers to determine which one reported the problem.

By all means look at other open source projects to get ideas, but don't assume that the designers of other projects got everything right or had the same goals as you. Many of the open source 8-bit controller board designs use the same bad choice of mosfet to control the bed heater, and I suspect that a poor choice made by one designer was perpetuated by others who copied that aspect of his design without checking whether it was a good choice or not.

Edited 1 time(s). Last edit at 12/27/2017 06:32PM 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].

Quote
dc42
- The 2130 does support software-controlled motor current, it's the IRUN field of register 0x10

Thanks! I missed that. Do you think the internal sense resistor system is good enough or should I add an external one?

Quote
dc42
- You don't need separate ENN signals for each chip because you can disable drivers individually by setting TOFF to zero in the chopper control register. One ENN signal feeding all the stepper drivers is sufficient

Cool.

Quote
dc42
- It may be nice to feed the DIAG pin of each chip to the MCU individually, but it's not essential. They are open collector outputs, so you can tie them all together. When one of them signals a fault, the MCU can read the status registers to determine which one reported the problem.

This comes back to my latency question earlier. In the event someone is using stallGuard2 as an endstop, would the MCU be able to check all of the status registers in time to figure out which axis to stop?

Quote
dc42
By all means look at other open source projects to get ideas, but don't assume that the designers of other projects got everything right or had the same goals as you. Many of the open source 8-bit controller board designs use the same bad choice of mosfet to control the bed heater, and I suspect that a poor choice made by one designer was perpetuated by others who copied that aspect of his design without checking whether it was a good choice or not.

Totally agree. I am just using other projects as starting points and reference. I plan on optimizing and improving the design several times before even making a single board.

@CthulhuLabs

hehe thanks mucho much, i really do love this project concept and idea, so ANY PCB help is going to be available to ya for free, any time, anywhere. You all have poured a lot of hard work into this project so far and your doing it for free, so to keep costs low, i will do my part to also do this job for free too, one would only need to pay for manufacturing of the small batches of PCB's which roughly it translates to about $10-£15 USD for a batch of 5 PCB's with Dimensions of 50mmx50mm

and if we even split the costs - itss even cheaper - right ??? !!! ???



Yaa as for checking that your schematics are correct, id sadly fail there, i can READ schematics very well, i just havent got the grasp of Electrical Engineering just yet - the mathss side of things are my weak point and im an EE student so i am learning it as time goes on

So my strong point is knowing how to populate PCB's and keeping the components that need to be grouped together in the schematics, as an example...

So if you need to design a shield or anything similar, let me know, send me a PM or email, this offer will not end, so contact me at any time when you know you have a schematic that is correct and checked, im going to closely follow this thread and just have to say - well done to all for keeping this thread and pretty much everything on this forum a very positive approach to these things, as im dealing with severe depression, projects like this keep my mind occupied, so thanks loads to everyone making this a really awesome project

Quote
CthulhuLabs
Thanks! I missed that. Do you think the internal sense resistor system is good enough or should I add an external one?

Unless you are very tight on PCB space, I suggest an external one.

Quote
CthulhuLabs

Quote
dc42
- It may be nice to feed the DIAG pin of each chip to the MCU individually, but it's not essential. They are open collector outputs, so you can tie them all together. When one of them signals a fault, the MCU can read the status registers to determine which one reported the problem.

This comes back to my latency question earlier. In the event someone is using stallGuard2 as an endstop, would the MCU be able to check all of the status registers in time to figure out which axis to stop?

Decide how and for what purposes you want to use stall detection. Take account of its limitations, which I describe at [duet3d.com]. If you just want to use stall detection for sensorless homing, you can enable stall detection just for the axis being homed, so you need only one MCU pin for the DIAG outputs. If you want to use it to detect missed steps too, then you can either poll the drivers continuously (which is what we do on the Duets, using DMA to keep the overhead low), or feed each DIAG output to a separate MCU pin. Either way, you may get false stall warnings at low motor speeds and you will need to have the firmware ignore them.

You could consider using the same MCU pin for both the DIAG output of a driver and the corresponding external endstop input, with a diode to prevent a 3-wire external endstop fighting with the open collector output of the driver.

The stall detection in the driver is only updated every 1 or 4 full steps depending on how you configure it, so aiming for super low latency stall detection isn't worthwhile.

---

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

Here is my current pin out after various optimizations:

ESP-WROOM-32
1 - GND
2 - 3V3
3 - EN
4 - TEMP_1
5 - TEMP_2
6 - TEMP_B
7 - H1_PWM
8 - H2_PWM
9 - HB_PWM
10 - X_ENDS
11 - Y_ENDS
12 - Z_ENDS
13 - AUX_GPIO1		MTMS
14 - AUX_GPIO2		MTDI
15 - GND
16 - AUX_GPIO3		MTCK
17 - SD_DATA2
18 - SD_DATA3
19 - SD_CMD
20 - SD_CLK
21 - SD_DATA0
22 - SD_DATA1
23 - AUX_GPIO4		MTDO
24 - FAN1_PWM
25 - FAN2_PWM
26 - MUX_ADDR0
27 - MUX_ADDR1
28 - MUX_ADDR2
29 - MUX_ADDR3
30 - SPI_CLK
31 - SPI_MISO
32 - NC
33 - STPR_DIAG
34 - UART_RX
35 - UART_TX
36 - AUX_GPIO5
37 - SPI_MOSI
38 - GND

MUX CHIP
STPR_EN
X_SPI_SS
Y_SPI_SS
Z_SPI_SS
E1_SPI_SS
E2_SPI_SS
DIR
X_STEP
Y_STEP
Z_STEP
E1_STEP
E2_STEP
AUX_DO1
AUX_DO2
AUX_DO3
AUX_DO4

Here are the optimizations I made:

1. Renamed SPARE_GPIO to AUX_GPIO pins
2. Renamed DIG_OUT to AUX_DO
3. I have removed the PWM chip and the IO chip (not needed at the moment)
4. I have made a single stepper enable pin (STPR_EN)
5. I have made a single TMC2130 diagnostic pin (STPR_DIAG)
6. I moved the SPI pins so that they can be tied directly to the ESP32's IO_MUX which improves the latency
7. I converted the I2C pins back to AUX_GPIO pins as there are no I2C devices on the board.
8. I move a number of other pins around so that the AUX_GPIO pins line up with the JTAG pins to ease troubleshooting

Assuming the pins do not change I planed on having an header that looks something like this:

1 - AUX_GPIO1
2 - AUX_GPIO2
3 - AUX_GPIO3
4 - AUX_SPIO4
5 - AUX_SPIO5
6 - AUX_DO1
7 - AUX_DO2
8 - AUX_DO3
9 - AUX_DO4
10 - SPI_MOSI
11 - SPI_MISO
12 - SPI_CLK

Quote
dc42
Unless you are very tight on PCB space, I suggest an external one.

Too early to tell, but I will keep that in mind.

Quote
dc42
Decide how and for what purposes you want to use stall detection. Take account of its limitations, which I describe at [duet3d.com]. If you just want to use stall detection for sensorless homing, you can enable stall detection just for the axis being homed, so you need only one MCU pin for the DIAG outputs. If you want to use it to detect missed steps too, then you can either poll the drivers continuously (which is what we do on the Duets, using DMA to keep the overhead low), or feed each DIAG output to a separate MCU pin. Either way, you may get false stall warnings at low motor speeds and you will need to have the firmware ignore them.

You could consider using the same MCU pin for both the DIAG output of a driver and the corresponding external endstop input, with a diode to prevent a 3-wire external endstop fighting with the open collector output of the driver.

The stall detection in the driver is only updated every 1 or 4 full steps depending on how you configure it, so aiming for super low latency stall detection isn't worthwhile.

I think what I will do is have a 3 pin jumper for each of the X,Y, and Z TMC2130s. In the first position one of the DIAG pins is tied to the STEP_DIAG pin on the ESP32. In the second position that DIAG pin is tied to the appropriate endstop with a diode. The other DIAG pins will always be tied to the STEP_DIAG pin on the ESP32. This is based off figure 17.1 in the TMC2130 datasheet. The question is which pin to route to the jumper. Both DIAG pins can report a stall. The DIA0 pin always shows Power On Reset and can optionally show driver errors and temp warnings. The DIA1 pin can show when the micro stepper is at index 0, when the chopper is on, and when steps were skipped.

Thoughts?


One of the things I have to keep reminding myself is this processor is considerably faster than any of the 8bit ones and has two cores. As such it should be able to react much faster to events.

@offtherails2010
I am hoping to make this board just two sided. At which point I can make the boards in house. I have access to a mini CNC that does a great job at cutting PCBs. This will also allow others to etch a board at home if they want. Not holding my breath for that though. LOL.

@CthulhuLabs

haha nice one man ! i will download and get used to using CircuitMaker software that you use and get acquainted with it, argh lol, old dog new tricks, i hate beginning to use a software i dont know lol, but meh, gotta get out the comfort-zone every once in a while to stay sharp i guess haha

i'd LOVE to also make up a prototype of this PCB and give it a try when my 3D Printer arrives and i start getting used to it, i have all i need to home etch PCB's although i usually only do single sided board because they just take much less time to home-brew, then once im happy with it, i make up the double sided version for outsourcing to a PCB Manufacturer, so pretty much all my designs have a single sided version

Double sided homebrew isn't a problem either, have a jig to keep everything lined up correctly upto 0.6mm trace widths, anything thinner than that and i cant do it at home.

You're so lucky to also have a CNC mill - i really want one too haha sorry it is a CNC "Mill" you have, right ? are you able to mill aluminum too ? asking so id have a clue into which type of motor you use for the main spindle that is recommended for Aluminum or more importantly, COPPER plates/bars, this would be very interesting to know more about, even though im researching this like crazy the last few months, thanks again in advance for the help man )

Yes it is a DIY mini CNC Mill. It has a 200x200mm milling area. It's owner uses it for mainly making PCBs so I am not sure what other materials it is good for.

Here is the project on CircuitMaker if anyone is interested:

NEMO - (V01)

Edited 1 time(s). Last edit at 12/28/2017 01:17PM by CthulhuLabs.