[greybeard]

I have built two identical articulated arms, each has three stepper motors.
This is a question looking for a simple way to run them together, so that the g-code controlling each of them steps at the same rate.
For example, the same code runs on each controller, but only outputs to the correct arm.
It might need another device that 'steers' the outputs, and is referring to the original code for its instructions.

I know there are many other ways of controlling them, but I want to try this approach first, if only in simulated mode.

[urbnsr]

I would look into only one machine and giving each joint it's own axis. LinuxCNC can control up to 9 axes. I think that would be the easiest (only?) way to keep both arms together.

Paul

[greybeard]

Hi Paul,
Thanks for your input. The 9-axis idea will be my next approach if the first one has no where to go.
John

[Tkamsker]

why don't you spilt the stepper signals to duplicate them ?

[neilw20]

Each stepper has it's own driver, and feed the drivers with the same step and direction signals.
As long as you start at the same position when off, they will stay in step, as long as no lost steps due to overloading or excessive acceleration used.

[greybeard]

why don't you spilt the stepper signals to duplicate them ?

I have now abandoned the idea of using g-code, and am using a system which is more like addressing the steppers directly in machine code.
Thanks for your interest, but I now consider this thread closed.

John

[greybeard]

Each stepper has it's own driver, and feed the drivers with the same step and direction signals.
As long as you start at the same position when off, they will stay in step, as long as no lost steps due to overloading or excessive acceleration used.

This is very much the way I am going.
I've built a 6 channel controller/driver, with separate 'homing' circuits for the left and right arms, using optical interupters and logic ic's for each motor.
i've made sure that the speed/load allows 'dead reckoning' navigation for the arms.
John

[urbnsr]

... For example, the same code runs on each controller, but only outputs to the correct arm.
It might need another device that 'steers' the outputs, and is referring to the original code for its instructions.

I know there are many other ways of controlling them, but I want to try this approach first, if only in simulated mode.

Kind of academic at this point, but I don't think the arms are always in sync that duplicating the signals would work. See what I set to bold in John's quote above. Maybe I mis-read.

[greybeard]

I guess it's my own fault for a poor choice of the word 'synchronously' in my title. Trying to keep my cards too close to my chest !

Basically trying to get the two arms working together, each following it's own path, but the timing of the two is linked in a single data stream that is sent to both, so that they don't collide.

John.

PS when I get to moving the prototype, a video will appear. When the final model has made its public appearance, I'll go open source.

[urbnsr]

Thanks John.