Tom, I have discord already… what channel are you guys on?
1 Like
Grbl_ESP32
tom you wouldn’t have the gcode for the XZ_Main_NEMA23_X_Vertical. I can’t figure out what direction to lay it.
don’t know if i need to lay it flat on its back or on the side along the braces when i print it
Regarding the 2209s in UART mode on the 6-pack, I exchanged messages with Bart as I was confused. I could see 2209 UARTs in the grbl-esp32 code base but based on the schematic I couldn’t see how they could work. Bart confirmed that the 6-pack doesn’t likely contain HW that can make the 2209s work in UART mode. The code in grbl-esp32 is for a different board.
1 Like
thanks
At least folks can still use their 2209’s in standalone mode in a pinch. There are some loss of features there, but IMHO nothing deal breaking. With uart you get programmable current and stallguard, but both of those are not items that are used once the machine is working well anyways. Sensorless homing… not a fan due to belt stretch. So really, I don’t see a huge downside to standalone mode for an mpcnc.
1 Like
I tend to agree. While software current adjustment is nice while your getting everything dialed-in, how many times do you change it during normal usage? Also, I’ve never been able to get sensorless homing to work reliably on anything. 
I would equate this to the zip-tie vs. adjuster knob question posed in the ZenXY dev thread. If it’s something you will constantly be adjusting throughout normal operation, knob for sure. But if it’s one and done, zip-ties win hands down for simplicity and part-count.
2130’s are working fine, as far as I know they are full featured but the only thing I am using is current control. If I remember right.
I need to see if there are any updates on this hardware.
Iirc Bart did mention v6 is on the way, and just needs more thorough testing before it goes out in the wild. Although, I think those changes were just to add pinouts for future use, different screw terms (v5 terminals got hard to find), but no tmc2209 compatibility afaik.
I have a set of 2130’s I used to use on my printer, is spi mode. They are full featured, but I think have a much lower current rating than 2209. Fwiw, on my a8 printer those things ran kinda hot at just under 1a (19V). I stopped using them for the wrong reasons probably… was dealing with skipped steps so went to drv drivers, only to discover later it was an intermittent motor DuPont. That said, I think 2130 would be too hot for most newbs to use on mpcnc… will oh fault unless you have it mechanically dialed.
Edit… I also recall Bart saying tmc5160 support is also not quite 100% yet. It would be great if we could get those working.
Hey, I couldn’t help but notice this:
…and after my recent testing with modified code for faster laser etch, I have to say I 100% approve, lol. For real though, I am talking super smooth 100mm/sec dithered etch with zero jitter or slowdowns. Increasing the block buffer made the huge difference; I also upped the baud rate, rx buffer, and line buffer just for assurance. With the default buffer settings, grblesp32 is not much faster than a mega2560 (~10-15mm/sec max).
The esp32 seems to be handling it just fine even with everything except BT enabled and working. I accessed the esp webui during a test etch. I did note that when first accessing the page, the laser paused for a second then resumed. No artifacts were left as it apparently throttled PWM properly when it did this. I was able to pause/resume and adjust overrides from the webui with no problems otherwise. My testing with the code changes has been relatively small, but I am fairly confident it is worth testing further. After all, ramps was 100% fine for everything I did except it was way too slow at laser etching. With defaults as is, one would find the speed increase not worth the upgrade from like a ramps/rambo.
FWIW, I’m using DRV8255 drivers. GRBLesp32 does not have a 16microstepping available for stepsticks. It is either 32 or 8 due to the circuit design. 32 microsteps has been working fine at 1.4A on my mpcnc w/ bart’s 6-pack (and I rapid @ 7500mm/sec).
Also worthy of note here… well at least finding the cause this issue took a lot of blood and sweat out of me, including hours of oscope work, swapping and flashing modules, playing with different senders, etc so thought I should mention it:
I found a bug with the Arduino espressif32 board manager libraries. UART gets broken with the latest 1.0.6. Downgrading to 1.0.4 worked well for me and AFAIK is an acceptable workaround for this (though I am sure devs will want to fix that). Reading up on 1.0.5/6 issues, it sounds like a bit of a mess. I noticed with 1.0.6 my wifi signal was much weaker, and the core temperature was much higher than with 1.0.4. Also the webui seems much slower on 1.0.6.
2 Likes
Bart also makes his files available so you can order your own pcb from the likes of JLCPCB if you feel confident soldering SMD. The only really tricky SMD component is the level shifter…man that thing is SMALL. You could probably do without it though and just short the input pin to the output pin and have a 3v3 pwm signal - you would also lose the PWM_Enable function. I also note they are out of stock at Tindie now and I wonder if Bart will be making any more now he has his 6 pack up and running.
Sounds good your config changes…perhaps you could document your changes, I’m not sure where all those parameters are kept, are they all the ones in config.h?
When you say ESP WebUI I assume you mean the ESP3D Webui from Luc-github?
I checked and I am on 1.0.5…did you by chance notice any performance issues between 1.0.4 and 1.0.5?
1 Like
Probably the only place to you can find these ready to use is from people like me who bought them and then upgraded to the 6-pack controller.
I suspect you are right. I ordered 5 PCB’s from JLC and mostly built them up…it’s almost as cheap to order components for 5 boards than for just one with minimum order quantities… I don’t think I will be needing any more thanks 
1 Like
I did not observe the controller was older, or connect that the 6pack supersedes it hehe. I suppose folks should be using 6packs anyways for the protected inputs.
@dart1280 I will share more detail on my changes after I am more confident they are stable. I did have some weird behavior during probing, and an unresponsive webui a few times with those settings posted above. I did cut through a few hours of operations done, but still too sketchy for all to try I think.
Since the adjustments I am making affect use of ram, the weird behavior is likely from low ram. This is hard to optimize beyond test and see. So I have been trying different values for block buffer and rx buffer to see what is stable while my router is installed. Once I go through like a week of normal use without issue, I will test the laser speed again on those settings and see how it fairs.
Right now it appears stable and is still laser etching smooth at about 80mm/sec. this is with block buffer at 128, and Rx buffer at 4096. The settings are by default commented out in config.h. You can instead add these parameters to your machine file to keep it in one place.
Also yes, in saying ‘webui’ I am referring to the esp3d interface used by grblesp32.
So even at block buffer 128 and rx buffer 4096, I had another glitch when probing for leveling (bCNC). This probing operation was very reliable on ramps. So I am going to go back to default block buffer and rx buffer for a bit to verify it is not something else. I am kinda hoping the problem is still there when I do this… otherwise that doesn’t bode well for the modifications I did to speed up laser etch.
You could raise the issue on Github. See if anyone else has been experimenting with the default settings. Bummer if it doesn’t work.
Strike that… https://github.com/bdring/Grbl_Esp32/issues/812 I see you have already been there
Yes you saw… I am certainly not smart enough to come up with the idea on my own hehe. 
With some spare time today, I am running some more extensive testing on this to see where it is at. Basically, I’m going to spend a few hours straight running probing, and hope that will be some indication of stability. So far so good on my last settings change. I also noticed the latest comment from Mitch… I had no idea $10=3 had some other benefits for some senders. I was running $10=1 though… running $10=3 now.