Skip to content
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

more sophisticated serial control #24

Open
davidelang opened this issue May 28, 2017 · 1 comment
Open

more sophisticated serial control #24

davidelang opened this issue May 28, 2017 · 1 comment

Comments

@davidelang
Copy link

I've been working with a couple of other advanced motor control projects (maslowcnc which uses brushed DC motors and encoders, odrive which uses high power brushless DC motors and encoders, pthat which can do very high speed stepper motor driving) that all need something more than the traditional step/direction interface. To be clear, I am not a part of the development team of any of these, just a user/community participant.

As I'm seeing multiple projects with similar needs, I'm trying to see if it's possible to create a standard so that getting the smarter protocol implemented in managing software (Initially I'm aiming at linuxCNC adn grbl) easier, on the basis that implementing one protocol will support multiple hardware offering.

PTHat has a well defined serial API at http://pthat.com/index.php/command-set/. I'm suggesting to different projects that if that they can implement something compatible, it would be easier to get good support from CNC software.

One addition to the pthat command that would be needed is a way to synchronize the execution of commands across multiple controllers. To do this, I am suggesting that one GPIO pin be connected to a common bus (with a pull-up resistor), under normal conditions, each controller would pull the pin low. When they are issued a 'delayed start' command, they would switch the pin to an input pin and wait for it to go high. Once every controller on the bus does this, the pin will go high and they all start executing simultaniously (and a short time later, pull the pin low again as they start moving). This can both serve as the initial synchronized start, and be scattered in every so often to make sure that the clocks of different boards haven't drifted.

This will allow coordinated moves to happen across motors managed by different controllers, be they several mechaduino board, or some managed by one type of board and others managed by other types of boards.

Is this something that you would be interested in participating in by implementing a subset of the pthat commands? (one axis, without the aux/adc commands)

@osresearch
Copy link
Contributor

I'm working on a simplistic gcode interpreter for the MechaDuino: master...osresearch:master

As of now it supports a few common commands: osresearch#1

Synchronizing multiple motors is something that we'll need. My thought was to use a multi-drop serial protocol instead and have the controller be able to send a "G1 Xxxx Yyyy Zzzz F" command so that it would reach all of them simultaneously and the commands like M114 would be repeated for each axis to tell the device that it could transmit on the bus.

28921960648_8cf45a9fa6_k

For my current whiteboard plotter I'm using separate USB ports for each motor and having the external controller dole out the points one a time to ensure that they remain synchronized. It does not require microsecond level precision, so the USB latencies are fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants