Z-Axis Sensor strange beahviour

Hi,

I just got my Ormerod and it is working rather fine. The only thing that keeps bugging me is the Z-Axis Sensor. To avoid any additional IR-Light I put the Ormerod in a light proof case. The case inside is illuminated with cold white LEDs so no IR lighting there. When I now manually try to find the Z homing point and I follow the steps in the assembly instructions for axis compensation I get significant different readings depending on comming from a higher value or a lower value, i.e. going up from Z=0 to a point where the sensor value is ~650 or coming down from a greater Z value.

Do you guys have any idea why this is happening? In theory the Sensor should have the same reading no matter from which direction it is brought to the homing point.

Another thing is, that the Sensor has different readings for the other three bed leveling points. I checked, that the sensor is indeed looking down onto the paper under the kapton tape and that there is enough paper surrounding the spot.

Cheers, DasBasti

It sounds to me that you have backlash in your Z drive. This is most likely caused either by the Z nut rotating in the Z nut trap, or by backlash in the Z gears. Also, lubricate the Z threaded rod with light machine oil.

A small amount of backlash doesn't matter, but you ought to reduce it to less than 0.05mm.

Also, bear in mind that when you home the Z axis, it will overshoot slightly, so the Z motor will stop at a point that gives a z probe reading a little higher than the target value. My firmware fork reduces this by slowing down the homing speed when the Z probe reading is approaching the target value.

---

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].

I tried to install your firmware fork but it does not work. I can start the printer, connect via webinterface and can start homing the axes. After the homing cycle the axes are stoll marked as not homed. I changed the content of the sd card to what is in your repository.

The leveling now works OK but I want to have it more reliable because now I have to get the paper out to do a test of the homing and modifying the values every time I start the omerod up

Hi DasBasti,

1. Which version of my firmware fork are you running? The version I recommend is 0.78r-dc42 available via [github.com].

2. You need to be using my version of the web interface, available at [github.com]. I think you may be using RRP's version, which would account for the axes not being shown as homed.

3. Can you confirm that you have an Ormerod 1, not an Ormerod 2? The homing files will need changing for Ormerod 2.

David

---

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].

Quote
dc42
1. Which version of my firmware fork are you running? The version I recommend is 0.78r-dc42 available via [github.com].

I got the master tree. will test with dev tree later today.

Quote
dc42
2. You need to be using my version of the web interface, available at [github.com]. I think you may be using RRP's version, which would account for the axes not being shown as homed.

I got your Webinterface also for master tree. I just copied the contents of SD-image as I did with original Ormerod firmware from RepRapPro

Quote
dc42
3. Can you confirm that you have an Ormerod 1, not an Ormerod 2? The homing files will need changing for Ormerod 2.

I have indeed Ormerod 1 with the square MDF Y-Plate and the ribbon Heatbed cable. External ATX power etc.

Hi DasBasti, I don't keep the web files up to date in the SD Image directory of my RepRapFirmware repository. Get them from my Ormerod Web Control repository instead.

---

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].

Hi dc42 I gave your Firmware (RepRapFirmware-078r-dc42.bin) another try and this is what I found:

• The X axis motor turns the other way than with original firmware -> turned the connector around
• The homing does not mark the axis as homed in the web interface. RepRapFirmware-078s-alpha-dc42.bin does this though

With 78s-alpha it felt like the y and x axis are driven more than needed. I had problems with my old bed leveling points as they are now outside of the printing area. I just ran some tests and I think now the problem is that Code G32 is started in relative mode. That would make sense to me since ist moves right after i did a z homing an the z homing coordinate is the same as the first bed leveling point. I looked into the .g files in the sys folder but could not find a reason why that might be. Is it hard coded?

Hi DasBasti, if you copied my config.g file from the SD Image/sys directory to your system, then you may need to adjust the two M208 commands in it to suit your machine. These define the axis limits. In particular, I set the X asis minimum to be negative so that X=0 is the edge of the bed. If you stick with this then you will have to adjust at least the X coordinated of your bed probe points. You can revert to your original config.g and homing files if you wish.

See [miscsolutions.wordpress.com] for some tips on using my firmware fork.

---

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].

another thing is that when is home x and y axis and move to a specific point. i.e. the z homing point G1 X65 Y8.

I do a z homing afterwards and move to the same point (G1 X65 Y8) the head actually moves a couple of millimeters in x and y direction. what is happening during z homing?

homez.g:
G91
G1 Z3 F200
G90
G1 X65 Y8 F12000
G30

EDIT: This are the values after Z homing: X60.77 Y4.79 Z2.29

Edited 1 time(s). Last edit at 09/25/2014 06:27PM by DasBasti.

DasBasti, that is caused by a long standing bug in all versions of the firmware. It only happens when axis compensation is used. I plan to fix this in my fork very soon.

---

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].

Can I check if I have the same issue here, or need to report it....

Basically without any axis compensation it all works fine, I printed out the compensation parts and followed the instructions, can came up with the following adjustments to make.

M556 S74.5 X-0.5 Y-0.5 Z1.125

(The distance is shortened from 78mm as it was measured shorter - that's not some typo or fudge).

However, with these updates in config.g, the axis homing works fine but when I start a print job from SD, the Z axis just runs upwards infinitum, locking itself against the top of the vertical extrustion eventually.

I double-checked but still the same, so I went back to the default values with no axis compensation and it works fine again.

Is this related to the same bug mentioned above?

Cheers,
Dan

Have a look what happens to your X and Y coordinates after you did the z homing. If they change without actually changing the positions of the printhead this might be the problem.

For now I will try to align the X and Y axis as good as I can get it. Maybe I have time to look at the code for the compensation part this weekend.

Quote
DasBasti
another thing is that when is home x and y axis and move to a specific point. i.e. the z homing point G1 X65 Y8.

I do a z homing afterwards and move to the same point (G1 X65 Y8) the head actually moves a couple of millimeters in x and y direction. what is happening during z homing?

This is now fixed in firmware 0.78t-dc42. See the separate thread I have started for that firmware.

---

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].