Project Logs Collapse logs

• Calibration with multilateration using W1209

  RigTig • 04/03/2017 at 00:52 • 4 comments

  To calibrate RB3DP, the idea is to set up a calibration object, manually move effector to 5 points on that object (at each point, record relative lengths to each winch) and calibration is just some arithmetic to derive the x, y, and z coordinates of each motor winch. So, we need a controller, which (of course) must be very inexpensive, so the choice is W1209 board (see https://hackaday.io/project/16097-eforth-for-cheap-stm8s-value-line-gadgets ) plus an ESP8266 for WiFi.
  

  The key for getting this to work is multilateration and the maths is on wikipedia (see https://en.wikipedia.org/wiki/Multilateration#Solution_with_limited_computational_resources). Many thanks to @Florian Festi for identifying multilateration as being a key solution to our calibration problem.
  

  The problem was that we did not know the lengths of the strings even if we knew the location of each of the motors (by physical measurement and typing them in). We can measure changes in length however, and that is what multilateration uses; differences in lengths. If you use 5 known points then you can calculate the cartesian coordinates of 3 motor winches. The origin is the one on the calibration object, so there is no transformation needed for different reference frames; everything is referenced to the object space. Another advantage is that there is no restriction on having the motor winches on a plane parallel to the baseplate. In fact, even the orientation of the axes is independent of the physical orientation of the motor winches.

  So, we need a calibration piece with points with known coordinates (P0 to P4), and we need a controller to make each motor winch move so its string is longer and shorter. Now, putting all the calibration code on the central GCODE interpreter might have been obvious, but actually putting code that is used for special purposes on a special purpose machine has the advantage of making this major function very cleanly interfaced. All we need to do at the end of the calibration is tell the GCODE interpreter the locations of the motor winches.

  And there is sure to be some additional functions we can add to the controller, such as moving the effector through a maze, and ...
  

• Wobbling of effector

  RigTig • 03/25/2017 at 12:16 • 2 comments

  What is needed is a way to stop the wobble caused by acceleration of the effector, and possibly the drag of the extrusion material. Two sides of a parallelogram stay parallel even if the angle with the other two sides changes. So, how about we use two strings from each support so the parallelogram is in the vertical plane? Well, that means three attachment points higher and three lower to the effector. Strings can get shorter by folding up a bit, but are (relatively) inextensible. So the parallelograms should be stable enough. Mmm...ok at the effector, but what about the motors?

  Well, each motor now needs to wind in and out two strings at the same rate. One motor can handle that easily. Each spare string needs to be kept clear of the other, and still have an accumulator, and that seems to be a simple piece of engineering, too.

  There is no change to the kinematics needed, so software is unaffected.

  This whole idea was the result of just thinking further about a question asked by @Florian Festi in a reply to one of my comments on Someone please build a parallel cable robot over in https://hackaday.io/project/11583-odrive-high-performance-motor-control. Now, Florian might be disappointed that I have not reverted to kinematics more like a delta printer, but Florian should be pleased that I have been inspired to think further about stability of this printer. Thanks Florian, for making me think about delta printers.
  

  Oh, yeah, and if this idea doesn't work, it is nothing to do with Florian.
  

• ESP14 is looking like a goer

  RigTig • 03/21/2017 at 11:36 • 0 comments

  The basic GCODE interpreter is about 90% coded onto the STM8 part of ESP14, with considerable thanks to @Thomas for his STM8EF forth interpreter. The comms part is also about 90% done on the ESP8266 part, with thanks to zeroflag for his punyforth. So here is a photo of the breadboard of ESP14 being programmed. Still running code in RAM until it works fully.

  Now, my job is to get back to the motor driver and get it to communicate with this ESP14. Since ESP14 is a wifi access point, I just need to connect ESP12 as dhcp client and set up the tcp channel through a chosen port (that's relatively easy). And then it is just a matter of getting both ends to behave properly when something (temporarily) interrupts communication (and that is the hard bit).

• Concept test for controller on STM8

  RigTig • 02/27/2017 at 22:34 • 1 comment

  Sometimes smaller is better. Thanks @Thomas for eForth on STM8. I've added the files to this project where I have tested the concept of using STM8 running eForth to be the controller for the RB3DP. The forward and reverse kinematics routines are tested, and a few GCODE commands are implemented. Stubs are used for actual actions, with text echo of internal commands.

  Based on this test, RB3DP will accept GCODE in millimeters and have a maximum size of about 60 meters (the 16-bit integer maths maxes out at 65.535 meters).

  Now to put it all together on ESP14 (which is STM8 with ESP8266).
  

• ESP14 as GCODE interpreter?

  RigTig • 02/23/2017 at 07:12 • 3 comments

  Rather than Arduino and ESP8266, I wonder if ESP14 might work as a GCODE interpreter. Mmm...looks like a job for Forth, so I got hold of eForth (for the STM8) from another hackaday.io project (thanks to Thomas @TG9541 - see https://hackaday.io/project/16097-eforth-for-cheap-stm8s-value-line-gadgets). It looks like the GCODE interpreter is going to be about 3K of code on top of about 4.5K of eForth. Not a fancy interpreter by any means but it'll work (I believe).

  I decided to implement each GCODE command as a Forth word. For example, the GCODE M17 command is to enable the motors, and has no parameters. Its implementation is trivial, as follows:

  : M17;
    \ enable motors
    motorsOn
    ;

  GCODE interpretation rules generally say to quietly ignore any GCODE command that does not apply to the particular machine, but Forth typically aborts operation if an unknown command is received. So, we want to change the outer interpreter. This is easy in eForth, thus:

  \ GCODE interpreter
  \ no prompt; ignore undefined words
  : GEV ( -- )
    NAME? IF EXECUTE ELSE DROP THEN ;
  

  and include the following in the initialisation routine
  

   \ change interpreter over for GCODE
    ' GEV 'EVAL !
  

  The forward kinematics and reverse kinematics routines are coded but untested. I've had a lot of fun with VARIABLEs and have finally reached a good way forward for this project. Just a little more coding and then some serious testing on ESP14, with both CPUs running Forth. Now that will be fun!
  

• Comms between Arduino and ESP12

  RigTig • 01/26/2017 at 09:24 • 0 comments

  I looked at I2C, Serial and SPI. The final choice of ESP12 as SPI master and Arduino Nano as SPI slave is perhaps somewhat non-obvious when you consider that the highest level controller is the Arduino Nano. Here's what I learnt from researching and my conclusions about communication between ESP12 and Arduino Nano for this project.

  I2C/TWI

  [The Arduino] Wire library has blocking I/O. That means, it goes into a busy loop and waits for the I2C communications to complete. Your application can do nothing while the TWI hardware is talking over the I2C bus. The maximum length of a 'message' is 32 bytes. The time to send just one byte is something in the order of 28 microseconds per byte using the maximum SCL rate of 400kHz (plus an extra byte for address).

  Summary: A 32-byte message takes about 1 millisecond, which equates to about 0.05mm for an effector moving at 50mm/sec. I am not sure about the effect of blocking I/O though, when getting GCODE input from either SD card or Serial.
  

  Serial

  Nano has only one hardware serial port. Software Serial cannot do the high speeds of the hardware port, and are (I think) blocking I/O. Hardware Serial can easily and reliably do baud rate of 115200 and probably much higher. The Hardware Serial is the default interface to a host computer and using it for interfacing to another microprocessor compromises the ease of host connection. Maybe using the Software Serial for host connection might be workable.

  Summary: Technically workable and faster than I2C.
  

  SPI

  Maximum speed is the clock speed of the slower partner (16MHz for Nano). Maximum transmission length is 64 bytes of data. NodeMCU does not yet support slave mode SPI on ESP8266. SD card readers typically use SPI, so may need to look in detail at timing for multiple SPI interfaces on the Nano.

  Summary: Initially, it seemed obvious for the Nano to be the SPI master since it processes the GCODE and would ask ESP826 to do work for it. However, it might just be better to have the ESP8266 have the SD card reader and be the SPI master sending the GCODE lines to the Nano for handling and getting back the WiFi commands to send to the motors.

  Grand Summary

  ESP8266 is faster clock (80MHz) so can handle its work 5 times faster than the Nano (16MHz), so how about we load it up with what it can do best. So, the ESP12 can have the high speed stuff of reading SD cards and sending WiFi. That means we use the Nano as slave SPI and does the distribution of work. Perhaps not an obvious choice, but it should be interesting to put together.

  PS Comments and any alternative suggestions are always welcome. Even better might be to put together your own project on Hackaday. You'll probably be quicker than me anyway; I am a slow coder.
  

• ESP12F/NodeMCU memory shortage for controller

  RigTig • 01/21/2017 at 09:35 • 2 comments

  The controller code for interpreting GCODE lines works fine on my desktop (using ZeroBrane). The lua code even loads onto the NodeMCU on an ESP12F, but it complains about not enough memory to run.

  After some research and careful reading of NodeMCU documentation, it seems I am asking too much of the ESP12F/NodeMCU combination. The device really is an ideal IoT terminal node, but not really capable of parsing the GCODE and performing all the related tasks.

  Oh well, looks like back to using an Arduino Nano clone and just using the ESP12F as the WiFi interface. I want to keep the Arduino serial IO for monitoring, etc. So, I now need to look at the best way to communicate between Arduino and ESP12F other than serial, then rewrite the Arduino code for the GCODE parser and WiFi interface.

  At least, I've learnt lots about the ESP8266 and the ESP12 in particular, plus got a non-trivial Lua program to work (if only in simulation mode).
  

• Drawing a line: Lua code

  RigTig • 01/17/2017 at 07:10 • 0 comments

  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.

• Use WiFi instead of ethernet cable

  RigTig • 12/08/2016 at 01:29 • 5 comments

  Each time I go to set up a test, I have to use long lengths of ethernet cable. Besides creating a trip hazard and generally making the rig look quite untidy, the cable has a tendency to break at the termination points. Ethernet cable is solid core and does not like being flexed! How about a solution?

  So a sub-project is born: ESP8266 stepper driver. Each motor still needs power, but that is much easier to handle than the ethernet cable back to central unit. I am not sure about the delay over WiFi for messaging to get three (or more) motors to move in a co-ordinated way, but that is what experimentation is about, isn't it?
  

• Drawing a line

  RigTig • 09/22/2016 at 14:27 • 0 comments

  An object is divided into layers as thick as the printer lays down material in the vertical direction, and each layer is divided into lines as far apart as the width of the extrusion. So, we build our object using lines to make each layer, and multiple layers to make the vertical dimension. This means our simplest thing to print in a 3D printer is a straight line.
  

  Pixels and stepper motors have a common characteristic in that a line has to be approximated into integral elements. Essentially, a line is represented by one or more steps in a direction and a step in a different (usually orthogonal) direction before continuing in the same fashion towards the end of the line. Mr. Bresenham figured this out a long time ago, and his algorithm is still widely applicable in fundamental graphics representation in digital media. [I'll leave it as an exercise for the reader to locate a suitable description of the Bresenham algorithm. I've used it for so long, I have no idea where I learnt it.]

  A 3D printer actually uses four degrees of freedom (so a minimum of 4 motors). Three degrees of freedom provide the movement in our 3D world, and the fourth drives the extruder (thus determining the amount of material extruded). In a GCODE file, the four degrees of freedom are called X, Y, Z and E. Each GCODE line (of movement) moves from the position in the previous GCODE line to the one in this GCODE line, so the position described in the GCODE line is the state of the machine after the GCODE line is executed. The machine is supposed to move in a straight line from one position to the next. [Yes, I know there are GCODE commands for doing arcs, but we'll stick to the easier stuff first.]

  The following Arduino code is the routine for drawing a single line in the rb3dp. Each motor moves one step at a time, and the Bresenham algorithm says which one to move to keep the actual movement as close to the intended line as possible.
  

  static void line(float x,float y,float z, float e) {
    long l1,l2,l3,l4;
    IK(x,y,z,l1,l2,l3);
    l4 = e * e2steps;
    // in machine space
    long d1 = l1 - m1Pos_steps;
    long d2 = l2 - m2Pos_steps;
    long d3 = l3 - m3Pos_steps;
    long d4 = l4 - m4Pos_steps;
  
    long ad1=abs(d1);
    long ad2=abs(d2);
    long ad3=abs(d3);
    long ad4=abs(d4);
  
    long ad1x2=ad1*2;
    long ad2x2=ad2*2;
    long ad3x2=ad3*2;
    long ad4x2=ad4*2;
    
    int dir1=d1<0?M1_REEL_IN:M1_REEL_OUT;
    int dir2=d2<0?M2_REEL_IN:M2_REEL_OUT;
    int dir3=d3<0?M3_REEL_IN:M3_REEL_OUT;
    int dir4=d4<0?M4_REEL_IN:M4_REEL_OUT;
  
    long i, err1, err2, err3;
    
    if((ad1>=ad2) && (ad1>=ad3) && (ad1>=ad4)) {
      err1=ad2x2 - ad1;
      err2=ad3x2 - ad1;
      err3=ad4x2 - ad1;
      for(i=0; i0) {
          onestep(m2,dir2);
          err1 -= ad1x2;
        }
        if(err2>0) {
          onestep(m3,dir3);
          err2 -= ad1x2;
        }
        if(err3>0) {
          onestep(m4,dir4);
          err3 -= ad1x2;
        }
        err1 += ad2x2;
        err2 += ad3x2;
        err3 += ad4x2;
        onestep(m1,dir1);
      }  
      if(readSwitches()) return;
    }
  
    if((ad2>=ad1) && (ad2>=ad3) && (ad2>=ad4)) {
      err1=ad1x2 - ad2;
      err2=ad3x2 - ad2;
      err3=ad4x2 - ad2;
      for(i=0; i0) {
          onestep(m1,dir1);
          err1 -= ad2x2;
        }
        if(err2>0) {
          onestep(m3,dir3);
          err2 -= ad2x2;
        }
        if(err3>0) {
          onestep(m4,dir4);
          err3 -= ad2x2;
        }
        err1 += ad1x2;
        err2 += ad3x2;
        err3 += ad4x2;
        onestep(m2,dir2);
      }  
      if(readSwitches()) return;
    }
  
    if((ad3>=ad1) && (ad3>=ad2) && (ad3>=ad4)) {
      err1=ad1x2 - ad3;
      err2=ad2x2 - ad3;
      err3=ad4x2 - ad3;
      for(i=0; i0) {
          onestep(m1,dir1);
          err1 -= ad3x2;
        }
        if(err2>0) {
          onestep(m2,dir2);
          err2 -= ad3x2;
        }
        if(err3>0) {
          onestep(m4,dir4);
          err3 -= ad3x2;
        }
        err1 += ad1x2;
        err2 += ad2x2;
        err3 += ad4x2;
        onestep(m3,dir3);
      }  
      if(readSwitches()) return;
    }
  
    if((ad4>=ad1) && (ad4>=ad2) && (ad4>=ad3)) {
      err1=ad1x2 - ad4;
      err2=ad2x2 - ad4;
      err3=ad3x2 - ad4;
      for(i=0; i0) {
          onestep(m1,dir1);
          err1 -= ad4x2;
        }
        if(err2>0) {
          onestep(m2,dir2);
          err2 -= ad4x2;
        }
        if(err3>0) {
          onestep(m3,dir3);
          err3 -= ad4x2;
        }
        err1 += ad1x2;
        err2 += ad2x2;
        err3 += ad3x2;
        onestep(m4,dir4);
      }  
      if(readSwitches()) return;
    }
  
    m1Pos_steps=l1;
   m2Pos_steps=l2;
  ...

  Read more »

View all 14 project logs