26

Re: Slic3r

Don't do anything yet. I have a suspicion that we've oversimplified the backlash problem. I'm confident the Z axis fix is an improvement but we should wait on Ian's results before we decide whether or not to include the rest of it.

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.

27

Re: Slic3r

The Z worked perfectly.  I bring the bed up 10mm until it bumps the gauge, then zero it.  Move up 10mm to something like 9.96.  When I move down 10mm it goes right back to 0.00.  Before it would stop at .18.

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.

28

Re: Slic3r

Glad to hear the Z works now.

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.

Post's attachments

Marlin.pde 55.49 kb, 9 downloads since 2012-09-07 

You don't have the permssions to download the attachments of this post.

29

Re: Slic3r

I was starting a print before work this morning, and had to turn the hysteresis off.  I enabled Z lift in Slic3r which drops the bed slightly when retraction happens, for a print with a lot of retraction in it.  It looked like every time it was doing the lift, it was stopping for a couple of seconds.  I don't know if it was being really slow at calculating, or if it was moving Z really slowly.  The rod might have been turning during the pauses, but when you spread .5mm over a couple of seconds, that motion can be hard to spot.

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.

30

Re: Slic3r

What you are describing is unexpected. What I'd expect is for the code to attempt to move 0.5mm by turning for 0.68mm. It might take 36% longer to perform the move, but not as much as 2 seconds.

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?

31

Re: Slic3r

I did a test by printing 2 cubes and reproduced the bug you described Ian. The Z was moving incredibly slowly as you suspected. It was due to bug I created when I adjusted the steps, but I didn't adjust the mm's. Both are provided to the stepper interrupt. So now I work out the mm's from the steps so they are always in sync. I tested it with a Z400 hysteresis value and it worked as expected. It's easier to give you the planner.cpp file rather than describe all of the changes.

Post's attachments

planner.cpp 35.12 kb, 34 downloads since 2012-09-09 

You don't have the permssions to download the attachments of this post.