-
-
Notifications
You must be signed in to change notification settings - Fork 386
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: link 2 identical cnc controllers so we can drive more motors #1362
Comments
We already have a 6-motor solution with the various 6-pack boards and the Jackpot board. It doesn't make sense to expend a lot of effort to try and synchronize two ESP32 when we already have good, well-debugged, fully supported ways to drive 6 motors. |
Sure I could buy some stuff, but I am here to learn and for the challenge ;) |
Okay, but we are not offering to help you. We prefer to spend our time doing stuff that helps everybody. Supporting all of the existing users with the myriad of existing hardware is challenge enough. Maybe you could have a third MCU that sends commands to two 3-motor controllers. |
Feel free to ignore my messages and lets see what others say. |
I have had good results by using multiple senders. I open up a serial connection to all ESP32 controllers and start sending commands to all at the same time. The starting deviation between controllers is about 2ms in my case. To coordinate the timing between controllers I use G93 inverse time mode on all moves. I am working right now on a new approach where I pre generate gcode files for all controllers, upload them via xmodem and start them at the same time. The starting deviation is still at 2ms, but I don't have to keep senders busy and worry about buffers. |
Machine Context
I am using a ESP32Duino (and it works like a charm) to control 4 motors of a 6 axis robot (ProArm RS2200). I would like to use a second ESP32Duino linked as a slave to the first one to drive more motors.
Feature Description
The 2 ESP32Duino could be linked somehow so they share the PWM clock.
Other Approaches
I believe alternate solutions wouldnt be feasible.
How I Can Help
I would like to hear and try your implementation ideas myself
The text was updated successfully, but these errors were encountered: