It seems that you will take gcode, parse it by actuator/motor centrally and then distribute motion commands to each decentralised motor. I'm sure the developers of marlin, repetier firmware and smoothieware would quickly let you know what options there are for extracting instructions that are "kinematically consistent" with your motion system. You've identified that the gcode cannot tell an individual motor what to do and taking the mechaduino approach of keeping track of the step/dir pulses doesn't buy your motor the time it could really do with. Very interesting problem. 

On another aspect, I've been looking at the RTCs and several of them can be configured to provide a regular square wave on a special pin (eg. 1Hz, 1024Hz, 4096Hz). This could be useful in checking sync. Another kind  problem may occur of needing to check/alert the other motors in case a motor falls behind or runs ahead. A regular sync "flag" could be transmitted by each motor module to say whether it is having issues. This could be set in advance of the end of a gcode command so that the motor modules know if they can maintain momentum or need slow/stop to ensure a synchronised start to the next command.  

Simon, thank you for your comments. They make me think about other ways to view this problem space, and that is what I like about Hackaday people. 

RTCs are inexpensive enough to include in my project, and they certainly can provide a more reliable timing baseline than clock cycles on a computer module. I'll start without RTCs and do testing, but great to know about the periodic square waves out of them.

I am not familiar with the time delays in a wifi network, so I am unsure at this time about whether there is enough time to send and react to synchronisation messages during the processing of a gcode line. I have just started playing with UDP messages, and they seem to be reliable enough for the single hop on a local network even though they have no acknowledgement. If wifi communications are fast enough, then making timing adjustments might be a really interesting path to explore further.

I fully understand it's important to keep things as simple as possible, especially when you are testing the concept early on. Just wanted to say that the sync aspects don't need to be wifi. Other ISM band RF methods, 38kHz infrared, ultrasonic, lasers etc could be good for decentralised timing pulses. 

RigTig, I think this is a brilliant idea. I think the mechaduino comments have some discussion about syncing, as the Tropical Labs team would like to parse gcode directly in the motor piggyback board of the future. For what it's worth, I'd suggest trying to get good enough synchronisation of two ESP8266 using NTP. A local NTP server would be better for identifying whether the error is mainly on the ESP8266 side or the Internet NTP server's side. Perhaps a very cheap RTC module would be helpful at each ESP8266. What's the time accuracy you think the machine needs? If it was a desktop cnc the linear motion would be pretty slow so tens of milliseconds would be ok for many use cases but printers are travelling much faster! 

Simon, I have looked at parsing the gcode at each motor and decided
it is easier to start with central gcode interpretation and distributed
motor movement and later look at distributed gcode interpretation. The
key to moving 3 or 4 motors to draw a straight 'line' is starting to
move at the same time, plus each knowing the time needed for each of the other motors to complete the move at its specified 'linear' speed. My assumption at this point is that the time spread for the central
controller to send 4 motor commands is small enough to be called 'start
at the same time'. I am hoping that the delays in sending the messages,
interpreting them and acting upon them are near enough to being the same for each motor, so that each motor starts its move at the same time (being a fixed time after being sent, well, within a few microseconds anyway). 

The trick I am working on at the moment is to avoid jerks between each move due to each motor coming to a full stop before restarting again on next move. This requires the motor controller to be able to multitask so it can control the motor speed as well as receive the next command(s). A very observant reader may notice another assumption for each move in the distributed motor model: each move is assumed to be small enough that a constant motor speed results in a sufficiently constant effector velocity (i.e. both speed and direction). In this printer (and all delta printers), the three motors are not orthogonal, so a long straight line move of the effector actually requires the speed of each motor to vary over that move. Sometimes, we can get away with 'near enough is good enough', and this should be one of them.

The challenge for the Tropical Labs team (as well as me) is to figure out how to embed the kinematics equation into each motor controller. If each motor is orthogonal to the others, then I can see a reasonably practical implementation is possible. I am having trouble working out a practical way to tell each motor the physical relationships between it and all the other motors so each motor is aware of what all the others are doing and can do. Essentially, the motors have to co-operate and it is the interface between them that can easily become unwieldy and unreliable.

If I need to specify a start time for each move of each motor, then all the motor controllers require to be synchronised with the central controller, and NTP technology will need to be implemented. With a bit of luck, keeping things simple might just be good enough, otherwise we'll just have to bite the bullet. That's what testing will actually tell unless anyone cares to do a thorough analysis and simulation. I'd rather try it and see!