Ormerod 2 bed plane compensation/G30 issue

Hi all,

I'm having an issue with the bed plane compensation macro (bed.g) on my new Ormerod 2 (v1.04 firmware). After homing the x, y and z axes I run bed.g and the x axis carriage ends up bumping and skipping against the far end of the x axis even though the coordinates specified (x=212) are well within the usual range of movement of the carriage. When I reduced the x coordinates to below 200 to stop if from hitting the axis end, I noticed that when going back to x=0 y=0 the nozzle was not over the original 0,0 point.

So I followed bed.g line by line (manually typing each command into the web interface) and it turns out that after each execution of G30 Pn Z-100000, the current x coordinate is decreased by about 5 mm and the y coordinate by 1 mm. This means that, if the first probe point is 50,5 (x,y), this becomes 45,4 after G30 P0 even though the nozzle stays at 50,5. When the head moves to the second probe point at what it thinks is 50,180, it actually probes at 55,181. G30 P1 then does its thing and decreases the current coordinates to read 45,179 (actual: 55,181). The head then moves to the third probe point at what it thinks is 212,180, but it actually is 222,182 (which is when the x carriage hits the end of the axis). G30 P2 runs and decreases the current coordinates to read 207,179 (would be 222,182 if x could move that far). The head then moves to the final probe point at what it thinks is 212,5, but it actually would be 227,8 if the head could move that far. G30 P3 S then runs and changes the coordinates to read 207,4 (actual: 227,8). So when I then return the head to what it thinks is 0,0 it stops at 20,4. Phew! Hope I explained this so it makes sense! See table below.

Command              | Reported     | Actual    | Accumulated difference
========================================================================
                     | 0,0          | 0,0       | 0,0
G1 X50 Y5 F2000      | 50,5         | 50,5      | 0,0
G30 P0 Z-100000      | 45,4         | 50,5      | 5,1
G1 X50 Y180 F2000    | 50,180       | 55,181    | 5,1
G30 P1 Z-100000      | 45,179       | 55,181    | 10,2
G1 X212 Y180 F2000   | 212,180      | 222,182   | 10,2
G30 P2 Z-100000      | 207,179      | 222,182   | 15,3
G1 X212 Y5 F2000     | 212,5        | 227,8     | 15,3
G30 P3 S Z-100000    | 207,4        | 227,8     | 20,4
G1 X0 Y0             | 0,0          | 20,4

I guess I can correct for this behaviour with the appropriate G92 command after each G30, but my question is, is it supposed to do this in the first place? Or is this a firmware issue or am I missing something else (I'm new to this)? My bed.g is below for reference.

Thanks,
Bart

M561
G1 Z10 F200
G1 X50 Y5 F2000
G30 P0 Z-100000
G1 Z10 F200
G1 X50 Y180 F2000
G30 P1 Z-100000
G1 Z10 F200
G1 X212 Y180 F2000
G30 P2 Z-100000
G1 Z10 F200
G1 X212 Y5 F2000
G30 P3 S Z-100000
G4 P1500 ; Leave the probe there to give the web interface time to report the plane points
G1 Z10 F200

Edited 2 time(s). Last edit at 04/18/2015 06:06PM by bartdietrich.

Hi Bart

Sorry you're having problems with the G32 bed compensation. First off, it's probably best to report problems in the Ormerod forum; most Ormerod owners (and other people running Duet boards) tend to use that forum, and you're more like to get a reply here: [forums.reprap.org]

Do you have any bed or orthogonal compensation already applied? ie, is this after running G32 for the first time after a reset (rather than repeatedly) and have you set values for orthogonal compensation in config.g ( M556 S[sss] X[xxx] Y[yyy] Z[zzz] )? If so, what values do you have for M556?

I think this is probably being caused by incorrect numbers in M556, which is applied in config.g at startup. Can you try running G32 with no Orthogonal compensation (ie, set M556 to M556 S100 X0 Y0 Z0 in config.g)?

Ian
RepRapPro tech support

Hi Bart,

It is a firmware issue, and as Ian says, it is triggered by orthogonal axis compensation. The problem is that in the standard firmware, orthogonal axis compensation is applied to the maximum possible height of each Z probing (which AFAIR is 1.1 times the Z axis height) instead of to the amount that the head actually moves. So instead of getting about 5mm worth of axis compensation, you get 220mm worth, resulting in a shift of XY position every time you probe. This issue is fixed in my firmware fork. I thought RepRapPro might have fixed it in their 1.04 release, but from your description, it sounds like as though they haven't.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

As dc42 points out, it's a bug in the firmware. I, too, thought it had been fixed (another bug had been), but evidently not. My workaround should also work.

We've fixed it in the firmware version, v1.09, that's currently in the test branch, and being tested! Should be released early next week.

Ian
RepRapPro tech support

Edited 1 time(s). Last edit at 04/23/2015 10:40AM by droftarts.

Thanks everyone for your replies!

I typed the following reply to Ian before I had seen all the others, so I'll just post it here anyway. Thank you everyone for your time!


====================================================================================================

Hi Ian,

Thanks for your reply. I’m copying this into the forum thread too.

You were right, when I reset all M556 parameters to default (M556 S79 X0 Y0 Z0), the weird behaviour stopped and returned when I put my values back in. The “incorrect” values in my config.g were S79.1 X-0.11 Y0.17 Z0.80, although those were the values that I calculated after printing and measuring the xyz test axes as described in the instructions.

I’m unsure why G32 (or the series of G30 commands in my bed.g) would cause such a large correction to my axes to be applied considering that I’ve done the manual bed levelling pretty well: no matter where I position the head over the bed, when I set Z to 0, the nozzle just touches the bed. After running bed.g this is no longer the case. Inaccuracies in the readings reported by the IR probe maybe? (I did calibrate it around its 600 reading as per instructions) I suppose if everything fails I could just not bother with ever running bed.g as my bed is pretty level anyway. In the meantime, I’ll redo all calibration steps from the beginning and see if that helps.

Thanks for your help!
Bart

My config.g for reference:

; Configuration file for RepRap Ormerod 2
; RepRapPro Ltd
;
; Copy this file to config.g if you have an Ormerod 2
; If you are updating a config.g that you already have you
; may wish to go through it and this file checking what you
; want to keep from your old file.
; 
M111 S0                             ; Debug off
M550 PMy RepRapPro Ormerod 2        ; Machine name (can be anything you like)
M551 Preprap                        ; Machine password (currently not used)
M540 P0xBE:0xEF:0xDE:0xAD:0xFE:0xED ; MAC Address
M552 P192.168.1.80                  ; IP address
M553 P255.255.255.0                 ; Netmask
M554 P192.168.1.254                 ; Gateway
M555 P2                             ; Set output to look like Marlin
G21                                 ; Work in millimetres
G90                                 ; Send absolute corrdinates...
M83                                 ; ...but relative extruder moves
M906 X800 Y1000 Z800 E800           ; Set motor currents (mA)
M305 P0 R4700                       ; Set the heated bed thermistor series resistor to 4K7
M305 P1 R4700                       ; Set the hot end thermistor series resistor to 4K7
M569 P0 S0                          ; Reverse the X motor
M92 E429                            ; Set extruder steps per mm
M558 P2                             ; Use a modulated Z probe
G31 Z3.2 P595                       ; Set the probe height and threshold
M556 S79 X0 Y0 Z0       ; Put your axis compensation here
M201 X500 Y500 Z15 E500             ; Accelerations (mm/s^2)
M203 X15000 Y15000 Z100 E3600       ; Maximum speeds (mm/min)
M566 X200 Y200 Z30 E20              ; Minimum speeds mm/minute
M563 P0 D0 H1                       ; Define tool 0
G10 P0 S-273 R-273                  ; Set tool 0 operating and standby temperatures
;M563 P1 D1 H2                      ; Define tool 1 Uncomment if you have a dual colour upgrade
;G10 P1 X19 S-273 R-273             ; Set tool 1 operating and standby temperatures
;Uncomment if you have a dual colour upgrade

Given that the new firmware with this bug fixed (1.09) will be released early next week, should I just wait until then before redoing all calibration steps? Is switching to dc42's firmware considered cheating on RepRap and result in Ian no longer talking to me? :-)

In the meantime, if I want to try printing stuff, the printer seems to work well enough without ever running bed.g.

Thanks,
Bart

Quote
bartdietrich
Given that the new firmware with this bug fixed (1.09) will be released early next week, should I just wait until then before redoing all calibration steps? Is switching to dc42's firmware considered cheating on RepRap and result in Ian no longer talking to me? :-)

In the meantime, if I want to try printing stuff, the printer seems to work well enough without ever running bed.g.

Thanks,
Bart

You will find discussions of my firmware fork (and zpl's) over on the Ormerod forum. To get an idea of the differences in my fork, take a look at [github.com], although that's a little out of date because RRP has fixed some issues in 1.04.

Obviously you can't expect Ian to offer support for firmware issues if you are not using the official firmware; but you should find all the firmware support you need on the forum.

Printing without bed compensation is good if you can achieve it. I only use bed compensation for large prints.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Was this problem fixed with version 1.09 firmware? I am running version 1.09 on my ormerod 1
My problem sounds similar to the one described above, though I haven't analyzed it as closely as Bart.
My first attempt at printing the 200 x 200 orthogonal test piece on my Ormerod 1 was a moderate success. I then measured the angles as instructed and then modified the M556 command in config.g to read:
M556 S81.5 X0.5 Y0.4 Z0
My two subsequent attempts at printing the testpiece have failed - the first time with the bed crashing against the Y endstop causing the subsequent printing to be shifted by a few millimetres; the second time the nozzle crashed into the bed clip (swiss style) at the X0 Y0 corner sending the clip flying and the nozzle to then crash into the test piece knocking it off the bed!! On each occasion I Homed X Y and Z and performed the Auto bed compensation.
Before seeing this thread I thought it might be backlash in the Y drive belt so tightened the belt up and tightened all the screws.
I am rather concerned that during the printing the bed is sent carreering at a very high speed between X=0 (or less) and X=200 (or more)!
Can anyone help?

Peter