Heuristic (AI) calibration for delta printers on Smoothie

[geneb]

That just sounds nasty as hell. This is like one of those bugs that can only be duplicated if you've got one leg up in the air, the moon is full and there's a green unicorn in your driveway. (This is why developers drink. A LOT.)

I'm really disappointed how S3D is handling this - I can _almost_ understand their "Not my monkey, not my circus" attitude, but considering the popularity of the board and how much they're charging for their software, you would think they'd do more than slam the door in the face of users having problems with it.

Thanks for the description Arthur. You going to be at MRRF this year?

g.

[Xenocrates]

If it's a heisenbug like that, it's pretty nasty. It's nice to know it won't arise in CNC mills and lathes, and that there is a planned refactor which should catch the bug, even if only by tearing out the entire section of code it's in. I think S3D by this time should have fixed it, or should add a parameter for the minimum move size. But I suspect that even if they did that, there would be an odd default, and it may well generate more identical steps, but less short ones. It must be like nailing jam to a tree, dealing with all the varieties of 'quirks' (I personally think it's just plain stupid to have two identical moves, unless they are across an M01 or M00 from each other (or it's tool change on a lathe) of the slicers, while attempting to keep track of all the kinematics and then doing step generation.

I not being a software developer, nor someone who routinely writes anything more complex than G, figured the bug was simpler than it was, considering what I was reading about it. And so Arthur, I have to give you credence for working with the in some cases bone-headed quirks of other programs to interface well with them, and doing your best to make it work. I almost wish you could have a hand-cranked computer for this (I have heard of one which had a crank for single-stepping to debug stuff), although your arm would probably get tired fast.

[arthurwolf]

or should add a parameter for the minimum move size.

That's what other slicers do and it solves the problem completely.

I was knee deep in Slic3r's code for part of december, and it takes a lot of care not to do what S3D does. It think any slicer worth the name should do that.

Slic3r has a default at 0.1mm ( which is fine for most machines ), but you could use even lower values and it'd still solve the issue.
The thing is S3D's lowest possible move is hundreds of times smaller than the resolution of most machines, and it doesn't have an actual limit on gcode density. Too many things going unchecked, simply.

I almost wish you could have a hand-cranked computer for this (I have heard of one which had a crank for single-stepping to debug stuff), although your arm would probably get tired fast.

In this case, there was a hand-cranked computer, but it was in another country, and I had to instruct the person actually cranking it via carrier pidgin, so it was too complex to get him to crank *exactly* in the right place, unfortunately.

I'm going to try to keep answers to people to a minimum from now on, I don't mean to hijack 626Pilot's thread, I just wanted to make sure some of the misconceptions about this issues were answered.

Cheers.

[626Pilot]

I'm going to try to keep answers to people to a minimum from now on, I don't mean to hijack 626Pilot's thread, I just wanted to make sure some of the misconceptions about this issues were answered.

It doesn't seem like a hijack to me. According to what I've read (but not verified, to be fair), Simplify3D is censoring people from complaining about this problem. Meanwhile, you're here, talking to people. Difficult to complain about that.

[bvandiepenbos]

I'm going to try to keep answers to people to a minimum from now on, I don't mean to hijack 626Pilot's thread, I just wanted to make sure some of the misconceptions about this issues were answered.

It doesn't seem like a hijack to me. According to what I've read (but not verified, to be fair), Simplify3D is censoring people from complaining about this problem. Meanwhile, you're here, talking to people. Difficult to complain about that.

+1 to that

[bvandiepenbos]

May have already been discussed somewhere, why not run a script on gcode that deletes duplicate lines, or within a specific tolerance?

[626Pilot]

I had the notion to write a G-code filter for Smoothie that keeps track of the position, but doesn't generate further motion instructions until the position has moved more than some distance (like 6 microns) from the last generated location. I think there are some post-processing scripts that do something like this, somewhere. I don't know how easy it is to set them up, or whether they work with more than one slicer, or whether they're cross-platform.

[bubbasnow]

can the smoothie support g2 g3 arc commands?

[arthurwolf]

can the smoothie support g2 g3 arc commands?

Yes.

Also, on scripts, you can find those that were written for the S3D bug here : http://smoothieware.org/simplify3d

[PyjamaSam]

...I'll keep you updated on my progress...

Ok I have managed to sync up your fork with the official edge. Turned out it was WAY easier then I though. I was just a moron.

My fork is at https://github.com/pyjamasam/Smoothieware

Be warned - I haven't actually tried it on my printer yet. I am away from home and won't be near it for another week. When I do get home I'll give it a whirl and report on my success, but if anybody else is up for an adventure then feel free. Just remember it might cause horrid things to happen... it might also work though.

chris.

[626Pilot]

From that page, there is an "online" tool (actually just local JavaScript) that will do it: http://mikk36.eu/SimplifyS3D/

That should work for everyone, no matter what.

BTW, KISSlicer is really awesome and anyone using S3D should consider it. It has a minimum resolution setting, so it doesn't generate moves that are the size of a single red blood cell.

I think it's nice of the Smoothie team to put up a page just for that issue.

Ok I have managed to sync up your fork with the official edge. Turned out it was WAY easier then I though. I was just a moron.

Cool. I will take a look at this next week. I'm also going to put a link to your depth map visualizer in the readme.

[FRANCO888999]

...I'll keep you updated on my progress...

Ok I have managed to sync up your fork with the official edge. Turned out it was WAY easier then I though. I was just a moron.

My fork is at https://github.com/pyjamasam/Smoothieware

Be warned - I haven't actually tried it on my printer yet. I am away from home and won't be near it for another week. When I do get home I'll give it a whirl and report on my success, but if anybody else is up for an adventure then feel free. Just remember it might cause horrid things to happen... it might also work though.

chris.

Hi,
I have compiled your fork but there is something wrong because with your firmware the extruder is to near the plate, and after reflashed the 626pilot one's it came back with the correct height.
Maybe it's something new parameter in the config file?

[PyjamaSam]

Hi,
I have compiled your fork but there is something wrong because with your firmware the extruder is to near the plate, and after reflashed the 626pilot one's it came back with the correct height.
Maybe it's something new parameter in the config file?

If you try the official smothieware edge firmware does it do the same thing (although you'll loose all the calibration that 626Pilot's fork brings with it), so not sure its an apples to apples test...

I am still away from my printer (Disney 4tw for another week!), but once I get home I'll give it a whirl on my printer and see. I do know that there were a lot of changes between the latest version that 626Pilot had checked into his github repo and what I merged up to with the smothieware edge repo. Most of 626Pilots changes though live in ComprehensiveDeltaStrategy.cpp/.h and a little bit in the ZProbe.cpp file.

Looking at a stock edge source directory and my fork's source directory I only see 4 different files:
The changes to add multiplication to the Vector3.ccp/.h files
The changes to Robot.cpp to allow longer lines to be split when writing the override file
The changes to ZProbe.cpp to include the new ComprehensiveDeltaStrategy stuff and improved z probe functions (sample count, decell, etc)

Again, as soon as I am home from vacation and can actually touch my printer again I'll get this firmware loaded and report back. Appologies for posting without trying it out on my own hardware first.

chris.

[626Pilot]

What process did you use to merge with upstream?

[FRANCO888999]

Appologies for posting without trying it out on my own hardware first.

Hey no problem at all, I just wanted to help a bit testing your fork


P.S. I compiled with the matrix set to 9...if can change something considering that I don't use the panel nor the ethernet module, only usb connection.

[PyjamaSam]

P.S. I compiled with the matrix set to 9...if can change something considering that I don't use the panel nor the ethernet module, only usb connection.

I haven't yet tried using the matrix size set to 9 yet but I was planning on doing that as well. I did set my make file to exclude networking stuffs and a bunch of modules (while the laser module is cool my delta doesn't need it ) as I use a PI for network access and streaming of gcode and my Azteeg X5 mini doesn't have networking built in.

chris.

[PyjamaSam]

Code: Select all

What process did you use to merge with upstream?

So I added the official smothieware repo as a remote to my fork (your fork should have it already since its a fork of that repo, but since my repo is a fork of a fork I needed to do that).

Then once I could do that I just did a

Code: Select all

git fetch smothie

(in my case smothie is the name for the official repo that I chose when I added it as a remote) which pulled down all of the code from that repo.

After that I could just do a

Code: Select all

git merge <sha hash of changeset I wanted to merge up to>

(which I got from just looking at the commit log for the official smothieware repo).

Git takes care of the rest of it and as long as there aren't any conflicts then all goes well. If there are any conflicts then of course you need to deal with them.

Then just a quick

Code: Select all

git commit

followed by a

Code: Select all

git push

and your done...

In my case since I have both your fork and the original repo as remotes in my fork I can merge from either of them and bring the commits into my fork.

Let me know if any of that wasn't as clear as I hoped.

chris.

[PyjamaSam]

Hey no problem at all, I just wanted to help a bit testing your fork
P.S. I compiled with the matrix set to 9...if can change something considering that I don't use the panel nor the ethernet module, only usb connection.

Ok I finally got out and tried the firmware on my printer.

I ran a print with no filament just to be safe and everything worked as expected (though I realize this doesn't give a super good indication if things are moving flat and at the expected height - I just wanted to make sure the building wouldn't blow up after all the merging).

I am running a print right now and things look "ok". My calibration seems to be a little out right now on the left and right out my bed (the head is too high)... But the printer has been out in the relative cold for over 2 weeks without use, so it might just be off and need a little tweaking. Nothing that concerns me.

I'll re-run the calibration routine with the new firmware and see how things go (I am especially interested to see how what the new zprobe code produces on my printer with respect to reproducibility).

And for reference I am running with the following modules disabled:

Code: Select all

tools/drillingcycles tools/filamentdetector tools/laser tools/scaracal tools/spindle utils/panel tools/touchprobe

as well as

Code: Select all

export NONETWORK = 1

set in my make file.

@FRANCO888999: One thing that might be effecting things is your use of a matrix with a size 9... Is your existing calibration file from when you used a size of 7? Though now that I look at the code it bails out if it doesn't find the correct number of elements when loading the file. So I don't think thats it. But it might just be a fun experiment to compile setting DM_GRID_ELEMENTS back to 7 and see if you get the same behaviour.

I'll keep running and testing with a firmware built from my branch, and I'll keep syncing it with the upstream smoothie edge branch and we'll see where we go from there.

chris.

[PyjamaSam]

@FRANCO888999: One thing that might be effecting things is your use of a matrix with a size 9... Is your existing calibration file from when you used a size of 7? Though now that I look at the code it bails out if it doesn't find the correct number of elements when loading the file. So I don't think thats it. But it might just be a fun experiment to compile setting DM_GRID_ELEMENTS back to 7 and see if you get the same behaviour.

Just thought of this. If it is ignoring your correction file because it doesn't have enough points in it you might be seeing movement that isn't tracking like you expected. Could be the reason its out. Though depending on the distance its out it might not be this. Hahaha.. So really what I am saying is I have no idea.

chris.

[626Pilot]

I got an email from the FirePick team about the possibility of adapting my calibration system to work on their robot. (It's an old-style delta with overhead rotating arms, rather than "linear" like ours.) I'm adding support to specify build area shape (round or square) with a config option, as they requested, because their robot has a square build surface. I will also help them adapt the routines to talk to their kinematics, which are very different from ours, but should respond about the same. I will be spending some time modularizing the code in two ways:

• Allowing selection of different kinematic systems, and adding an option to choose linear or rotational delta.
• Allowing selection of different heuristic calibration systems. This will allow me to offer schemes other than simulated annealing, such as the math used by dc42's Duet firmware.

I'm also bringing my fork up to date with the main Smoothie repo. I have the basic merge part done, and am currently working on getting the config files up to date. This has historically been torturous, because my config files are re-organized into sections so that it's easier to find what you're looking for. Diffs of .ini-like files are much harder to fathom than diffs of source code. To that end, I'm releasing a tool that will do two things. First, it will find any keywords that are present in the upstream (main Smoothie) config, but not in your local config. That will tell you any new options that you should copy into your config.

Second, it will tell you what options exist in your config, but not in the upstream config. This will tell you about any potentially obsolete options that have been retired. (It will also flag all the options I've put into my branch that don't exist upstream, so you can ignore most/all of that output.)

It will be included with my next commit, which I think will be in the next few days. In the mean time, if you want to take a look, it's here: http://pastebin.com/WCwXGQFv

The tool runs on Linux under bash. If you have Mac OS X, you may be able to run it in a terminal; obviously you would need to install the bash package (however you do that). If you have Windows, you will need to install cygwin (free). I'm not able to support this tool under any platform other than Linux. If someone wants to port it to run in JavaScript on a browser, that would make it run for everyone.

[626Pilot]

pyjamasam -

I'm including your excellent dm_surface_transform visualizer in my next release. I've put in instructions on how to install matplotlib for python, and modified the script so that it automatically looks for dm_surface_transform in the current directory. You have been credited, and a link has been included to your source on gist. If you don't want me to include the script (so people have to go to your gist to get it), let me know and I'll remove it.

For anyone curious, this is what the visualizer looks like. It lets you pan around!

I saw you've been having a few issues with your fork of my fork. Thanks for figuring out the new way to hand arrays to the FK/IK methods. Copying the array subscripts into a new array that those methods understand is alright. However, you forgot to copy the output back into the main array after the first call you modified. I fixed this on my side. I also noticed one of your commit comments is that you've disabled stuff because you're crashing. This is because you have enlarged the probing grid from 7x7 to 9x9. It may not seem like a large increase, but doing that requires significantly more memory. There are places where this can be addressed. For example, right now, we have some 2D arrays that contain XYZ coordinates (XY for bed position, Z for vertical deflection relative to bed center). The bed position subscripts of these arrays can be dropped in favor of calculating the coordinates every time we need them. This is a little slower than reading them out of an array, but not much. It requires a few adds, subs, and muls, but that's it. The relevant code is in ComprehensiveDeltaStrategy::init_test_points(). I will look into that in a future release.

[626Pilot]

OK, I have a new release: Right-click, save as.

I tested the motion control, but not the calibration, because I don't have a mount for my probe right now. (Waiting on a new nozzle from E3D - should get here around Wednesday.) If someone can do the usual run-through (G29, G32, G31 HOQR, G31 A), let me know how it goes.

New stuff:

• Added support for specifying the bed shape (round or square). Search for probe_bed_shape here and make the appropriate addition to your config. Or, don't. It will default to round, which is what you want.
• Added ConfigComparator.sh to the ConfigSamples directory. Its purpose is to help you figure out whether your file is missing any new options, or holding on to any that have been changed or removed (such as the pause button options - that was renamed from pause to kill!) Run without args for help.
• Added pyjamasam's dm_surface_transform visualizer to the Smoothie root directory. Drop dm_surface_transform into the same directory and run: python dm_surface_analyzer.py. You need to have python and matplotlib installed. Instructions are in the comments at the top of the script.
• Updated code to work with the new ActuatorCoordinates struct.
• Fixed possible bug concerning probe_ignore_bed_temp. Made on_config_reload() use as_int() rather than as_number() for int values.

[PyjamaSam]

...You have been credited, and a link has been included to your source on gist. If you don't want me to include the script (so people have to go to your gist to get it), let me know and I'll remove it...

No probs. Include it away. It's all good.

...I saw you've been having a few issues with your fork of my fork....

Ya I also didn't actually activate the ComprehensiveDeltaStrategy at one point and slammed my probe into the bed a few more times that I really liked to... Hahaha.

I think I'll sync up with your edge and just keep the fork around for bug fixes and contributions now that your synced with upstream. Nice stuff. Glad for the little help I could provide.

Also that ConfigComparator script is great. Thanks for that.

Appologies for the delays in responding. Apparently the email alerts on this thread aren't actually getting to my inbox.

chris.

[AEK]

Hello 626 Pilot,

Thank you for spending the time to update the firmware.

After spending many long hours trying the new firmware and switching back and forth from the Sept 19th to the March 5th firmware, I have encountered some issues with the new one.
I made sure my config was all edited based on your latest config and did the usual process that I've been doing successfully and achieving incredible results with the Sept 19th firmware.

My setup: Rostock Max V2/Smoothieboard latest version/FSR's with custom machined supports/tricklaser arms and the list goes one...

I was always been able to get a perfect scores with G29E but with the new FW I was getting awfull scores, "saying...check your wiring of belts..."
The homing was very smooth on previous FW, went up gently, triggered the end stop came down and back up stopping at the triggered end stop.
With new FW, it homes very obruptlty, repeats its self twice and stop about 5mm under the switch.

Once I'm completed the entire process, G29E, G32, G31HOQR (x5), G31A. I check bed centre and the result are never the same, either sits about 10mm off the bed or it pins the paper extremely hard. Even if I manually set the Z height, The calibration is completely off all over the bed, I have tried this many times over and over to achieve good results and it was impossible for me. I have formatted the Sd card numerous times/ flashing the firmware...I tried everything, thinking could it be me doing something wrong.

So now im back to the older FW and everything is back to normal.

Just thought I would share this with you and maybe help narrow down the problems.
No sure if any one other than me encountered these issues.

Thank you
AEK

[626Pilot]

AEK, thanks for helping out.

E3D screwed up. I ordered some new nozzles from them last Wednesday, thinking they would be here by about Wednesday of this week. They have been sitting on my order for the last six days, with no comment about why they haven't touched it yet. Without a new nozzle, I can't print a probe mount, so I'm stuck waiting for them. I sent them an email earlier today, asking what the hold-up is, and asking whether they might overnight me the nozzles, since it's entirely their fault, and this is causing problems for me.

Unfortunatley, Filastruder doesn't carry Cyclops nozzles, so I'm outta luck. I have to get them from E3D.

Anyway. This new release incorporates a lot of new code from Smoothie. I haven't touched any of the homing code, but I do notice the homing sequence is slightly different from how it was before. The carriages seem to back off a little from the endstop switches now - don't know why. I also don't know why it would be homing "abruptly," but you might want to try reducing the homing speed.

As for the rest, I'll have to try it for myself after I've got a probe mount.