Welcome to the SeeMeCNC Community

Posted: **Mon Feb 23, 2015 6:58 pm**

I built your branch and uploaded it to the X5. Its working pretty well as of now. Haven't done the fancy calibration yet, my FSR mount design for the Kossel frame isn't quite up to snuff and it ruins some of the repeatability. Need to modify it a bit before I do any real calibration.

Posted: **Tue Feb 24, 2015 11:27 am**

Still not having luck with M500. The config override files exist, but they are corrupt.

edit: suddenly its magically working.

Posted: **Wed Mar 04, 2015 6:57 pm**

How are your FSRs wired? Did you have to do any modification of the firmware to make them work?

Posted: **Wed Mar 04, 2015 7:17 pm**

This page: http://www.tridprinting.com/Electronics/

Scroll down to the FSR section, there is a control board there. It works very well if you have a good mount. My mount I've done for the Kossel is a bit poor as of now, I have to make some mods so right now its not very repeatable, but my MAX mounts are pretty sensitive, if only there was a reasonably priced smoothie based board that could wield a Kraken..

Posted: **Thu Mar 05, 2015 9:48 pm**

That's cool. I'm picking up a board+FSR combo for the Max.

Posted: **Sat Mar 07, 2015 2:28 pm**

626Pilot, I've been lurking and following your work for a while now - big fan. I strongly believe this is the way we need to go.

G31 OPQRS hasn't successfully converged for me yet. If I run a couple of cycles, the results get progressively worse and worse. I'll try tweaking my physical build a little to hopefully prevent this, and can post my results if you are interested.

All in all great work!

Posted: **Sat Mar 07, 2015 10:53 pm**

Malcolm wrote:626Pilot, I've been lurking and following your work for a while now - big fan. I strongly believe this is the way we need to go.

G31 OPQRS hasn't successfully converged for me yet. If I run a couple of cycles, the results get progressively worse and worse. I'll try tweaking my physical build a little to hopefully prevent this, and can post my results if you are interested.

All in all great work!

If you can try these things and post the results, it might help shed some light.

Code: Select all

G28
G32
G31 OPQRS
G31 OPQRS
G31 OPQRSY
G31 OPQRS
G31 OPQRS

That will show me how the code performs in different scenarios, as well as probe repeatability. Put the code on pastebin and link it here - it'll be far too long otherwise.

Posted: **Sat Mar 07, 2015 11:43 pm**

Thanks for the quick reply. The link for the results is here: http://pastebin.com/z8zJDgUS

I also added a G29 at the end so you could see that my probe is repeatable.

Posted: **Sun Mar 08, 2015 12:07 am**

Malcolm wrote:Thanks for the quick reply. The link for the results is here: http://pastebin.com/z8zJDgUS

I also added a G29 at the end so you could see that my probe is repeatable.

Actually, it worked the first time

Code: Select all

[HC] Annealing : Within target
 
[HC] End of annealing pass (energy=0.009)
[HC] /!\ SUCCESS /!\

...

[PD]                        -0.062
[PD]
[PD] [ 0.000]    -0.006     -0.037      0.000    [ 0.000]
[PD]
[PD]   0.031      0.031      0.000      0.056      0.075
[PD]
[PD] [ 0.000]     0.037      0.056      0.081    [ 0.000]
[PD]
[PD]                         0.031
[PD] Best=0.000, worst=0.081, min=-0.062, max=0.081, mu=0.012, sigma=0.031, energy=0.042

From running G32 followed by G31 OPQRS, it did the best it could. With that calibration, you would have had positional accuracy significantly better than 100 microns across the whole print surface. Now, if you run G31 A, it will do a depth-map to correct the remaining Z error. X and Y error will remain, but it will make your first layer a little smoother. (I say "a little" because it's already super good with these numbers.)

Your printer obviously lost the calibration here after you ran G31 more times, but if you just do the same thing again - G32, G31 OPQRS - you should get about the same results.

Posted: **Sun Mar 08, 2015 1:28 am**

I was under the impression that this was just the simulated results. For example when I run:

Code: Select all

G32
G31 OPQRS
M500
G31 Z

The simulated results don't actually match the next probed results. Link to latest results: http://pastebin.com/3Jgcm5QX
Is there a step in between that I'm missing?

*** I forgot to turn the heated bed on, I think that's why the two solutions are different ***
Edit: Here is the same procedure with the bed temperature properly set: http://pastebin.com/5u05Tc5y Same Result

Posted: **Sun Mar 08, 2015 5:10 pm**

Scroll down to the FSR section, there is a control board there. It works very well if you have a good mount.

I found that that board messed with the repeatablilty of my Z probing. With the board you could see it recalibrate its rolling average part way through a Z probe test run and produce a bad score on the test. I would get a series of identical or 1 step deviate probes then suddenly the count would change by up to 10 steps. Without the board I was getting zero deviation with the same number of steps on every probe. I have the FSRs between my glass bed and the support tabs on my Kossel Mini wired in parallel between 5V and an endstop pin on the smoothieboard. It does seem to take a little too much pressure to trigger like that, however, I can see some "nodding" of the effector in some probe positions while calibrating which, I think, is leading to bad results. With the board you can see that the trigger pressure is more reasonable so I was thinking of adding a "hold" switch to the A/D board to stop the recalibration perhaps.

Cheers,
Robin.

P.S. a bit more info while I'm on ... I couldn't get the SA to run without crashing when I had network or panel support enabled on the smoothie.I guess RAM might be getting tight?

Posted: **Sun Mar 08, 2015 6:39 pm**

Ethernet support is extremely RAM costly, you have to have multiple MTU sized buffers, and it adds up.

Posted: **Mon Mar 09, 2015 1:06 am**

Malcolm wrote:I was under the impression that this was just the simulated results.

You're right, I had that confused. However, if the annealer makes it to the target accuracy, as it did in your case, you've got as much out of it as you're likely to. You can run G31 Z to probe it again and see if the numbers are good enough and try again, but yours were already really good as it is, way better than mine. On my printer, it never makes it to the target accuracy.

I think I may need to add tower lean as a parameter to get my printer (and many others) to a super-good calibration. I think most linear deltas (carriages on rails/smooth rods rather than overhead DC servomotors with levers) have some problem with tower lean. Unless your printer was assembled by million-dollar robots in a FANUC factory, it's hard to get the towers super-precise. However, if the firmware could learn the exact tower lean, it wouldn't matter!

One of the things I want to do is redo the calibration procedure so that it depth-maps the bed after it's done, and shows that instead of the simulated result, and then if you want to anneal again it will just remember that result instead of re-probing. I think that would be a bit less confusing.

Zedsquared wrote:I couldn't get the SA to run without crashing when I had network or panel support enabled on the smoothie.I guess RAM might be getting tight?

It is. The trouble with Smoothie is that the RAM is 64K, but they divide it in half. There is 32K system RAM, then another two banks of 16K each on the AHB0 and AHB1 buses. (Not sure, but I think it's set up like this because memory access to AHB0/1 won't block in some conditions where the system memory would be blocked, like DMA transfers.) In my opinion, they should really make system RAM 48K and just use one bank on AHB0 for time-critical stuff, but I don't know if that's feasible.

I have already migrated one array of several hundred bytes to AHB0, but there's ~1K of arrays I can still migrate. Once I have the RAM usage trimmed down, it may be possible to run an LCD panel, Ethernet, or whatever other modules you want. In the mean time, you could try turning off some modules in the makefile, like SCARAcal, which doesn't even apply to our printers.

Posted: **Mon Mar 09, 2015 1:10 am**

Zedsquared wrote: I found that that board messed with the repeatablilty of my Z probing. With the board you could see it recalibrate its rolling average part way through a Z probe test run and produce a bad score on the test. I would get a series of identical or 1 step deviate probes then suddenly the count would change by up to 10 steps. Without the board I was getting zero deviation with the same number of steps on every probe.

How did you have the FSRs connected before you used that board? Also, do you have any contact info for the guy who made it? I wanted to ask him some questions about the firmware, but I can't figure out how to reach him.

Posted: **Mon Mar 09, 2015 11:08 am**

626Pilot wrote:I think most linear deltas [...] have some problem with tower lean.

Agreed.

To sum up: Tower lean or some other unaccounted for parameter is affecting my calibration. The annealing is attempting to model it, but can't and therefore its solution is not matching the real world.

Posted: **Mon Mar 09, 2015 8:37 pm**

Nylocke wrote:This page: http://www.tridprinting.com/Electronics/

Scroll down to the FSR section, there is a control board there. It works very well if you have a good mount. My mount I've done for the Kossel is a bit poor as of now, I have to make some mods so right now its not very repeatable, but my MAX mounts are pretty sensitive, if only there was a reasonably priced smoothie based board that could wield a Kraken..

The best way to do that is the Smoothie 5x and using 4 total GPIO pins on the smoothie together with 2 TB6560 Single Axis Stepper Drivers to do that. Although you said reasonably priced... It definitely cannot compete with the Azteeg X5.

Posted: **Mon Mar 09, 2015 9:43 pm**

I think the alligator is smoothie based, but it's $400 for the board+expansion to run 4+ :/

Posted: **Tue Mar 10, 2015 2:31 am**

Nylocke wrote:I think the alligator is smoothie based, but it's $400 for the board+expansion to run 4+ :/

It would cost you $185 to do it with the Smoothie 5X. 1 TB6560 stepper driver is like 7 dollars, you just have to use the gpio pin outs available on the Smoothieboard.

Posted: **Tue Mar 10, 2015 4:24 am**

Four. Hundred. Dollars. For a board using a slower chip than Smoothieboard. *headdesk*

Posted: **Tue Mar 10, 2015 9:18 am**

What's worse is the Alligator board guy is doing a pretty good job of pissing off a number of people on the deltabots list.

g.

Posted: **Tue Mar 10, 2015 9:26 am**

@626Pilot - the FSR Endstop Controller firmware is open source and here: https://github.com/JohnSL/FSR_Endstop

You should be able to contact the developer (John) through git as well.

cheers,
Michael

Posted: **Tue Mar 10, 2015 1:26 pm**

mkx wrote:
Nylocke wrote:I think the alligator is smoothie based, but it's $400 for the board+expansion to run 4+ :/
It would cost you $185 to do it with the Smoothie 5X. 1 TB6560 stepper driver is like 7 dollars, you just have to use the gpio pin outs available on the Smoothieboard.

I've got several pololu style drivers already purchased (including the Panucatt 32X ones) that I could use. I might look into that, just have to figure out if I can get enough from my Viki+X3 Pro to actually do it. I like running an LCD+SD reader though, and it seems from what Pilot and others have been saying the current gen smoothies aren't capable of handling that. Probably will just end up waiting until someone makes one with an upgraded processor, and by the time that happens there will probably be one that also has the other features I'm wanting.

Glacian22 wrote:Four. Hundred. Dollars. For a board using a slower chip than Smoothieboard. *headdesk*

I didn't even know it was slower, that makes me want it even less.

geneb wrote:What's worse is the Alligator board guy is doing a pretty good job of pissing off a number of people on the deltabots list.

g.

I couldn't imagine why.

Posted: **Tue Mar 10, 2015 4:29 pm**

Unfortunately, I don't have a link for you. The gist of it is that his hardware really isn't open source because the schematics aren't machine readable and they're obviously wrong in a number of places. No board files, etc. It's..weird.

g.

Posted: **Tue Mar 10, 2015 8:57 pm**

Its unfortunate to see kickstarters for things like that do well, the people not being informed on how good the actual product is, or how well prepared the company is to make the number they sell.

Some of the people at my Makerspace got burned from this, they backed the Pheonix3D printer during the kickstarter campaign. The company spent 1 and a half years trying to deliver their product, and they hired numerous people. In the end they couldn't even send the hardware for people to print their own parts for the printer, apparently the bank seized their assets and they couldn't do a refund for anyone since all the money went into acquiring hardware/mould making materials (they were trying to mass produce printer parts with hobby quality casting).

Posted: **Tue Mar 10, 2015 10:53 pm**

I went through something similar when I backed the DeltaPrintr. About 14 months after the close of the campaign, they delivered me a kit, but it's missing some key features (some of them badly needed safety features) and is, in my opinion, a legit fire hazard. I always tell people not to buy a car or any other big ticket thing in its first year of production, because there is always some annoying problem like this...

The Phoenix 3D story is a fascinating read... I think I'll start a thread on their postmortem if nobody else has.

Welcome to the SeeMeCNC Community

Heuristic (AI) calibration for delta printers on Smoothie

Re: Heuristic (AI) calibration for delta printers on Smoothi

Re: Heuristic (AI) calibration for delta printers on Smoothi

Re: Heuristic (AI) calibration for delta printers on Smoothi

Re: Heuristic (AI) calibration for delta printers on Smoothi

Re: Heuristic (AI) calibration for delta printers on Smoothi

Re: Heuristic (AI) calibration for delta printers on Smoothi

Re: Heuristic (AI) calibration for delta printers on Smoothi

Re: Heuristic (AI) calibration for delta printers on Smoothi

Re: Heuristic (AI) calibration for delta printers on Smoothi

Re: Heuristic (AI) calibration for delta printers on Smoothi

Re: Heuristic (AI) calibration for delta printers on Smoothi

Re: Heuristic (AI) calibration for delta printers on Smoothi

Re: Heuristic (AI) calibration for delta printers on Smoothi

Re: Heuristic (AI) calibration for delta printers on Smoothi

Re: Heuristic (AI) calibration for delta printers on Smoothi

Re: Heuristic (AI) calibration for delta printers on Smoothi

Re: Heuristic (AI) calibration for delta printers on Smoothi

Re: Heuristic (AI) calibration for delta printers on Smoothi

Re: Heuristic (AI) calibration for delta printers on Smoothi

Re: Heuristic (AI) calibration for delta printers on Smoothi

Re: Heuristic (AI) calibration for delta printers on Smoothi

Re: Heuristic (AI) calibration for delta printers on Smoothi

Re: Heuristic (AI) calibration for delta printers on Smoothi

Re: Heuristic (AI) calibration for delta printers on Smoothi

Re: Heuristic (AI) calibration for delta printers on Smoothi