Heuristic (AI) calibration for delta printers on Smoothie

[626Pilot]

I don't immediately see anything missing from the config, but it's kind of hard to tell with hundreds of options. I've been wanting to write a shell script to parse two config files and tell which options are set in one and not the other, but haven't got around to it yet.

Can you post the console output from when it runs and then crashes? Does it always freeze in the exact same place, or does it change from time to time?

[[email protected]]

I ran G29 and G32 then G31 A it worked fine. I will include Overide and map file

[[email protected]]

When I took the entire config sample from git and made changes only for viki2 and other setting for bed and hotend, the crash happened before the first probe but z moved towards the bed 2 inches, the first config fie that I copy and pasted to, the crash was after the first probe. I am printing your x5 mounting plate right now after that I will copy feed.

[[email protected]]

Could the viki2 be hogging to much memory or processing power?

[Nylocke]

I've been having a similar hard crashing problem. I suspected the small PSU I'm using (just a 5 amp one, enough to run the steppers and hotend). If the panel is enabled and I turn on just the hotend its fine. If I turn on just the motors (as in I home, G28) its fine, but as soon as I turn on both it hard crashes (and if its connected to my computer it can even crash my computer). If I disable the Viki2 in the config file all is fine, I had to do that to get a print off on the Mini Kossel. Also running an X5 mini.

[JFettig]

So, with this people are actually getting better x-y accuracy too? My accuracy is terrible on my machine, I'm tempted to install a smoothie temporarily while I build another printer just so I can build accurate parts if this is working.

Do you have any actual before and after measurements?

[Polygonhell]

With equivalent settings it shouldn't have any effect on accuracy, that's largely limited by the mechanical aspects of the machine. Using 32x uStepping might help marginally, but uSteps are more about smooth motion than they are about more accuracy.

[[email protected]]

I am running a HP poweredge 6800 12v 100amp power supply, I do not think my problem is power.

[[email protected]]

The panel has some effect, disabled and unplugged viki2 and made it 5 probes then locked.

18:17:47.256 :
18:17:47.256 : [HC] Heuristic calibration in progress. Press Reset to abort.
18:17:47.256 : [HC] /!\ PROBE CRASH DANGER /!\ Don't press buttons, send commands, or access the SD card.
18:17:47.256 :
18:17:47.256 : [HC] Data source: Probe
18:17:47.256 : [HC] Active tests: [Endstops (O), mul=1.00] [Delta Radius (P), mul=1.00] [Arm Length (Q), mul=1.00] [Tower Angle Offset (R), mul=1.00] [Virtual Shimming (S), mul=1.00]
18:17:47.256 : [HC] Inactive tests:
18:17:47.256 : [HC] Keep last settings (K): false
18:17:47.256 : [HC] Annealing tries (T): 50
18:17:47.256 : [HC] Max temp (U): 0.350
18:17:47.256 : [HC] Binary search width (V): 0.100
18:17:47.256 : [HC] Overrun divisor (W): 2.000
18:17:47.256 : [HC] Zero all offsets (Y): false
18:17:47.256 :
18:17:47.256 : [HC] Baseline kinematics updated.
18:17:47.256 : [HC] Keeping existing kinematics.
18:17:47.256 : [HC] Depth-mapping the print surface...
18:17:47.256 : [PK] Arm length: 269.000
18:17:47.256 : [PK] Delta radius: 133.029
18:17:47.256 : [PK] Endstop offsets: {-0.512, 0.000, -0.236}
18:17:47.256 : [PK] Radius offsets (ABC): {0.000, 0.000, 0.000}
18:17:47.256 : [PK] Angle offsets (DEF): {0.000, 0.000, 0.000}
18:17:47.256 : [PK] Virtual shimming: {0.000, 0.000, 0.000}, vector={0.000, 0.000, 1.000}, d=0.000, enabled
18:17:47.256 : [PK] Depth (Z) correction: disabled
18:17:54.147 : [BH] Determining the probe-from height.
18:18:21.542 : [PR] Priming probe 5 times.
18:18:55.253 : A device attached to the system is not functioning.

18:18:59.450 : Smoothie
18:18:59.496 : Begin file list
18:18:59.496 : system volume information/
18:18:59.496 : firmware.cur
18:18:59.496 : config-override
18:18:59.496 : dm_surface_transform
18:18:59.496 : config.txt
18:18:59.496 : ccc.gco
18:18:59.496 : End file list
18:20:23.841 : Smoothie
18:20:23.887 : Begin file list
18:20:23.887 : system volume information/
18:20:23.887 : firmware.cur
18:20:23.887 : config-override
18:20:23.887 : dm_surface_transform
18:20:23.887 : config.txt
18:20:23.887 : ccc.gco
18:20:23.887 : End file list
18:21:00.700 :
18:21:00.700 : [HC] Heuristic calibration in progress. Press Reset to abort.
18:21:00.700 : [HC] /!\ PROBE CRASH DANGER /!\ Don't press buttons, send commands, or access the SD card.
18:21:00.700 :
18:21:00.700 : [HC] Data source: Probe
18:21:00.700 : [HC] Active tests: [Endstops (O), mul=1.00] [Delta Radius (P), mul=1.00] [Arm Length (Q), mul=1.00] [Tower Angle Offset (R), mul=1.00] [Virtual Shimming (S), mul=1.00]
18:21:00.700 : [HC] Inactive tests:
18:21:00.700 : [HC] Keep last settings (K): false
18:21:00.700 : [HC] Annealing tries (T): 50
18:21:00.700 : [HC] Max temp (U): 0.350
18:21:00.700 : [HC] Binary search width (V): 0.100
18:21:00.700 : [HC] Overrun divisor (W): 2.000
18:21:00.700 : [HC] Zero all offsets (Y): false
18:21:00.700 :
18:21:00.700 : [HC] Baseline kinematics updated.
18:21:00.700 : [HC] Keeping existing kinematics.
18:21:00.700 : [HC] Depth-mapping the print surface...
18:21:00.700 : [PK] Arm length: 269.000
18:21:00.700 : [PK] Delta radius: 133.029
18:21:00.700 : [PK] Endstop offsets: {-0.512, 0.000, -0.236}
18:21:00.700 : [PK] Radius offsets (ABC): {0.000, 0.000, 0.000}
18:21:00.700 : [PK] Angle offsets (DEF): {0.000, 0.000, 0.000}
18:21:00.700 : [PK] Virtual shimming: {0.000, 0.000, 0.000}, vector={0.000, 0.000, 1.000}, d=0.000, enabled
18:21:00.700 : [PK] Depth (Z) correction: disabled
18:21:07.607 : [BH] Determining the probe-from height.
18:21:35.007 : [PR] Priming probe 5 times.
Here is Log

[JeremyDK]

I'm having a slightly different issue. I've successfully probed, and built out the depth map, but now whenever I send an absolute move (I.e. G0 Z100), my effector crashes into my print surface. Relative moves through Pronterface work fine, but I'm not sure what is going on.

I can run a G28, G30, and then a G0 Z xx.x to go down .1 mm, and still end up with a head crash.

Any thoughts?

[[email protected]]

I hate Pronterface, had nothing but face palms and double face palms. got repieter host working and now all the weird crashes are no more. I not saying it was the software, just my lack of familiarity with setup. I did crash head into bed several times, which I had not done in the past.

[626Pilot]

If you are getting crashes during probing, try turning off smooth deceleration in the config. I fixed some problems with that a couple of pushes ago, but that was usually where it crashed for me, and you will turn off some new code if you disable that feature.

I was also getting head crashes in one particular location. It would probe fine until it got to the end of the 4th row, and then it would crash the probe into the surface. After scratching my head for awhile, I realized it was a wiring problem. The wires connecting the probe, when they were in that one exact angle, would come loose for some reason. I lashed the wire to a screw bolted to the effector, and the problem ceased. So, if it seems to run but then always probe-crashes in the same place, double-check your wiring! If you're using the Hall-O probe, there is a little light that comes on when it triggers. Watch that carefully. That's how I finally figured it out. If your probe doesn't have a light, maybe think about soldering something up!

I developed and tested without an LCD panel hooked up. They do consume significant RAM, so it might be necessary to leave that turned off. Smoothie already runs with only a few KB to spare. It would've been better if they had spent an extra few dollars to get a CPU with more memory, but this is what we have to work with for now. They are working on porting Smoothie to the new hybrid Intel platform with multiple CPUs and lots more RAM, so maybe in a year or two such problems will go away.

[[email protected]]

smooth deceleration ?
zprobe.decelerate_on_trigger, Comment this out?

[Nylocke]

How do all those other people run with the whole fancy delta setup and the panel? Ive seen numerous videos of different Rostock and Kossel designs doing this sort of thing. I'm assuming they are all using G32 to calibrate their printers, any other way is a bit of a PIA with smoothie.

The other issue I'm having is M500 is refusing to actually save a config override file. I type in the command, it recognizes it, and if I use M503 to check if theres an override present it tells me there is, and its using all the data, but as soon as I power off the printer everything gets reset. Z height, arm radius, tower offsets. I'm running the latest smoothie from the github. I haven't had a chance to figure out how to build your version quite yet (though when I do that is definitely going onto it). I know you mentioned some issue with M500, but I'm not quite sure if the issue I'm having is the same issue that you identified. It almost seems like the file isn't even being created, I don't see one on the SD card? I even tried making a config-override file myself and nothing got saved to it.

[JeremyDK]

Any thoughts on my issue? Gonna have to roll firmware back to edge because I'm completely stuck after this calibration.

[Nylocke]

Is you Z-height set correctly? I don't think the smoothie calibration sets z-height.

[JeremyDK]

Running a G30 outputs the correct Z height, and that's within 1-2mm of what is in my config. Doesn't explain me running a G0 Z220 and still crashing into glass.

[626Pilot]

smooth deceleration ?
zprobe.decelerate_on_trigger, Comment this out?

Set it to false.

The other issue I'm having is M500 is refusing to actually save a config override file.

There is a bug in older versions of Smoothie that has since been fixed. It corrupted config-override. If you use newer firmware (like mine) you should be set.

Running a G30 outputs the correct Z height, and that's within 1-2mm of what is in my config. Doesn't explain me running a G0 Z220 and still crashing into glass.

Probably the probe offset in config is wrong. Type M503. Find the output where it says M665 Zsomething. That is the Z height it's using for the printer. G28. Jog the hot end down until it snags the paper. Take the difference between that and the Z-value of M665 to find what the value should actually be. Type M665 Z(correct number you calculated). G28, G1 Z10 or whatever, then carefully jog down to 0, at which it point it should be snagging the paper again. Then, M500 to save.

[Nylocke]

I updated it on Friday to the latest firmware.bin on the Github though? Is there a newer version that I'm missing?

[626Pilot]

I updated it on Friday to the latest firmware.bin on the Github though? Is there a newer version that I'm missing?

If there's a firmware.bin on my github, it's out of date. You have to build it for now.

[Nylocke]

I was referring to the main branch of smoothie. I haven't taken the time to figure out building smoothie yet.

[Tonkabot]

Here is a possible laser option.
http://hackaday.com/2014/03/29/hacking- ... asy-steps/" onclick="window.open(this.href);return false;

You can see from the display in the picture that it took three readings, and they all were within 83mm of each other.

A time of flight laser sensor is never going to be cost effective for these 3d printers, assuming you could get a reasonable accuracy.

There is a new one-chip TOF sensor I was looking at, it looked like it only varied by 10mm or so - again, not useful for replacing a dial gauge. it did look useful for keeping a robot from running into walls...

[626Pilot]

Filed a ticket with the dude who maintains Repetier firmware: https://github.com/repetier/Repetier-Fi ... issues/367" onclick="window.open(this.href);return false;

I don't know if he'll care that much. If you care, please post in the ticket to show your support.

[JeremyDK]

Probably the probe offset in config is wrong. Type M503. Find the output where it says M665 Zsomething. That is the Z height it's using for the printer. G28. Jog the hot end down until it snags the paper. Take the difference between that and the Z-value of M665 to find what the value should actually be. Type M665 Z(correct number you calculated). G28, G1 Z10 or whatever, then carefully jog down to 0, at which it point it should be snagging the paper again. Then, M500 to save.

No luck. Config has probe offset of X0 Y0 Z0 (Using nozzle + FSRs).

Ran a G28.


M503
23:06:29.891 : ;Max Z
23:06:29.891 : M665 Z230.130

Running a G30
23:07:54.534 Z:233.4600 C:46692

Should be safe running a G0 Z230 (i.e. a 3mm move), but instead it will crash into bed if I let it. Using relative moves via Repatier Host/Pronterface GUI moves the correct amount, and I was printing fine prior to this calibration.


edit:

Might be working. Manually jogged to pinch paper, ran a G92 X0 Y0 Z0. I have no idea what crept into the config that made it get so weird, but so it goes.

edit2:
Doing the above let a G0 work. I have G28/G30 in my start gcode, and a test print nailed the bed. It looks like the problem is in G30. If I don't run a G30, the G0 commands work as expected. I think the way G30 sets the bed height (overriding M665) is interacting with the calibration offsets, but I'd have to dig through your code.

edit3:
Multiple repros. G30 is what is causing this behavior for me.

[626Pilot]

I had some issues with G30 before, but I thought I had them fixed. I'll have to look into it the next time I'm working on the code. Thanks for figuring out the problem!