Welcome to the SeeMeCNC Community

The Z height is set automatically according to the offset you specify in config. However, it's still a good idea to set it the old fashioned way because the hot end is likely to be at a slightly different elevation each time you mount it. (Unless you have a probe system that doesn't require unmounting the hot end.)

In theory the FSR system would need that since nothing changes but my Bed/FSR setup is possessed. Now that I'm abandoning that approach and will fix the bed to the frame and go with a removable probe on the effector, I'll need to set the Z-height after.

Your firmware (especially G29) has been a big help in diagnosing the cause of my calibration woes. I see the latest Edge has G29 now.

On the "config" file resource usage, we noticed that if you're using the "custom_menu" like we do, you are able to have around 13 "custom_menu" items enabled without Network stuff enabled and all works well.

With Network stuff enabled, it's 7 "custom_menu" items... With our setup(s) that is, being a single Hotend/Extruder.

The more things that are "enabled" the more the resources dwindle away.

Without Network enabled = 13 "custom_menu" items
With Network enabled = 7 "custom_menu" items

For calibration though, we turn off the GLCD, Network, etc...

It's nice to have this "custom_menu" ability when not connected to the computer via USB, or you're no where near your computer and want to check/test things out.

Below is what the "custom_menu" looks like on one of the Rostock MAX v2's and it works/prints perfectly:

WZ9V wrote:Your firmware (especially G29) has been a big help in diagnosing the cause of my calibration woes. I see the latest Edge has G29 now.

If it does, I didn't put it there.

Was talking to dc42, author of the delta calibration system for the Duet (RepRapFirmware). His firmware uses root mean squared (RMS) instead of average when looking at the suitability of a candidate solution. I like that and I think I'll try it the next time I'm working on this firmware.

Has anyone tested my latest release, and how is it working for you? I heard from a couple people who had issues with temperature stabilization, but they didn't get back to me yet.

626Pilot wrote:Was talking to dc42, author of the delta calibration system for the Duet (RepRapFirmware). His firmware uses root mean squared (RMS) instead of average when looking at the suitability of a candidate solution. I like that and I think I'll try it the next time I'm working on this firmware.

Has anyone tested my latest release, and how is it working for you? I heard from a couple people who had issues with temperature stabilization, but they didn't get back to me yet.

We are having problems with the temperature not holding true... PID Autotuned a bunch of times, but it still isn't very stable.

However, we believe it's the Layer Fans playing havoc on the Hotend at this time. So we ordered some Aramid Material to wrap the Hotend, like Werner Berry did. He had the same type of problem(s).

So... Until we get that delivered and installed, we won't know for sure.

Other than that, all seems to be working just great! Good to know that you're still working on/with the Smoothieware updates!

I was talking to another math guy about better energy functions, and he mentioned Huber: https://en.wikipedia.org/wiki/Huber_loss - that would be another thing to try, aside from RMS. I theorize that the annealer could be made to try the existing strategy (average), RMS, and Huber, one after the other, and see which one delivers the lowest (best) energy. It would make the annealing phase take a few seconds longer - not a big deal.

If your hot end or bed temp won't stabilize, for my money, manual tuning is the best solution: https://en.wikipedia.org/wiki/PID_contr ... ual_tuning

I can usually get a lot smoother curve than the auto-tuner will find, if I just massage the variables by hand according to the table in that article. I think it would be better if Smoothie used the deadtime heat control feature from Repetier (where you only tell it ONE variable that describes how long it takes to significantly change heat), but when I mentioned that in IRC, one of the main developers scoffed at the idea of anything from Repetier ever being in Smoothie. I think deadtime is really the way to go. PID is very sensitive.

I said earlier that I wouldn't work on this fork anymore, but I will keep working on it if people keep using it. I have a Smoothieboard with a busted bed heater, so useless for printing, but it's fine for testing calibration code. I still want to come back to Smoothie when the Smoothieboard 2 comes out, especially since the Pro board will have 3+4 stepper drivers. That's enough to run a Kraken!

626Pilot wrote:I said earlier that I wouldn't work on this fork anymore, but I will keep working on it if people keep using it. I have a Smoothieboard with a busted bed heater, so useless for printing, but it's fine for testing calibration code. I still want to come back to Smoothie when the Smoothieboard 2 comes out, especially since the Pro board will have 3+4 stepper drivers. That's enough to run a Kraken!

I'm pretty sure that a lot, if not most people that are running Smoothieboards are using your fork as the Firmware in their Deltas. I know for a few of us it was the biggest factor in the purchasing decision.

Sure the Smoothieboard is a much better alternative over a RAMBo, but it was your AI Autotuning Calibration routines that really made the difference!

For us Delta users, setting up the Delta build geometry is enough on it's own, but knowing that your Firmware irons out the wrinkles for a damn near perfect print (calibration wise) means a lot!

So please, on behalf of the users out here using your Firmware, keep it up to date.

The results we've gotten using your Firmware is leaps and bounds over what we could achieve before using it, and I personally thank you for that!

RMLynch wrote:

626Pilot wrote:I said earlier that I wouldn't work on this fork anymore, but I will keep working on it if people keep using it. I have a Smoothieboard with a busted bed heater, so useless for printing, but it's fine for testing calibration code. I still want to come back to Smoothie when the Smoothieboard 2 comes out, especially since the Pro board will have 3+4 stepper drivers. That's enough to run a Kraken!

I'm pretty sure that a lot, if not most people that are running Smoothieboards are using your fork as the Firmware in their Deltas. I know for a few of us it was the biggest factor in the purchasing decision.

Sure the Smoothieboard is a much better alternative over a RAMBo, but it was your AI Autotuning Calibration routines that really made the difference!

For us Delta users, setting up the Delta build geometry is enough on it's own, but knowing that your Firmware irons out the wrinkles for a damn near perfect print (calibration wise) means a lot!

So please, on behalf of the users out here using your Firmware, keep it up to date.

The results we've gotten using your Firmware is leaps and bounds over what we could achieve before using it, and I personally thank you for that!

Your firmware was one of the main reasons I chose the smoothieboard, Please keep it up to date. Thank you for your hard work.

3D52 wrote:
Your firmware was one of the main reasons I chose the smoothieboard, Please keep it up to date. Thank you for your hard work.

Ditto here as well. I have been lurking and learning here for a while because the 626pilot firmare has been a lifesaver for my Kossel XL with a Smoothieboard. Thank you!!!

Welp, after discovering that the dc42 firmware for Duet doesn't give me full-bed print capabilities...

Yeah, I ordered another Smoothieboard. I need full-bed capability, even if it means being one extruder short. I might wind up having one printer on the Duet (3 materials, partial bed) and another on Smoothie (2 materials, full bed).

@626Pilot:

Have you seen the M668 ?

I havnt checked it yet, but maybe its easy for you to write code for the 40 points that are probed and can be stored in a file to be read out for the M668 command?

Maybe for the moment you can probe 40 points manualy and use them in M668. After that it should be possible to use the complete bed...

Or am I wrong and missunderstood this M668?

Looks interesting, but it doesn't seem automated, like probably you have to use external tools to generate the points and collect the depths and so on. (Which is a common gripe with the Duet solution: you have to use auto-generated files to tell it where to probe, and if you don't like the supplied choice of two probing radii, you have to figure out how to generate a new file using slic3r or something.) Also, I don't know what fork 'dc42-cmm' is.

My calibration system does all the repetitive idiot work for me, because computers are idiots and they excel at this sort of thing. Plus, I already have a tracking number for my new Smoothieboard, so...

What in the Duet firmware is constraining you from using the whole bed?

g.

dc42's calibration is not able to calibrate my printer to the point where I can print across the whole bed, and what looks like a prototype Z-only correction appears to be pre-alpha quality and not in dc42's main fork.

DC42´s calibration is working well if you have a complete flat bed and hardware which is accurate built.

I have 0.02-0.05mm tolerance on glas across the whole bed (280MM dia). But only on Glas.
When I do it on Buildtak or PEI on my finemilled aluminum heatspreader I got 0.07-0.12mm.

That shows, that the calibration is working, but not building a "bed-map" like your routine is doing.
I really miss your calibration on the duet!
Have you talked to David about implementing your routine into his fork? He´s a really nice guy and maybe you can work together on it. Many guys asking for a map-based calibration in the Duet firmware. I would love it! I don´t know if he isn´t working on it already. See the M668 command. But I don´t know how to use this as long as I don´t get a example.

He is also working on more probe points. Read about up to 100! Maybe thats a first sign that he is thinking about a "bed-map" and autocorrection routine ?

I am at a point to where I can upgrade to the newest release of this, just to double check... all I need to do is drag the binary file into the main directory and reboot? or because its an upgrade do i need to put it in the firmware folder?

Thanks

To upgrade the firmware you need to use Bossac. Look up "David Crocker blog" on Google, and find his post about updating firmware on a duet.

bot wrote:To upgrade the firmware you need to use Bossac. Look up "David Crocker blog" on Google, and find his post about updating firmware on a duet.

Would be superhard to do on a smoothie ...

lol wtf was I thinking? Sorry.

bubbasnow wrote:I am at a point to where I can upgrade to the newest release of this, just to double check... all I need to do is drag the binary file into the main directory and reboot? or because its an upgrade do i need to put it in the firmware folder?

Thanks

Straining at memory because I usually just do make/make upload, but this should work:

Delete FIRMWARE.CUR on your SD card. Upload FIRMWARE.BIN. Boot the Smoothieboard. You should see the blinkenlights counting in binary for a couple seconds as the image is copied to the board's internal flash memory. Then, they should start their usual rapid strobing. If you look at the SD card, FIRMWARE.BIN should have been renamed (by Smoothie itself) to FIRMWARE.CUR. That will guarantee you're working with the newest firmware.

critical_limit wrote:DC42´s calibration is working well if you have a complete flat bed and hardware which is accurate built.

I have 0.02-0.05mm tolerance on glas across the whole bed (280MM dia). But only on Glas.
When I do it on Buildtak or PEI on my finemilled aluminum heatspreader I got 0.07-0.12mm.

That shows, that the calibration is working, but not building a "bed-map" like your routine is doing.
I really miss your calibration on the duet!
Have you talked to David about implementing your routine into his fork? He´s a really nice guy and maybe you can work together on it. Many guys asking for a map-based calibration in the Duet firmware. I would love it! I don´t know if he isn´t working on it already. See the M668 command. But I don´t know how to use this as long as I don´t get a example.

He is also working on more probe points. Read about up to 100! Maybe thats a first sign that he is thinking about a "bed-map" and autocorrection routine ?

I don't know how flat this glass is. It's the standard SeeMe borosilicate. The printer is a Trick Laser MAX METAL, which is designed from the ground up to be very easy to align properly (and I do mean very, this thing has maybe 1/10th as many steps to build it as a Rostock, and he uses alignment pins so all the towers are as close to square as possible.) It would be nice to see more probe points on dc42's calibration. He is only testing 13, I think. My firmware uses 28 (7x7 grid, trimmed to fit round printers). More points means better tolerance for variations in the surface of the glass, probe repeatability issues, etc.

At this point, I'm not terribly interested in developing for the Duet. David is interesting to talk to, and we have exchanged a few messages about the differences between our firmware. He also helped me correct some things I got wrong in my Duet vs. Smoothie comparison thread (you can see that in the Duet forum, if you're interested). However, my time is pretty well spoken for right now, and I don't want to be straddling two different ecosystems - as nice as the incredible PanelDue is! Smoothie was my first firmware I really cared about doing anything with, development-wise, and it is far (my opinion) easier to deal with. Someone else (mhackney? could be wrong) said he had spent a few hours trying to get set up to do RepRapFirmware (Duet) in Eclipse, and it was a big pain in the ass. With Smoothie, you run a shell script to download the free compiler, then another to set the environment variables, and that's it. No IDE is even required, at all.

I also don't care for some Duet conventions, particularly the fact that there's no equivalent to config-override. Values are stored in EEPROM instead. This is BAD because it all gets WIPED OUT whenever you upgrade your firmware!!! I asked David about it. He said it's because the RepRapFirmware guys don't want people editing a config override file. (Well, like I told him, Smoothie has the same preference - they just put a warning at the top of config-override, stating, "Don't edit this yourself." Simple, huh!) There is also the probing grid - it's in a g-code file, that someone has to generate by hand. My firmware just figures that out based on the requested probing radius. Doing lots of stuff with files/macros/whatever is definitely cool, and something I wouldn't mind seeing in Smoothie, but I feel this takes it a few steps too far.

I also have to say that despite some issues earlier this year, I still believe firmly in the Smoothie project, as a firmware and as a hardware platform. When the Smoothieboard 2 comes out (hopefully next year), it will be running on a 204MHz Cortex-M4 with M0 coprocessor, have 136KB RAM, a megabyte of flash, FPU, SDIO, enough drivers for a Diamond hot end without having to buy an expansion board, an FPGA (ridiculous!), AND an Edison slot so you can run a fancy GUI or whatever. The M0 coprocessor, OR the FPGA, can be used for step generation, similar to the PRUs on a BeagleBone.

With this move, Smoothie will break away from being in the same class as the Duet. With the Edison option, it will be comfortably in the same class as the BeagleBone solutions, which at the moment have only basic delta support. Smoothie has... a lot more than basic delta support. I can't imagine what cool stuff they'll do with the FPGA, but I want to see!

Of course, if David wants some pointers for bringing some of my code into RepRapFirmware, it's fine with me and I'd be happy to help with that. Open source is supposed to be for everyone, and I like seeing my code take on a life of its own and being useful to someone other than just me. He hasn't asked, and I'm not surprised, as he has his own ideas for how to do things.

Couple more things...

I'm working with a mathematician to see if we can tackle the leaning tower idea. I don't know if he'll have enough time to work on it yet, but hopefully he will. I'm not fully convinced of its use, and won't be until I have some code, and can see whether it shaves off any error from the calibration. If it does work, it'll let some of us get a better calibration with less error in the all-important XY plane. May not matter much for statues, small-footprint items, etc., but it will definitely make a difference on large prints, and parts that need to be dimensionally accurate to the point where they can be fit with other parts.

Also, I have read somewhere that someone from the Smoothie team wants to get the PanelDue working on Smoothie. When I install my Smoothieboard, I will miss the hell out of that panel. If no significant progress has been made on getting that supported, I might just have to do it myself.

626Pilot wrote:Also, I have read somewhere that someone from the Smoothie team wants to get the PanelDue working on Smoothie. When I install my Smoothieboard, I will miss the hell out of that panel. If no significant progress has been made on getting that supported, I might just have to do it myself.

YES PLEASE!

RMLynch wrote:

626Pilot wrote:Also, I have read somewhere that someone from the Smoothie team wants to get the PanelDue working on Smoothie. When I install my Smoothieboard, I will miss the hell out of that panel. If no significant progress has been made on getting that supported, I might just have to do it myself.

YES PLEASE!

Oooohhhhhhh ..... I haven't seen these before....Shiney....I wants one

Someone asked,

Sorry to bother but I was curious what board I should use in regards to your firmware. Should it be the Smoothieboard X5? Also do you still recommend the Smoothieboard? I noticed in a post that it seemed you have switched platforms. I just don't want to buy the board to find out that it is obsolete. Oh and one last question... Does the control panel for the rostock work on the Smoothieboard?

The Smoothieboard 5X or Azteeg X5 will work fine. I prefer the Smoothieboard because while the Azteeg is cheaper, it also has weaker FETs (power transistors that drive the bed and hot end heat). I had some problems dealing with their US distributor earlier this year, but the Smoothie team reached out to me and explained what they were doing to correct the issue. (Shipping new orders was OK, handling returns was not - apparently they're on the ball now.)

I think the Rostock panel might work with the Smoothieboard, but I don't know for sure. There might be a thread here in this forum about that somewhere. Someone else might chime in if they've done it.

I am currently using a Duet (Arduino Due-based board) because I need 3 extruders. However, I have more confidence in the Smoothie project's prospects moving into the future. In about a year (give or take) they'll come out with the Smoothieboard 2, which will have support for more extruders, about double the RAM and CPU speed, loads more flash, an FPGA (which is just crazy), m0 co-processor (useful for motion control while the main CPU does other stuff), fast SDIO, and an Intel Edison socket (similar capabilities to Raspberry Pi or BeagleBone Black - you could run a print server on that, or whatever). The Duet is pretty good right now, and certainly the PanelDue is a beautiful piece of technology. However, I am already invested in the Smoothie ecosystem and their firmware is far easier to develop for, from a programmer's perspective. I also find it to be better laid-out, in terms of the design of the firmware. RepRapFirmware has "Arduino smell." Vast majority of important files in one directory, more tight coupling (which makes expanding it more difficult), etc.

Should you invest in a Smoothieboard 1, when its successor is due out in a year? That depends on your needs, and whether you think they'll change over time. I recently bought another Smoothieboard because my firmware does some things better (easier) than what runs on the Duet.