Aren’t those for stepper motors?
HTML tends to be small, but js libraries aren’t necessarily. I use three.js in webcontrol and it’s 566k minimized. It’d have to be rebuilt from source to eliminate everything that’s not necessary… just an example… there’s only 174k left on the spiffs partition if you install grbl_esp32 with OTA. Drop OTA and you’ll have much more room.
1 Like
I knew that sounded too easy. Still, there are solutions to convert the step/direction commands to servo drive a motor. Step & Direction - ADVANCED Motion Controls
Building that motor controller to the DRV8825 pinout would save a LOT of software development and I think they would sell like hotcakes outside of the Maslow community.
Edit: I’ve done some looking and there are a handful of products that actually do this for real cnc machines. The cheapest I’ve seen is $89 retail and found a post where the creator claimed he makes $40 on each one. FWIW estimating what we could build one for.
Each step pulse that comes in is a request for a fixed number of encoder ticks.
The time between previous step and current step is proportional to the desired speed.
We can control the step rate by changing PPR setting in GRBL. We control the number of encoder ticks per step in the motor controller.
The changing load on the motors based on sled position could be tough to deal with.
This might be ridiculous, but I wanted to put it out there for comments.
2 Likes
I knew that sounded too easy. Still, there are solutions to convert the
step/direction commands to servo drive a motor.
Step & Direction - ADVANCED Motion Controls
we implement the servo control in our core controller, switching to a much more
time sensitive step/direction arrangement to send it to a controller to convert
it back to a pwm/encoder setuup
Building that motor controller to the DRV8825 pinout would save a LOT of software development and I think they would sell like hotcakes outside of the Maslow community.
step/direction interfaces are extremely timing sensitive, and they also end up
with significant high speed problems.
David Lang
1 Like
There is a lot going on with the webserver code on grbl_esp32 and unless the compiler is really good at optimization, some of it is rather bloated (repetitive) so there’s likely room for making the code smaller. That will help but I still think either we forgo OTA or we use larger flash variant.
1 Like
Have you seen any larger flash variants which look good? A surface mount one which still had the USB circuitry would be ideal.
@blurfl here is the webserver I have been using. ESPAsyncWebServer.zip (270.1 KB)
I’ve had pretty excellent results with it.
1 Like
Are you asking if there is a esp32 (developer) board with usb that can be surface mounted? If so, I don’t think that exists. I also don’t think there are any developer boards (with headers) that have larger flash memory… If you want larger flash memory and/or surface mount, I think you have to build it. There’s not a lot of components that make up the developer board, so I don’t think that’s hard to do… but this website has a ton of information that I’m digging through:
1 Like
espressif makes the reference design for the developer kits available (schematics and gerber files). I think it would be relatively easy to pick those up and incorporate them into a new controller board.
1 Like
Thanks for the info. Could you elaborate on the way in which they are timing sensitive and what the high speed problems are. I realize its probably not appropriate for Maslow, but the concept interests me and I’d like to make some experiments. Any prior experience you have might help me narrow in on problems. I found this Arduino code GitHub - cswiger/dcservodrive: Arduino sketch to turn step / direction signals into DC servo motor position control - 'stepper simulator' from this post DC Servomotor drive for step / direction
where he makes it public domain. So there is a starting point for anyone else interested.
For the sake of argument, lets assume that a larger flash variant is available or will soon be available. The fact is right now, we don’t know how to get our hands on one. So what is a suitable interim solution that we can all start using today for development, and then painlessly move to the ideal platform once it is identified for deployment? During development, we can suffer without OTA to have the larger codespace available. Closer to deployment, when we get our codesize down, we can try to switch OTA back on and see if it fits or if we need to find or build a custom large flash integrated motorcontroller board.
Any opinions on ESP-WROVER-KIT-VB?
Pro;
Made by Espressif
has onboard JTAG debugging. This could be important for identifying and resolving some types of bugs. If we don’t encounter those bugs, it is unnecesary.
Has just a little extra RAM 4.5MB
PSRAM is 8 MBytes
VGA camera interface
3.2” SPI LCD panel
I/O expansion
If we decide in the end to make a custom integrated motor controller board using ESP32 chips or modules, most cons become moot but the pros remain.
AWS-qualified development board. Option to use Amazon FreeRTOS out-of-the-box connectivity with AWS IoT, AWS Greengrass, and other AWS services. Probably not useful for Maslow, but after Maslow development is finished, this feature could be useful for other projects.
Barrel 5v power connector.
Con:
Barrel 5v power connector.
Large uncommon form factor.
Expensive $40 vs. about $10 for smaller boards.
Not viable as a shipping solution, development only.
Not the highest possible spec
One thing to keep in mind when thinking about OTA is that you still need some form of serial (USB) connection to upload the first OTA image and to recover from broken OTA situations. Ignoring OTA seems reasonable, at least for now.
1 Like
I’m not advocating not working on things… just saying if you are going to build a esp32 directly onto a motor controller board, you will be using an esp32 module and therefore can readily use one with a larger flash. But for developing, yes, use what you got and don’t worry about OTA.
1 Like
The reason for that as far as I can tell is that the maximum internal flash is 4MB in any ESP32 device. The ones that have more flash have it external to the chip, but still under the metal can. It is memory mapped so it works just like internal flash except that it uses pins. Since development kits need to allow maximum flexibility, they leave those pins free. That means we can use development boards without external flash, but add a flash chip to the pins if/when we need it.
WROOM vs WROVER
The WROOM-D variants make gpio16 & gpio17 available, the WROVER-D variants use those to handle on-board PSRAM. Which should we be aiming at? Do we need that PSRAM?
1 Like
That is a great question, but I don’t think there is really any way to know until the code is tested. Obviously we need hardware to test on. I would rather have the extra ram and not need it than need it and not have it.
Adding additional slow gpio is less critical of weird trace routes than adding additional fast PSRAM.
I vote WROVER.
Core controller is how it is done currently, where everything was created from scratch for this one machine. That all changes when we move to Grbl_Esp32 realm of the square machine. Its chief developer Bart Dring has expressed interest in supporting machines like ours. Most of our math will need to be done within the kinematics area, a new part of this library for machines like ours that don’t use common trivial linear kinematics. We wont have as much dynamic freedom to run loops upon loops, and our calculations need to be finished within strict timing limits. The algorithm will need to change a little bit. That is not a bad thing IMO as I think it is currently too complex and not modular enough. It does require a reality check on expectations. Developers probably understand this already, but this next part is for the masses expecting a miracle.
The first working versions on Grbl_Esp32 WILL HAVE WORSE ACCURACY THAN CURRENT VERSION.
That is to be expected. We will be loosing the benefit of hand tuned code that cannot simply be moved over. We are taking a step back in order to turn and share a path with other V kinematic machines. This means we will benefit from code written by people who don’t even know what Maslow is. It is impossible to say how long it will be before Maslow on Grbl_Esp32 will catch up to the accuracy of the current system. Some may wonder why bother with this approach at all? It is a matter of long term maintainability. By allying Maslow development with another strong opensource CNC entity, we can help each other remain relevant into the future.
Some may wonder, “What happens if Maslow accuracy never recovers under Grbl_Esp32? Will these efforts be wasted?”
NO. Whatever happens, these ESP32 efforts will improve Maslow. ESP32 as an Arduino processor runs much faster than the current Mega. There is a potential fallback position where we could only slightly modify the current Maslow codebase to run on the ESP32. In that case we are likely to see immediate small accuracy improvement from higher clockspeed alone. But that road leads to a dead end.
This has been a public service announcement. I now return you to your regularly scheduled forum.
1 Like
@ldocull has already ported grbl to work for the maslow, so much of the lessons learned there can be used with maslow-grbl-esp32. I personally think accuracy will be equivalent if we fully incorporate the current triangular kinematics. Afaik, the kinematics that @ldocull used was just basic triangulation but over the years we’ve greatly refined it to work better with maslow (chain sag, wrap around sprocket, etc.)
the high speed problem is just generating enough pulses fast enough to spin at
high speed (200 pulses/rev * microstepping ratio * gear ratio * rpm the pulse
rate you need gets very high very quickly)
the accuracy is something I picked up in the grbl comments. Since you are giving
it 200+ pulses/rev, for it to appear to turn resonably smoothly you need to
microstep, and you need to give your pulse at just the right time, or else the
motor has to stop and then start moving again when it gets your pulse (or speed
up and then stop and wait if your pulse is early)
steppers aren’t designed to move smoothly, they technically move in short steps,
if you send the steps fast enough, mechanical momentum blurs your steps together
(and microstepping instead of full stepping helps blur this more.
grbl tops out at around 20k pulses/sec (performance limits of the arduino cpu),
if you 1/4 step, this is:
20,000 / (200 steps/rev) * 1/4 microstepping = 25 rpm, give it a modest gear
box of 10:1 (a very small worm drive to prevent backdriving) and you are down to
2.5 rpm, about 1/10 the speed of the maslow motors.
1 Like
questionable, the existing code is not as hand tuned as you are thinking, and
the much faster cpu will cover many sins. it will only be less accurate if we
have to change the math and leave out some calculations.
I expect even the early versions to perform better in practice (with the right
settings) due to the improvement that acceleration planning provides.
David Lang
2 Likes
Wink wink, nudge nudge. I was trying to get ahead of it and manage expectations. Leaving an out, just in case. That is one of the nice things about opensource though. Less need to CYA.
2 Likes