Tweaking and Fine Tuning Delta DuetWifi
-
If the vertical dimension is incorrect, you need to adjust your tower (X, Y and Z) steps/mm. At x16 microstepping and using GT2 belts, this will normally be 80, 100, 160 or 200 depending on whether you are using 20 or 16 tooth pulleys, and 1.8 or 0.9deg motors. Put the rod length back to the measured value.
-
I measured my rods from center to center 215.7mm and re-calibrated. I verified my pully is 20 tooth. I do have GT2 timing belts. I verified settings at 80 and my micro stepping is at 16 (256 interpolated) I have 1.8deg motors..
The height is an issue on printed objects which seems to be too short.
Prints are slightly too big in all directions in the horizontal axis?
I will explain again that I had my bed lower and did not have an issue at the time with horizontal axis.
Same problem either way is One side of print is smaller than the other but model file is square.
-
Let me narrow this down to one set of actions and one problem to solve. I moved my bed up and adjusted the config.g height. Then I reran my auto calibration and set m666 m665 and m500
Heres a picture of the bed raise.
https://drive.google.com/open?id=0B4nxVsZnC01PNFRFWlNkWmRKYU0Now this lid to my DuetWifi enclosure along with the enclosure is having to be printed out in parts due to my bed area not able to print out large enough. So I had to slice the model file up. Needless to say I told my self not to move the bed up until I finished printing. Well I thought no changes could be that bad just moving up the bed. Here is a photo of the difference on it lining up on the lid.
Showing that all parts line up before bed raise
https://drive.google.com/open?id=0B4nxVsZnC01PTjZEUWVrbk5EejAPart printed after bed raise.
https://drive.google.com/open?id=0B4nxVsZnC01PUWNkWDhzVWNYVXMThe part I'm holding is clearly larger than the bottom half that is connected to the enclosure. You see ruff edges on the bottom of the lid piece I'm holding due to I trimmed off some because at first I thought it wasn't fitting well slightly, but then I noticed the whole part was larger. In my first sentence in this reply I am saying that is all I did and why would that change the size?
I am thinking there is convex issue going on. The higher up I print the larger my print gets. Although I am not fully sure.. This picture needs to be looked at like the flat right side is the bed….
-
Were both openings of each half of the lid facing (oriented) the same way when printed?
-
Hello number40fan thanks for the reply,
Actually no, but I turned the part around and it's still the same issue. I also printed the bottom lid part that swivels on the enclosure and it is also larger than before and matches the lid part I was holding. I could print everything again but that would not solve it and worse the board matches the holes correctly before. I think I will figure the difference and shrink the part I'm holding in cura program, but that officially would not solve it.
-
If holes parallel to the bed, are appearing squashed and your x,y,z, steps/mm is right (i.e. parts are 20mm tall when they are meant to be 20mm tall). Then I would assume its printing larger in XY than it should which indicates a diagonal rod setting too small. Try increasing your diagonal rod length, then recalibrating using 6 or 8 factors so rod length remains what you set. Then try again.
It makes sense to ensure your extrusion is really close, but 1% over/under extrusion will not distort parts to this degree.
Try printing some towers, maybe with holes in them and see how they come out.
-
DjDemonD thanks for your reply,
Ok setting the rods at 215.7 gave me close to the 118.5mm (.5mm too short) and keep in mind it has a brim. Now the x and y I measured the biggest part of my lithophane in two places and this is 2.25mm too large. The upside is that it was the same with two measurements top and bottom. Here is a set of photos.
imgbb.com
Album https://ibb.co/album/eAJcMF
-
I discovered something just now and I will have to test it. I just checked the config override file and it's still using some of the old settings even though I was sure that I did m666, m665, m500.
And I just did the autoconfiguration again and those codes and it did not update the settings for rod. I think I have partially found the problem…
Yet it knows the bed height changes and prints at the correct height... -
dc42
Firmware Electronics: Duet WiFi 1.0
Firmware Version: 1.19.2 (2017-09-01)
WiFi Server Version: 1.19
Web Interface Version: 1.19.3I changed rod length in overide file to match what is in the config.g file and it made the print smaller than expected this time rather than larger.. dc42 what do you need to know? My autoconfig is broken and I will have to halt on understanding what I can do with this at this point.
Now for the changes to the rest of the config override I am not sure, but I do know the web interface z is not displaying the config.g height and it isn't displaying the overide file version of height but something different in upper right hand corner.
WEB INTERFACE UPPER RIGHT HAND CORNER Z
282.55OVERRIDE FILE H
H287.555CONFIG FILE H
H285 -
The standard delta homing files drop the effector by 5mm after homing so that it can be centred in X and Y. So it agrees with the value in config-override.g.
-
Hey dc42 thanks for the info about how those z values are calculated,
The problem I have found is that m666 is not returning the new rod length from config.g
Or Auto Delta Calibration is not adding (L) to string for m666….Ok to test this I have changed my config.g (L) to something random like L214 and then I run auto delta calibration.
m665 returns:
delta radius 98.092, homed height 287.615, bed radius 80.0, X 1.719°, Y 2.610°, Z 0.000°No (L) parameter.
m500 saves correctly in the override file I think but does not have the (L) Parameter to save. So it goes with this one that has been there a long time ago? It never rewrites it.
M665 L208.590 R98.092 H287.615 B80.0 X1.719 Y2.610 Z0.000Is this a normal problem and what should I do to get the value to pass from config.g to override file without me having to manually hand rewrite it myself?
-
That sounds like a bug. I'll look into it next week. We recommend in most cases to use 6 or 8 factor calibration, which do not change the L parameter, and that may be why it hasn't been noticed before.
-
Thanks dc42, yeah think it's on 10 point calibration at the moment I guess I will check bed.g.
EDIT: bed.g file
–------------------------------------------------------------------------------------------------------------------------
G30 P0 X0 Y74.11 H0 Z-99999
G30 P1 X57.44 Y33.16 H0 Z-99999
G30 P2 X57.44 Y-33.16 H0 Z-99999
G30 P3 X0 Y-74.11 H0 Z-99999
G30 P4 X-64.95 Y-37.5 H0 Z-99999
G30 P5 X-64.95 Y37.5 H0 Z-99999
G30 P6 X0 Y35.89 H0 Z-99999
G30 P7 X25.67 Y-14.82 H0 Z-99999
G30 P8 X-32.48 Y-18.75 H0 Z-99999
G30 P9 X0 Y0 H0 Z-99999 S6Just so I read you correctly using 6 or 8 will not save L parameter so you are you saying if I use over 8 or under 6 it will save the L parameter?
Glad I could work out a bug. I just wasn't sure if I needed to upgrade something... I know it used to save it correctly somehow. So maybe it's just something that got changed in the version I have over the one before for web interface or firmware.
How is the paneldue manual calibration addition going?
-
He means the S6 number at the very end. Check out the Wiki for Delta calibration and it will explain what the # after the S will do.
-
Thanks number40fan I have ended up using the bed wizard and now understand it's adding halfway points. http://www.escher3d.com/pages/wizards/wizardbed.php
I am trying to set the correct delta radius as I'm sure that might be throwing things off too. So I found these two photos. What is the correct way to get the value for delta radius (R) parameter to use with this firmware.
Would my delta radius be the arm radius plus to the center which is the delta effector offset.
Is your firmware figuring in the effector offset already? This photo says the arm radius is the delta radius which does not include the delta effector offset. Also I have found other photos out there that really contradict both these photo's. So I thought I should ask. I didn't see in your documentation anything about how to get the value your firmware is looking for…
EDIT:
Found my answer in plain sight on the page Calibrating a delta printer lol."R = delta radius. This is the horizontal distance spanned by each of the rods when the effector is centred, again measured between bearing centres. You do not need an accurate value for this because calibration will determine it, so use a ruler to estimate it to within about 5mm."
-
Ok guys I am here to report that I have calibrated this officially a thousand times now forward and backwards
The problem that throughout this post that threw off all values during auto calibration was due to lastly not setting the H parameter to it's height as close as possible in config.g. I kept thinking that auto calibration was handling that. It would set a corrected height but all the other values it would throw off like x and y degrees and delta radius etc.. My guess is it had a corrected height but the rest would use the config.g height… Atlas after measuring everything forward and backwards this solved the inaccurate auto calibration.
I hope this is another bug that can be remedied some how. Atleast I know now what is going on...
So what I am saying is after your first few auto calibrations on a delta and it's also true for new changes to your bed height. Look at what the height is changing to when auto calibrating from the overridefile or the m665 command. Then incorporate that into the new height in config.g. Then do auto calibration a few more times. repeating that cycle. Also be sure to reboot every time. And remember to use m500 to save last configuration etc. Use configuration override command M501 in config.g..
After setting my L parameter to exactly what I measured in both config.g and configoverride and set H to exactly what it really is from home to bed in config.g. This made the rest fall in to place. I had measured the delta radius so I now knew if the auto calibration was getting the right numbers !!!!! It's now setting the values in config override to all things within .3mm or closer. My prints are back to being right. Matching the model file pretty close...
Now hopefully the squareness/trapezoid issue will be resolved... If not then I'll continue to see whats up with that. Like every rod needs to be perfectly the same..
-
Auto calibration does set the homed height (M665 H) parameter. I have re-tested M665 and M501. All the parameters set by auto calibration are reported by M665 without parameters, and stored in the M665 command in config-override.g.
As you have realised, if you auto calibrate and don't run M500 afterwards, then next time you restart the Duet it will pick up whatever values you last saved with M500 from config-override.g.
-
I've always since you told me been using m500 before rebooting. More importantly like I said your auto calibration was saving the corrected homed height in the override file, but until I used the corrected height that auto calibration came up with in my config.g file the values the auto calilbration was using was off because it didn't use the corrected homed height from the override file.
I assume your auto calibration script uses only config.g (H) and not config override (H) parameter every time it runs. So if you have a config-override enabled in config.g than it should ignore config.g (H)
The simplest way to hear my findings for a fix for now would be "Make sure your config.g (H) parameter is correct before running auto calibration". A person can definitely find the correct (H) parameter by running the auto calibration, but they need to change the config.g to the new corrected height.
Again I ran my test over and over for the last 7 days every day all throughout the day and until I changed the (H) parameter to actual correct height from bed to the home position in config.g the auto calibration did not act correctly on getting the parameter values for (R)(X)(Y)(Z). Auto calibration was never using the (H) parameter in config-override.g while doing auto calibration. This is only my experience. I am just trying to help.. The important thing is that I have my printer working correctly now going by the methods I explained above.
dc42 I like this board! I do appreciate your hard work, don't forget that. It means alot to me knowing the guys who made the electronics I'm using are willing to keep making their product better
-
If you insist on using the Config -Overide file then you do need to load it after a boot with M501 else how does the board even know about it?
Put M501 as the last line in your Config.g if you must use but what you have found is the very reason that most of us DO NOT USE the config-Overide but prefer to hand graft the figures into the Config.g instead
Doug
-
If you insist on using the Config -Overide file then you do need to load it after a boot with M501 else how does the board even know about it?
Put M501 as the last line in your Config.g if you must use but what you have found is the very reason that most of us DO NOT USE the config-Overide but prefer to hand graft the figures into the Config.g instead
Doug
Thanks for your reply!!!
I use the M501 command, but yeah good point I should just as you say hand graft the m665 and m666 commands into config.g. I do however would like to help the engineers work out bugs or improve things. I feel like I am possibly helping their product. I think of it like this. My last board and the people behind it stopped making the board and with no support at all. It was costly and an inconvenience of time. Me helping correct issues in this product would ensure that a few years from now i'll have an easy upgraded replacement
Just swap out and continue.
