Duet Electronics - Commissioning hardware and troubleshooting Firmware

Quote
dc42
If you want to do manual calibration, start by measuring all three heights just in front of the towers, and adjust the M666 parameters to make them all equal. Then measure the height at the bed centre, and adjust the delta radius by about 2.2 times the difference in height at the centre compared to the height by the towers. When you have all 4 heights equal, adjust the homed height to get Z=0 right on the bed.

Well this is exactly what I was trying to do.
I started with with the X-tower (left front) sent the effector in front of the tower, did a paper test, couldn't reach the paper (the firmware allows only Z-0.5 I assume) and knowing I have at the center about 1mm headroom I sent a "M666 X-1.00 Y0.00 Z0.00", homed and redid the the papertest but there was no change in the height at the X-tower, still couldn't reach the paper.

After I had done that I tried what I described in the post above.

There is something very strange happening here.

I have done a manual calibration with Marlin a number of times and the printer have never behaved like this.

I just moved my numbers from Marlin to the duet so they should be fairly close to reality, I bring the effector down at the Y-tower, about 2mm over the bed, and then make a move over to Z-tower also at 2mm over the bed, and then a move to the X-tower, 2mm over the bed, forr all these commands I have set up buttons in pronterface.
I then go back to Y-tower going down the last 2mm to Z=0 (in reality it is not quite 0, the nozzle never touches the bed) then I try to move to the Z-tower using the button so it should end up 2mm over the bed but here the effector no longer moves in a straight line....
Furthermore when I press the button to go to X-tower the effector raises significantly over the bed, way more than the 2mm that it should be.

What is going on...?

The commands used for the travel is:
G0 F6000 X0 Y90 Z2 Z-tower
G0 F6000 X77.94 Y-45 Z2 Y-tower
G0 F6000 X-77.94 Y-45 Z2 X-tower

I made a video of if:
[youtu.be]

EDIT: Another thing I have noticed is that if I put F6000 in homedelta.g it only moves about half that speed vs if I issue the same command in pronterface
Is that because of the "relative positioning"?

EDIT2: I've been at it for hours now and seems impossible to do a manual calibration on the duet with a delta....
With Marlin I just followed this video and I've done it several times with good reults, I used the same method with the duet with no luck.
I finally reached the paper at the X-tower with a setting of "M666 X4.00" + pushing 8 times on the -0.1 in pronterface witch is the absolute wrong way, my bed is slightly below Z=0 at the X-tower when starting out with M666 X0.00, certainly not 4mm below and wouldn't M666 X4.00 send the endstop in the other direction?

Anyone who have managed to do a manual calibration of a delta with a duet?

Edited 3 time(s). Last edit at 08/15/2015 11:36AM by Koenig.

Hi,

1. By default the firmware doesn't allow you to move below Z=-0.5 on a delta, but you can override that by sending M564 S0.

2. I assume from the values you are using that your printable bed radius is 90mm. Have you entered this in the B parameter in the M665 command? Otherwise you will be limited to moves no further than the value of the B parameter from the centre - again, unless you send M564 S0 to override that.

2. F6000 should work the same in homedelta.g as in Pronterface. If you are certain there is a difference, I'll test it on my delta.

3. If you want to do manual calibration, I suggest you follow the procedure I describe at [miscsolutions.wordpress.com]. I don't know how the M666 parameters work in Marlin, or whether a negative sign means the endstop is too high or too low. I believe they all have to be negative in Marlin, whereas in RepRapFirmware they can be negative or positive. The autocalibration function normalises them so that they average 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
dc42
Hi,

1. By default the firmware doesn't allow you to move below Z=-0.5 on a delta, but you can override that by sending M564 S0.

Thank you was searching for which command it was that removed the constraints

Quote
dc42
2. I assume from the values you are using that your printable bed radius is 90mm. Have you entered this in the B parameter in the M665 command? Otherwise you will be limited to moves no further than the value of the B parameter from the centre - again, unless you send M564 S0 to override that.

My radius is 105 (actually 110 but then the effector could hit one of my clamps) and that is entered in the M665 command

Quote
dc42
2. F6000 should work the same in homedelta.g as in Pronterface. If you are certain there is a difference, I'll test it on my delta.

Definitely different, timed the effector going down ("G0 X0 Y0 Z5 F6000") to 4.7s using a stopwatch and then going up again issuing G28 (line from homedelta: "G1 S1 X600 Y600 Z600 F6000") and that time was about 9s

Quote
dc42
3. If you want to do manual calibration, I suggest you follow the procedure I describe at [miscsolutions.wordpress.com]. I don't know how the M666 parameters work in Marlin, or whether a negative sign means the endstop is too high or too low. I believe they all have to be negative in Marlin, whereas in RepRapFirmware they can be negative or positive. The autocalibration function normalises them so that they average zero.

Yes but something is definitely off with it.
If I start out with M666 X-0.00 and put the effector at Z=0 at the X-tower I have ~1mm left until the nozzle hit the bed, okej testing with the constraints off M114 reports "X:-77.94 Y:-45.00 Z:-1.10 E0:0.0 E1:0.0 E2:0.0 E3:0.0 E4:0.0" when I hit the paper.
So now I would send "M666 X-1.10" right?

Well OK, did that and homed it and tried again, this time it touches the paper at "X:-77.94 Y:-45.00 Z:-1.30 E0:0.0 E1:0.0 E2:0.0 E3:0.0 E4:0.0"

So I have checked for loose pulleys and endstops but they were all tight and snug.

So the thing left that comes to my mind is that the M666 command is not working quite right....

EDIT: I'm using your firmware 1.09e.

Edited 1 time(s). Last edit at 08/15/2015 12:41PM by Koenig.

1. I think I have worked out why the movement during the combined XYZ homing move is slower. It's by a factor of sqrt(3) if I am correct. I'll log this as a bug and fix it in the next release.

2. I think your M666 corrections have the wrong sign. At the X tower, the nozzle is 1.3mm too high compared to the Z tower, therefore you need M666 X1.3 Z0 to tell the firmware that the X endstop is 1.3mm too high.

---

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
2. I think your M666 corrections have the wrong sign. At the X tower, the nozzle is 1.3mm too high compared to the Z tower, therefore you need M666 X1.3 Z0 to tell the firmware that the X endstop is 1.3mm too high.

I'm assuming that you mean that it is 1.1mm to high as that was the initial measurement when the endstop correction was at "X0.00 Y0.00 Z0.00" it didn't become 1.3mm to until I had issued the "M666 X-1.10 Y0.00 Z0.00"

Either way I will redo the test changing the M666 command to "M666 X1.10 Y0.00 Z0.00"

Redid the initial test first just to confirm that Z is at -1.10 when it bites the paper when all the endstops are at 0 - confirmed
Sending new endstop correction - "M666 X1.10 Y0.00 Z0.00" and does the papertest again.
M114 reports: "X:-77.94 Y:-45.00 Z:-0.80 E0:0.0 E1:0.0 E2:0.0 E3:0.0 E4:0.0"

Just for the sake of it I'll send this endstop correction and see where we land: "M666 X5.00 Y0.00 Z0.00"

And with that done and a new papertest the M114 reports: "X:-77.94 Y:-45.00 Z:-0.20 E0:0.0 E1:0.0 E2:0.0 E3:0.0 E4:0.0"
Still 0.2mm from where I would like to be....

Given these readings I'd say that the endstop correction is off by a factor of 5 in the firmware.

Hi Koenig,

1. I've just looked at your video, and I find it puzzling. Are you sure that the only thing you did when you lowered the nozzle at the Y point was to send regular G0 or G1 commands?

2. I agree that it looks strange that you ended up making a correction about 4.5 times the initial height error, but unless the diagonal rods are completely vertical when the head is in front of a tower (which is never the case), the endstop corrections have a lesser effect than you might think. Also the endstop corrections indirectly affect the homed height calculation. Please can you try doing the calibration exactly as I describe in my blog (apart from adjusting the coordinates to be appropriate for your machine) and see what results you get and how they converge. If you are still getting poor convergence, I'll try following that procedure on my delta.

---

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 a newbie in delta terms I find it very difficult to follow some of the advices written here or in the g-code wiki. I often get confused by naming the towers "XYZ" ( often the g-code parameters are called XYZ ) and sometimes XY coordinates refer to the position of the nozzle and z refers to the height of it.

I know, the towers are named after the driver-position on a Ramps board, but I would like to see the towers named ABC to have a clear definition of what´s what....
-Olaf

Edited 2 time(s). Last edit at 08/16/2015 02:06AM by o_lampe.

Quote
dc42
Hi Koenig,

1. I've just looked at your video, and I find it puzzling. Are you sure that the only thing you did when you lowered the nozzle at the Y point was to send regular G0 or G1 commands?

I can't really answer that, what I can say is that I used the commands I've written earlier for the travel between the towers and when I went down the last 2mm at the Y-tower I used Pronterface's -1 button one time and the -0.1 button ten times (pronterface does not output what gcode is sent when using these buttons)

Quote
dc42
2. I agree that it looks strange that you ended up making a correction about 4.5 times the initial height error, but unless the diagonal rods are completely vertical when the head is in front of a tower (which is never the case), the endstop corrections have a lesser effect than you might think. Also the endstop corrections indirectly affect the homed height calculation. Please can you try doing the calibration exactly as I describe in my blog (apart from adjusting the coordinates to be appropriate for your machine) and see what results you get and how they converge. If you are still getting poor convergence, I'll try following that procedure on my delta.

The rods are almost vertical but lets put that aside.
These setting were the ones I used in Marlin "M666 X-0.90 Y-1.22 Z-0.90", in this case I had the homed height set so that when M666 is set to 0 (all axes) Z=0 is actually ~1mm above the bed in the middle (in marlin if you set "M666 X-1.0 Y-1.0 Z-1.0" you actually move the homed height down by 1mm)

I'll try the way in your blog and report back!

Koenig, I'm thinking that the effect you posted in the video is maybe what's causing the M666 corrections not to behave as expected. I think we need to get to the bottom of that.

Can you attach your config.g file to a post?

---

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
Koenig, I'm thinking that the effect you posted in the video is maybe what's causing the M666 corrections not to behave as expected. I think we need to get to the bottom of that.

Can you attach your config.g file to a post?

Your way of calibrating worked like a charm!

But the phenomenon I showed in my video persists even if I use the buttons in the web-interface.

I did macros of the code for the movement between the towers and to reach the center:

Quote
X-tower
G0 F6000 X-77.94 Y-45 Z2

Quote
Y-tower
G0 F6000 X77.94 Y-45 Z2

Quote
Z-tower
G0 F6000 X0 Y90 Z2

I also made two other macros for getting down without having to go into settings in-between just to change "Use half Z steps"

Quote
Down 0.05
G91
G1 Z-0.05
G90

Quote
Down 0.02
G91
G1 Z-0.02
G90

I use 16 teeth pulleys so I was hoping that the resolution should be enough to actually go down an actual 0.01 (2 microsteps) but I found that to be a little sketchy, but I managed to get consistent results to within just a little below 0.05, I think more like 0.04.
I think maybe with these motors you can't come closer than 8 microsteps.
Anyway...

When I push the buttons for my macros the effector travels fine between all three towers, but if I stop at one tower and use the web-interface buttons to go down to Z=0 and then travel to the next tower that behaviour I showed in my video is repeated.

Edited 1 time(s). Last edit at 08/16/2015 05:20AM by Koenig.

Quote
Koenig

Quote
dc42
Koenig, I'm thinking that the effect you posted in the video is maybe what's causing the M666 corrections not to behave as expected. I think we need to get to the bottom of that.

Can you attach your config.g file to a post?

Your way of calibrating worked like a charm!

But the phenomenon I showed in my video persists even if I use the buttons in the web-interface.

I did macros of the code for the movement between the towers and to reach the center:

Quote
X-tower
G0 F6000 X-77.94 Y-45 Z2

Quote
Y-tower
G0 F6000 X77.94 Y-45 Z2

Quote
Z-tower
G0 F6000 X0 Y90 Z2

I also made two other macros for getting down without having to go into settings in-between just to change "Use half Z steps"

Quote
Down 0.05
G91
G1 Z-0.05
G90

Quote
Down 0.02
G91
G1 Z-0.02
G90

I use 16 teeth pulleys so I was hoping that the resolution should be enough to actually go down an actual 0.01 (2 microsteps) but I found that to be a little sketchy, but I managed to get consistent results to within just a little below 0.05, I think more like 0.04.
I think maybe with these motors you can't come closer than 8 microsteps.
Anyway...

When I push the buttons for my macros the effector travels fine between all three towers, but if I stop at one tower and use the web-interface buttons to go down to Z=0 and then travel to the next tower that behaviour I showed in my video is repeated.

EDIT: Before you find it for your self I have corrected the Y0.0.2....

Attached the macros for the travels between the towers.

As long as you keep the travels to the same plane the printer behaves as expected but if you stop at one tower and go down (perhaps up as well, didn't try) and then try to travel to another tower the printer behaves as in the video.

EDIT2: For some reason Simplify3D wont connect to the duet....

Pronterface does it without problem on COM6 @ 115200 bits/sec but Simplify3D won't connect with those settings.

Edited 1 time(s). Last edit at 08/16/2015 07:35AM by Koenig.

I'm glad the calibration worked. Are the final M666 and M665 values close to the ones you had when using Marlin?

Just to be clear about the other problem:

1. You have set up the 3 macros using the gcode you describe, to go between the towers, stopping at height 2mm each time.

2. You have calibrated the printer and put the M665 and M666 values in config.g.

3. You press one of those 3 macro buttons in the web interface, then drop the nozzle to Z=0 using the web movement buttons. Then you press another one of the buttons to move to a different tower.

4. The problem is that the nozzle doesn't end up 2mm above the bed at the other tower, it ends up higher than that. Correct? EDIT: I have just reproduced this, looks like sometimes the nozzle ends up at about 4mm height instead of 2mm. I am investigating.

I don't have Simplify3D, so I don't know what it is sending and what response it expects. Try putting a T0 command at the end of config.g, if you don't already have one there.

Edited 2 time(s). Last edit at 08/16/2015 10:24AM 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].

Quote
dc42
I'm glad the calibration worked. Are the final M666 and M665 values close to the ones you had when using Marlin?

Sort of, if you think of that you would have to add the missing mm in homed height and invert the endstop correction values.

Marlin:
Delta radius: 121 (well that's what was left after subtracting effector offset and carriage offset)
homed height: 462.8
endstop adjustments: M666 X-0.90 Y-1.22 Z-0.90

Your firmware:
Delta radius: 121
homed height: 463.75
endstop adjustments: X-0.06 Y0.2 Z-0.10

Quote
dc42
Just to be clear about the other problem:

1. You have set up the 3 macros using the gcode you describe, to go between the towers, stopping at height 2mm each time.

2. You have calibrated the printer and put the M665 and M666 values in config.g.

6 macros 3 on 2mm height and 3 on 0.1mm height (it was only 3 from the beginning and then using the buttons in the web interface to go down, but it is just as reproducible with these 6 macros and quicker)
The printer is calibrated.

Quote
dc42
3. You press one of those 3 macro buttons in the web interface, then drop the nozzle to Z=0 using the web movement buttons. Then you press another one of the buttons to move to a different tower.

4. The problem is that the nozzle doesn't end up 2mm above the bed at the other tower, it ends up higher than that. Correct?

Correct, except you don't actually have to go all the way down to Z=0

Quote
dc42
I don't have Simplify3D, so I don't know what it is sending and what response it expects. Try putting a T0 command at the end of config.g, if you don't already have one there.

I have T0 there.

I don't really have a clue as to what Simplify3D expects to get back from the printer when connecting.
this is the only thing from the log I could find:

Quote
Simplify3D
Attempting connection at \\.\COM6...
Testing plaintext communication protocol...
Testing binary communication protocol...
Testing alternate communication protocols...
Attempting RTS reset and trying again...
Connection failed.

EDIT: Was too slow you had already reproduced the behaviour.

Solved the Simplify3D issue as well.
I had to turn on "Hardware flow control" in S3D, found under "Tools>Firmware Configuration" and then the communications tab.

Edited 1 time(s). Last edit at 08/16/2015 11:07AM by Koenig.

@ dc42:

I asked you earlier in this thread if there were some delta specific calibration for dimensional inaccuracies in your firmware and you referred me to [reprap.org]
All I could find on that page was a correction of the angles between the towers, that doesn't really correct what I was after.

When I used Marlin I could add these lines:

Quote
Configuration.h
// Tower position correction
#define DELTA_TOWER1_CORRECTION 0.0 // front left tower
#define DELTA_TOWER2_CORRECTION 0.0 // front right tower
#define DELTA_TOWER3_CORRECTION 0.0 // back middle tower

Quote
maril._main.cpp
// Effective X/Y positions of the three vertical towers.
#define SIN_60 0.8660254037844386
#define COS_60 0.5
#define DELTA_TOWER1_X -SIN_60*(DELTA_RADIUS + DELTA_TOWER1_CORRECTION) // front left tower
#define DELTA_TOWER1_Y -COS_60*(DELTA_RADIUS + DELTA_TOWER1_CORRECTION)
#define DELTA_TOWER2_X SIN_60*(DELTA_RADIUS + DELTA_TOWER2_CORRECTION) // front right tower
#define DELTA_TOWER2_Y -COS_60*(DELTA_RADIUS + DELTA_TOWER2_CORRECTION)
#define DELTA_TOWER3_X 0.0 // back middle tower
#define DELTA_TOWER3_Y DELTA_RADIUS + DELTA_TOWER3_CORRECTION

It solves some dimensional inaccuracies that may come of that the towers or the carriages might have slightly diffrencies.
Say if I print a line that begins at the far edge of the buildplate at my X-tower and then runs through the middle, then that line comes out about 0.1-0.2mm longer than if I were to do the same at the other towers.

Is there a command to input such corrections in your firmware?

Here's a link to where I found those lines of code: [delta-calibration.s3-website-us-west-2.amazonaws.com]

Edited 1 time(s). Last edit at 08/16/2015 01:37PM by Koenig.

I'm glad you solved the S3D problem. I've found the immediate cause of the other problem: if I enable Move module debug by sending M111 S1 P4, then it shows me that moves are being aborted due to problems with the calculated step interval timing for certain moves with a large XY component and a small Z component. I expect to have a fix 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].

Quote
dc42
It's fairly common for the temperature to read low at room temperature when using a Duet with 1K resistors, because of the offset in the ADC on the SAM3X chip. That's why I added the M305 H parameter Try H30, and adjust up or down until you get the about the right reading at room temperature. Leave the L value at zero.

I found the datasheet for the B57560G104F here [www.farnell.com]. The quoted B value is 4036, but that's from 25C ro 100C. Looking at the temperature tables, a more accurate value over 25C to 220C is 4190. I choose 220C because that's close to PLA and ABS printing temperatures.

Ok so I've done some testprints and the temp seems to be a about 10 degrees off, at least between 200 - 220, seems that it now reads 10 degrees lower than what it used to with Marlin.
The filament I'm using has a working temperature between 215-235 degrees and earlier with Marlin my extruder started skipping steps @215 degrees, now it starts skipping steps @ 205 degrees.

I think that the datasheet you found belongs to a thermistor that is deemed to be obsolete according to the wiki

I found another datasheet to a more likely one, 8304 but I'm uncertain as to how to obtained the beta value before.

Would you think that that thermistor and another beta value (fitting to that one) would account for the 10 degree difference?

Sorry for asking again but is there a similar calibration function for deltas in your firmware as the one I described in the post above?

Quote
Koenig
I think that the datasheet you found belongs to a thermistor that is deemed to be obsolete according to the wiki

I found another datasheet to a more likely one, 8304 but I'm uncertain as to how to obtained the beta value before.

Would you think that that thermistor and another beta value (fitting to that one) would account for the 10 degree difference?

The resistance of that thermistor is 379 ohms @ 220C according to the table in the datasheet. I've plugged that value into my spreadsheet, and a B value of 4204 gives the best accuracy at 220C. The change in temperature reading from using a B value of 4190 is only 1.1C. If you want to check the reading, you could connect a 390 ohm resistor in place of the thermistor, which should give you a reading close to 219.4C.

Quote
Koenig
Sorry for asking again but is there a similar calibration function for deltas in your firmware as the one I described in the post above?

Yes. Firmware 1.09d-dc42 and later provides for X and Y tower position corrections in the M665 command. Firmware 1.09e-dc42 also allows a Z tower position correction, so that you can rotate the whole machine axis if you need to (I added this to better support "square" deltas"). See [reprap.org]. The simplest way of establishing the correct X and Y tower corrections is to run 6-factor auto calibration, if you have a good Z probe.

---

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
Yes. Firmware 1.09d-dc42 and later provides for X and Y tower position corrections in the M665 command. Firmware 1.09e-dc42 also allows a Z tower position correction, so that you can rotate the whole machine axis if you need to (I added this to better support "square" deltas"). See [reprap.org]. The simplest way of establishing the correct X and Y tower corrections is to run 6-factor auto calibration, if you have a good Z probe.

That function of rotating the towers is not similar to the correction I described in the previous post.

Even if your rods are even and the angle of the tower is a perfect 120 degrees in correlation to the center, one or more more of the towers might not have the exact same distance to the center, say there is a small bump in the carriage, for us who is using rails, that makes that towers offset towards the middle slighly different from the others and thus affects the dimensions of the prints, as the radius of the towers does not converge exactly where they are expected to.
Something that affects both those with rails and not is if on of the horizontal extrusions happens to be few tenths of a mm longer than the others, that way one tower will end up slightly closer to center than the others.

So giving each tower an individual radius with a "correction value" can take care of such errors, I suppose with printed corners these errors are quite common.

Take a quick look at point 4 on this page

Edited 2 time(s). Last edit at 08/17/2015 02:18PM by Koenig.

here's a coarse little picture showing what I mean.



The error I mean is represented by the Y-tower in the right figure.

Been looking at your code for a bit and wouldn't something like this account for those errors?

Quote
code "DeltaParameters.cpp"
towerX[A_AXIS] = -((radius + TOWER_X_CORRECTION) * cos((30 + xCorrection) * degreesToRadians));
towerY[A_AXIS] = -((radius + TOWER_X_CORRECTION) * sin((30 + xCorrection) * degreesToRadians));
towerX[B_AXIS] = +((radius + TOWER_Y_CORRECTION) * cos((30 - yCorrection) * degreesToRadians));
towerY[B_AXIS] = -((radius + TOWER_Y_CORRECTION) * sin((30 - yCorrection) * degreesToRadians));
towerX[C_AXIS] = -((radius + TOWER_Z_CORRECTION) * sin(zCorrection * degreesToRadians));
towerY[C_AXIS] = +((radius + TOWER_Z_CORRECTION) * cos(zCorrection * degreesToRadians));

Changes in bold.

But somehow one must define a gcode to input those values and that I have no clue how to do, I'm no programmer.

Maybe add T, U ,V values to M665 or A, B, C to M666

Edited 4 time(s). Last edit at 08/17/2015 04:26PM by Koenig.

Marlin is providing a huge amount of unnecessary redundancy, 4 variables to be precise. There are only 6 independent variables: the X and Y positions of the towers. Providing more than that is pointless. If you are prepared to accept the restriction that X=0 Y=0 will be the centre of the circle that passes through the three tower positions (which works even for "square delta" geometry), then this removes 2 of the 6 variables. So you are left with 4 independent variables, which is exactly what the M665 R, X, Y and Z parameters provide. If you don't need the option to rotate the XY plane, then you only need R and two of X Y Z.

Edited 3 time(s). Last edit at 08/17/2015 05:44PM 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].

@DC42:
this is only slightly on-topic but there you are..
I pass the homing and fast move tests per the blog, so I am ready to approach the endstop correction/auto-leveling.
I'm used to Marlin, which I was able to understand and hack into for various sub-tests before feeling like it was safe to perform the bed-leveling routines.

IR probe works as expected so I am ready to go.

The answer is buried somewhere in the delta kinematic equations, but it is easier to ask: how much of the lateral calibration is performed by the auto-leveling, if any?
With Marlin I usually had to measure/adjust the R and D values of the M666 command until all three measured heights were the same. Same with Duet?

Finally, were is the up-to-date G-code dictionary for duet firmware? I have 1.09m..whatever was the latest a few days ago.
thanks

Quote
shadowphile
@DC42:
this is only slightly on-topic but there you are..
I pass the homing and fast move tests per the blog, so I am ready to approach the endstop correction/auto-leveling.
I'm used to Marlin, which I was able to understand and hack into for various sub-tests before feeling like it was safe to perform the bed-leveling routines.

IR probe works as expected so I am ready to go.

The answer is buried somewhere in the delta kinematic equations, but it is easier to ask: how much of the lateral calibration is performed by the auto-leveling, if any?
With Marlin I usually had to measure/adjust the R and D values of the M666 command until all three measured heights were the same. Same with Duet?

As you have the IR probe working, you can do most of it using auto calibration, like this:

1. Set the D value in M665 to the measured distance between the bearing centres of each rod.
2. Set the R value to about the right delta radius (the horizontal distance subtended by each of the rods, bearing to bearing, when the effector is centred).
3. Set the H value to get the homed height about right, so that e.g. G1 X0 Y0 Z10 puts the nozzle 10mm above the centre of the bed.
4. Set up your bed.g file with at least 7 probe points. See [reprap.org].
5. Temporarily increase the H parameter in the M558 command to e.g. 15mm, to increase the height from which bed probing starts in case your delta radius or endstops are a long way out.
6. Run G32 a few times as described in that wiki page, until the value reported by M665 annd M666 have converged.
7. Copy the final M665 and M666 parameters into config.g and reset the M558 H parameter back to normal (default is 4mm).

Quote
shadowphile
Finally, were is the up-to-date G-code dictionary for duet firmware? I have 1.09m..whatever was the latest a few days ago.
thanks

Latest version is 1.09e. Go to [github.com] and then use the Raw button to download it. I expect to release 1.09f in a day or two from now.

---

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

ignore me, just a test ping...

I'm having problems with the web interface: (on 1.09e)
-At first the response to manual jogs would have erratic delays, sometimes up to a minute (or what felt like one)
-Also uploading a new config with motor currents turned all the way down to 100 (after trying 500, then 200, etc) did not seem to affect the motors moves.
-Then, after several successful config file uploads, uploading would fail.
-I have now powered down the PC and the printer, AND unplugged the LAN connector in case it was leaking power into the pcb. Then repower/boot it all.
-Now it won't even connect. Ping reponse is ok but it gives the message 'Destination host unreachable'
-Pronterface (connecting it after all of the above was performed) can't connect either. Window's does show it's COM port in Device Manager.
-I haven't touched the SD card during all of the above (except uploading through the web interface)

It almost sounds like the firmware is not running or corrupted, somehow. Didn't want to reflash it yet.
Ideas?

edit: PC and printer are connected through a local gigabit switch sitting on a larger home network.
edit: If not cached, the printer web interface does not appear at all if I close the browser then go back to the printer IP.
edit: PC can still browse rest of the network.

Edited 5 time(s). Last edit at 08/17/2015 09:52PM by shadowphile.

Quote
dc42
Marlin is providing a huge amount of unnecessary redundancy, 4 variables to be precise. There are only 6 independent variables: the X and Y positions of the towers. Providing more than that is pointless. If you are prepared to accept the restriction that X=0 Y=0 will be the centre of the circle that passes through the three tower positions (which works even for "square delta" geometry), then this removes 2 of the 6 variables. So you are left with 4 independent variables, which is exactly what the M665 R, X, Y and Z parameters provide. If you don't need the option to rotate the XY plane, then you only need R and two of X Y Z.

OK.

But for me who is for now doing a manual calibration (I'm guessing I won't be the only one who does that) and my tower are at a perfect 120 degrees apart at least according to printing this object:



Not my picture

But the measurement along the "X-axis is 60.15, the other two "axis" is spot on, and I know how long my rods are centre to centre, 4 are 250.42 and 2 are 250.43, that small difference in rod-length does not account for the discrepancy in the print.
If I measure between the towers and the center of the nozzle when homed the distance from X-tower to centre of nozzle is slightly less than the other two, therefore my conclusion that my X-tower is standing slightly closer to the center but still have that perfect 120 degree correlation to the other towers.

Quote
dc42
If you don't need the option to rotate the XY plane, then you only need R and two of X Y Z.

I'm sorry, I may be bit dumb here but I don't understand how to apply this to compensate for the error in my print.

It's not as simple as that:

- Moving the X tower inwards in the config will affect the angles and both the X and Y lengths. More importantly, if affects the Z=0 height in different ways at different points of the bed.
- Your angles are almost certainly not exactly 120 degrees, because it's much harder to measure angles accurately than lengths.
- Looking at your test print, it appears to me that you have the print slightly to the right of where it should be on the calibration sheet, because the centre point and the Z point are not lined up. Either that, or the camera lens was left of centre when you photographed it.
- As well as lengths in the X and Y directions, you also need to consider the lengths in other directions, e.g. at 45 degrees to X and Y.

If you just want to adjust the relative lengths of X and Y in your prints, then try making the X and Y angle corrections equal but opposite. But what I recommend you do instead is to get a Z probe working and run 6-factor auto calibration.

I think that in many builds, the main problem is not that the towers are in the wrong positions, it's that the towers are leaning slightly, i.e. not at 90 degrees to the bed. This is a problem I was unable to fix until I replaced my printed corners by metal ones.

---

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
It's not as simple as that:

- Moving the X tower inwards in the config will affect the angles and both the X and Y lengths. More importantly, if affects the Z=0 height in different ways at different points of the bed.

I know this and it is very visible while printing the first layer as it comes out thicker at certain places of the bed (for example far away from Y-tower) and thinner at others (for example far away from X-tower), this phenomenon I have without that correction, with it I have perfectly flat layer all across the bed (measured with calipers)

Quote
dc42
- Your angles are almost certainly not exactly 120 degrees, because it's much harder to measure angles accurately than lengths.
- Looking at your test print, it appears to me that you have the print slightly to the right of where it should be on the calibration sheet, because the centre point and the Z point are not lined up. Either that, or the camera lens was left of centre when you photographed it.

As I mentioned in the previous post, it is not my picture, I could make one just like it if you want, but judging from the testprint I have, my angles are very close to perfect.

Quote
dc42
- As well as lengths in the X and Y directions, you also need to consider the lengths in other directions, e.g. at 45 degrees to X and Y.

Yes, they are not correct either, I have printed a square in the center of the bed and the sides come out slightly different, it is rectangular but not a true square, again this was corrected with those lines in Marlin.

Quote
dc42
If you just want to adjust the relative lengths of X and Y in your prints, then try making the X and Y angle corrections equal but opposite. But what I recommend you do instead is to get a Z probe working and run 6-factor auto calibration.

I think that in many builds, the main problem is not that the towers are in the wrong positions, it's that the towers are leaning slightly, i.e. not at 90 degrees to the bed. This is a problem I was unable to fix until I replaced my printed corners by metal ones.

I happen to have one of your IR-probes it is just not wired yet, but I just think that it should be possible to get an almost perfect calibration without having to use a probe, it was possible with Marlin.
I also have the metal corners from robot-digg

I will eventually wire the probe to see if that will correct the issue I have or if it will remain.
It is sort of a good manual calibration vs. Z-probe situation.

Here's an image of my test-print and some measurements:



The Y-value that is obscured by the print is 60.04

Same picture at higher resolution if anyone wants to take a closer look.

[someimage.com]

I could also provide with picture to show how the first layer is laid out without the fix, unfortunately I cannot provide a picture with the fix applied.

If it was as easy to compile as Marlin I would add a static value in the lines needed to test this out, but judging from this thread it seems a real hassle to get it to compile.

How did you find the correction to the X tower position that you needed in Marlin?

---

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