@bar might have a different reason, but the TLC5947 PWM driver chip outputs a 1kHz PWM signal. The prototype might test the effect of that frequency on the setup.
If I remember correctly, the Arduino-ESP32 code doesn’t include analogWrite() yet. Not sure of the reason, though.
I think that was a default in the motor library I used. It was kind of nice to hear it so I could keep track of what the PID loop was doing 
You can hear the integrator creep up as you mess with the input. You are right that bumping it out of the audible range would be nice
That is a very good reason to keep it. Have you noticed any trends in PID values for motion in dfferent parts of the workspace? I imagine P is maxed for upward motion near top center, but other motion is less intuitive. I’m thinking in the direction of precomputed feed forward based on zone to speed PID reaction time and mellow fluctuations.
I’ve just been learning of something called RemoteXY. It provides a customizable GUI for Arduino devices.
The key features are that there is a web based user interface editor for android and iOS. Regardless of how you choose to design the user interface, the phone/tablet/android tv/whatever just runs a common RemoteXY app from the app store. All the details about what buttons, where they are, what they do, is contained within a section at the top of your Arduino sketch. What the web based graphical editor does is generate that Arduino code. You just copy/paste it into your sketch.
It isn’t perfect, but it is really good. It is open source and has passionate user support including a guy that wrote support for ESP32. https://github.com/FedericoBusero/RemoteXY The original developer is not a native English speaker and I think that has hurt adoption somewhat. If we adopt it into a Maslow interface it will be important that the GUI design website stays up. Inclusion in Maslow would probably help give the project legs. Though it has been around a few years.
This would be a pretty simple thing to add on to any ESP32 Maslow firmware. But beyond that, It provides another interface option immediately for existing Maslow installations. With a minor firmware change on the mega to open up a hardware serial port to talk to a ESP32, the ESP32 can be a bridge between WiFi and Maslow, Bluetooth and Maslow, USB OTG and Maslow. There are cloud options too. Thoughts?
I think a key recipe for success here is to keep the ESP Web-server code as simple as possible.
A possible idea would be to have the whole Web UI as a single-page application (I do these in my day job; I can definitely help if needed) that’s served directly from a directory on an SD card. UI updates would be as simple as just downloading the new version and putting it on the SD card.
The firmware itself would just have an API (either regular REST-like or WebSocket), and that single, index endpoint.
Having the SD card would also really help to store gcode files while cutting.
I’ve been looking at using ESP32 GRBL. It seems well supported and designed and supports an SD card to store gcode.
If you have experience with this type of things I would love to hear if you think they have done a good job or not. Here is the repo:
Sorry to he necroposting, but is this project still active?
I’m nearing the end of installing Bart’s 3 driver board on my 2008 +/- Zenbot Mini, converting it from LinuxCNC and a Gecko G540. So far I’m very impressed with the board (although the magic smoke and flames left one DRV8825, seems to be common with these 5 for a tenner boards). The ZBm is a conventional Cartesian moving gantry router with a sub Maslow working area of 6x8 inches (150x200mm). I’ve cut a few projects and it’s working well, but let’s say the wiring is a less than competent bodge, speaker and telephone wiring that’s awaiting some new parts. I like to think I’ve learned something during it’s 10 years of hibernation but will keep the fire extinguisher handy.
Bart announced a new board yesterday, with replaceable plug in modules along with 6 stepsticks. At first glance it looks well suited for Maslow development although it would need stripping down for production. A video and blog post are up, tindie arrival “soon”. No price but looks more spendy than the current boards.
And OT, the swamprats are getting excited about their new digs, the moose wood and Maslow shop is back under construction. All the 120 year old barn structural repairs are nearly complete (could be 30 or more non-metric tons of hay on the ceiling at times), an impressive bill for the delivered 2x4 and plywood walls came with the material, covid surge pricing, and the closed cell foam guy is eying a new boat after his quote.
Also @blurfl hasn’t been here for several months, anybody know if he’s OK?
It is very much still active!
Although taking a lot longer than I anticipated. I don’t have anything really ready to share yet, but hopefully I will reasonably soon.
@blurfl we miss you!
He’s been away for a little while, but I’m hoping to woo him back once I can get my new esp32 machine working
Like all of my projects 
.
Check out Bart’s latest video when you get a chance, depending on the price that might become my goto CNC controller. He talks about DC motor (or maybe it was servo) modules, so making one for a Maslow may not be terribly difficult, might be worthwhile for a beta test board. If I actually get my Maslow going again (just ordered one of Metal Maslow’s sleds) before snowbird season you can consider me for the list. Right now my Maslow looks pretty forlorn and feeling abandoned after being ignored the last couple years while we were gone.
He mentions that it might be supported by future hardware, but I don’t think they are quite there yet. Maybe I can get the ball rolling 
Here’s the video:
I maybe could have been clearer, sorry. I don’t think Bart has a Maslow driver (or DC motor with encoder) on his own project list, but the mention suggests that one could be developed by a Maslovian with the appropriate hardware design skills. While the video suggests that it would be a comparatively easy task they don’t say easy for who 
Me! It’s me who’s going to do it 
The basics are outlined here: Encoder support · Issue #330 · bdring/Grbl_Esp32 · GitHub
Thanks!
I hadn’t seen that discussion before. Liked the many layered reference to Barbie cars, with 3 daughters we had so many Barbies that I bought Mattel stock.
Expect Squeakie will continue that, although not sure that her little brother (due any day now) will share the same interest.
Interesting how it also ties into Printrbot with the credit to Brook Drumm in the linked servo project, this really is a small world
Nothing like posting a year later… Lots of legal painkillers about that time.
Not that it really matters but grbl 1.1f tops out a little over 30K steps/sec on a 328, then fails gracelessly with a crash back to the reset messages. Just before that it starts stuttering.
I spent some time testing different microstepping rate drivers on a 3018, with a controller that connected the MS lines together. Using G0 rapids and boosting max speeds found that going from 32x to 16x doubled the machines rapid speed showing it was firmware limited. No scope, just eyeball and phone video.
The Zenbot previously used LinuxCNC on an older quad core AMD and would rapid at 800ipm per the config, haven’t tried pushing (or actively measuring) it yet, with Bart’s 3 port board it appears to top out around 600.
I want to make ESP32 development happen. I think everyone agrees this is where the future is. I have done much research on the ESP32 and wanted to both share what I have found and actually do some work to make it happen.
I think everyone in this thread has gotten a bit distracted by the future porting of GRBL and WebControl and OTA updates and etc. I think we need to focus on smaller, more manageable steps. Anything in software can be created/fixed after the hardware is made.
Develop new reference hardware
Get GRBL_ESP32 ported to Maslow kinematics and motor control. Make the ESP32 functional as a Mega replacement
Then start looking at WebControl/Makerverse/Whatever-software-exists-at-the-time work directly from the ESP32.
So, my starting goal is to replace the Mega + shield with a new ESP32 board. I dont want to focus on the GRBL stuff just yet; you dont need to remind me that getting GRBL to work will be a pain. I have seen a lot of the threads.
I plan on designing the hardware board soon. I will hand solder the first batch and will accept orders for it so that other developers can get one. I expect we could have the first batch of boards by the end of October if I continue to have free time to work on this.
This leads to the question of what to put on the board and how to interface with it. I need everyone’s help to get some feedback on what I believe the board will look like. Here is the plan at the moment:
We need 3 DC motor controllers and a Stepper controller. I want to include a stepper motor for the Z axis as an option for people. It will be a Pololu-compatible stepper slot, so it wont really add any cost to the boards. Honestly, I think steppers should be on all axes, but I don’t really want to open that can of worm.
There is a peripheral on the ESP32 called the MCPWM (Motor Control PWM). It is intended to give smooth, lower frequency PWM outputs (compared to the other PWM peripherals on the ESP32) specifically for motor control. It is overkill, since it has a few advanced features for directly controlling the H-bridge that we will not be using. But overkill is better than the opposite.
I plan to connect that peripheral to some DC motor drivers - I prefer the DRV8870. They have nice features, adequate current capability, current limiting and go up to 40V. I plan to make make the board capable of running on either 12V or 24V. The current limiting feature of the DRV8870 should help prevent damage. This should allow faster Maslow movements when combined with proper acceleration control.
One of the peripherals on the ESP32 is the Pulse Counter which can be made to directly read a quadrature encoder signal and count up/down a 16 bit register. With an interrupt to catch the overflow, you have a virtually-zero-CPU-usage memory-mapped encoder reading. This will be ideal for the feedback loop.
Sure, I will include some AUX pins. Current Maslow designs do not use more than 3 as far as I know. We will target the standard 8, but they will be the first to go if we run out of pins.
There has been a lot of debate over storage options, like PSRAM vs SPI Flash vs SD Card etc. Unless someone can come up with a really compelling reason, I am going to use an SD Card. They are cheap, commonly available, familiar to users, have huge storage capacity, portable (allowing for sneakernet setups), and it means we can use the flash on the ESP32 solely for program storage.
Note that there is a semi-conflict on pin Slot 1 D2, where the pin needs to be pulled up for the SD card to function, but needs to be pulled down at boot. We might need to burn a GPIO just to pull this up after boot. Oh well.
like this?
Bar has been working on this for some time and has made some progress with some prototypes and has an easyEDA design you can look at that may be useful for reference. The firmware isn’t very far along. I volunteered to help, but he was making more changes, so I’ve been holding off. I’m going to focus on incrementally improving the mega for the existing user base, but I’m watching this development and at some point will be interested in helping out.
I think that is a great idea! I’ve been working on an experimental five motor board using AMS encoders which is probably not worth copying, but might be useful as a source of inspiration.
Getting GRBL ESP32 working with maslow stuff is actually pretty easy. I point to the right bits of code to modify in this thread:
Adding things like calibration is going to require a little more work, but the ability to add custom homing routines is built into GRBL ESP32 which is promising
