Hysteresis Fix (Page 2 of 2)

Yes that's correct.

The reason is that if these settings change, for example you change the belt tension, then you have to recompile the firmware. I have my setting placed in the start gcode of Slic3r so they are applied every time I start a print.

There used to be a setting for default hysteresis in the original code by Neil, but I removed it because I couldn't see why anybody would hardode something like that in the firmware. Apparently I was wrong So yes, you will need to change the cpp file.

In short, I advise against it, but if you want to do it you will not break anything.

Well, I am trying to accomplish calibrations on my SD2, starting with the extruder calibration.  I have an IMAC with Mountain Lion software.  I can open the Arduino.cc file, but where is the Marlin.PDE and then the "configuration tab?  Can't find it.

Could someone please ELI5 how to edit my SD3 firmware to add the hysteresis fix code please ?http://www.soliforum.com/topic/313/hysteresis-fix/
So far I'm trying to follow the instructions here:  http://www.soliwiki.com/Updating_Solidoodle_Firmware
How can I tell if I have a ATMega644P (Solidoodle2 default chip) or ATmega1284P

SoliForum - 3D Printing Community → Hacks & Mods → E3D extruder on a new SD3 FW HELP..

Page 3 or 4 follow instructions from user enrage.

If you're trying to take up z slop, then yes it does work - I used this for a while!
If you are trying to compensate for backlash in X/Y there are some issues (under some circumstances can cause layer shifts). This is not a problem for Z movements, and as long as you set the X,Y hysteresis values to 0.

I also believe the SD4 should work with https://github.com/ozadr1an/Solidoodle-Marlin_v1 firmware, which has the hysteresis fix applied (you may need to switch it on in configuration.h). As I understand, you're right, it's basically an SD3 in a box (at least as far as firmware is concerned).

If you are fixing z hysteresis, then there is another option you might consider: using a z-offset to take up the slop in the first layer. The bed moves up when homed, and then consistently down for the rest of a typical print (without z-lift etc. enabled). This means you only have one direction change to compensate for, at the start of the print. In slic3r, you can set a z-offset to the measured backlash. With other slicers where you can't set a z-offset, you can add some start g-code to make a compensation move and re-set zero position just before printing:

G28 Z ; home
G1 Z0.1 F3000 ; make 0.1mm compensation movement
G92 Z0 ; set position to zero
; *** print ***

Alternatively, in the printer firmware you may be able to configure a fixed z-offset for homing (although this makes changing it difficult). Haven't really bothered much with this.

Awesome! It works. I tested it with movments consisting of an circle (made of real arcs), a polygon and a real object so far. Thanks!

I had done the following (Info: Github instructions are sufficient):
- I followed the steps described in the first post.
  - Instead of the non-existing "marlin.pde" I changed "marlin_main.cpp".
- I downloaded the files from https://github.com/mlaws/solidoodle2-ma … ll/2/files instead of the attached ones in the first post.
- In "hysteresis.cpp" I changed "Hysteresis hysteresis( 0.0f, 0.0f, 0.0f, 0.0f );" to "Hysteresis hysteresis( DEFAULT_HYSTERESIS_MM );" to be easier to access.
- I added "M99 X0.15 Y0.15" to the top of my gcode files.

I'd like to add DEFAULT_HYSTERESIS_MM to the EEPROM, but its structure should not be touched.

The upper object is with backlash compensation.

[Edit]

I now estimated my backlash by moving the carriage repeatedly back and forth with a small delay in between by a known distance via a gcode file and observed the carriage movement by a webcam at close range. No movement is observed below 0.075mm (6 steps) and movement can be observed above 0.0875mm (7 steps). So backlash is somewhere in between. So i have set 0.075 as values for the firmware.

By printing a 100mm circle with a backlash over-compensation of 10mm it can be observed, that the marlin backlash compensation is implemented as an approximation. It is not an ideal solution but it works very well.

If I'm not mistaken an ideal implementation of backlash compensation should be implemented _after_ the marlin planner and _before_ the stepper driving because the backlash compensation should not be influenced by acceleration calculations. Ideal backlash compensation does not move the carriage, it only tensions the belt so it is load-free thus the motor can be moved instantly at a high speed. I cannot say if such an approach (after marlin planner and before stepper driving) is possible to implement in marlin.

As an experiment I implemented backlash compensation in gcode via pairs of G1 (move) and G92 (set position) in python with the following idea:
G1 X1 E1
G1 X2 E2
  G1 X1.8 ;backlash fix: move back by -0.2 with respect to current position
  G92 X2 ;backlash fix: re-set current position to 2
G1 X1 E3
However, besides some bugs (layer shifts), additional artifacts (corners) were introduced. I assume the planner decelerated before the fix and thus introduced uneven extrusion. So I think altering gcode is not an option.