I'll take a closer look at the code to see if I've missed something that could cause this.

Did you get the M99 to work?

I didn't have time to investigate, so I just set it to 0 which made it go back to normal behavior.  I had set the Z lift to .5, so the actual lift would be .32 which should be enough most of the time for a .1mm print.

I used repetier to send M99 commands about a dozen times and I didn't notice any failed sends. You can add the following bit of code to see if the M99 command is managing to change the values. In Marlin.pde, search for SERIAL_PROTOCOL(getHeaterPower(tmp_extruder));

After that line there's an #endif, after the #endif insert the following...

        SERIAL_PROTOCOLPGM(" H:X");
        SERIAL_PROTOCOL(hysteresis_steps_x);  
        SERIAL_PROTOCOLPGM(" Y");
        SERIAL_PROTOCOL(hysteresis_steps_y);  
        SERIAL_PROTOCOLPGM(" Z");
        SERIAL_PROTOCOL(hysteresis_steps_z);  
        SERIAL_PROTOCOLPGM(" E");
        SERIAL_PROTOCOL(hysteresis_steps_e);  

This will now report back the current hysteresis values. In repetier the printer output is returned in the console window at the bottom. I think in pronterface it appears in a separate command window. It should look something like this...

ok T:21.9 /3.0 B:22.1 /3.0 @:0 H:X0 Y0 Z0 E0

The last four values are your hysteresis values. If the M99 is not working, the problem is likely in Marlin.pde, so I'll attach mine so you can compare it to yours.

I couldn't get the M99 command to work however, I had to put the steps into the planner.cpp.  I didn't double check my work on the M99 part.  Also I'm finding that Pronterface is better for sending gcodes by hand.  Sometimes Repetier doesn't seem to send them.

I haven't messed with Y, I would rather get the M99 working first, since things are a little more fuzzy with that one.

If it does work then we should try and get it submitted into the original Marlin firmware. There are other printers that will have worse backlash problems than the Solidoodle.

Is this something that should be added to the Solidoodle firmware I have on Github?

If so please let me know and I'll put it in and credit you.

I'd recommend the first one so it's easier to recognize what you're printing with.

If you'd prefer to change planner.cpp, I can add extra information to be fed back to Repetier. At the moment Marlin reports the temperature of the bed and the nozzle, but I can add anything to that. I added the hysteresis values to that report so I could debug my code, but if anyone else can think of something useful that they'd like to know about what's going on inside Marlin, I'd be happy to add it.

Are you sure your X/Y backlashes are as high as 0.3mm? We should be able to observe a flat 0.3mm surface on the North/East/South/West walls of the objects you've been printing.

Would speeding up the added steps put all of the correction closer to a point near 5, across the duration of a few Y steps rather than spread all the way between 5 and 1?

Maybe Y could pause for a bit, and the steps can be sped up a bit to shorten the length of pause needed.  I don't think it takes much pause at all for blobs to show.  The pauses from running Sprinter without look ahead were very short, the the results were very evident.

If you want to fix hysteresis in the X and Y axis, then you must perform the hysteresis correction before performing the intended move. Imagine a zig-zag pattern where the X is going back and forth and the Y is advancing in one direction. The numbers are both positioned in the X axis and show their X position values

1
 2
  3
   4
    5
   4
  3
 2
1
 2
  3
   4
    5

with no hysteresis correction, some of the X backlash would be absorbed as shown below. This is what is happening on everyone's prints right now...

1
 2
  3
   4
    5
    5
   4
  3
 2
 2
  3
   4
    5

So we are seeing two problems.
1) The X is briefly static at the 5 and 2 positions while the hysteresis is occurring, because there is no hysteresis occurring in the Y.
2) Due to hysteresis, we don't even get back to x=1

My code adds hysteresis which adds extra steps to the motion, this will only fix problem 2. This is what will happen to prints that use my hysteresis code...

1
 2
  3
   4
    5
    5
   4
  3
 2
1
1
 2
  3
   4
    5

Problem 1 will still occur as the hysteresis motion is interpolated along with the non-hysteresis motion. In order to fix problem 1 then a more involved code fix needs to occur where the hysteresis error needs to be applied separately from the intended motion. With that kind of fix in place, then the exact intended path would be followed. However, there would be a slight pause in motion as the extruder remains motionless while the hysteresis is fixed. At 50mm/s, the pause would be 160th of a second, so shouldn't be noticable.

Hopefully I'm making sense to people?

Would gravity change things?

If you find that you need two separate Z hysteresis values for up and down motion then let me know and I'll add it.

 // If there has been a change in direction, add any hysteresis to the steps
  if( block->direction_bits != previous_direction_bits )
  {
    if( (block->direction_bits & (1<<X_AXIS)) != (previous_direction_bits & (1<<X_AXIS)) )
    {
      block->steps_x += hysteresis_steps_x;
    }
    if( (block->direction_bits & (1<<Y_AXIS)) != (previous_direction_bits & (1<<Y_AXIS)) )
    {
      block->steps_y += hysteresis_steps_y;
    }
    if( (block->direction_bits & (1<<Z_AXIS)) != (previous_direction_bits & (1<<Z_AXIS)) )
    {
      block->steps_z += hysteresis_steps_z;
    }
    if( (block->direction_bits & (1<<E_AXIS)) != (previous_direction_bits & (1<<E_AXIS)) )
    {
      block->steps_e += hysteresis_steps_e;
    }
    block->step_event_count = max(block->steps_x, max(block->steps_y, max(block->steps_z, block->steps_e)));
  }
  previous_direction_bits = block->direction_bits;

Also, if you want to be able to set the hysteresis values with a command that you can send from the repetier G-Code text box, then you need to add the following to Marlin.pde.

This first one is just a comment so isn't necessary, but for completeness. Add this comment amongst the similar command comments near the top of the file...

// M99  - Set XYZE hysteresis values. To turn off hysteresis... (M99 X0 Y0 Z0 E0)

Search for M92 in the code to find the case statement that processes M commands. After M92, insert the following...

    case 99: // M99
      {
        if(code_seen('X')) hysteresis_steps_x = code_value() ;
        if(code_seen('Y')) hysteresis_steps_y = code_value() ;
        if(code_seen('Z')) hysteresis_steps_z = code_value() ;
        if(code_seen('E')) hysteresis_steps_e = code_value() ;
      }
      break;

Finally, we need to inform Marlin.pde of where the hysteresis variables are by adding the following to planner.h...

extern long hysteresis_steps_x;
extern long hysteresis_steps_y;
extern long hysteresis_steps_z;
extern long hysteresis_steps_e;

That's it. You can now change the hysteresis values from repetier like this...

M99 Z5000

That would add a 2mm hysteresis to the Z motion. Obviously way too much, but it lets you see that the code is working. You can set multiple values at the same time, for example, the following will turn off all hysteresis...

M99 X0 Y0 Z0 E0

Have fun with that. If you want me to explain anything in detail then I'll be happy to.

So either my code isn't working or the commands to move the bed up and down are not going through plan_buffer_line.

I'll look into it some more.

It's a little nitpicky since it probably won't show in a print, but I would get some satisfaction in seeing the all the measurements be dead-on in the dial gauge.  On the other hand, I'm finding that my white PLA is really unforgiving in showing every little variation in thread placement in .1mm. 

There is a biweekly printing contest at the RepRap forum, and I would like to get a print that is as good as the Solidoodle can possibly make.  They like to choose challenging prints like this one - http://www.thingiverse.com/thing:29365 .