search

reprappro / RepRapFirmware

OO C++ RepRap Firmware
Other
143 stars 120 forks source link

Home All does not use proper X,Y coordinates to perform Proximitysensing #85

Open gratefulfrog opened 9 years ago

gratefulfrog commented 9 years ago

I have discovered that although the sequence HomeX, HomeY, HomeZ works as expected, a call to Home All, does not work the same way.

In particular, my G31 settings in the config.g file are respected by homez.g but not by homeall.g.

The issue is that homeall causes the head moves too far to the right pushing the proximity sensor beyond the white tape, causing the head to crash into the bed, catastrophically.

The workaround is to never use home all!

I would attach my config.g, homex.g homey.g, homez.g and homeall.g files, but I do not have permission. Contact me if needed. Cheers, Bob

gratefulfrog commented 9 years ago

Here is some updated information, I amnot sure where the problem lies, but I am now pretty sure that there is a problem!

I have determined that during the Home Y process, the X axis point displays are shifted by 4.36mm, but represent the same physical point!

In other words, after homing X, I move the head to X=40, according to the web interface, then measure its physical position relative to a fixed point on the x-axis smooth bars. Say this is 35mm.

Then I home Y, and according to the web interface, we are now at x=44.37, but the physical measurement still shows 35mm from the fixed point.

If I repeat the Y homing, the same point moves another 4.36mm higher on the x display!

Here are the details, all of this was run on a freshly started Huxley Duo:

  1. Restart machine completely!
  2. Home X: Head Position: (0.00, 0.00, 0.00)
  3. Move to X=40, (4x X+10) Head Position: (40.01, 0.00, 0.00)
  4. measure from fixed point on X axis: 35mm
  5. G91: no movement,no changes
  6. G1 Z5 F200: head moves up, Head Position: (40.01, 0.00, 5.00)
  7. G1 X20 F2000, head moves right, Head Position: (60.01, 0.00, 5.00)
  8. measure from fixed point on X axis: 15mm <- this seems correct!
  9. G90: no movement, no changes
  10. G1 Y-140 F2000 S1: no movement, but Head Position: (62.19, 200.06, 5.00) <- x position +2.18mm?
  11. G92 Y0: no movement, but Head Position: (62.19, 0.00, 5.00)
  12. G1 Y3 F200: bed moves forward, Head Position: (62.19, 3.00, 5.00)
  13. G1 Y-5 F200 S1:bed moves backwards, Head Position: (64.37, 200.06, 5.00) <- x position + another 2.18mm?
  14. G92 Y0: no movement, but Head Position: (64.37, 0.00, 5.00)
  15. G1 Y0 F2000: no movement, no changes
  16. measure from fixed point on X axis: 15mm <- this seems correct, still!
  17. G92 Y0: no movement, no changes
  18. G91: no movement, no changes
  19. G1 X-20 F2000: head moves left: Head Position: (44.37, 0.00, 5.00)
  20. measure from fixed point on X axis: 35mm
  21. step 18&19 values are incoherent with values in steps 2&3!!
dc42 commented 9 years ago

The shifting of X=0 after Y homing, and more particularly after Z homing, is a bug that occurs when axis compensation is enabled. I fixed it in my fork of RepRapFirmware over a year ago. To be honest, I thought it was fixed in the official 1.09 release too.

RRP-support commented 9 years ago

I've had two reports of problems with firmware v1.09c and orthogonal compensation now. I, too, thought that we had the same compensation in now as yours, dc42. It's possible that the numbers are causing an odd effect. The two settings are: M556 S49.5 X-0.54 Y-0.54 Z0 (from gratefulfrog) M556 S80 X-0.35 Y-1.25 Z-0.35 (from Stefan) Is it possible that the compensation bug was fixed for positive numbers, but not negative? And it's always the Y axis that seems to cause the problem! Ian RepRapPro tech support

gratefulfrog commented 9 years ago

I have run the same test without orthogonal compensation and the problem does not occur!

  1. M556 S100 X0 Y0 Z0
  2. home X,
  3. move X+10 4x
  4. displayed X=40.01 measured x distance from fixed point D= 67.5
  5. home y
  6. displayed X=40.01 measured x distance from fixed point D= 67.5

It would seem to be the orthogonal compensation which is broken.

Stefan3 commented 9 years ago

I figured only the X value in the M556 command affects this behaviour, but it doesn't matter whether it is positive or negative. With positive values for X, the reported X position decreases during homing of Y, with negative numbers it increases. When I keep X at 0 in the M556 command, it seems I can set Y and Z to any value without affecting the reported X position.

dc42 commented 9 years ago

The X parameter defines the coupling between X and Y so that makes sense. The other two parameters will probably affect whether X and Z homing cause shifts in the other axes.

On 2 November 2015 11:48:48 GMT+00:00, Stefan3 notifications@github.com wrote:

I figured only the X value in the M556 command affects this behaviour, but it doesn't matter whether it is positive or negative. With positive values for X, the reported X position decreases during homing of Y, with negative numbers it increases. When I keep X at 0 in the M556 command, it seems I can set Y and Z to any value without affecting the reported X position.

Reply to this email directly or view it on GitHub: https://github.com/reprappro/RepRapFirmware/issues/85#issuecomment-152996835

Sent from my Android phone with K-9 Mail. Please excuse my brevity.