Bed levelling on a Delta system, possible alternative?

OK, I will start from the thought that maybe we're trying too hard to get the level sensing by using switches and probes and the like.

Working from the premise that the bed is a piece of aluminium or ply, with a heater of some sort on it, and then a sheet of "suitable" float glass clip mounted on that, if I read it correctly, the object of the exercise is to then use a levelling system to determine if the hot end is travelling at the correct height above the glass to successfully deposit the print across the printing area.

So, why are we not using the brass nozzle of the hot end as the sensor, using an electronic return capability from the print bed, which in simplest form is a piece of aluminium of known thickness placed on top of the glass. The float glass is level, so the intention is to adjust the glass level so that the hot end is the same height above the bed across all of the print area, which initially is a calibration issue that may require adjusting the bed position using levelling screws, and then after checking the zero position has not moved, it is then a mechanical issue related to the design of the device, so tweaks are used in the firmware to get the head to move accurately above the surface.

So, how about if the piece of loose plate is one side of a circuit on the RAMPS, or similar, and the calibration sequence goes something like turn hot end off, etc, and then adjust z at centre of print circle so that it just touches the plate, which can be completely automatic under firmware/programme control. As a check, Move up 5, and down 4 several times, then move down to just contact the plate again, and make sure that the Z distance has not changed and the contact between the hot end and the plate happens at the same position. That's the Z max less the thickness of the calibration plate determined. There might be some upper X Y & Z implications in here if they are significantly off position, maybe there's a case for having a centre spot on the lower sensor that would determine if the hot end was correctly finding the middle of the printing area accurately, or if there was/is an upper sensor calibration issue. Going back to the days of mechanical computer printers, (yeah I AM that old), the lateral position was determined by driving right till it stalled, and then drive left to the zero position, not using steppers it's true, but I'm sure a similar concept could work, the XY&Z could be set maybe 5 steps from the end of track, so when end of track is sensed, drive at slow and low power to the upper mechanical limit, and then back 20 steps to make sure the sensor is in the right place, and then the lower calibration has a chance of being somewhere close to where it should be.

Then, move out of the centre, and calibrate on the 3 tower axes, first to see if the plate is level, and then to see if the mechanical movements are accurate, for all 3 towers, and then if we want to get really fancy, at the mid points between each tower.

I don't have the beginnings of a clue which parameters would have to be adjusted within the firmware to save the corrections, or even if the firmware as presently constructed would be capable of holding and using these corrections, but the beauty of this concept (I think) is that it's repeatable, and checkable, and can be re run at any time if anything changes, even as a check of accuracy or belt wear or whatever, and the only change after the calibration has been run is to change the overall Z depth to take out the thickness of the plate used for calibrating. Another option would be a second piece of glass with tin foil stuck carefully to one side so that it will provide a smooth surface for calibrating.

The same concept could work with using a piece of paper on a go no go method, but that would require a lot more user intervention to step down till it jams at each location, if it could be done with the hot end effectively making the circuit to the plate, the programme itself should be capable of determining the correction information, which can then be fed into the system, if it can't be captured automatically, which might be the case if the data transfer system is one way, which it may well be.

Am I missing something, or would this be another way to get the delta side of things set up for accurate printing with very little user intervention?

I will be travelling this route very soon, the order for the parts is in, and the hotend will be ready in a few days, so I'm motivated to get my printer working reliably and accurately as quickly as possible, I'd like to use my grey matter before i hit snags where ever possible, rather than having to spend time working out if I even have an issue that needs solving


Steve

I know on the printer I run now, the hot end manages to pick up a fair amount of charred/misplaced plastic. It cakes up on the hot end over time. Sure, I could get out some sandpaper or the dremel and grind it off, but usually I don't bother with anything but the tip. As a result, I suspect that my hotend would generally fail to make an electrical circuit with a metal bed, even if it were in contact. Also, what's the consequence if you forget to remove the glass when you "auto-level"? Is shattered glass a possibility?

As for finding center: there probably isn't any need to find an exact center. Run the arms up to the limit stops at the top, and name the resulting head position (above) "center". Though it might be difficult to determine when you've reached the top, starting at an arbitrary position, without either a lot of stepper stalling (consequences of this?) or some limit switches.

Yes, the possibility of muck and rubbish on the tip had crossed my mind, but I have to admit I was thinking more along the lines of initial set up and calibration than ongoing checking, so the chances are that the hot end will be very clean at that point. If the software for calibrating is done with the safeguards I envisage, it will only be microstepping, at slow speeds, so in theory, the bed plate should not be at risk, but that was one of the reasons I was thinking of a metal plate for the calibration work, but cost might be a factor here.

The maybe spurious thought of finding true centre was that with the way delta geometry works, if the centre truly is centre, it should help the accuracy of all the other points around it, all other things being hopefully accurate.

In repect of upper limits and switches, I would not be doing away with the switches, they are the protection against driving fast into a hard limit, which is not a good idea, but I was thinking that if the hard limit was a few steps above the soft limit, that might help with the setting up accuracy, and make subsequent calibration easier, the soft limit is the signal to the system to stop under normal operation, but for calibration, the soft limit would be the signal to carefully find the hard limit, which in theory would mean that the centre really would be the centre, as long as the mechanical accuracy and lengths etc were correct,

Yes, some basic measurement of the Z height will have to be put into the softeware in order to do even basic calibration, to save time, but if it was possible to say something along the lines of

Home X,Y,Z
Check X hard limit
Check y Hard Limit
Check Z Hard limit

which would drive X steps past the soft limit, which should in effect hit the top mechanical block

Home to soft limits

Position down by Z height - plate thickness - 5mm and stop

Visual check for basic looks good. press a continue option

Slow power and speed step down at appropriate distance till contact with plate. That gives accurate height offset from soft limit.

Validate that, however is deemed appropriate, by up down steps a good few times, then check it again

Check for plate level position at each mast base, to see if the plate is anywhere near level, if not, provide feedback for adjustment, which can be done with system live, by moving base till it contacts the hot end,

Recheck centre height and then tower heights if changes have been made, as they could (will) all be different.

Now the bed is level, (might take a couple of more of adjustments to get it right) check for accuracy moving over the bed and determine the adjustment to the code to ensure level printing across all sections of the bed. Again, this can all be automatic, with the data being saved on board, or stored for display to the user for entry into the final software information.

When completed, either store, or update firmware or as needed, then remove the calibration plate, and the entire unit should in theory be very accurately set up, and the user has had to do very little in comparison to the procedure at present, if what I've been reading is correct, and hopefully, the printing will be accurate across the entire print area.

If the only requirement is to clean the hot end tip and put the plate on the print station to check everything is OK, that has to be a bonus before starting a large or complex print job, just to make sure a belt has not slipped, or stretched, or a bearing has gone slack, or is worn.

That's my thinking on that one, and for some systems it could save some pain. On the Delta Pi for example, there are no lower limit switches, so the calibration has to be accurate in order to prevent head crashes into the print bed, and this was my way of trying to arrive at an automatic way to determine the correct values for the critical items. There is no way to have a lower limit switch system, because of the geometry of the Delta, so the whole calibration concept and accurate geometry of the towers is much more important.

That's my take on the Delta and I still like the idea . though I have to admit to having some interest in a modified version of the H system, as that can do the X & Y coordinates on a large bed with effectively 2 motors.

Steve

Ok, you want to use brass nozzle and some metal foil on the glass bed as a switch. I do not have idea how it would work. I think some way to suck air from below the foil (so that it precisely sticks to the glass) would be required. The problem is that if your measurements of z-heights at the bed level are inacurate then it will be hard to compute delta system parameters from the measured data. I have some experience with this:

* microswitch was used for z-probe (not so sofisticated one as Johann's automatic bed leveling has; ours was just a temporarily attached just bellow nozzle - it is not on the platform at all during normal printing)
* firmware was extended to alow modification of top endstops using an M command and store this in EEPROM
* Johann's z_probe routine (not the rest of his bed leveling code) was called separately from a new G command
* a script was used to call the G command (z_probe) and M114 (get pos)
* the collected data about firmware reported z-height at the time of bed touch were fed to a maxima notebook
* the notebook computed the correct positions for the towers, diagonal rod length, and endstop adjustements
* the bed was leveled with error of about 0.05 mm across whole surface (though I'm not positive about this part since our rostock 3dprinter movement does not seem to be 100% repeatable ... which is strange, but definitely no issues with bed leveling noticed during prints)
* modified Marlin firmware was used

Encountered problems:
* a few cycles of (measure z-heights, compute new parameters in maxima, load firmware with new paramters) were done since the approach did not converge immediately at once
* not all parameters (i.e. tower positions, endstop adjustements, rod length) were computed at once (i.e. within one cycle we first computed endstop adjustements, then tower positions, then rod length) since it looked like it did compute crap for diagonal rod length when everything was computed at once; this might be dute to measurement error and equation instability around solution
* the system must not have slack, otherwise the equation will not be able to give usable results at all; (with slack of about 1 mm in platform movement, about 8 cycles of measure/compute/adjust were needed to achieve leveling with error of 0.18 mm accross full bed
* with system which does not have any noticable slack, we needed 3 cycles of measure/compute/adjust to get bed leveling error to 0.05 mm
* the printer behaved strangely (even when the cariage/rod/platform with no noticable slack was used): when first moved to bed level from top endstop position, it had inidialy some error in z positions (the size was around 0.1mm) which disapeared after few horizontal movements to the sides at the bed level

What was learned:
* it can be done but it may not be as effective as we hoped (we hoped for only one cycle of measure/compute/adjust)
* it should be possible to create software support which would allow user to enter aproximate system parameters (tower positons, diagonal rod length, printer height) and compute the precise parameters using purely z-probe measurements at the heatbed level; for this to work the only reuired condition is that the towers are equidistant (easily achieved by drilling top and bottom plate at once) and all 12 diagonal rods are the same length (should be easy to achieve with a jig)
* maybe math/method needs to be improved
* 3d-printed u-joints are a piece of shit (they wear out too quickly); they definitely can be improved so that they can withstand more but ... just go for some ball joints from an RC-Model shop
* it is nice to have diagonal rod ball joints screwed from both sides (one with left and the other with right handed thread) - then it is easy to make them precise without woriing about tension when glue hardenes

And since you were asking about the centre of coodinate system. You do not need to bother where to put it at all. Let a,b,c be the tower names and xa, xb, xc, ya, yb, yb their coordinates. Then put the coordinate center so that: xb = -xa, yb = ya, yc = -2*ya. This way you need only 3 nubmers to specify tower coordinates and if the system is precise the center will be the same as in the traditional firmware.

That's just the sort of feedback I was looking for, and will hopefully make my task a lot easier. The printer I am going for iniially, and can modify once I have one, is the Delta Pi , which is still in the early stages, but the simplicity of the towers appeals to the engineer in me, and the tube system will lend itself to being "hardened" with tube bearings, things like that, without much pain.

Silver foil on glass would be a cheap way to provide the contact, a better route would be a piece of aluminium plate, but that's clearly a higher cost, and if it's only basically a one off, I'm not sure that it's justified, a lot will depend on how often the accuracy has to be checked.

The math at the end is blowing my fuses right now, I shall have to take a very close look at the whole calibration scenario, and also have a closer look at the switch concept that's been used for calibrating to see which will work better, if the switch is a removable device, (which I hadn't completely recognised) then that may not be so much of an issue as I thought it might be.

I've already realised that calibration will be iterative, in that one change to the bed levelling will change other readings that have already been set up,so if a corner is moved up or down, to coin an old Monopoly phrase, "Go to Jail, do not pass Go, do not collect £200!,", but if the process is done with care, I think it will be good in the end.

What's thrown things slightly is that the developer of the Pi has just posted that he's about to migrate firmwares, so I'm not quite sure what that's going to mean, and he's not yet posted up a config file for any of his initial set up, which would at least provide a starting point, and right now, I would be the first to admit that I do not have enough knowledge of the cartesian Polar conversion systems to understand what most of the variable parameters actually mean, or how changing them will affect the device. Making the mechanical side of it will (in the scale of things) be relatively simple, getting it to perfom accuarately after I've done that will take a lot longer, so I'm desperately trying to get ahead of the game in terms of understanding what and why I'm doing, before it bites me or damages something.

I shall be printing your message, and storing it on my local machine, so I have some more reference information that will hopefully get the thing productive as quickly as possible.

Again, many thanks for a comprehensive reply, it's appreciated.

Steve

---

Shore, if twas easy, we'd all be doin it

Irish Steve

Irish_Steve Wrote:
-------------------------------------------------------
> if the switch is a removable device, (which I hadn't
> completely recognised) then that may not be so
> much of an issue as I thought it might be.
It was in our case. Johann's probe is different, it is not removable but is retractable.

> I've already realised that calibration will be
> iterative, in that one change to the bed levelling
> will change other readings that have already been
> set up
The proces should not be iterative. Notice we descrite the whole system with equations and them solve them. We should have got the correct resonse at the first attempt. Anyway this did not happen and we needed 3 iterations for bed leveling withing 0.05mm. We did not try more since that is good enough for 0.2 mm layer height and we do not expect to need smaller layers.
The equation is of 4th order but I believe it should have only 2 real solutions. That is in ideal case when everything is measured precisely. Maybe the inexact measurements "break" it. Anyway it works enough to be usable. This would deserve more investigation. If you want to continue I can post the maxima notebook. Though it will take some time to review/fix comments so that even somebody else can understand the process.

> I would be the first to admit that I do
> not have enough knowledge of the cartesian Polar
> conversion systems to understand what most of the
> variable parameters actually mean, or how changing
> them will affect the device.
I doubt any delta bot uses polar coordinate system (distance, azimuth, elevation). At least Marlin and Repetier convert directly cartesian to delta. Most people seem to take the route of laser cut top and bottom plate and then they get precise tower positions. Figuring out precise diagonal rod and endstop positions is easy even without any math. Fixing tower positions manually is a bit harder, but it is not a big deal either.

The general rules are like:
* moving tower radially have biggest impact on the oposite side of tower (so if it is symetricaly high/low on the oposite side then you need to move the tower nearer/further in firmware parameters)
* moving tower diagonally have the biggest impact on the z-postion just to the left/right of the tower - one side is going up and the second one down (so if e.g. left side is up and right down then you need to move tower in firmware to the right)

This manual approach for figuring out tower positions precisely is very iterative. The math based approach idealy should not be iterative at all (but it was ... at least in our case ... although 3 cycles are not that much ... maybe we got lucky ).

Firmware parameters are described quite well in Configuration.h. Although it may be a quite a chalenge if you do not do software at all. There are some gotchas, e.g. comment for DELTA_SEGMENTS_PER_SECOND talks about corners precision, but it has hardly anything to do with corners, it is much more about slight imprecisions in stright lines or if you happen to have diagonal rod precise to a whole number of milimeters and you do not add .0 the end then compiler will unterstand it as an integer and its square root will overflow and you get delta bot which can home but cannot move
But mostly it is ok.

Good luck building your printer.

It will sound strange, I am actually looking forward to this build. I can't go for laser cut frames, but I have enough equipment here to be able to make them up accurately, which is the main thing, what's becoming very clear is that there are some things to be very careful of when assembling the tower, in terms of parallel, vertical, and possibly most insidious, twist, and the only way to avoid them is to make sure that there are good bracings between lower and upper that will prevent them. After that, it will be down to adjustments and good quality materials, and a lot of care assembling things.

Given the Pi is still very much a development machine, I will be proceding with care, but I'm reasonably confident that it will be possible to get some good accuracy with this design, maybe with a few tweaks that will reduce the wear points, but that will be the joy of engineering, and I've done enough over the years to be reasonably happy that it will work out OK with care.

Many thanks for the detailed comments, they have helped, and fortunately, I have a long standing background in programming, so that will help a lot, most of the experience was with commerical type software, but several years putting together a very complex flight simulator based on a 20 machine PC based network was a help in that respect, so dealing with parameter files is not too worrying, as long as the documentation is accurate, and the data is good.

A long time ago, someone said to me that the only difference between being at the cutting edge or on the bleeding edge is the amount of pressure you're under, and that's very true. Hopefully, I won't be under too much pressure on this project, so will be able to take my time and get it right, rather than having to rush things to meet a deadline.

I will update progress here as it happens.

Steve

---

Shore, if twas easy, we'd all be doin it

Irish Steve

Richard from google groups requested this. So here we go.

Implementation of software endstop modification M666 (it is already pulled upstream) and implementation of G29 (single point probe) is here: [github.com]

Note: Also I used G29 as Johann's auto level, G29 in this branch of Marlin does not run Johann's auto level. It does single point probe. To use it efficiently, write scripts which send gcode to your printer:
* move to some point of interest just above the bed surface with G0 (G29 below tries to find surface at most 20 mm below this position),
* use G29 to probe Z height, and use M114 to get position after the probe,
* the returned Z height from M114 is 2 mm more than the surface height.
Use the measured data whatever way you want. We fed them to maxima for more processing. If you want to try it too let me know and I'll try to brush maxima notebook to be more readable. You must have some clue about math and maxima for this to be usefull to you: [maxima.sourceforge.net]

hercek Wrote:
-------------------------------------------------------
> Use the measured data whatever way you want. We
> fed them to maxima for more processing. If you
> want to try it too let me know and I'll try to
> brush maxima notebook to be more readable. You
> must have some clue about math and maxima for this
> to be usefull to you:
> [maxima.sourceforge.net]

Is there any chance of you sharing your maxima code and procedure?

I recently installed a probe and am using Johann's deltabot branch. The movement is the "most" level it has ever been, but I still have a couple areas where the effector is ~0.1mm high and I cannot print there. I have an ~8mm thick cast aluminum build plate that is *flat*.

From what you describe, it sounds as if your post-processing code can help identify any possible structural/mechanical issues?

Hopefully it helps. It took me quite a lot of time to add/improve comments.
[github.com]

If you find bugs or devise a better way to do it, let us know.
(I may not be available the next week though.)

I will look forward to trying this out, my plan, rightly or wrongly, will be to have a metallic bed base, and a probe ( A fixed pin with a connection back to the Ramps board) on the moving platform that will be a substitue for the hot end, and then I can probe to my heart's content across the surface of the print area, get it aligned correctly, and then get the appropriate correction factors from as many or as few places as I care to use across the entire print area.

As for the math to then work out that correction factor that will be needed in the software, I suspect that's where I will be looking for some pointers or guidance on how to put them into the code so that it works correctly.

Then, I mount the hot end, and the heated bed and the relevant cover glass plate, or whatever, and then move the head down from a known position above the bed, until I can't move a feeler gauge of my desired nozzle print height that is between the nozzle and the bed, and the offset from the originally calculated z height becomes my new z height, and in theory, I have a perfectly calibrated printer. assuming that the hot bed, and plate are a uniform thickness, which will have to be checked before making assumptions that could be misleading. I may then need to check it with different bed heat temperatures, to allow for differences due to the heat, which I've not seen mentioned previously, and I don't know if it's significant,

in theory, it would then be possible to make up and mount an optical switch based sensor that could be used to check things out on an ongoing basis, but that needs some thought

Am I barking up the wrong tree here, or is this the best way to get perfect bed alignment that can also compensate for bed thickness variances with temperature?

Thanks

Steve

---

Shore, if twas easy, we'd all be doin it

Irish Steve

Irish_Steve Wrote:
-------------------------------------------------------
> Am I barking up the wrong tree here, or is this
> the best way to get perfect bed alignment that can
> also compensate for bed thickness variances with
> temperature?

Sounds ok. Make sure you probe z-height at abot the same place where hotend tip will (few mm difference should not matter though). Once you have correct tower postions and diagonal rod length, then these parameters are correct till you do not chane carriages, rods, or platfrom (hardware wise).

Printer z-height can change with different hot ends and different temperature (both hotend and heatbed). And if you change bed (different bed for different materials) then this will have impact on z-height and possibly endstop adjustements. These things can be fixed easily without the math in the maxima notebook.

Read comments in the maxima notebook. I believe they are exhustive. I'm not sure I can add anything which is not written there. Any SW we used is in the github repository [github.com]

Thanks for the extra comments, they indeed help, and I will be playing with this very soon, to get it working well will be a bonus.

What's become very clear is that there is a lot more to the Delta than had first been anticipated. The version I am going to try and get working is a variant of the Rostock, the Pi, as the bearing towers are a lot cheaper to get the parts for, but should be every bit as accurate, the thing that's not clear to me yet is which offsets apply to which settings in Marlin, or whichever firmware, while the documentation is better than some I've seen, it's still pretty confusing,

Re hot end swaps, different bed thicknesses and the like, appreciate those comments, I'd sort of arrived at some of those conclusions over the last couple of weeks, but this reinforces the other things to watch out for, the one that only dawned on me today was that if I use (say) an aluminium base plate for the bed, if I don't make it in a way that keeps the heat from getting into the plate, it could change thickness and upset things as well, depending on how it is anchored to the bottom plate.

If I get into trouble, I will shout. Once again, thanks for your efforts and the help you are providing to the community.

Cheers

---

Shore, if twas easy, we'd all be doin it

Irish Steve

Hi again Peter.

I've finally taken the time to brush up on my Maxima (it's been a while) and look at your notebook. After still struggling with a bit of lift at the points opposite the towers, even with the other four positions and the delta radius being tuned, I'm hoping to learn something from your offline analysis of the geometry. I do have a couple of questions about the variables.

1) The 'm' vector of the seven coordinates. What is the order of the points? Also, are these required to all be on the same diameter circle? It would seem that index 0 is the center, but the rest aren't quite as easy to determine by simple inspection. This is what I guess, but was hoping you would confirm:

m = [ center,
opposite tower a,
tower c,
opposite tower b,
tower a,
opposite tower c,
tower b
] $

Or...as I guessed at these I'm starting to wonder if the order is relevent?

2) The zta, ztb, ztc variables and the comments above their definition. Specifically, I don't quite understand the sentence "Adjust carriage positions on towers by z-probe measured z heights at positions nearest to the tower bases." What I think it means is that the zt* variables are some type of z-probe, z-axis, offset (i.e., the difference in z-height from the tip of the nozzle to the point the z-probe is activated), but I'm having trouble figuring out why that would change (possibly) at each tower base.

Thanks!

edwardh Wrote:
-------------------------------------------------------
> After still struggling with a bit of lift at the points
> opposite the towers, even with the other four
> positions and the delta radius being tuned,
If center, and tower base poitns have all good height but the positions oposite of tower bases are wrong then it indicates error in tower positions. If it is all symetric then most probably delta radius is wrong, if it is not symetric then only some tower positions are wrong.

> 1) The 'm' vector of the seven coordinates. What
> is the order of the points? Also, are these
> required to all be on the same diameter circle?
The order of point is not significant; use any order you like.
Also the points do not need to be on some specific locations.
But it is good to have them at the locations which maximize certain errors from certain geometry parameters. This is only to increase the chance that searching for solution (lbfgs) will converge well. At least that is my hope. It looks to me like a common sense. But, in math, nothing is common sense till it is prooven. And I did not do the proof :-)

> It would seem that index 0 is the center, but the
> rest aren't quite as easy to determine by simple
> inspection. This is what I guess, but was hoping
> you would confirm:
>
> m = [ center,
> opposite tower a,
> tower c,
> opposite tower b,
> tower a,
> opposite tower c,
> tower b
> ] $
This order is good enough, as any other order which just provides these 7 points (i.e. the center, near each tower base and as far as posible from each tower).

> Or...as I guessed at these I'm starting to wonder
> if the order is relevent?
Correct, the order is irelevant.

> 2) The zta, ztb, ztc variables and the comments
> above their definition. Specifically, I don't
> quite understand the sentence "Adjust carriage
> positions on towers by z-probe measured z heights
> at positions nearest to the tower bases." What I
> think it means is that the zt* variables are some
> type of z-probe, z-axis, offset (i.e., the
> difference in z-height from the tip of the nozzle
> to the point the z-probe is activated), but I'm
> having trouble figuring out why that would change
> (possibly) at each tower base.

Actually zta,ztb,ztc directly correspond to the needed endstop adjustements if the point near tower base would be exactly as near to the tower as possible (that is at the diagonal rod length diameter circle). You can try to just put there always 0 (for all 3 of them), and if you are lucky the solution will compensate for this correctly in the α,β,γ. I'm not sure it is needed. But if you use them then e.g. for tower A:
- go to the position nearest to the base of tower A (you do not need to get to the point on the diagonal rod length diameter circle - just lets say 5% near to it - don't bother here with the exact place)
- execude z-probe (G29)
- execute get current position (M114)
- set the number returned as Z coordinate postion from M114 to the variable zta.

Notice that I introduced zta/ztb/ztc only to get the starting point of the solution search nearer to the actual solution. It may be need or it may not. I guess this will depend on the exact nature of all the measured points. You do not need to (and even cannot) get to the solution point (in coordinates α,β,γ) exactly anyway. So getting approximately nearer may be what is needed for correct solution search convergence.

If you have hard time visualizing how tower position errors influence bed leveling then check out this file
[github.com]

It is not documented well, but if you understand calibration.wxm, then this one will be a piece of cake.

Thanks Peter. I wouldn't say I completely understand the Maxima code, but I'm going to.

I'll be sure to update here if/when I get results.

Instead of a metallic bed, what if you were to use a standard piece of aluminum foil that is probed and removed? I think foil packaging usually provides the thickness in mils?

I think glass/mirror with microswitch z-probe is the best option. The probe should be stiff so that its mount does not bent when it is pressed. A makebort user told me that aluminium plates tend to bend over time because of repeated heating and cooling. A relatively new one should be flat. I do not have any experience with aluminium heat beds. But I would avoid them based on the makerbot user comments.

If you get a machined, cast aluminum plate you should be OK. The industry names are MIC-6, K100, Alca Plus to name a few. The micro structure of the cast aluminum allows it to tolerate heating/cooling cycles with great stability.

Well, I should have figured I'd have trouble. I think I understand the high level picture that the code is solving, but the software is holding me back. It's been at least 5 years since I've used anything like (wx)Maxima/Maple/Mathematica and I need some help.

I've put my measured values in the m-list and the zt{a,b,c} variables, and defined the ir, ix{a,b,c} as in firmware. When I start stepping through the cells I get to the one with XEq, YEq, and ZEq and it produces and error:

part: invalid index of list or matrix
-- an error. To debug this try: debugmode(true);

It seems to be the ZEq line causing the trouble.

If you don't mind, I could use a few pointers to refresh my memory. I'm sure I'm not the only one interested in your script that also doesn't fully grasp the details of the software.

Hmm it works fine with my numbers and WxMaxima 13.04.1.
It would be interesting to know if it works on your computer with the original values. (My guess is not, but still...)
Also check the results for XEq and YEq when you evaluate the block containing ZEq definition.
E.g. my maxima puts the results to a list so they look like this:

Notice that results for XEq (%o14) and YEq (%o15) are lists containing one element (the equations for x and y respectively). From the error message, it looks like your maxima does not put the restults into a list. Try whether a definition for ZEq like this:
ZEq : subst( rhs(XEq), x, subst(rhs(YEq), y, C) ) ;
would work. The difference is that this version of ZEq is not trying to pull the equations from a list.

Well I'll start by upgrading to the same version of wxMaxima. The (K)Ubuntu 13.04 repos provide version 12.04.0.

Stay tuned

Edit: Installed v13.04.2. The core maxima version here is 5.29.1.

It's strange. The expressions for XEq and YEq evaluate to an empty list: (%o14) = (%o15) = [].

As I understand it, the only thing that I need to change in any block above are the parameters ir, ixa, iya, ixc (and then list m in the next cell), correct?

Edited 1 time(s). Last edit at 09/24/2013 08:51PM by edwardh.

edwardh Wrote:
-------------------------------------------------------
> Edit: Installed v13.04.2. The core maxima version
> here is 5.29.1.
My core (command line version) maxima is 5.30.0.
It is using Lisp SBCL 1.1.10.
The Lisp version probably will not be a problem but higher version of the core may be a problem. I do not really know since I did not use 5.29.1.

> It's strange. The expressions for XEq and YEq
> evaluate to an empty list: (%o14) = (%o15) = [].
Ok, that is a problem. The equations XEq and YEq are trivial (only first order in x and y respectively). Their solution cannot be empty. Actually your outputs for this cel should be exactly the same as what I posted (regardless of the input parameters ir, ixa, iya, ixc, zta, ztb, ztc). Notice that at this level we are still completely symbolic. So it should be the same.

> As I understand it, the only thing that I need to
> change in any block above are the parameters ir,
> ixa, iya, ixc (and then list m in the next cell),
> correct?
That is correct. You may also define zta, ztb, ztc to non-zero value (as we discussed it) if there are problems with convergence.

Well it's good to know that it likely isn't me, yet!

I'll get my Maxima version to the same as yours in order to try to sort out this issue.

Hi again Peter. I'm still here

After being away for some time and starting a new job I'm back investigating the maxima approach to offline calibration. The good news is that in the mean time I've manually calibrated my machine to its best yet by iterating through tower position adjustments. I'd still like to get this code working out of curiosity and to see if it verifies the firmware parameters I now feel are very good. While I'm no stranger to compiling software, I ran into some strange issues trying to get the same toolchain as yours built on my desktop computer (but I do now have it identical), and continued getting an XML error when some of the symbolic output wasn't suppressed. I think it's related to the window size, but that's not the point here...

As you state the first, direct, attempt at solving everything didn't work for me so I proceeded to use the longer method. I finally get some numbers!

Here's my output after a single run:

(%o35) [r=268.6142183031029,xa=−175.1183282621307,ya=101.0373358607874,xc=−.5788933769816547,α=−45.66327383476023,β=−45.23244983846182,γ=−45.50102010926728]

The r, xa, ya, and xc seem reasonable, but I'm not so sure about the α, β, and γ. I understand that I need to iterate with this approach, but also I don't think I quite understand the physical representation of those latter three parameters. You describe them as "tower carriage position offsets," but I don't think I fully understand what you are referring to.

Thanks again for your help and patience.

edwardh Wrote:
-------------------------------------------------------
> Here's my output after a single run:
>
> (%o35)
> [r=268.6142183031029,xa=−175.1183282621307,ya=10
> 1.0373358607874,xc=−.5788933769816547,α=−45.6
> 6327383476023,β=−45.23244983846182,γ=−45.501
> 02010926728]
>
> The r, xa, ya, and xc seem reasonable, but I'm not
> so sure about the α, β, and γ. I understand
> that I need to iterate with this approach, but
> also I don't think I quite understand the physical
> representation of those latter three parameters.
> You describe them as "tower carriage position
> offsets," but I don't think I fully understand
> what you are referring to.

α, β, γ are adjustements needed to the top endstops so that the probe just exactly touches bed at Z coordinate of -2 mm. Since the values are so big it indicates you did not use zta, ztb, ztc. That is probably ok. If you would use zta, ztb,ztc then the values reported should be about 2mm (or -2mm, I'm not sure now) which is the distance the probe returns back after touching the bed. That is because the get current position command is send after the 2 mm return from the bed touch location.
Since α, β, γ are measured when you have the z-probe attached, their absolute value is not very interesting (it also contains the z-height difference between the hotend tip and the probe tip which is probably not precisely know). But I used their relative distance to adjust endstop position using M666 command.

Hello!

Hercek:

This part of the maxima gives me error, for some reason maxima doesnt recognize those symbols?





if I change those three things to something else it works, atleast I think it does
is it ok to change those?



Edit: naturally I replaced all î± ,î^2,î^3 in the file

Edited 1 time(s). Last edit at 10/21/2013 06:37AM by Jokeri.

Those strange things are supposed to be α, β, γ (endstop adjustements). It should be standard UTF8 encoded Unicode codepoitns. You can replace them with some other variable names which are not already taken (e.g. ga, gb, gg; or whatever else which is unique in the document).

hercek Wrote:
-------------------------------------------------------
> Those strange things are supposed to be α, β, γ
> (endstop adjustements). It should be standard UTF8
> encoded Unicode codepoitns. You can replace them
> with some other variable names which are not
> already taken (e.g. ga, gb, gg; or whatever else
> which is unique in the document).


What can I do to fix the symbol problem, other than changing those to somethign else?

Do you have any idea how can I get your marlin firmware to work with printrboard electronics?
It gives me serial error amongs other errors when i try to compile it. I'll get screenshot of the error.