Experimental firmware 0.78a-dc42

Thanks for that David,

As soon as my print has finished I'll try a new config with the M210 line commented out but I doubt that could be causing the problem.
I wonder if anybody else uses M210
Paul

---

appjaws - Core XYUV Duet Ethernet Duex5
firmware 3.1.1 Web Interface 3.1.1
Ormerod 1-converted to laser engraver, Duet wifi
OpenSCAD version 2020.07
slic3r-1.3.0, Simplify3D 4.1.2, Cura-4.4.1

Hi Paul,

I just loaded your config.g file on to my machine, leaving the homing files alone, and rebooted. Straight after reconnecting, I homed the Y axis. It worked as normal.

Is it just my Y homing file that doesn't work or you, or do you have problems with my version of homex.g as well?

---

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

Thanks for that, it can only be one of 3 files that are causing this but when you look at them in isolation everything looks OK. Could you try my setbed. please just in case..
My print hasn't finished yet so I will try your home files again in the morning.

Paul

---

appjaws - Core XYUV Duet Ethernet Duex5
firmware 3.1.1 Web Interface 3.1.1
Ormerod 1-converted to laser engraver, Duet wifi
OpenSCAD version 2020.07
slic3r-1.3.0, Simplify3D 4.1.2, Cura-4.4.1

Quote
dc42
* M208 command allows you to set axis minimum positions (e.g. a negative x-axis position) as well as maximum positions.

Quote
appjaws1
You suspected an intermittent microswitch connection, but I have checked and rechecked, the connections are tight, also I did mention that the x movement was only a few steps in the middle, it did not travel to the homing point.

Could it be that your previously existing M208 command, by not specifying the minimum positions, was confusing the firmware?

Quote
planar
Could it be that your previously existing M208 command, by not specifying the minimum positions, was confusing the firmware?

Possibly, however it shouldn't matter because the axis minima all default to zero.

---

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
planar

Could it be that your previously existing M208 command, by not specifying the minimum positions, was confusing the firmware?

I did have M208 X200 Y210 Z180 and M208 X-8 S1 in my config file, the same as dc42 but still had the problem.

Here is my config

; Configuration file for RepRap Ormerod
; RepRapPro Ltd
M111 S0 ; Debug off
M550 Pappjaws-Ormerod ; 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.14 ; IP address
M553 P255.255.255.0 ; Netmask
M554 P192.168.1.1 ; Gateway
M555 P2 ; Set output to look like Marlin
G21 ; Work in millimetres
G90 ; Send absolute corrdinates...
M83 ; ...but relative extruder moves
M208 X200 Y210 Z180 ; Set axis travel
M208 X-8 S1 ; Set axis minimum
M906 X900 Y1000 Z900 E800 ; Set motor currents (mA)
;M210 X1000 Y1500
M563 P1 D0 H1 ; Define tool 1
G10 P1 S0 R0 ; Set tool 1 operating and standby temperatures
M92 E420 ; Set extruder steps per mm
M558 P1 ; Use an unmodulated Z probe
G31 Z1.5 P500 ; Set the probe height and threshold
M557 P0 X30 Y30 ; Four...
M557 P1 X30 Y175 ; ...probe points...
M557 P2 X190 Y175 ; ...for bed...
M557 P3 X190 Y30 ; ...levelling
M556 S74.5 X-0.56 Y0.18 Z0.267 ; Put your axis compensation here
M201 X800 Y800 Z15 E1000 ; Accelerations (mm/s^2)
M203 X15000 Y15000 Z100 E3600 ; Maximum speeds (mm/min)
M566 X600 Y600 Z30 E20 ; Minimum speeds mm/minute
M140 R30 ; set bed standby temperature to 30C

The problem is very strange so I am using absolute positioning for homing now.
I'm not sure what the advantages of relative positing for homing would be.

Thank you for your interest
Paul

---

appjaws - Core XYUV Duet Ethernet Duex5
firmware 3.1.1 Web Interface 3.1.1
Ormerod 1-converted to laser engraver, Duet wifi
OpenSCAD version 2020.07
slic3r-1.3.0, Simplify3D 4.1.2, Cura-4.4.1

Quote
dc42
I'd still like to know what was the cause of your Y-homing problem, as switching to RRP's homey.g file shouldn't have made any difference. I still suspect an intermittent microswitch connection,

I got exactly the same problem today after upgrading to 0.78, and it reminded me of several months ago when my Y-axis would crash when trying to home it.

The source of the problem was the bed plane compensation. If I tried to home after setting the bed plane compensation, it would crash. I put an M561 command to reset the bed compensation before homing the axes and the problem was solved. I don't know why it came back after the update (I haven't done any bed compensation for months, I've done what's needed to get a level bed).
When I switched back to my setup.g file for homing (instead of using RRP's files) the problem disappeared again.

Maybe something fishy is happening with relative moves when the bed compensation is set.

Quote
planar
The source of the problem was the bed plane compensation. If I tried to home after setting the bed plane compensation, it would crash.

Good observation. I've just remembered that I have seen something similar. The problem occurs if the Z probe is close to the bed when you do an X or Y homing move. The bed plane compensation causes the Z axis to move a little as well. If the Z probe reading is above the threshold set by G31, this is interpreted as having reached the endstop, which ends the homing move.

The problem could also occur if you have the wrong z probe type selected when you do the X or Y homing move, for example if you have probe type 0 (the default) selected.

The workaround is to make sure the bed is high enough off the bed when doing a homing move, and to ensure that the correct z-probe type is selected before doing a homing move. The homex.g and homey.g files move the head up 5mm, but do not set the Z probe type.

Perhaps there are other situations in which a Z move is interpreted as having reached the Z endstop, when it hasn't really? I'll take another look at the code.

---

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

The workaround is to make sure the bed is high enough off the bed when doing a homing move, and to ensure that the correct z-probe type is selected before doing a homing move. The homex.g and homey.g files move the head up 5mm, but do not set the Z probe type.
.

I have just started my ormerod from cold with your home files. The first thing I did was to raise Z by 10mm and then selected setbed.

The bed flew to the right until it couldn't go any further and then went to the left but stopped short of the microswitch. Automatic bed levelling did not happen and eventually the nozzle went to X100 Y100 when the bed temperature was reached, and turned the hot end heater on and just sat there.

So I agree something is preventing automatic bed compensation from working but I don't think it is the Z height

I tried it a second time with the same results.

This is my setbed

G30 P0 X30 Y30
G30 P1 X30 Y175
G30 P2 X190 Y175
G30 P3 X190 Y30
M92 X87.5766 Y87.5766 Z4000
M556 S74.5 X-0.56 Y0.18 Z0.267
M140 S65 ; start heating the bed to 65C
M561 ; clear bed height transform
G91 ; relative positioning
G1 Z5 ; raise 5mm
G90 ; absolute positioning
G28 X0 Y0 ; home the X and Y axes
G1 Y200 F5000 ; get the head out of the way so we can clean the bed
M116 ; wait for bed temp to stabilise
M104 S195;
G32 ; execute bed plane measurement procedure
G1 X100 Y107.5; now home the Z axis at the centre of the bed
G28 Z0
G1 Z5


I don't know if this is relevant but when I copied, into the message panel, my config file in an earlier post I had empty lines between each entry. When I copied my setbed no empty lines.

I have just reverted back to reprap original and restarted and all works correctly. So still baffled.

Paul

---

appjaws - Core XYUV Duet Ethernet Duex5
firmware 3.1.1 Web Interface 3.1.1
Ormerod 1-converted to laser engraver, Duet wifi
OpenSCAD version 2020.07
slic3r-1.3.0, Simplify3D 4.1.2, Cura-4.4.1

Hi DC

Is there a file size limit on the config.g?

Lloyd

Edited 1 time(s). Last edit at 07/13/2014 08:05AM by ezwul.

Quote
ezwul
Hi DC

Is there a file size limit on the config.g?

Lloyd

No, there's no file size limit for that file. The output on the HTTP and Telnet interfaces might be truncated though, because the corresponding buffer is limited to 1000 bytes. In my latest firmware release I've increased that one to 2000 bytes and added a workaround to remove duplicate whitespaces, so RRP's default config is displayed properly.

Ok thanks, that explains why, as I remove the comments after each G-code, I see more of the file being displayed, and will not be a sympton of any of the above problems.

Quote
appjaws1
I have just started my ormerod from cold with your home files. The first thing I did was to raise Z by 10mm and then selected setbed.

The bed flew to the right until it couldn't go any further and then went to the left but stopped short of the microswitch. Automatic bed levelling did not happen and eventually the nozzle went to X100 Y100 when the bed temperature was reached, and turned the hot end heater on and just sat there.

So I agree something is preventing automatic bed compensation from working but I don't think it is the Z height

I tried it a second time with the same results.

This is my setbed
...

Paul, thanks for that, I'm seeing the same issue when I run your setbed. I'll investigate it and hopefully have a fix in my forthcoming release.

---

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 found the problem. I don't use any axis compensation, but you do. My Y homing file doesn't move the head in the X direction at all, so if X was already homed, the X endstop is active. The axis compensation means that Y movements cause small X movements, which cause the X endstop status to be monitored. This terminates the Y homing move prematurely.

The short term fix is to move the head away from the X home position during Y homing. This version of homey.g avoids the problem:

G91
G1 Z3 F200
G1 X5 F2000
G1 Y220 F2000 S1
G90
G1 Y0 F12000
G91
G1 X-5 F2000
G1 Z-3 F200
G90

Similarly, in my homeall.g file, insert G1 X5 before the G1 Y220 F2000 S1 line.

You might want to move Z up and down by 5mm instead of 3mm depending on which bed clips you use.

The longer term solution is that if a G1 S1 move requested a move along one axis only, only the endstop on that axis should be monitored. [EDIT: I have now implemented this, and I expect to release a new firmware revision later today.]

Edited 2 time(s). Last edit at 07/15/2014 05:14AM by dc42.

---

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

David,

Thank you, That worked well, I am now using your modified home files.

I still don't really understand why this method is better than the reprap original.
One thing I have noticed is that the X100 is being set at Z115, so I still have something not quite right. Is this the main reason for relative homing, so that this error can be compensated for? If so Where and What do I need to amend.

Glad you got to the bottom of this problem, thanks again

Paul

---

appjaws - Core XYUV Duet Ethernet Duex5
firmware 3.1.1 Web Interface 3.1.1
Ormerod 1-converted to laser engraver, Duet wifi
OpenSCAD version 2020.07
slic3r-1.3.0, Simplify3D 4.1.2, Cura-4.4.1

Quote
appjaws1
I still don't really understand why this method is better than the reprap original.

The are are a couple of minor issues with the reprap original:

1. If you use M208 to change the bed size, you also have to adjust the homing files if the changes M208 values affect the coordinates of the endstops; for example, if you adjust the maximum Y axis value or the minimum X axis value.

2. If the machine fails to find the endstop, it still flags the axis as having been homed.

---

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

An issue for me is that I often print things that are close to or bigger than 200mm X 200mm (Y is physically longer than 200mm and while the X bed length is 200mm, you can still print overhangs that extend over the bed edges in X) In Slic3r you can define any coordinate to be the bed centre, but in Cura the bed centre is always half the axis dimensions. When a part is very close to the physical bed/machine limits, it is important that the slicing software puts the part centre over the exact bed centre - so the homing position must be defined so that the coordinates of half the defined bed size in X and Y results in the nozzle being over the real physical centre of the bed. If you never print anything near the limits it is not so important, and you can define a bed size of 200 X 200 and have the X100, Y100 point anywhere that is reasonably close to the middle of the glass. I define my bed as being 220mm X 220mm (a bit bigger than is physically achievable), and must ideally define the home coordinates so that the physical bed centre is exactly at X110 Y110. With some of my prints part of the skirt (at 1mm distance) is sometime printed off the glass (I have to print a skirt otherwise part of the perimeter of the part is printed before the plastic starts flowing).

Dave
(#106)

Hi David,

I need help.

I leveled My bed manual (Spring screws on 3 Points) and all is in the right place. The bed is absolutely plane.

So i Homer My x,y,z Axis and do a g32 with your new diff zprobe.

If i Start a print and the nozzle moves right the x Axis ... The z Axis Love to high (1mm or more)

A raise of 0.1 is ok if the bed is Not 100% plane. But why so high???

Hi muggi, here are some suggestions:

1. Check that the coordinates you have set for the bed levelling procedure in M557 commands place the sensor head over clear areas of the bed, not too close to the corners or bed clips, and (if you are using Kapton tape) not too close to a join in the tape.

2. If you still have white or aluminium tapes on the corners of the bed, remove them.

3. Home the Z axis over the centre of the bed after you have run the G32 command, instead of (or as well as) before.

---

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

So a few quick answers:

To 1.
I use bluetape, the coordinates are line x25y25 and this for each corner

To 2. no alu or white paper Tapes in the corner

To 3. actually i home the z in the corner with the first m557 Point x25y25


Can 3. bring this problem or My bluetape?

Muggi, where exactly have you set the bed probing coordinates? There are a couple of important issues to consider:

1. Unless you are using my firmware fork, and an M208 command to set a negative axis minimum, and have modified the homing files, the edge of the bed will not be at X=0, it will be more like X=10.

2. The sensor is offset from the nozzle in the -X direction. You must choose the bed probing coordinates to place the sensor about 25x25mm in from each corner, not the nozzle.

On my Ormerod, I set the X axis minimum to -8mm, and I have modified homex.g and homeall.g so as not to redefine the X homing point as X=0. So X=0 on my machine is where the nozzle is over the edge of the bed. Then I have defined the bed probing coordinates. Like this:

M208 X214 Y210 ; set axis travel
M208 X-8 S1 ; set axis minimum
M557 P0 X35 Y20
M557 P1 X35 Y200
M557 P2 X210 Y200
M557 P3 X210 Y20

Also, when using the differential probe, I recommend that you change the Z homing coordinates to be at the centre of the bed, not at one of the corners. This is because most prints use the middle of the bed, but few use the corners; and it is not unusual to have a twist in the X axis that affects the apparent height at the centre.

Finally, it is best to run G32 and final Z homing after heating the bed to operating temperature. This is less important if you have DaveK's aluminium bed support, but very important if you are using the original MDF bed.

I hope this helps - 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].

Hi David
I have just finished updating to your firmware 078a-dc42 from 057a, and I am running through the bed setup process.
Can you post the content of the sys directory from your printer, so I can compare how you run your printer to how I was thinking of setting up my printer.

I was interested in how to move where the printer thinks the bed center is so it looks like your files might be interesting.

Thanks

Lloyd

Edited 3 time(s). Last edit at 07/15/2014 05:52PM by ezwul.

Hi Lloyd, my current firmware is 0.78c. Here is a zip of the files in my sys directory.

---

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

Thanks for the files, I noticed the heatbed turning 'on' for a short while on powerup, and was going to mention it, but as you listed in a previous post you beat me to the fix.
Looks like I will be upgrading pretty soon to get the rest of the goodies you have added, and to practice firmware upgrades.
Lloyd

Hi David,

i just tried it with your sys files and it works. thanks for sharing the files.


I didn´t use the M556 S78 X0 Y0 Z0 ; Put your axis compensation here and no axis minimum. Maybe this confused the firmware.

Edited 1 time(s). Last edit at 07/16/2014 12:04AM by muggi.

Hey.

After homing X, when I press HEAD 1 via Web interface, the X moves to 0.1.. ?

Edited 6 time(s). Last edit at 07/24/2014 06:10PM by Sardi.

Quote
Sardi
Hey.

After homing X, when I press HEAD 1 via Web interface, the X moves to 0.1.. ?

That's needed for a 2-head system. For a single-head system, you can comment out the commands in tfree1.g and tpost1.g.

---

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 have this issue as well, getting confused running from solution to solution but nothing is working... My y axis still doesn't home.

Hi Ecko,

1. What happens when you try to home your Y axis?

2. What you you have in homey.g and homeall.g?

3. Is your machine an O1 or an O2?

---

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

When I try and home y, the extruder doesn't stop moving and keeps going in one direction. (It doesn't move back and home like it did before).

I have the ormerod 1, no upgrades.

My homeg and home all are from the reprap download on GitHub for 0.78c