So, we now have motors connected by WiFi rather then copper cables. This also means that the controller gives up using individual steps for each motor as well as giving up the tight co-ordination of the movements. So we need to rewrite the line drawing code to allow for a higher level command set to each motor. Since we really need the controller to be an access point, the least expensive controller I have found is an ESP12 development board. I started doing a GCODE interpreter using a Forth language, but then decided to learn Lua mainly due to the availability of the excellent NodeMCU platform.

So, here is the routine for drawing a line in 4D (being the 3 cartesian dimensions of x, y and z, plus the extruder), using the Lua language.

function line(x, y, z, e)
  -- starting at {posx, posy, posz, pose}
  --  go to {x, y, z, e} at speeds stored in globals
  local tmp = (x-posx)^2 + (y-posy)^2 + (z-posz)^2
  if(tmp < .1 and math.abs(pose - e) < 1) then return end -- already there (within 10 um)
 
  -- calculate string lengths at end posn
  local l1,l2,l3,l4;  
  l1, l2, l3 = IK(x,y,z);
  l4 = e * eRate; --2do: define interface and conversion for extruder
 
  -- calculate time for movement: distance to move / rate of movement
  -- 2do check maths for length
  local dist = math.sqrt(tmp) * 1000 -- um
  local duration = 1000000 * dist / xyzSpeed -- microseconds
 
  -- send target length and duration to get there to each motor
  msgMotor(0, string.format('%d', duration) .. ' ' .. (l1) .. ' move')
  msgMotor(1, string.format('%d', duration) .. ' ' .. (l2) .. ' move')
  msgMotor(2, string.format('%d', duration) .. ' ' .. (l3) .. ' move')
  msgMotor(3, string.format('%d', duration) .. ' ' .. (l4) .. ' move')
 
  -- in object space
  posx=x;
  posy=y;
  posz=z;
  pose=e;
end

A couple of interesting points in this code that I'll mention are the interface to the motors (msgMotor()) and the conversion from the cartesian coordinates to the string lengths (IK()).

• IK is an abbreviation of Inverse Kinematics and neatly takes care of the key conversion between what we (and GCODE) understand (X, Y, Z) and the active parts of the printer (strings hanging from motors).
• msgMotor just sends a message (second parameter) to the motor (first parameter). It's not coded yet, but obviously msgMotor() uses WiFi to get the message to the specified motor. [For more details of the motor interface, see https://hackaday.io/project/18533-esp8266-stepper-driver.]

The good part is that this version of line drawing routine is much less tedious than the code needed for directly attached motors.