Delta heightmap (and more) Simulator

Ok, first off, two links, first is the program on SF, second is a windows x64 binary distribution of Qt Linux users don't need it....if you're on 64 bit Linux and have qt5 installed, its already 64 bit, digia is just in the stone age with windows not providing x64 downloads only just offering it for VS 2013. I'm not sure, that may work, so you're welcome to try it, but the program was built with 2012. You may be able to build everything with VS Express. I don't know. You're welcome to try. Source code has vc2012 vcxproj and sln files.
[sourceforge.net]
[sourceforge.net]

One thing to note: This ONLY works in X64 mode. No 32 bit oses! (maybe eventually....theres nothing physically restricting 32 bit code)

I don't want to write too much here. The readmes in the source tree say everything about design decisions, how it works, etc. Eventually I may fill in a bit on the wiki, so I'll just go over a few things here.
First Linux. Ubuntu 14.04? Binaries are on SF
Everyone else, building isn't that bad, but not as straightforward as I'd like.
Get the source (its SVN, but I included a .tgz in the file tree)
Go to the SIMDVectorLibX64 directory you need to use the included qmakespec, and the command line options didn't seem to work on my machine. I had to export QMAKESPEC=/path/to/DeltaCalibrationSim/SIMDVectorLibX64/linux-gas-64
then its as simple as qmake && make
cd ../ErrorViewer
unset QMAKESPEC
qmake && make
cp ../SIMDVectorLibX64/libSIMDVectorLib.* ./
./ErrorViewer
If you want to contribute binaries, let me know. I'd be more than happy to post them!

Windows should be easier right? Should....
Update: Try just downloading Release.zip and extracting it to its own folder. It seems like I have a standalone version working. I've been out of QT development, so a lot changed since 4.2, the last version I had used...a lot of things I didn't see good documentation for. Anyhow, I think its all working now. If the extracted .zip doesn't work, grab the file in the second link above, and install it and follow the original windows directions that follow:
download the x64 qt distro. Install it, but you can skip the tools, examples, doc. You just need base. Once installed, download the .zip. The qt installer didn't set the path to the libraries, so I just included the used QT libraries in the zip. It did set up a bunch of other things that are new to me in qt5, like the platform plugins, and other plugins. On my dev box I have to copy the things around....such a pain...(I didn't know about the binary distribution on SF....so I built QT myself...ugh) Now you should be able to just double click it. Note: I included debug binaries just in case a developer wanted them for some reason, but most of you will want the release version. If you get something about like msvcrtd10.dll or something like that (somethingD.dll) you have the debug version and don't have VS2012 installed, and no I can't provide it, and no there's no good reason to run the debug version if you aren't a developer.

So what exactly is it? It generates a height map, or accurately, a colormap of the magnitude of the error in positioning of the delta effector in the z axis. I say that because it also offers that in the X axis, Y axis, combined XY vector, and combined XYZ vector offering a more complete view of delta errors. (not all at once though, you can select one type of error to plot) I also offer all the built in QCustomPlot color gradients, as well as a dialog box to create your own, including ones with alpha support. The images can be saved (even with alpha support). Parameters can be saved/loaded (though as I was generating some screenshots for SF I noticed there was a bug in the loading....not the actual parameters, but something isn't getting initialized properly. I'll try and get a fix soon) You can also click on the plot and view the X, Y, and Z values, as well as the tower positions the firmware used, and the tower positions were those firmware parameters, and real errors used to z probe. (important for simulating least squares approximation of the printer geometry.

If there was some other tool out there, well, I really wish I'd have seen it rather than making my own. I saw a few python things, but they were more about optimizing the printer design than showing build inaccuracies, and none of them I found included all the correction parameters offered in repetier (pretty much everything except for different rod lengths on the same side of the effector) Anyhow, I did still use it as a learning experience. Both for delta printers, and in programming. That's the first time I've written "cross platform" assembly code (the os is at least part of the platform ) I cover all it, in the readme, but in case people don't read that, yes, I'm well aware the vector functions in this program are so simple assembly really doesn't win here...Like I said, learning....that and there are other functions in my old 32 bit windows only version of the library that will be *much* faster than intrinsic C code. Eventually I'll bring it all up to speed

Please offer feedback, likes, dislikes, etc. I'll realistically probably be back to working least squares for now so any feature requests might take a while, but I think delta auto-calibration has been a requested feature for some time. To get this clear, the program is to have least squares simulated in it. I'm not planning on using this program to calibrate deltas. If it takes an x86/64 processor to solve a 12 factor least squares, then I'll see about writing it with less assembly code to get it on as many platforms as possible, but I hope to be able to put this all in the firmware (32 bit arm only though). I'll make sure to offer a pc based one capable of parsing logs or talking directly to the printer for everyone on arduino mega boards if I get it working well enough to consider it release worthy. I might not be feasible with just z error. It might need an X, Y, or both probe to get a good solution, especially if I can't hammer out the diagonal rod length/radius issue! (Their Z errors are quite similar....X and Y aren't). If anyone's got ideas for X/Y probes, accurate X/Y probes, send them on over just in case

Edited 2 time(s). Last edit at 10/05/2015 03:11AM by corry.

Oops....couldn't load it.

That would be the debug version. I'll double check that mine's not linked to the debug qt runtime somehow. I did just post a new version with the load issue fixed

Ok, I just double checked, the program is linking to qt5core.lib as opposed to qt5cored.lib (the debug version). You sure you grabbed the release version? I put the debug version there mainly so if it crashes on a machine that happens to have visual studio 2012 installed, they may be able to get me a bit more information about the crash and their machine (like code file, line number, function name...all the good stuff ) I guess I'm also a bit confused since the debug version should include the debug qt runtime in the zip file, so qt5cored.dll shouldn't be what it fails on, should be MSVCP110D.dll which is what my non-developer windows virtual machine errors out with

Hmmm, figured I'd check what the binary distribution came with, and it does have qt5cored.dll, so I decided just in case your install options didn't include it and mine somehow did, I renamed it to qt5cored-something-else.dll and the program still worked without issue on my test vm. Its gotta be you've got the debug version, but didn't download the debug qt runtime in the directory. Just ignore the debug directory, go to release, grab the zip, unzip it, and run Let me know how that goes

One more edit....This is actually my first time releasing code anywhere public, though I've had lots of releases at work. I'm generally familiar with all the technical issues with release, but just to make absolutely 100%, like beyond a shadow of a doubt certain, I grabbed depends the dependency walker and checked my exe, lib, and the qt libs. Nothing in the release folder is linked to qt5cored.dll.

Edited 4 time(s). Last edit at 10/05/2015 01:52AM by corry.

Post a new link to the working version.

Its on sourceforge.....windowsX64\release\release.zip
[sourceforge.net] is the shortcut directly there


Oh, ok, I see the problem....SF tried to "help" me posting a link to a file on the main page....let me see if I can fix that!

Ok, got that fixed now. Windows will see Release.zip as the default file on the SF page. I also looked at the web access to svn and didn't see anything to download a tgz, so I put one up and made it the default file for Linux, bsd, solaris, macos, and others. This may work on macos. I'm not sure what their ABI on X64 is. If they follow Linux, it will work. Same goes for BSD and solaris....

Edited 2 time(s). Last edit at 10/05/2015 02:25AM by corry.

Nope...

I extracted the files to a dedicated folder and tried to run the program from there.

Edited 1 time(s). Last edit at 10/05/2015 02:19AM by simspeed.

Right, that's the other link. Did you install qt?

the forums shorten the urls, so the program and qt looked the same, but I assure you the second link was something else
[sourceforge.net]
there it is again. Remember, only need to install the base.

Edited 1 time(s). Last edit at 10/05/2015 02:27AM by corry.

Also, I just realized looking at my VM setup. The paths to the plugins directory is hard coded in the dll files. If you modified the directory it installed to, you will need to go to that directory, copy the dll's you see in the release directory over the ones there. Alertnatively, you can delete them, and add the QT Bin directory to the system path. Don't you just love the "enhancements" in QT5? Making it so easy! (no not at all...I get why they did it though....just not a fan of the hard coded paths)

Ok, actually, I took a look in the platforms folder....looked like a whole bunch of nothing, so I deleted most of it, and tried running. It works with the now much smaller Platforms directory *was 36MB! Its now 1). I put that on SF, so if you want to try it before installing QT....I don't have a VM without qt installed anymore, so its not a good test. It may work, it may fail again. Installing QT will work for sure.

Nevermind. Uninstalled QT and tried it. Failed. I'm not too happy with the latest changes from QT....but IMO its still the best cross platform gui (and more) toolkit available!

Just tested, and verified. I had read about it, but not tested, but yes, the .dlls have hard coded paths to the platforms directory...so if you install to another location, you'll have to delete. the QT dlls, and either copy the ones from your installation, or set the path environment variable in windows pointing to the bin directory where those libraries reside. I'm going to look at one more thing. I seem to remember there might be a way I can include a text config file to tell QT to look in the local directory...not sure if I'm remembering that correctly at 3:00am or not

Edited 3 time(s). Last edit at 10/05/2015 02:53AM by corry.

Ok....I wasn't going to try this all initially, but I didn't think installing qt would have been an issue. Anyhow, I think I have a standalone version working. SF already has the new version. Just extract to its own folder and it should work. At least, it did on my VM, but that was with QT uninstalled, not having never installed it. I don't like the possibility of residual files...

Thanks for this, I'll take a look at it when I have time. What are the 12 factors that you are fitting?

---

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

None yet . Eventually 3 tower angle offsets, 3 radii, 3 diagonal rod lengths, and endstops....

That's not entirely accurate...many of those are duplicates. You add to all three angles you have a net rotation and an addition on 1 or 2 angles. Adding to 2 diagonal rods is the same as subtracting from one. I think, though, because one set of errors isn't dependent on any others, 12 factors will be be necessary despite their individual interrelationships. Instead it will have to be tweaked to keep it from getting wacky solutions.

Your 4/7 factor correction difficulties was the inspiration for the alpha channel work in this. I'm hoping there are some good points to select to distinguish between radius and rid errors. I figured a visual overlay would be the easiest way to see it. I wanted to get this out to the community first though before playing with that to see if there is a good spot. I'll be looking at that over the next several days . I'll post the overlaid pic when I generate it for my printer!

Well, I started trying to generate my alpha overlay maps....Looks like release was a bit premature in that regard. Everything looked good initially, but I found an error in the alpha interpolation. At my most negative spots, I show some dark colors, which shoule be transparent! Further, I realized for the overlay to work the way I want it to, showing sections of error contribution, I can't simply map alpha from 0-1 on the scale. I need to take the absolute value of the error term first. Otherwise negative error terms show up as non-existant in the overlay. Oops! I'll be working on fixes.

Ok, several bugs fixed, alpha works properly now. There's an option for "absolute magnitude" using the absolute value of the position for alpha, and I fixed an issue where the display was mirrored and rotated. Still quite interesting not as predicted errors. New files are up on sourceforge

One more update....sorry about all this, the QT problem got me. I thought I had replaced the qt libs in the release staging directory but had done so in a different directory, so that version wouldn't work. I've blown away all the bad dlls outside my install directory now That won't happen again

Hmmm 173 downloads and no more comments. I assume this means it's working? . Hopefully. I took a week or so off due to my insomnia breaking (I think/hope...been really tired and sleeping a lot, so here's hoping!). I'll be moving to calibration shortly.

In my small amount of productive time, I've decided I won't be basing things off the wxmaxima script published. It simplifies the z equation by assuming there are no angle errors, but the repetier folks and my sim confirm 2 angles off by just .1 or .2 degrees makes a pretty big difference.

That said, Seems like the simple answer is to use forward kinematics as that arrives at a z equation anyhow. Using wxmaxima, matlab, sage, etc, I should be able to get the full z equation fairly easily...it'll just be huge and ugly. Once I have that, the rest, generating a z error squared function, and the partial derivatives will all be the same (more partial derivatives though). So perhaps things might accelerate here a bit. . Maybe.

I'm still not convinced least squares is the best way to go here. I've taken and applied plenty of math, but never took a modeling course. My "gut feeling" (based on no logic whatsoever) is that there's a better way. If anyone has suggestions, I'm all ears! I'll also be consulting with a friend of mine, as well as some papers I recently discovered about "real" delta robots (not the linear kind we use in printers) to see what they've done. If least squares is the way to go, then at least I'm barking up the correct tree!

The main advantage of using linear least squares error minimisation is that calculating the solution doesn't require iteration to converge on the solution, so it is fast. I think least squares error minimisation is fit for purpose too because it is weighted towards reducing large errors even at the cost of increasing the number of small errors. Other strategies such as minimising the total spread of height errors might be preferable in theory but not by much.

Edited 1 time(s). Last edit at 10/12/2015 03:01AM 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].

well, least squares can be (and really should be) weighted and constrained. For example, I forget names pretty quickly, and I apologize for it, but the author of the wxmaxima script. He said, you can measure diagonal rod length with calipers and tower angles can be set with a laser cutter. So we can make sure least squares doesn't try and use those for radius corrections (just actually use those calipers and use them correctly! Not too much pressure!). So we can play with what it's going to weight.

That said, in my request for other approaches, I was well aware of the benefits of least squares. I've often found though, my domain knowledge is low level software. I love it. I branch out into many other fields though. I'd say jack of all trades master of nothing, but I know I'm good with assembly code in "exotic" architectures . Still, that leaves a huge gap in many other domains, math included. The wizardry I've seen mathematicians cook up is incredible! (Just look at things like rsa key exchanges, or some of the quantum secure encryption techniques!). As far as I'm concerned, this may very well be a case of unknown unknowns for me.

Fast isn't a huge concern for me. I'd like it to be quick enough to be able to be firmware, but I won't lose much sleep if the data has to be passed back to a PC. Shouldn't need to calculate rod length, radii, etc every print, just basic bed angle correction, and some printers, maybe not even that. I would like the data passing to be automatic, and the corrections sending to be automatic if it needs to be PC based.

I've also ordered a snicker doodle board. I think if a standard due can't hack it, maybe an fpga based solver can . Just need them to make a mega formfactor baseboard so I can plug straight into my radds board ...then port repetier to it (and I guess arduino in general) since Iirc it's not software compatible even with the baseboard for the shield.

Oh, and I'll throw in a little update...pretty sure fatigue is the nasty cold people have been talking about on the east coast. I'm medicated thanks to my motorcycle accident and those meds are likely blocking most symptoms other than fatigue (and likely enhancing fatigue), so I suspect I'll be down for another few days (saw signs I'm almost over it, which is how I came to realize I had it in the first place.) Concentration for any length of time is quite difficult with it... I really want to figure out what's going on with my big delta though, so one way or another, I'm getting this done! (Right now it's quite strange as the best value I can find for horizontal radius is +2mm over what it should be in the cad model...more than build inaccuracies should account for. I want to see what parameters flatten things out then do my best to measure them and figure out what's going on! )

Edited 2 time(s). Last edit at 10/13/2015 12:31AM by corry.

You can already do least squares delta calibration on your Due + RADDS, because RepRapFirmware has been ported to run on it.

---

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

Right, I can do a 4 factor least squares. What I meant was if the due can handle the "12" factor (In quotes because in reality it will be constrained in one way or another to not allow a single parameter on all 3 towers to vary). I don't know how slow things go on sub 100MHz processors, (really sub 1GHz processors since that's about all I've worked with, but I'm working on that ) Unless it takes a significant time to solve it on my laptop, I'll be trying it in firmware anyhow.


If I had more faith in the 7 factor, I might try it, but to be honest, even that won't really cover it. I built an aluminum framed hexagon shaped delta. No laser cut anything, so I have angle inaccuracies. I bought some big digital protractors to measure, and measured errors up to .4 degrees. I'd just call that good, but the tools have errors, and getting them against the big aluminum towers which aren't perfectly flat is tough as well, so I know I have angle errors up to .4 degrees +/- probably .4 degrees. So regardless of anything, I know that the 7 factor isn't enough, and it ignoring my column position errors means it'll produce irrelevant results.

I made the primitive approach of this for xy printers hahaha: [www.thingiverse.com]

RepRapFirmware does up to 7 factor least squares fitting using up to 16 probe points. So tower position corrections are already fitted, but not tower tilt. However, in my experience it is better not to fit the diagonal rod length, because it isn't well defined by bed probing unless you probe outside the normal print area. In any case, you can measure the diagonal rod length accurately. So I normally use 6 factor calibration.

---

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

Not so fast. It "looks" like it does, but in reality, it only allows for adjustments to the a tower and the x of the c tower. (His coordinate system is rotated 90 degrees vs repetier. Not sure about repeal firmware., but that was a cause for one of the sim bugs). This is because he assumes that the angles are all equal. The adjustment is just for the radius, not the angles between the towers, thus only adjusting x on the c tower. In his coordinate system, the c tower is on the x axis. To allow for an angle error, he'd have to have a y correction for the c tower as well. But worse, his factoring out of x and y, where he does solve ([A-B], [x]), ([A+B-2*C], [y] only works because he's forcing all angles to be 60 degrees, forcing x's and y's to be the same because of that angle. So no, there is no adjustment for angle errors, and thus, it simply will not get a good solution for printers with tower angle errors. I suspect even laser cut printers have some error there, so those with their printers going flat to within .1mm or so (pretty darned good I won't lie!), it may be because of angle errors.

Corry, I wrote the 7-factor auto calibration in RepRapFirmware, and it most definitely does not assume equal angles when you run it in 6- or 7-factor mode. It does of course assume equal angles if you run it in 4-factor mode. I don't know what you mean by "repeal firmware".

There are 6 degrees of freedom in the placement of the towers, e.g. three X and three Y coordinates. But three of them correspond to translation of the origin in the X or Y direction, and rotation of the bed. Those degrees of freedom do not change the bed shape, so adjusting them during auto calibration would be a very bad idea. Therefore it is only worth adjusting three tower position factors.

In earlier versions of the firmware, I adjust the coordinates of the Z tower and the spacing between the X and Y towers. In later versions I adjust the delta radius and the angle offsets of the X and Y towers. The effects are identical apart from a small origin shift, but the newer arrangement allows you to plug the delta radius and tower angles back into the M665 command in config.g so that you can save the calibration results.

I am not sure what you mean by "tower angle errors". If you mean towers that are not perpendicular to the bed in both directions (i.e. towers that lean either radially or circumferentially), then I agree that this is a common problem. It would need much more complicated kinematics to compensate for, another 6 factors to calibrate, and therefore at least another 6 bed probe points (preferably more). My solution was to change to metal corners instead of printed corners, to keep the towers perpendicular to the horizontal extrusions as far as possible.

---

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

Ok, I think the confusion is the angles. Maybe reprap firmware doesn't allow for corrections there, I don't know. And yes, my stupid phone decided that reprap=repeal....as the meme says, I correct autocorrect more than it corrects me.....

So, first off, lets get that out of the way. A picture is worth 1000 words, so, let me link to repetier. I know, many have a strong preference for firmwares, so it can be distasteful But it goes to my frame of reference allowing us a common communication platform. I've not seen as much documentation elsewhere....I can't link in the options, so you'll have to click next, and select delta printer...[www.repetier.com] scroll down to dimensions. It has a picture of what I'm talking about. The angles I'm talking about are angle of column A, angle of column B, angle of column C. In repetier, this defaults to 210, 330, and 90, putting column C on the positive Y axis.

Ok, now on the same page, I guess I can see, yes, the angles can change, but still with just one radius, so technically, out of 4 degrees of freedom, they only have 2. You could argue the third because of the radius changing, but they're intertwined. Towers cannot be arbitrarily placed like what happens in the real world. Realistically, each tower has 2.333 degrees of freedom. I admit, I scanned through, didn't see any angles, and assumed they weren't there. I also thought he was using the steve graves coordinate system placing the C tower on the X axis, and thus the C tower coordinate would just be a radius, not an angle....which forced the A tower to a single angle....No I got it rotated back to the same coordinate system I'm using here...I don't really know why he chose to use tower positions other than maybe to simplify things. I'm letting the computer keep track of things

That said, I do plan on calculating all repetier corrections, 3 (really two, but it can be any set of two from the set of 3, a,b,c) angles, radii, rod pair lengths, and 3 offsets, though, the 3 offsets are there more to keep the other values in line, and can be passed to rotate the coordinate system so it doesn't skew the positions the way it described in the script. That is, there will actually be 4 degrees of freedom for the towers. Its not easy, but I never look for the easy solution. Only when the hard is actually impossible

Right now, I have the forward kinematics in wxmaxmia, and the partial derivatives calculated, which is probably all I need to get this into C code and solve it there. I haven't added a weight matrix, nor any of the other constraints, but I want to see what the basic approach yields when all factors are considered. I expect it will blow up in my face honestly, but I also like to keep expectations low so the only surprises are good ones

Sorry for missing that. Like I said, I skimmed over it to see what he was doing, saw the mention of the coordinate system, thought he was talking about that for the precise side of things, not the model, didn't see angles computed, and stopped there. Should have looked a little further. But as I said, its still not the 4 degrees of freedom it really needs to be

I took a look at that Repetier configurator. It does indeed allow more than 3 degrees of freedom in the tower corrections. But you have failed to grasp that just because a manual configurator allows more than 3 degrees of freedom in the tower positions, that does not mean that auto calibration should try to optimise more than three.

I allow one extra degree of freedom in manual configuration of my fork of RepRapFirmware. Specifically, I allow the Z tower position angle to be changed as well as the X and Y tower position angles. I added this to make it more convenient for users who build 'square' delta printers, with 3 towers at 90 degree intervals instead of 120 degrees. But letting the auto calibration adjust all 3 tower angles is counter productive, because there is no point in letting the auto calibration routine rotate the bed. Similarly, I could allow manual movement of the bed origin, although I have not come across any delta printer configuration for which this would be helpful. But letting the auto calibration routine do that would be foolish, because it would move the centre of the print closer to one of the towers, thereby reducing the maximum print size unless you compensate by deliberately printing off centre.

Please think more carefully about the maths, as I have done, instead of blindly assuming that any parameter that you might want to adjust manually can also be adjusted automatically.

---

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

Come on man, if you want to have a discussion, I'm all for it, but part of that has got to be reading the entire posts and not telling me what I've already said. Part of it is keeping tempers down too. I know that in person I've got a bad case of "resting asshole face", and online my posts tend to come off as angry/heated. They aren't. In my mind they sound perfectly happy and in a discussion tone, not an argumentative tone. I could pepper my posts with 's and emojis but that just makes me look childish in my opinion.

So that said, I get it, we call this "NIH" (Not invented here) syndrome. Its not your idea, so its garbage. Repetier offering all the corrections, probably garbage too, as I said, I know people have this religious following of firmwares. Combine that with Freeman Dyson's critique of science (groupthink) and you've got a powerful combination. I'm not an idiot. Just because I'm willing to go off on my own, and do what I need, not what someone else needs, doesn't make me stupid.

I'm not going to readdress the fact that I know modification of 3 tower angles is rotation. I said that multiple times in this thread, and I don't need to go over it again. Just like the other parameters which you failed to see or mention, that I already did.

I whole heartedly disagree with your presumption that towers will always be on a circle and thus should not be given degrees of freedom to allow for that. I live in the real world, not the ideal, and I know for a fact my printer, though relatively accurate, has some of these errors, because there's a balance in time, cost, and complexity that has to be struck. Ideally yes, they'd be on the same circle +/- 0.001mm. In reality, that's probably more like +/- 0.3mm. Pretty good, but not good enough for purposes I want my printer to handle. Just because reprap firmware doesn't support it, just because your printer doesn't need it, doesn't mean its useless.

I think I've already demonstrated that I've thought more about the math than most. I wrote a sim, which can give you not only z errors, but X/Y as well. I've been thinking about whether there exist "reasonable" alternate solutions which yield a flat height map, but position errors in X/Y. That's why I added those options to the sim. In reality, I want a better visualization, but again, its a time/complexity balance, and the magnitude of the errors is good enough to see if a solution offers an alternate for height but not X/Y. I've also consulted a friend who with her PhD in Math calls least squares "kiddie math". When I mentioned the issue that was said about the radius adjusting too much, first thing she said was its likely got bad constraints. Well, it has no constraints, so yes, she was 100% correct. Oh, I also planned to implement correction IN THE SIM FIRST! You know, so I have the actual values accurate to 0.00000000001mm? So I can see if the math converges on the CORRECT solution? No, I've thought heavily about the math, more so than most.

Now, if you have something constructive to offer that I've not already mentioned, please, feel free. I know my intelligence, but know I don't know everything, and am fallible. Don't take my admission of wrongness as a sign of weakness, or a sign of I haven't thought about things thoroughly. Its a sign I dismissed a solution because it wouldn't work for my non-ideal printer, so I didn't look too deeply into the solution. That's it. If the tone in this seems a little more hostile than the last posts, that's because the number one blood boiling issue I have is having to repeat myself, over and over when the text is right there. Perhaps its a character flaw of mine, but text is permanent. There's a recording of exactly what I said, and when I said it. Having to repeat it online is so redundant, worthless, and a waste of time.....yeah, it gets me annoyed.

Regardless of your dissatisfaction with my attempts to provide a better solution, I will be trying. If its impossible, all I've done is waste my own time. If it works, it benefits everyone. So why all the negativity? I really don't get it. Even NIH cannot account for that!

Edited 1 time(s). Last edit at 10/15/2015 11:54AM by corry.

As you appear to dispute the geometrical fact that a circle can be drawn through any three points that do not lie on a straight line, I see no point in discussing this with you further.

---

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

And you're oversimplifying it, a common error

Kindly explain why you don't think the towers necessarily lie on a circle, when geometry dictates that they must.

---

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