JuKu wrote:
The axes need to know about each other. Even a simple XY move needs to be synchronized to be smooth. With a distributed system it would be difficult to draw a circle, for example.
Yes, they would know about each other and be synchronized. Sorry, I must not have explained very well.
Think of it this way: 95% of the TinyG software remains the same, but instead of the "big" Atmel manipulating the stepper-driver-chip-pins directly, it instead sends a digital request to the appropriate one of the four "little" Atmels asking it to do this. If necessary, a timestamp can be included with the command ("do this at a specific time").
It's simply a way of multiplexing what are currently sixteen noisy high-current-motor-drive wires into two high-current-power-supply-wires and two low-current digital signaling wires.
And those remaining two high-current-power-supply wires would be much less noisy than motor-control wires: you can add decaps to reduce the di/dt of a power supply wire, but you can't do that to a motor-drive wire since those *need* the high di/dt. This means that the wires can be cheaper, possibly even unshielded (not 100% sure there).
mawa wrote:
And you need at least 4 wires to connect to each distributed stepper driver.
Yes of course. But in my proposal those 4 wires are about 2cm long instead of running the entire length of the dragchain. They also don't run parallel to any other wires, which is the main source of noise issues.
mawa wrote:
Please believe me building a bus driven distributed solution in a dirty EMC environment you need to use insensitive communications like CAN or RS432.
Then why is the LitePlacer currently able to run a 480mbit/sec downcam USB connection through the exact same dragchain? Clearly sending high-speed data through the dragchain is not an obstacle; all of us are already doing it. However it may be necessary to run a separate quiet digital power supply (as the downcam currently does), which would bring the wire count up to 2+4=6.
.