1

Topic: Hysteresis Fix

From the Google Groups forum, a simplified set of changes if you want to add hysteresis correction to your firmware.


I could apply the hysteresis changes directly to our Solidoodle code, but then that would make updating from the main Marlin code more complicated. It's better to apply complicated changes to the main Marlin code, so that the changes naturally trickle down to our Solidoodle code. We want to keep our Solidoodle alterations to a minimum to enjoy the benefits of easy and regular updates from the main Marlin code.

So here are the changes you need to make. You can make these changes to Lawsy's Solidoodle firmware or Solidoodles v4.2 firmware. If you've already added my previous alterations, then best roll back to Lawsy's firmware and then apply these...

Step 1. Add a define to configuration.h. I added the following line after the define for DEFAULT_MAX_ACCELERATION

#define DEFAULT_HYSTERESIS_MM         0, 0, 0, 0  // X, Y, Z, E hysteresis in mm. These are the extra distances that are performed when an axis changes direction to compensate for any mechanical hysteresis your printer has.

Step 2. Add some cases to the switch statement in process_commands in Marlin.pde. Search for "case 115: // M115" and insert the following lines before that line....

  case 98: // M98
    {
      hysteresis.ReportToSerial();
    }
    break;
  case 99: // M99
    {
      if(code_seen('X')) hysteresis.SetAxis( X_AXIS, code_value() );
      if(code_seen('Y')) hysteresis.SetAxis( Y_AXIS, code_value() );
      if(code_seen('Z')) hysteresis.SetAxis( Z_AXIS, code_value() );
      if(code_seen('E')) hysteresis.SetAxis( E_AXIS, code_value() );
    }
    break;

Step 3. Insert an include in Marlin.pde. Add it near the top, after the other includes that are already there...

#include "Hysteresis.h"

Step 4. Do the same for planner.cpp. Add it near the top, after the other includes that are already there...

#include "Hysteresis.h"

Step 5. Insert a line in the plan_buffer_line function in planner.cpp. It should be the first line in the function, before "int next_buffer_head = ...."

hysteresis.InsertCorrection(x,y,z,e);

Step 6. Add the attached files (hysteresis.cpp and hysteresis.h) to the Marlin directory, the same directory that has Marlin.pde in it.


That's it. I've tried to simplify it as much as possible, the bulk of the code is in the new files and I've minimized the changes we need to make to the Marlin code while we wait for Erik to incorporate the changes directly. With the above changes made, you can now add a line like the following into you start code...

M99 X0 Y0.17 Z0 E0

This would add a 0.17mm hysteresis fix into your Y axis. Ian, be sure to change from steps to mm if you are already using the M99 command. Use M98 to see what your current hysteresis settings are. Post here if you have any problems.

Post's attachments

Hysteresis.cpp 5.94 kb, 112 downloads since 2012-10-15 

Hysteresis.h 1.38 kb, 95 downloads since 2012-10-15 

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

2

Re: Hysteresis Fix

That is a beautiful simple post and set of instructions.

I'm guessing the main Marlin github hasn't adopted your pull request?

Perhaps I can setup a branch or fork of the Solidoodle2marlin with this in it and people can download the one they want to use.

As for my maintaining I'll fetch and merge changes from the original Marlin to Solidoodle2marlin, and then fetch and merge changes into the variant.

Do you think this would be appropriate?

3

Re: Hysteresis Fix

Erik hasn't adopted it yet, I think the main problem is his printer is not working. He's aware of the request, you can see our discussion here...

https://github.com/ErikZalm/Marlin/pull/247

I'd hold out a little longer and cross your fingers, hopefully Erik will integrate it soon. If for whatever reason the pull request doesn't happen then I'd suggest simply adding my changes to the Solidoodle firmware rather than keeping two Solidoodle branches active. The default behaviour of the hysteresis fix is to do nothing, so maintaining a separate branch seems pointless. Even if we discover a problem with the change we only need to comment out the call to Hysteresis::InsertCorrection to stop using the new code. So this could be done with a #define in configuration.h if need be.

4

Re: Hysteresis Fix

I'll be adding this code to the github in the next day or so, hopefully later today.

5

Re: Hysteresis Fix

Ok the code has been added, test compiled and uploaded to my machine.

Unfortunately my dial gauge is out of action so I can't actually use the M99 command yet.

M98 correctly reports back 0 for each axis.

Neil, can you write a line each for M98 and M99 for me to add to the comments at the start of Marlin.pde?

I have started a new thread to keep track of changes to the firmware:

http://www.soliforum.com/post/2357/

6

Re: Hysteresis Fix

lawsy wrote:

Ok the code has been added, test compiled and uploaded to my machine.

Unfortunately my dial gauge is out of action so I can't actually use the M99 command yet.

M98 correctly reports back 0 for each axis.

Neil, can you write a line each for M98 and M99 for me to add to the comments at the start of Marlin.pde?

I have started a new thread to keep track of changes to the firmware:

http://www.soliforum.com/post/2357/


Great work, once again Lawsy.

Former Solidoodle employee, no longer associated with the company.

7

Re: Hysteresis Fix

I finally got around to trying this out.  I can set values and read them back with M99 and M98, but I'm not seeing any actual changes in the readings.  I calibrated my axis steps with M92 commands, then when I set an M99, it seemed to take out the axis step adjustment.   It wasn't a problem after I set the axis steps in firmware.

Setting the hysteresis in firmware didn't help either.  I could read back the value with M98, but again, no change in hysteresis.  I'm setting it by mm, ie .15 for Z.  Also using the latest download.

8

Re: Hysteresis Fix

Just wondering if anyone has done any further testing with this?

I would love to but my dial indicator has died so I'm in the dark.

9

Re: Hysteresis Fix

What is hysteresis in the context of 3D printing.
Are you talking about backlash?

hysteresis:  a retardation of an effect when the forces acting upon a body are changed

Backlash:   The play resulting from loose connections between gears or other mechanical elements.

10 (edited by cephdon 2012-11-23 21:06:35)

Re: Hysteresis Fix

I am testing this now...

I was able to set the value and read it back:

> 7:29:27 PM: N234496 M99 X0.00 Y0.00 Z0.00 E0.0000 *19
> 7:30:10 PM: N234498 M98 *2
> 7:30:10 PM: N234499 M190 S100 *120
< 7:30:10 PM: H=X0.00 Y0.00 Z0.00 E0.00

Granted, I set it to 0 so that I could see if there was any change in behavior off the bat.  However, I should be able to tell if it does what we expect in a few moments.

EDIT:
It did have an effect when I set the values to something that was not zero.  I found that the version of the firmware I had previously would crash immediately upon attempting any move.  So, I downloaded the most recent version from Lawsy again and uploaded that.  The current version does work with the settings and the settings do have an impact on position.

I had my values incorrect, so I ended up with something that didn't quite look right.  I am going on the assumption that positive values will add to the movement and negative values will subtract.  When I added a negative value to X of -0.15 I ended up with a stair step shape (where each subsequent layer was shifted to the left a small amount).

What I expected was that the sides would line up but be larger in the correct dimensions and smaller in the correct dimensions but in a consistent way.  So, if I had my numbers incorrect I would see a perfectly formed but out of dimension shape.  A 20 x 20 x 20 cube would be off by some amount which could then be improved until the exact right size was met.

Without the hysteresis fix, my sides are nearly perfectly aligned.  However, a 40 x 40 x 40 cube comes out 40.03 x 39.59 x 39.80. Close, but I would like to see if I can get it closer.

11 (edited by g00bd0g 2012-12-09 03:12:08)

Re: Hysteresis Fix

I finally managed to get the new firmware onto my machine.

When I add an "m99 y.2" to the beginning of my code my parts come out "slanted" by about that much. I though this was a backlash compensation, am I wrong, or using it in the wrong manner?

Additionally, an m98 does not return any non-zero values, but obviously something is changing because the part gets shifted, even with same gcode.

Any thoughts?

12

Re: Hysteresis Fix

@g00bd0g

i think there is a bug in the firmware for the Hysteresis. We have to wait for an update.
The printed part looks like its skipping steps if M99 is active

13

Re: Hysteresis Fix

breaker wrote:

@g00bd0g

i think there is a bug in the firmware for the Hysteresis. We have to wait for an update.
The printed part looks like its skipping steps if M99 is active

This is my experience as well. Thanks for letting me know I'm not crazy smile

14

Re: Hysteresis Fix

Hello, Noob Here.
Whats the difference between adding all those additional code to the firmware rather than changing the step values of the motor under "#define DEFAULT_AXIS_STEPS_PER_UNIT   {88,88,2268,138}" in the Configuration.h Tab? ...or am I comparing apples to oranges?

15

Re: Hysteresis Fix

The problem is that when changing directions, the first few steps result in no movement so the total move comes up short.  Neil's fix is supposed to add extra steps to compensate, but only when changing direction.  If you increase Steps/mm, every individual move along the same direction will be too long.

16

Re: Hysteresis Fix

IanJohnson wrote:

Neil's fix is supposed to add extra steps to compensate, but only when changing direction.

The only problem is that it doesn't quite work.  When I was testing this, I noticed that having anything set for hysteresis caused a diagonal shift in layers by about the amount specified.  So, if I said to shift Y by 0.1, I would get about a 0.1mm shift for each layer in Y. Almost like each layer was moved in relation to the previous layer.

3rd) shift 0.1   ------------
2nd) shift 0.1    ------------
1st)  Normal       -------------

Something like that.  I still have not had time to figure out why.  I started debugging it around the time that I started having jamming issues on my hot end.  In fact, I changed steps per mm for the extruder and hysteresis on the y axis at about that same time. After backing all the changes off, I could print again, but I could never get the steps per mm or hysteresis to work as expected.  Mostly because the of the jamming.  Once i get it to be reliable again, I will take a look at the hysteresis code and see if I can find out why it doesn't work (unless someone beats me to it).

17 (edited by MeshMoth 2012-12-27 20:01:58)

Re: Hysteresis Fix

IanJohnson wrote:

The problem is that when changing directions, the first few steps result in no movement so the total move comes up short.  Neil's fix is supposed to add extra steps to compensate, but only when changing direction.  If you increase Steps/mm, every individual move along the same direction will be too long.

So lets say I made a 100mm x 100mm square to calibrate and it's actually printing 100mm x 110mm instead, is that a hysteresis issue or an issue with the steps? It seems that all my prints are coming out wider and shorter than it's supposed to be.

18

Re: Hysteresis Fix

MeshMoth wrote:

So lets say I made a 100mm x 100mm square to calibrate and it's actually printing 100mm x 110mm instead, is that a hysteresis issue or an issue with the steps? It seems that all my prints are coming out wider and shorter than it's supposed to be.

That would be due to the step count being off. The hysteresis will tend to show up as minor shifts (ridges or bumps) in the effected axis. The Y-axis tends to be the worst for this since there are more belt / pulley interfaces to get sloppy.

it will look something like this.

     ----------
    ----------
     ----------
    ----------

19

Re: Hysteresis Fix

If your square was too long on Y, it would be steps/mm.  If it was too short, it could be backlash or steps/mm.  If it is backlash, printing a circle would show bulges at the diagonals, and fill not quite reaching perimeters in some areas.

20

Re: Hysteresis Fix

Thanks guys.

Another problem I've got is that my prints look like this:

-------------------------------
  ----------------------------
    ------------------------
  ----------------------------
-------------------------------
  ----------------------------
   ------------------------

What could be causing that?

21

Re: Hysteresis Fix

Probably z-axis wobble or backlash.

22

Re: Hysteresis Fix

MeshMoth wrote:

Thanks guys.

Another problem I've got is that my prints look like this:

-------------------------------
  ----------------------------
    ------------------------
  ----------------------------
-------------------------------
  ----------------------------
   ------------------------

What could be causing that?

Have the backlash fix?

Former Solidoodle employee, no longer associated with the company.

23

Re: Hysteresis Fix

g00bd0g wrote:

I finally managed to get the new firmware onto my machine.

When I add an "m99 y.2" to the beginning of my code my parts come out "slanted" by about that much. I though this was a backlash compensation, am I wrong, or using it in the wrong manner?

Additionally, an m98 does not return any non-zero values, but obviously something is changing because the part gets shifted, even with same gcode.

Any thoughts?


Was anyone able to fix this issue?  I have the same problem as g00bd0g in that with the hysteresis fix causes a slant to form with each layer being slightly off -- uniformly and in the same direction.  I've been through the the gamut of y-axis shift and hysteresis fixes and problems.  Belts tightening and loosening to the point of failure on both ends of the spectrum, I even replaced the y-axis motor.  My electronics are aggressively cooled (because I have a guaranteed y-axis shift if it isn't) but I just can't seem to get the SD2 to print circles that are not squished.  I know its possible, prints I have from when my solidoodle was brand new, are perfectly round. Perhaps the mechanical hysteresis is due to my belts stretching out, in which case I would hope this firmware fix could be made to compensate for this problem.

Any help would be greatly appreciated

24

Re: Hysteresis Fix

Sadly, I have not even had much time to work with my SD2 for a long while.  No chance to fix this issue yet.  If no one else  has solved it before I get the chance again, I am planning to look into it.  Just so hard to make the time lately.

To answer your question more directly, no one has discussed or posted a fix as far as I know.

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.

However, the problem is getting the time.  I saw a quote on a billboard the other day and it said "a goal without a plan is a wish."  So at the moment, I have a goal to fix it and I wish I had the time to work on it, but at the moment I don't have the ability to make a plan for when that will happen with any certainty.

25

Re: Hysteresis Fix

cephdon wrote:

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.