Heuristic (AI) calibration for delta printers on Smoothie

[WZ9V]

I'm trying to use this calibration on my Smoothie V-Slot 250.

I get a probe repeatability within 2 steps.
My iterative got down to 0.025
My heuristic energy is 0.034
I did a bed mapping.

When I do a 210mm circle, the effector almost seems like it's on a roller coaster as it goes around. I've checked the towers and they are level with the bed. What should I check?

BTW 220mm is about the maximum diameter I can hit on this 250mm bed before carriages might have trouble and run past the bottom on moves.

[626Pilot]

What is your probing radius set to? Do you have any photos of the printer?

[WZ9V]

It's a standard Ultibots V-Slot 250. I have the probing radius set to 100 because the micro switch is offset a bit since I have to attach it to the part fan. I started having some other weird issues also. I suspect the AZSMZ Mini maybe part of the problem. It's started having weird problems like I edit the config, eject the drive, reboot and the edit to the config is gone. The part fan mosfet also seems to have taken a permanent vacation. I have an actual SmoothieBoard 5XC I'm going to swap in and retry.

[626Pilot]

Avoid using an offset probe to calibrate a delta printer like the plague. You will never get the best calibration possible.

Probe radius is 100mm, circle radius is 110mm (I assume), so the firmware is basically guessing what the height is beyond the probe radius by projecting the edge of the probing circle outwards along the X axis. An approximation, and not one that can work very well, although better than other firmwares that just assume zero offset outside the probing circle.

To edit config on Smoothie, assuming you're using FTP or mounting the SD card over USB, first you have to make sure you haven't done anything that would cause Smoothie to write any data to the card (like sending M500) since it was last turned on. You can mount it over USB or edit over FTP. After that, you have to "safely eject" the card after you're done editing it, and power cycle the printer. Smoothie's FS implementation doesn't resync the file allocation table after you write data over USB/network, and if you edit a file that way and then (for example) send M500, it will blindly corrupt your files. This is an awfully stupid behavior, one that can utterly trash your carefully-perfected settings, and one I wish they'd fix.

[WZ9V]

OK. Yeah, it's way to easy to corrupt the SD Card on a Smoothie. Unfortunately because of the V-Slots setup with a direct extruder I'm stuck with an offset probe unless I use FSRs and I found the FSR setup to be less than reliable due to smoothie wanting to probe in the most unsupported spots on the bed. The V-slot uses three mount points on the extrusions so the mounts are between towers and smoothie probes at the towers. It needs something like the snowflake under the Onyx.

[626Pilot]

If I was in your position, I'd build a temporary mount that screws down to the effector, goes down and around the hot end, and places the probe dead center beneath the hot end nozzle. Since discovering that offset probing is a pain on deltas, my solution has been to simply remove the hot end and replace it with a probe, and then put the hot end back when I'm done.

Unless the printer is moved or knocked into hard, or you do some mechanical work like changing out the arms or re-tightening the belts/frame, it's not likely that you'll need to re-run the calibration. If you change out the hot end, or take the nozzle out of the hot end to blow-torch some gunk out of it, it would probably change the Z height by a fraction of a millimeter, but the calibration would be otherwise unaffected.

[courcirc8]

Hello 626Pilot,
First of all thank you very much for your very good work on delta calibration. I tried it with resonably good result (for me simulated annealing did not improved significantly but Zmapping did a great job).
I was wondering if it is possible to go back to the original smoothie firmware once the calibration is done in order to benefit from the last updates?
Thx again

[626Pilot]

The heightmapping portion doesn't work without my firmware.

If there have been significant changes recently, I can pull them into my branch. I think they've added a new G29 code, which I already used for my probe calibration, so perhaps some reworking needs to be done.

[courcirc8]

Thank you for your fast answer 626Pilot!
Just a general comment for users. I ordered different stepper drivers (Raps128 and Silencioso) using the same THB6128 chip able to do 128 microstepps and I can see this improved significantly my probe repeatability by eliminating most of the vibrations at low speed.Of course better probe mean better overall calibration.
Surprisingly I also replaced my mechanical zprobe by a contact btw aluminium bed and nozzle and it works much better. For sure you can't do it often because you need a VERY clean bed and nozzle but this have no offset by design. If you try this method, be very careful, aluminium oxidize naturally with oxygen, and the oxide is .. isolating. So I do not really advise the method (you can damage your bed if you are not careful), but it is cheap...

[626Pilot]

I was talking to Haydn (from the deltabot forum) about dimensional accuracy on delta printers, and he suggested calibrating with a fixed arm length rather than letting the software mess with it. I tried this on dc42's Duet fork, and discovered that even though you send G32 S6 instead of S7, it acts as though you had sent S7. (Ditto S4... guess the version I have is broken.) Maybe he has a newer firmware that fixes this issue, but I've been looking for an excuse to come back to Smoothie, and now I have it.

I will miss that awesome web interface, but the basic Smoothie one is functional enough. Anyway, I'm back to developing and printing with Smoothie on a daily basis. At the moment, I'm tweaking a couple things that might help probe repeatability.

If you find that you're not getting dimensionally accurate prints, try setting your arm length to the manufacturer's value:
- 269mm for old SeeMeCNC arms
- 290mm for new SeeMeCNC ball-cup arms
- 269mm or 300mm for Trick Laser arms

(e.g.: M665 L300)

Then, try running the calibration again, and see what it does. It might not give the same low "energy" you got before, but it's more important to chase accuracy than numbers. Mine and dc42's firmware both like to adjust the arm length to "make the numbers fit better," but if we already know the arms are 269mm, and the firmware is pushing it to 271 or something, that's wrong and we don't want it!

My next work with Smoothie will be to work on reducing memory consumption so that people can (hopefully) run panels and other stuff.

[courcirc8]

We are glad to hear that you are are back on the smoothie platform! Solving the memory size problem would be a big plus indeed!
It's a pity that smoothie does not have more memory. Imagine the same firmware on something like that:
https://developer.mbed.org/platforms/ST ... ry-F746NG/" onclick="window.open(this.href);return false;
M7 @ 216MHz, 320k Sram, FPu, color LCD for less than 50$!
If somebody wants to make the software migration, I will do the hardware module! (stepper control and switches)

[mhackney]

@626Pilot - how do you typically configure and run your firmware and smoothie to run on a daily basis?

Cheers,
Michael

[mhackney]

re: the S6 parameter - I just verified that it is NOT calculating the diagonal arm length on the 1.09k-dc42 version. Either that or it is calculating the exact same arm length on every run!

I agree with Haydn, I always calibrate with fixed arm length. Arm length has an impact on the dimensional accuracy of your part as it affects Z scaling significantly so I want to hold that constant once I've determined the correct arm length from measurement first and test prints to refine. It is a bit of an iterative process but usually no more than 2 iterations required.

I still have one delta running smoothie. I don't want to take my foot out of that camp as it is not clear who the "winner" will be. I do think these are the two front runners but each has its wrinkles. From an overall day-to-day operational aspect, dc42 works best for me right now.

[626Pilot]

If somebody wants to make the software migration, I will do the hardware module! (stepper control and switches)

It would be really nice if someone made a "shield" for Smoothie that would plug into the external driver ports, the ones you have to solder pin headers to if you want to use external drivers, and use that to drive some chips with 256x microstepping. Smoothie has 16x and Duet has 32x, and I notice that my probe seems to have better repeatability on Duet. A couple extra stepper drivers would be nice, too, although they would probably require hooking up a shift register to the serial port somehow. Smoothie doesn't expose many of the GPIO pins.

@626Pilot - how do you typically configure and run your firmware and smoothie to run on a daily basis?

Upload file over USB, unmount, power cycle (so it doesn't corrupt its own FS), connect via Repetier Host, tell it to play the G-code file, make sure it isn't set to query bed/probe temperature, and then disconnect while it prints. That last is because if Repetier asks it what the temperature is and disconnects before it receives the answer, it will stall the serial queue and freeze the board.

There is some data that's stored redundantly in arrays, and other data that could be cheaply calculated in real time rather than fetched from an array. Those are the first things I want to attack. After that, I would like to move the online help stuff into a text file that would be read off the board, so it doesn't occupy so much space in the flash EEPROM.

The lack of a panel is annoying. If I can't get the RAM usage down enough to run a panel, I might get one of the MatterControl tablets. Don't think I'd use the slicer, but everything else looks good.

re: the S6 parameter - I just verified that it is NOT calculating the diagonal arm length on the 1.09k-dc42 version. Either that or it is calculating the exact same arm length on every run!

Do M665 L(some integer) and see if that happens. I think I was running 1.09k and it would always say that it had calibrated 7 parameters, no matter what. I'm not totally positive on that. Could be I'm running an older version.

I still have one delta running smoothie. I don't want to take my foot out of that camp as it is not clear who the "winner" will be. I do think these are the two front runners but each has its wrinkles. From an overall day-to-day operational aspect, dc42 works best for me right now.

Once the SB2 is out, I think there will be very little reason to buy a Duet. It'll have enough drivers to run just about anything, lots of RAM, and an Edison socket. 256x microstepping too, if I'm not mistaken.

[mhackney]

The M665 will display the delta configuration - including the arm length even if it was not changed. When I do an M665 (I actually have that added to the menu in the web interface for convenience) from calibration run to calibration run (s=6) the L value never changes - it is set to the value I calculated to calibrate my Z.

My workflow with Duet is about as simple as it gets. I bring everything up to temp, then calibrate (30 sec) and then upload gcode via the web interface (if not already on the memory card) and print either from the web interface or PanelDue. Since I have my Duet on wifi this is convenient, I don't even have the USB connected unless it's time to refresh for a firmware update.

I've not been able to duplicate this simplicity with smoothie (yet). Transferring gcode to the smoothie is a pain in my experience. The whole mounting/unmounting is just a little too much friction and error prone for me. Hopefully the v2 will have some updates to USB and ethernet that enable better support for the firmware.

[626Pilot]

I believe the new microcontroller has native SDIO, rather than using a dog slow I2C adapter.

I used to print on Smoothie directly from Rep Host, which is as simple as it gets, or would be if Rep Host didn't like to crash 9 hours into a print for no discernible reason. Maybe the Matter Control tablet is better.

[626Pilot]

Well! I reorganized ZProbe.cpp's wait_for_probe() method very slightly, and now I'm getting MUCH better repeatability:

Code: Select all

20:46:42.740 : [PR]    Repeatability test: 10 samples (S)
20:46:42.741 : [PR]      Acceleration (A): 100.0
20:46:42.741 : [PR]    Debounce count (B): 100
20:46:42.751 : [PR]  Smooth decel (D0|D1): False
20:46:42.751 : [PR] Eccentricity test (E): On
20:46:42.751 : [PR]   Probe smoothing (P): 1
20:46:42.751 : [PR]     Probe priming (Q): 0
20:46:42.751 : [PR]             Feedrates: Fast (U) = 75.000, Slow (V) = 10.000
20:46:42.751 : [PR] 1 step = 0.00625 mm.
20:46:46.677 : [BH] Determining the probe-from height.
20:46:55.178 : [BH] Probe-from height = 325.188
20:47:01.201 : [BH] Bed height set to 315.612
20:47:13.279 : [PR] Test  1 of 10: Measured 1547 steps (9.669 mm)
[...]
20:47:46.653 : [PR] Test 10 of 10: Measured 1547 steps (9.669 mm)
20:47:46.653 : [PR] Stats:
20:47:46.653 : [PR]   range: 1 steps (0.0063 mm)
20:47:46.660 : [PR]      mu: 1547.400 steps (9.671 mm)
20:47:46.660 : [PR]   sigma: 0.490 steps (0.003 mm)
20:47:46.660 : [PR] Repeatability: 0.0063 (add a little to be sure)
20:47:46.660 : [PR] This is your best score so far!
20:47:46.660 : [PR] This score is very good!

Hmm, not too bad. Let's try again...

Code: Select all

20:47:50.860 : [PR]    Repeatability test: 10 samples (S)
20:47:50.860 : [PR]      Acceleration (A): 100.0
20:47:50.860 : [PR]    Debounce count (B): 100
20:47:50.871 : [PR]  Smooth decel (D0|D1): False
20:47:50.872 : [PR] Eccentricity test (E): On
20:47:50.872 : [PR]   Probe smoothing (P): 1
20:47:50.872 : [PR]     Probe priming (Q): 0
20:47:50.872 : [PR]             Feedrates: Fast (U) = 75.000, Slow (V) = 10.000
20:47:50.872 : [PR] 1 step = 0.00625 mm.
20:48:02.949 : [PR] Test  1 of 10: Measured 1544 steps (9.650 mm)
[...]
20:48:36.288 : [PR] Test 10 of 10: Measured 1544 steps (9.650 mm)
20:48:36.288 : [PR] Stats:
20:48:36.288 : [PR]   range: 0 steps (0.0000 mm)
20:48:36.295 : [PR]      mu: 1544.000 steps (9.650 mm)
20:48:36.295 : [PR]   sigma: 0.000 steps (0.000 mm)
20:48:36.295 : [PR] Repeatability: 0.0000 (add a little to be sure)
20:48:36.295 : [PR] This is your best score so far!
20:48:36.295 : [PR] This score is very good!

Now, a test with 30 samples:

Code: Select all

20:56:17.328 : [PR]    Repeatability test: 30 samples (S)
20:56:17.328 : [PR]      Acceleration (A): 100.0
20:56:17.328 : [PR]    Debounce count (B): 1
20:56:17.338 : [PR]  Smooth decel (D0|D1): False
20:56:17.339 : [PR] Eccentricity test (E): On
20:56:17.339 : [PR]   Probe smoothing (P): 1
20:56:17.339 : [PR]     Probe priming (Q): 0
20:56:17.339 : [PR]             Feedrates: Fast (U) = 75.000, Slow (V) = 10.000
20:56:17.339 : [PR] 1 step = 0.00625 mm.
20:56:29.415 : [PR] Test  1 of 30: Measured 1544 steps (9.650 mm)
[...]
20:58:17.224 : [PR] Test 30 of 30: Measured 1544 steps (9.650 mm)
20:58:17.224 : [PR] Stats:
20:58:17.224 : [PR]   range: 1 steps (0.0063 mm)
20:58:17.239 : [PR]      mu: 1544.100 steps (9.651 mm)
20:58:17.239 : [PR]   sigma: 0.300 steps (0.002 mm)
20:58:17.239 : [PR] Repeatability: 0.0063 (add a little to be sure)
20:58:17.244 : [PR] Best score so far: [sigma=0.000, range=0] => accel=100.000000, debounce=100, decelerate=False, eccentricity=On, smoothing=1, priming=0, fastFR=75.000, slowFR=10.000
20:58:17.244 : [PR] This score is very good!

1 step of error on average, after 30 probes, and the effector is moved around between each probe to try to provoke any issues more realistically.

Before this, it was frequently... bad. It would sometimes abort the repeatability test because the results were too awful.

Assuming that it keeps working this well, this change will be featured in the next release!

[courcirc8]

It would be really nice if someone made a "shield" for Smoothie that would plug into the external driver ports, the ones you have to solder pin headers to if you want to use external drivers, and use that to drive some chips with 256x microstepping. Smoothie has 16x and Duet has 32x, and I notice that my probe seems to have better repeatability on Duet. A couple extra stepper drivers would be nice, too, although they would probably require hooking up a shift register to the serial port somehow. Smoothie doesn't expose many of the GPIO pins.

I soldered manually the 2 LCD connectors Ext1 Ext2 to the Ramps. Without any software modification you can have access to P1.30 P1.31 P3.25 P0.28 P3.26 and P0.9 to control 3 additional motors, which makes a total of 8 external motors if you re-use the existing stepper IOs (P0.4, P2.0, etc )
(P3.25 and P3.26 are PWM hardware capable pin, so better using it for step, but apparently Smoothie can do it SW as well...)
I'm currently testing the TH6128 that is used in RAPS128 and silencioso but do not have already the TMC260.
Surprisingly, if more micro-stepping seems good at very low speed, it is not always true at moderate or high speed. For example, I have a motor that generates a lot of vibrations at 40kHz step rate 128microstep (40000/200/128*60=93rpm). If I set it up at 64microstep, I get the same resonance but at 80kHz which correspond now to 375rpm, and 375rpm is equivalent to 80000/5/64=250mm/s which does not borrow me because it is outside my targeted print speed).
I pushed the resonance speed by a factor of 4 by lowering the step rate by 2, which is counter intuitive.
To summarize, I strongly suggest to test the combination stepper driver+stepper+supply voltage with a frequency generator before putting it in your machine and list the bad resonance frequency that may be generated by step size, but also by the update rate of the driver. Yes, the voltage plays some role too because it changes the frequency of the PWM that is generated. As a hardware engineer I have the feeling that vibrations are exited by an aliasing effect between PWM freq and stepping refresh rate and that better drivers could reduce the problem, but this is an other story...
By the way, I ordered the "smoothie clone" MKS SBase 1.2 for my second (home designed) printer which requests 8 steppers and I have to say that except the lower speed processor, the board quality is slightly superior at the SB (my apologies to Arthur). Yes this is not real open-source because you find the schematic only in pdf format (I needed more that one hour to find it ), but as I already bought a real SB, I feel ok...
So for me, the 5 included Ti driver DRV8825 are not that bad in 32microstep, superior to the Allegro ones, the LCD "adaptor" is build-in, there are heatsink for the MOS and a 5V step-down buck converter, and I forgot to mention for 1/3 of the SB price...

[626Pilot]

I came up with a couple improvements to the calibration process.

The first improvement is to try the calibration with the bed heat off/bed at room temperature, and then again at your preferred printing temperature. Accept the best of those two calibrations. Then, with the bed stabilized at printing temperature, do the Z correction. This way, you get the most accurate kinematics possible, with Z correction to account for whatever shape change the bed goes through when brought up to heat.

The second improvement involves making sure your prints are dimensionally accurate. It's possible to get a nice, low-energy calibration, but still have parts that are out of scale with the original model by a small (but significant) amount. The effect of this is magnified as the size of the print increases.

Start with the right calibration instruments. You'll need two.
You'll need an ACCURATE set of calipers, and an ACCURATE micrometer. Don't use crappy calipers with bad repeatability. Both of these tools are reasonably priced, and you will get LOADS of use out of them. You should be able to zero your calipers, open and shut the jaws a bunch of times, and see 0.00mm +-0.02mm every single time you close the jaws. If you're seeing some ridiculous BS like ~0.3mm, like I got on my old calipers, throw that crap in the trash and get something good!!!

REALLY calibrate your filament flow.
You need to make sure a 0.45mm (or whatever) extrusion is as close to that as possible. Due to die swell, it often isn't! Measure the filament in ten places, a foot apart, with a micrometer, not calipers. The one linked above has a low-torque ratchet so that it won't deform the filament. You twist the knob, and it will start clicking rather than tightening once it has applied a very small amount of pressure, thus ensuring a consistent measurement. Hold the filament so that its curvature passes through the pincers at a perpendicular angle. If you measure it perpendicular to the curve, what you measure will be flat. Otherwise, the thickness of the curve may throw your measurement slightly.

Tabulate the widths in a spreadsheet, take the average, and put it into the filament diameter section of your slicer. That done, print a small calibration box, one loop only, no infill, skin thickness=0. The point of this is to give you a wall one loop thick. Measure this in a bunch of places with a micrometer, or your normal calipers. You should see numbers within 0.02mm of the extrusion width you have in the slicer, but the first time you do this, you'll probably see around 0.1mm thicker! I commonly see numbers between 0.55 and 0.6 on a specified extrusion width of 0.45.

Go into your slicer. If the measured width is thinner than specified, increase the flow tweak. If it's thicker than specified, decrease the flow tweak. I find 0.9 to 0.95 is usually the right number. Keep doing this until you have a measured width as close as possible to specified. I can usually get this down to 0.02mm across most of the points I measure.

Find out & fix your scaling error.
Set your slicer to your usual preferred number of loops, infill, and skin thickness. Print a small calibration cube. I like to use a 25mm one. You should use something that large, if not larger. Then, measure the part with your calipers in several places. Is it exactly the specified size? If so, you're done! If not, you'll need to adjust your arm length.

On my printer, I did the 25mm cube with 300mm Trick Laser arms after carefully calibrating the filament flow as above. It came out at ~25.25mm on all three dimensions! Follow this math:

(Observed size / Specified size) * Current arm length setting = New arm length

In my case, that was:
25.25/25 = 1.01
* 300 = 303

I put in 303 as my arm length. I'm out of time for tonight, but I plan to try recalibrating with and without letting it touch the arm length. Whichever one is better, I'll take, and then I'll re-print the cube. I have a feeling that the longer arm length will tell the firmware not to push the effector as far, and that in turn will result in a part that's shrunk just the right amount to be 25mm as specified.

[courcirc8]

Many thanks for the update!
Is there any reason why you adjust the arm length and not the step/mm? Step/mm should impact only the physical dimensions and nothing else.

[626Pilot]

I added that feature to the calibration system a few months ago, but it never went anywhere so I took it out. It always wanted to keep the multiplier right at 1.0 until the annealing was nearly done, and then it would start fiddling with the multiplier and throw the whole calibration off exponentially. The kinematics equations produce output in axis millimeters, which then get turned into steps. If steps/mm is wrong, everything is wrong. The belts and pulleys are manufactured to precise standards, so I'm inclined to trust the number that comes from a belt calculator.

The arm length impacts scaling because it defines how far the effector moves from bed center. If it's too high, the robot won't push it as far as it should, and the print will be too small. If it's too low, the robot will push further than it should, and the print will be too big.

[626Pilot]

I was talking to dc42, author of the Duet fork with delta calibration, a few months back. He noted that my firmware uses the mean (average) of all deviations as the evaluation metric, whereas his uses RMS (root mean squared) as the eval metric. I decided to give Smoothie the ability to switch between using mean and RMS using an option with G31. The improvement with RMS has been marginal (like, 5-10 microns) so far. I'll include this feature in the next release, along with the improvement that makes probing more repeatable. Maybe the gain will be bigger for someone else than it is for me.

Code: Select all

3x with RMS
------------------------------------------
[PD]                                    0.112
[PD]
[PD] [  --  ]     0.044      0.025      0.013      0.013      0.050    [  --  ]
[PD]
[PD] [  --  ]     0.025      0.006     -0.013     -0.019      0.025    [  --  ]
[PD]
[PD]  -0.050      0.000      0.019      0.000      0.006      0.019      0.075
[PD]
[PD] [  --  ]     0.050      0.044      0.038      0.025      0.038    [  --  ]
[PD]
[PD] [  --  ]     0.038      0.056      0.056      0.044      0.025    [  --  ]
[PD]
[PD]                                   -0.019
[PD]
[PD] Best=0.000, worst=0.112, min=-0.050, max=0.112, mu=0.015, RMS=0.031, sigma=0.027, energy=0.041


3x with Mean (same starting point)
------------------------------------------
[PD]                                    0.100
[PD]
[PD] [  --  ]     0.075      0.038      0.025      0.013      0.031    [  --  ]
[PD]
[PD] [  --  ]     0.038      0.013      0.006      0.006      0.038    [  --  ]
[PD]
[PD]   0.000      0.006      0.025      0.000      0.031      0.044      0.075
[PD]
[PD] [  --  ]     0.056      0.044      0.038      0.044      0.056    [  --  ]
[PD]
[PD] [  --  ]     0.044      0.050      0.044      0.044      0.038    [  --  ]
[PD]
[PD]                                    0.006
[PD]
[PD] Best=0.000, worst=0.100, min=0.000, max=0.100, mu=0.021, RMS=0.033, sigma=0.025, energy=0.043

[PyjamaSam]

... I'll include this feature in the next release, along with the improvement that makes probing more repeatable....

First off let me say awesome work! I really like the additions you have added for us delta users. Really great stuff.

I have been running your fork for a little while now and I was able to get my delta noticeably better calibrated.
I have been using a IR probe (actually DC42's probe - its awesome) that I made a magnetic mount for (I am running magnetic arms so I can just easily stick it under the effector when I need to probe)

Believe it or not I actually hand tuned my dm_surface_transform file while printing a thin circular test pattern, as even though I ended up with an energy of 0.006 after doing a surface probe I still found that there were sections of the bed that were out and the head was a hair too high or too low.

I also created a quick and dirty python script to plot the dm_surface_transform file as a means to visualize the corrections being applied
https://gist.github.com/pyjamasam/7b1cc52be3647a16e075 (I know the Y axis numbering is backwards. I haven't bothered to fix it up yet, but the orientation of the graph is correct with respect to the X and Y annotation arrows)

I have noticed that there haven't been any checkins in a while to your repo, is there a branch you're working in (I'd love to follow along with your work in progress).

I have also been informally syncing things up between your branch and the official edge branch, but recently there were some major changes with regards to multiple actuators and the switch to the ActuatorCoordinates structure instead of an array of floats that's thrown me for a loop with regards to your code (I don't know it well enough yet to really convert things over). Do you have a plan on staying sync'ed with the official edge? Do you want help to do some of the grunt work (i.e. syncing all the other changes that don't really impact your code?)

Again great stuff with the fork. I look forward to your next release. Thanks for all your work.

chris.

[626Pilot]

I have been running your fork for a little while now and I was able to get my delta noticeably better calibrated.
I have been using a IR probe (actually DC42's probe - its awesome) that I made a magnetic mount for (I am running magnetic arms so I can just easily stick it under the effector when I need to probe)

I'm in the middle of figuring out how to get my MAX METAL converted to mag arms. What effector/carriages are you using, and where did you get your arms?

I also created a quick and dirty python script to plot the dm_surface_transform file as a means to visualize the corrections being applied
https://gist.github.com/pyjamasam/7b1cc52be3647a16e075 (I know the Y axis numbering is backwards. I haven't bothered to fix it up yet, but the orientation of the graph is correct with respect to the X and Y annotation arrows)

Cool. I might put a mention of this in the README. Could you put some comments at the top of that file about how to run it, commandline args or whatever?

I have noticed that there haven't been any checkins in a while to your repo, is there a branch you're working in (I'd love to follow along with your work in progress).

I think I did a push in October that brought in some upstream changes. I wasn't actively using the board at the time, as I had migrated to the Duet. I'm back now, and I intend to stay with Smoothie through the Smoothie 2 release next year and beyond. At the moment, I'm chasing down a couple of bugs and getting ready to merge in some changes from upstream.

I have also been informally syncing things up between your branch and the official edge branch, but recently there were some major changes with regards to multiple actuators and the switch to the ActuatorCoordinates structure instead of an array of floats that's thrown me for a loop with regards to your code (I don't know it well enough yet to really convert things over). Do you have a plan on staying sync'ed with the official edge? Do you want help to do some of the grunt work (i.e. syncing all the other changes that don't really impact your code?)

Sounds like a bit of trouble, but I can probably figure it out. I do know someone "took" G29, which I was already using for probe calibration, so that's a bother. I might take you up on that offer in the future. Merging in upstream changes has historically been a headache for me, but I'm getting better at it, as I need to. Nothing to do with their code quality, which is very good. It's just that the way git does stuff can be somewhat arcane.

[PyjamaSam]

I'm in the middle of figuring out how to get my MAX METAL converted to mag arms. What effector/carriages are you using, and where did you get your arms?

Hopefully I don't derail this thread too much I picked these up http://www.aliexpress.com/store/product ... 31967.html. I got them during the 11/11 sale and I am quite happy with them. The rods are sized for my kossel mini frame, so not sure how that will sync up with your max metal.

The seller does also sell sets of just the carriages alone, or the carriages and efector but no arms. There are a number of sellers selling the same aluminum parts, but this one had a sale and I have been happy with them for what it's worth (did take a bit to get from china, but I didn't bother to upgrade my shipping).

They also have effectors that have holes and effectors for dual extruders... Which is tempting Though I'd need to upgrade from my Azteeg X5 mini to something with a few more outputs Maybe a smothie2 hahah.

Cool. I might put a mention of this in the README. Could you put some comments at the top of that file about how to run it, commandline args or whatever?

I updated the gist. If you want to pull the gist down and add it as a file to the repo I am good with that as well. Whatever works for you.

I think I did a push in October that brought in some upstream changes. I wasn't actively using the board at the time, as I had migrated to the Duet. I'm back now, and I intend to stay with Smoothie through the Smoothie 2 release next year and beyond. At the moment, I'm chasing down a couple of bugs and getting ready to merge in some changes from upstream.

Nice. Looking forward to it.

Sounds like a bit of trouble, but I can probably figure it out. I do know someone "took" G29, which I was already using for probe calibration, so that's a bother. I might take you up on that offer in the future. Merging in upstream changes has historically been a headache for me, but I'm getting better at it, as I need to. Nothing to do with their code quality, which is very good. It's just that the way git does stuff can be somewhat arcane.

The change is really mostly a syntaxual one. The new class behaves like a array of floats, so really the code that uses it doesn't care, but when it gets passed to other methods it needs the correct method signature (which means that things need to change as we pass them into smothie core...) But you're allocating a lot of your floats arrays in AHB0 and I am not totally sure how that all works yet.

According to the smothieware site G31 is used to report the zprobe status (I think this is based out of the TouchProbe module based on what I can find), but G29 isn't listed.
G29 looks to be in use in DeltaCalibrationStrategy and ThreePointStrategy (it might be in another strategy but my quick grep of the code didn't turn up anything).
So when ComprehensiveDeltaStrategy is in play the other strategies aren't in use so G29 is freed up for use. My guess is that G29 is actually a better code to use then G31.

I agree with you on the quirks (and my understanding) of git... I tried to make a fork of your fork and then merge it back with the original edge..... Needless to say it was really unhappy with my attempts hahaha.

Needless to say, give me a shout if you want any help with anything, or if you want a 2nd set of eyes or somebody to test stuff

Oh ya... Happy New Year!

chris.