Feedback on MRR_ESP_3DP #1
Comments
|
What you do is exactly what I am looking for, thank you very much ! A nice feature would be to be able to use SPI TMC2130 stepper drivers by moving jumpers like on the future RAMPS 1.7. |
|
@dtony Thank you for the note about SPI, unfortunately, I do not have much experience with TMC2130 drivers, so if you have any information on what are the pins needed and other information on what is needed to drive them, I can try to see how I can fit it in. |
|
@dtony I did a bit of searching on Google, and I think I have an idea of what it takes to connect the TMC drivers (2130 and 2208, SPI and UART). What I am doing now is adding some jumpers (actually, quite a lot of them) to allow the board to be configured for either TMC2180 SPI mode, TMC2208 UART mode, or just plain simple A4988 drivers. However, for TMC2130 drivers, they require a separate CS pin for each driver. With the current pinout of the ESP32, there simply isn't enough pins to support 4 TMC2130 drivers running in SPI mode. Two of them (most likely X and Y) can be connected to the I2C pins (SCL and SDA) if you are not intending to use I2C. GPIO0 is also still available, but I am not very sure whether using GPIO0 for output is fine or not, since it is also used for flashing the firmware. @simon-jouet and @Aggebitter are talking about using shift registers to increase the number of pins available. This may eventually be the way to go, but meanwhile, for a basic minimum board that can do the bare minimum, this board should be more or less there. I will push out the schematic and gerber files once I have done up the PCB design alterations. If anyone knows how to convert EasyEDA schematics and PCB designs into KiCad, please let me know. Easier to share the designs in KiCad, which seems to be what everyone is using. I probably should start learning it too. |
|
@vivian-ng But Now I feel that I will keep it a bit on hold course the ref design on pinouts could be merged;) |
|
@vivian-ng thank you, I did not had the time to answer to you yet so I am glad that you had figure it out. Wouldn't it be possible to use the freed pins from A4988 step pin or dir pin to be used as chip select ? I need to look at ESP32 datasheet to be sure but I guess it can be possible. I think keeping the BOM minimal in term of component count is a good idea but you are the captain ;) Edit : in Marlin code it is stated :
then I don't see any reason to not be able to use pins X_STEP_PIN, Y_STEP_PIN... or X_DIR_PIN, Y_DIR_PIN... on your schematics as CS. And yes, an important remark is that these pins are not needed in case the drivers are used in SPI modes, let me find a reference for this in order to validate it. Edit 2 : TMC2130 can work in sensor-less mode and detects stalled stepper motors effectively freeing up to 3 pins more but this needs to be tested as it me not be reliable enough. |
|
@dtony Thanks for the feedback. From what I understand, whether TMC2130 or TMC2208, whether SPI or UART, the STEP and DIR pins are still needed for actual motor movement control. SPI or UART allows you to set modes, change microstepping, enable stallguard, etc. but they do not allow actual control of the motors. So we are still stuck with needing STEP and DIR pins for each motor. @Aggebitter and @simon-jouet are working on the I2S shift register feature, which will allow a lot more pins to become available through shift registers. Until that happens, I think we are stuck with the number of pins available for TMC2130 on SPI mode. For TMC2208 on UART, there isn't really much of a problem since it can use the existing TX/RX ports. But I am not sure what will happen when both a host (such as PC) is connected through USB and uses the same TX/RX as the TMC2208... |
|
@Aggebitter RAMPS 1.4 is a 5V board, so some work will be needed to mod it to allow 3.3V logic. It may be a better idea to develop a 3.3V capable RAMPS equivalent for use with common ESP32 development boards. I think @simon-jouet has done something like that before. Meanwhile, I think I will focus on a basic board, using only the ESP32, no fancy stuff. |
|
@vivian-ng Vcc hacked to 3.3V of course applied. |
|
@vivian-ng I Did a first quick look into your board design and I'm building a proto/breakout/wire-wrap board based on your design right now. One issue that I noticed is that I prefer to gate MOSFET's with a transistor. This is due the fact that a MOSFET is voltage drive (as charging a capacitor). A well known design flaw in chinese RAMPS 1.4 is MOSFET's that does not open correct when driven in 5V. A NPN transistor to drive it at higher voltage would be preferred and it will open the range for other MOSFET's as well One thing that I really would like is a separe voltage line for driving steppers. Driving steppers at higher voltages is an big advantage and just going from 12V to 24 on a 3D-printer does magic. On My small router the difference was huge in speed as it uses ball screws. Today newer stepper drivers can handle 40V or more. Goal 36V ? |
|
@Aggebitter Thank you for the feedback. I have tried to choose mosfets which can be driven by 3.3V logic but I guess driving them at 5V is better, safer, and also more efficient. A question on how to connect these transistors. I am thinking of using a 2N3904, which I guess will be connected with: |
|
@vivian-ng Your schematic might need a gate resistor (for drain) to ground just to assure that the MOSFET are off. I'm not an electronics engineer but I was thinking to use the transistor at VBED level instead of 5V. In that config the on voltage will be almost VBED and off will be pulled down to ground. I Like the KISS model, Why not just use a MOSFET driver ? here you got a non inverting one: Those ones are easy to integrate and will give you good switching times as well If you go for the transistor way this design will get some ripples but that does not matter for a heater: |
|
@Aggebitter I also like the KISS model. A mosfet driver seems like the easiest and best choice. But how about using a NOR gate, like in the Duet, to drive the mosfets? The Duet uses the 74HCT02. By the way, for my learning, what is the problem with the current design, which is used on most boards that I see? |
|
@vivian-ng As in open source that we all love there is also often open clone. When China started to manufacture the RAMP 1.4 The started as well to reduce there cost by using cloned parts and the cheapest available kind of replaceable part. One common problem is the MOSFET's. The gate voltage is to low for the MOSFET to open fully. That creates heat at the MOSFET. Ad that it might be a complete different silicon inside of it with the right false marking aka bad clone. This will get really hot and create some hazards. If You are designing a good 3D controller board, I think a lot of known issues could be addressed and evolve to a better and more safe design. Some things is just for safety and I think a MOSFET driver is one of them. There is a lot of juice flowing over the MOSFET. Over heat and you got a nice PLA fire if printed out a funky box for your controller. Been there done that ;) |
|
Hi, I'm following this project very closely and I'm willing to help with what I can. Sorry for the naive question, but why have the MOSFETs onboard? Would it be preferable/easier/safer to have and external board like this one: |
|
Any reason to have different values for R13 and R14? Asking because potentially both VIN and VBED are the same. |
|
@danielfmo Thanks for showing interest in this project. And also for pointing out the R13 and R14 values. Yes, they should be the same value. Different because they used to be annotated differently (VIN used to be 12V, VBED used to be 24V) but they should both be 2.2K. As for having an external MOSFET, it is highly recommended if you are going to be driving a lot of current to the heat bed. Still, I want to have a decent MOSFET for the heat bed on the board itself for those who wish to just use a single board, and do not have such high requirements for current. For example, those who are using this with a 12V heat bed should need less than 10A of current, and it helps to have a decent MOSFET to keep the temperature low. Most people use external MOSFETs with Chinese boards because those Chinese boards use poor quality connectors and onboard MOSFETs which then become fire hazards, forcing people to have to buy Chinese-made external MOSFETs (which cost about USD10 more than a decent MOSFET if installed on the board itself). For the Chinese manufacturers, this may help their sales, but as the end consumer, we probably want to strike a balance, keeping price low without compromising safety. Personally, if I am going to drive more than 10A, I will use an external MOSFET just to take the heat off the controller board. |
|
@vivian-ng I'm wondering about this part : |
|
@Aggebitter I believe Z_MIN is connected to GPIO15. Will that affected uploading of firmware? My understanding is that GPIO0 is the one which needs to be grounded when uploading firmware, which is why I try to avoid using IO0 for anything. But then, it probably doesn't matter, since people are unlikely to be using the printer for anything else when uploading firmware. If you are referring to using a different pin for the Z probe instead of sharing with Z_MIN, my consideration was that the Z probe is a replacement for Z min endstop anyway, so might as well share the same pin. |
|
@vivian-ng GPIO15 will not affect firmware upload. I was thinking about using GPIO0 at the probe pin and that would not affect firmware upload as we hopefully will not Z-probe in the same time as we are uploading firmware Have you thought about making an "Mega/RAMPS" pinout board instead ? Then everyone could easily obtain your controller a RAMPS board and stepper drivers for an easy setup? I've already builded one proto board that uses RAMPS 1..4 but I'd like to design one later that includes 3.3 to 5V level shifting. That's my learning KiCAD challenge |
That's basically a ESP32 on a MEGA2560 dev board layout. I guess it is not that difficult to design. Just a ESP32 module, a circuit for the CH340, circuit to step down 5V to 3.3V, and level shifters for all GPIO pins. Plus a ton of unused header pins. 😅 However, that won't solve the problem with poorly cloned RAMPS boards. Still, it is a good idea, and like you, I may use this as my learning KiCad experience (I want to move away from EasyEDA, which is good but the file format it exports in is not easily readable by other software). |
|
@vivian-ng you said put header for Nextion like screen / PanelDue which use rx/tx, |
|
@vivian-ng The unused pins on RAMPS is mostly for screens in an already controller heavy display. If we get the shift register to work we have a lot of unshifted GPIO left on the ESP32 and outputs for servos and everything else |
Unfortunately, no, all TX/RX takes place on the same two pins, whether they are from USB, AUX1 connector, or TMC2208. Unlike other 32-bit boards, or boards based on the ATMEGA2560, the ESP32 just doesn't have enough pins to support more than 1 set of TX/RX. Of course, this may eventually change if @simon-jouet and @Aggebitter get shift registers to work via I2S as output pins. @Aggebitter Regarding the idea for use with RAMPS, SparkFun has a bidirectional level shifter which can help with digital shifting. The idea seems to be two resistors and a transistor, and this circuit is just going to be duplicated for each pin that needs level shifting. However, I am not sure how to go about analog shifting (which I guess is only needed for inputs on VP and VN pins, right?). This ESP32-on-MEGA2560-footprint board probably will have a lot of the space taken up by level shifters, and shift registers (eventually). Meanwhile, I will focus on getting this basic ESP32-based control board out first. It is not much, but at least it has all the minimum requirements to print something. Will be getting a PCB made soon so that I can solder together something and test it with @luc-github's Marlin fork. |
|
@vivian-ng As I just got my small router up and running with GRBL on ESP32 I noticed some things about limit switches that I think should be addressed. The design includes caps for low pass filtering the mechanical switch bouncing issues. But we are using 3.3V as signaling voltage for the limit switches. Add Steppers that with an ESP32 can do a lot of micro stepping at a high rate we will get a lot of noise in the limit switch signal if the cables are routed in the same path. Shielded cables is a must but there is an extra way to do it by just pump up the signal voltage. Then do a voltage divider and drive the base of an NPN transistor. Feed the collector with the 3.3V pullup and we reduce the noise a lot. A darlington array would reduce size. If you do a debounce circuit before the transistor as this one, the signal would rock solid |
|
@Aggebitter I am not very sure how to do this, but I am guessing you mean the signal pin being connected to a voltage divider (any suggestions on the values to use? 10K for both?) as well as a capacitor (100nF?). This is going to be tricky as it will mean adding 6 resistors and 3 capacitors to the board, where space is limited. But I will see what I can do. As for the suggestion on using transistors, if you have an example diagram of how to do this, it will really help my understanding. Also, how bad is the noise that you are experiencing? Are the endstops being triggered just be the motors moving? |
|
@vivian-ng Well I was thinking like this. I have not tried out the circuit yet and the resistors should probably be different |
|
@Aggebitter why not have the debounce outside of this board/project? If I understood correctly the goal of this project is to have something that everyone can use to give a try with ESP32. And I'm not aware of other hardware that already have the debounce circuit integrated (3d printing wise). Off-course that I'm not against it! It's that I think its a very simple circuit that one that needs it can have on an external homemade PCB. |
|
@Aggebitter @danielfmo |
|
@vivian-ng @danielfmo Well, I was thinking when doing 3.3V signaling, that it must have some good filtering and debounce to reduce false triggering. Especially when the steppers are driven at higher voltages. This is cheap and will help a lot |
|
After looking at the PCB, I think I will add the bare minimum: capacitors as filters for the endstops. The entire setup with more resistors and transistors is probably an ideal state, but it is going to be hard to squeeze into the limited real estate available. Hopefully this is enough to cut down on most of the noise. Once this basic version is done, I may work on a R2 with this better filter and also incorporate shift registers for additional output IOs. And use smaller SMD parts to make space. |
|
I finally managed to solder together v0.6 using a frying pan. Flashed the latest version of Luc's Marlin fork, and the web UI is working. Next is to actually connect it to a printer to see if this works. This will take a while since I will be busy over the next few days with work, but I will try to see what I can do to test it out this week. Meanwhile, v0.7 is already in the works, incorporating the suggestions from everyone. v0.7 will reflect any other changes needed based on testing of v0.6. One update: TMC2208 support will be removed from v0.7 onward as there are not enough sets of TX/RX pins for a meaningful implementation (need 4 pins to implement X and Y at the very least). Maybe when I2S is working and we have more pins available, TMC2208 support will appear again in R2. |
|
After nearly burning the house down, I realized the LM2596-5.0 was not outputting 5.0V. It was giving more like 5.8V. This caused the 74HCT02 to fail, resulting in voltage being fed continuously to the MOSFETs (one of which I had a hotend attached to). A few options:
Option 1 is the easiest, and I will likely be adopting it as I: If anyone has any better suggestions, please let me know! Meanwhile, I have removed the 74HCT02 from the board, and used wires to connect the MOSFETs to their respective ESP32 pins. |
|
I think I narrowed down the problem with the high output voltage of the LM2596S-5.0. Stupid me chose the wrong inductor when I was designing on EasyEDA. While the schematic doesn't show it, the inductor being used in v0.6 is rated for a much smaller current (540mA) than recommended. I guess that's why I couldn't get the LM2596S-5.0 to deliver proper 5V. Still, it does expose the flaw of using the 74HCT02 (which can use a max supply of 5.5V) so I will replace that with a 74HCT125. The next version will likely also include using an opamp to select 5V (either from VIN or VUSB) like on the Arduino UNO R3 board instead of jumpers. Too risky to use jumpers and hope the user remembers to set the jumpers correctly. |
|
Nice board ! :) What do you think of having jumpers to switch from X, Y or Z endstops to SPI CS_PIN of TMC2130 ? For the extruder controller I don't know which pin could be used as default. |
|
@dtony On another note, I don't think the endstops should be used for CS_PIN. Because even if you are using sensorless homing on the TMC2130, you still need to connect the pin on the TMC2130 to an endstop pin. I would think CS_PINs can most likely use SDA, SCL, and IO0 for X and Y plus either Z or E. |
|
Just uploaded the files for v0.7. Major changes are the use of 74HCT126 (non-inverting buffer gate) to drive the MOSFETs instead. And a revamp of the 5V step-down circuit to use the TPS54340 instead of the LM2596 for a smaller footprint. The amount of space freed up will eventually be used to add two 74HC595 for I2S driving of the motors (and maybe even MOSFETs). I will probably order the PCB from JLCPCB again soon and give it another go. Hopefully this design works and I can upgrade it to v1.0 before Chinese New Year, because it is going to be hard to get parts or PCB during Chinese New Year period with all the Chinese companies taking a break. But that also means if I can get v0.7 PCB done by Chinese New Year, I can spend that period testing it and make any necessary (hopefully none) changes. |
|
@vivian-ng, Simon has the I2S running know so some shift register as the next step ? |
|
@Aggebitter Why? Meanwhile, let me get a proper v1.0 out first. |
|
I have renamed the project in preparation for a v1.0 release to give it more identity. Future discussions on the project should be on this thread. Meanwhile, v0.8 is on KiCad, and the files will be released on GitHub soon. BTW, v1.0 will still just be a basic board, no I2S. But space has been allocated for I2S, which I will get down to working on once v1.0 is out. |
|
I have finally managed to find a PCB manufacturer to get a proper quote. I have launched this project on Kickstarter based on the quote to make it available to everyone who wants one but do not have the time/resources to make one themselves. The reward is priced at cost: 76.5% production and shipping, 5% Kickstarter fees, 4.5% Kickstarter payment provider fees, 6% bank fees, 8% taxes. For those who already have the required components on hand, making your own board by ordering a PCB (from JLCPCB, for example) is the cheaper option. But for those with no such components, I think backing this Kickstarter is the easy (and cheaper) way since the unit price is based on a larger production volume. Anyway, here is the link: |
Please give any feedback on the board design (schematic and PCB) on this thread.
The text was updated successfully, but these errors were encountered: