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.

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.

Page 3 or 4 follow instructions from user enrage.

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.

Have you followed the instructions here? And what motherboard do you have? Unfortunately there is no firmware available for the new Printrboard yet...

pcm81 wrote:

Is it possible to set default value for y-axis hysterisys, rather than feeding it to firmware via g-code?
I am guessing i'd need to change the code:

Hysteresis hysteresis( 0.0f, 0.0f, 0.0f, 0.0f );

in Hysterysis.cpp to something like:
Hysteresis hysteresis( 0.0f, 1.5f, 0.0f, 0.0f );

to add 1.5mm of y-axis hysterysis offset?

Yes that's correct.

Is there any reason why i should not do it in firmware and rely on g-code command instead?

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.

I am hesitant to just make the change in *.cpp file and try it, because i'd think default hysterysis values belong in *.h file...

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.

Thank you

Is it possible to set default value for y-axis hysterisys, rather than feeding it to firmware via g-code?
I am guessing i'd need to change the code:

Hysteresis hysteresis( 0.0f, 0.0f, 0.0f, 0.0f );

in Hysterysis.cpp to something like:
Hysteresis hysteresis( 0.0f, 1.5f, 0.0f, 0.0f );

to add 1.5mm of y-axis hysterysis offset?

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.

Hysteresis hysteresis( 0.0f, 0.0f, 0.0f, 0.0f );

in Hysterysis.cpp to something like:
Hysteresis hysteresis( 0.0f, 1.5f, 0.0f, 0.0f );

to add 1.5mm of y-axis hysterysis offset?

Is there any reason why i should not do it in firmware and rely on g-code command instead?

I am hesitant to just make the change in *.cpp file and try it, because i'd think default hysterysis values belong in *.h file...

Please advise.

Thanks ahead

The code is now (hopefully) debugged and re-added to lawsy's repository: see https://github.com/mlaws/solidoodle2-marlin/pull/2

I am beginning to believe that all of these firmware fixes are a hinderance.  I may eventually bring the firmware back to something more pure on the control side and move the corrections to the processing software.  Doing so will enable much more flexibility and be universal for all machines, rather than just the ones using this version of the firmware.

This is an interesting approach. I see things differently: the code that goes into the machine should be as machine-agnostic as possible. In my opinion it is a job for the hardware and for the firmware to reproduce this code as accurately as possible.

For example, I don't see why introducing some backlash compensation directly in the GCode would make it more universal: on the contrary, it would mean that the code will only work for the machines with exactly the same amount of backlash as the one you tailor it for. Conversely, having an ideal GCode with zero backlash, and letting the rest of the pipeline handle it makes the code much more portable.