Heuristic (AI) calibration for delta printers on Smoothie

[mhackney]

Yeah, I don't think eeprom is required. The problem that Nylocke was addressing is that some of the config parameters in the config file cannot be set with set-config. Specifically, the parameter that enables/disables the SD card mounting can't be set with set-config. That makes it a PIA once you turn off mounting as you then have to remove the SD card and use a card reader on computer to change the parameter back to allow the sd to mount. If it could b set, it would be so simple - set to turn off sd mounting and reset then later set to turn on sd mounting and reset - all remotely via telnet.

[626Pilot]

I washed my borosilicate plate again and put it back on, and got some nozzle-blockingly bad performance. I rotated it 180 degrees and now it's fine. I have bed roughness set to 0.2, meaning KISSlicer adds 0.2mm to the thickness of the bottom layer for a total of 0.3 thick.

This tells me that the boro plate I got from SeeMeCNC has surface deformations of ~0.2 to 0.3 millimeters. For a good calibration, I want something about ten times more precise! I've ordered this granite surface plate, a bit under $50 shipped, which one of the commenters said he used a professional depth probe on to discover that the average surface deflection is within one thou, with one particular area where it was up to two thou. THIS should let me do some decent probing, I think!

This thing is heavy, listed at 26.4lbs. That means that if I use FSRs instead of the standard overhead Z-probe, each FSR will have to bear 8.8 pounds plus a little extra for the snowflake, heater and glass. According to the specs on tridprinting.com, they are rated for 100g - 10kg, which is far more than that. So, I think it will be okay to use a granite plate, even if FSRs are involved.

Using a granite plate, the procedure will be to run the heuristic calibration until a satisfactory result is obtained, remove the granite, and then have it do the height correction directly to the glass. That should yield a very good result indeed. You could even install PEI or whatever, making it perhaps somewhat rougher, and it should still be OK.

[Nylocke]

The Two Up from QU-BD uses granite for the bed, and it's a Mendel type Cartesian (oh god is it a piece of crap though). Granite seems promising, good tolerances, large thermal mass, low expansion, like aluminum and Boro had a baby with each of their best qualities and a bit extra.

[mhackney]

Well, the good news is that set-config actually does work to change the value of msd_disable. I verified this with arthur on the Smoothie irc last night. His suggestion was to make sure there were no tabs for the white space. Sure enough, there were. I replaced them with spaces and now I can:

config-set sd msd_disable true/false (only 1!)

and reset to get the behavior I want. So now I can run smoothie via USB from Mac and disable the SD mount until I actually want to mount it to move gcode files or mass-edit config. Now I'll disable ethernet to free up more memory to see if I can get some completion with the Heuristic Calibration now!

On a related note, my niece had a nice little ASUS laptop with touch screen that the HD died. She gave it to me. I replaced the drive with an SSD and installed Win7. It took several tries to get the USB driver for smoothie installed. I can connect to smoothie via USB from my Mac but I can't when connected to the Win7 laptop. Very off. Using RH latest on Win. I can connect from RH via TCP on the telnet port on smoothie. I'll talk to arthur and the guys later to see if they have any suggestions.

[Nylocke]

I was able to get it running after installing the driver and restarting the computer (on win7, my school is a PC based environment). Its a bit more clunky with windows RH, I really really hate the interface changes.

[mhackney]

It's odd, the driver installed, says it is operational but RH won't connect.

[Nylocke]

I had that issue when I first tried as well. Then I came back a day or two later and magically it worked. I can't remember doing anything other than installing the driver and then coming back after a bit. I wish I could be more helpful but thats pretty much how it happened.

[626Pilot]

In RH set Reset on Connect to Disabled and protocol to ASCII.

[mhackney]

Thanks, I'll give that a try.

[mhackney]

Perfect, that worked, thanks!

[Brian]

This may be something that someone has already though of, but why use the FSR for the sensors when you could mount sensitive strain gauges (like from a postage scale) on the delta arms and be able to sense with extreme precision the moment the nozzle contacts the bed? There's possibly a whole lot of useful information that you could pull out of the relative force feeding back into each of the three arms as you move the nozzle around the build plate.

[Nylocke]

Not *exactly* the same concept, but one of the billion Kickstarter deltas use an accelerometer mounted near the hotend. It probes the bed by touching the nozzle to the glass and sensing the acceleration from the nozzle hitting the glass.

[mhackney]

The FSR solution is inexpensive and surprisingly accurate. It just works and there is some momentum around it and the little board makes it dead simple to implement. Will there be better solutions in the future? I hope so, but FSRs aren't horrible here and now.

[Brian]

The FSR solution is inexpensive and surprisingly accurate. It just works and there is some momentum around it and the little board makes it dead simple to implement. Will there be better solutions in the future? I hope so, but FSRs aren't horrible here and now.

What would a printer board need in order to read a value from a strain gauge? They are not very expensive at all, so you only need to read the force, A simple instrumentation amplifier board would be fine for getting the values into a high level analog signal. Does the typical printer board have ADC channels available for reading the sensors? If it does, the board needed to read the strain gauges would be dirt cheap and simple.

Once you measure the force on the arms with this method, it open up all sorts of other interesting applications. You could even tell if the print failed and abort by the resistance of the extruder pushing filament into the air. You could probably do a much faster auto calibrate by dragging the nozzle around the build plate and mapping the shape of the plate as the nozzle moves.

If the hardware were available, do you think someone would take an interest in doing the software?

[mhackney]

Yes, I think a few of us would be interested. Of course, I for one would want to focus on Smoothie. I've tried doing Marlin and Repeater development and it is just too painful!

[626Pilot]

The FSR triangulation idea is dead. I did a mockup with a kitchen scale and a 1KG weight, did some math, and it turns out that the pressure gradient per millimeter (assuming you just want a light tap) is so small that vibration from stepper motors, a slight breeze from the AC, or a truck driving by outside, would be enough to noise up the results to the point of uselessness.

Not *exactly* the same concept, but one of the billion Kickstarter deltas use an accelerometer mounted near the hotend. It probes the bed by touching the nozzle to the glass and sensing the acceleration from the nozzle hitting the glass.

Before GPS, airliners used to use three accelerometers to reckon their global position. I'm sure they also had LORAN, but I don't think that worked everywhere, so they had to have an internal, inertial guidance system. They would average the outputs of all three to get their velocity vector, and that would be continuously integrated into the airplane's reckoned coordinates. I don't know how accurate it was, but it's not a bad idea. It might be possible to use something similar, where you take two or three cheap 3-axis accelerometer boards and average their outputs. It could be complicated due to all the vibration the steppers cause, but maybe not insurmountable, especially since each would respond at a slightly different time, therefore removing some of the bias.

I also liked the mouse idea. There are expensive gaming mice you can buy that will work on glass surfaces just fine. I suppose one could take out the measuring mechanism and put it on some spring-loaded mechanism that would keep it pressed to the bed.

Yes, I think a few of us would be interested. Of course, I for one would want to focus on Smoothie. I've tried doing Marlin and Repeater development and it is just too painful!

You said it!!! It's a pleasure to work on Smoothie. It's a "real" C++ application, where the files are put into their own directories. Arduino is all spaghetti with a terrible IDE, all files have to be in one folder, there are non-standard behaviors that break the C++ rules and confuse the HELL out of programmers who don't know its bizarre tendencies, it has a stupid old compiler that doesn't support closures or (AFAIK) anything from C++11, etc. On top of that, uploading a new firmware to an ATMega board takes a LONG ass time. It can easily be counted in minutes, between hitting compile and having the controller boot. By comparison, Smoothie firmware uploads at full USB speed. Save file -> compile -> upload -> boot -> connect with Repetier is perhaps a ten-second wait!

For a programmer, a minute and a half wait, while all the concepts you primed your brain with are slowly leaking out of your ears, is an impediment. You have to work harder to regain all that momentum you lost. It's so wasteful. When your code is acting weird and you can't figure out why, the last thing you want to do is have to wait a million years for the next iteration to upload. Atmel likes to crank out, basically, the modern version of the Z80 that was used in cheapo 1980s computers that you would hook up to a television. I am so done with that.

[Brian]

The problem with Atmel is not the AVR Microcontroller, it's the Arduino 'stuff' that layers on top to make it accessible to script kiddies that makes it so painful to program for a software engineer type. The MEGA series all have a real JTAG interface with true hardware debugging facilities built in. You can use Atmel Studio and develop in real C language and it feels no different than working with one of their ARM Cortex micros.

Arduino is sort of like Java.

[Nylocke]

I'm trying to build a version with MSD disable enabled, and I'm getting this for the error:

Code: Select all

Mikes-MacBook-Pro:Smoothieware mikelongnecker$ make DISABLEMSD=1 all
Building src
Deploying cpp/AnalogIn.h to drop
Deploying cpp/AnalogOut.h to drop
Deploying cpp/BusIn.h to drop
Deploying cpp/BusInOut.h to drop
Deploying cpp/BusOut.h to drop
Deploying cpp/CAN.h to drop
Deploying cpp/DigitalIn.h to drop
Deploying cpp/DigitalInOut.h to drop
Deploying cpp/DigitalOut.h to drop
Deploying cpp/DirHandle.h to drop
Deploying cpp/Ethernet.h to drop
Deploying cpp/FileBase.h to drop
Deploying cpp/FileHandle.h to drop
Deploying cpp/FileLike.h to drop
Deploying cpp/FilePath.h to drop
Deploying cpp/FileSystemLike.h to drop
Deploying cpp/FunctionPointer.h to drop
Deploying cpp/I2C.h to drop
Deploying cpp/I2CSlave.h to drop
Deploying cpp/InterruptIn.h to drop
Deploying cpp/LocalFileSystem.h to drop
Deploying cpp/PortIn.h to drop
Deploying cpp/PortInOut.h to drop
Deploying cpp/PortOut.h to drop
Deploying cpp/PwmOut.h to drop
Deploying cpp/SPI.h to drop
Deploying cpp/SPISlave.h to drop
Deploying cpp/Serial.h to drop
Deploying cpp/Stream.h to drop
Deploying cpp/Ticker.h to drop
Deploying cpp/Timeout.h to drop
Deploying cpp/Timer.h to drop
Deploying cpp/TimerEvent.h to drop
Deploying cpp/mbed.h to drop
Deploying cpp/platform.h to drop
Deploying capi/analogin_api.h to drop
Deploying capi/analogout_api.h to drop
Deploying capi/can_api.h to drop
Deploying capi/can_helper.h to drop
Deploying capi/error.h to drop
Deploying capi/ethernet_api.h to drop
Deploying capi/gpio_api.h to drop
Deploying capi/gpio_irq_api.h to drop
Deploying capi/i2c_api.h to drop
Deploying capi/mbed_debug.h to drop
Deploying capi/mbed_interface.h to drop
Deploying capi/pinmap.h to drop
Deploying capi/port_api.h to drop
Deploying capi/pwmout_api.h to drop
Deploying capi/rtc_api.h to drop
Deploying capi/rtc_time.h to drop
Deploying capi/semihost_api.h to drop
Deploying capi/serial_api.h to drop
Deploying capi/sleep_api.h to drop
Deploying capi/spi_api.h to drop
Deploying capi/toolchain.h to drop
Deploying capi/us_ticker_api.h to drop
Deploying capi/wait_api.h to drop
Building mbed-lpc1768.mk
Compiling vendor/NXP/capi/PinNames.c
make[3]: arm-none-eabi-gcc: No such file or directory
make[3]: *** [Release/LPC1768/./vendor/NXP/capi/PinNames.o] Error 1
make[2]: *** [mbed-lpc1768.mk] Error 2
make[1]: *** [src] Error 2
make: *** [all] Error 2

[mhackney]

I did a 'make clean' and then the make. Try that?

[Nylocke]

No go, I even deleted the stuff I downloaded originally and recloned the Git.

[626Pilot]

I don't know what that is. Try googling it or asking on Smoothie IRC.

[Nylocke]

Why does it say PinNames.o? Shouldn't it be .c? I googled the error message and I didn't find anything really that helpful

[626Pilot]

make[3]: arm-none-eabi-gcc: No such file or directory

I think it can't find your compiler. Did you run BuildShell first?

[Nylocke]

Yeah. I closed the terminal window and redid some of the previous steps and now it seems to be working. I'm pretty bad with the terminal still, not much Linux experience, so I pretty much just flailed around and now its working.

[mhackney]

LOL, "flailed around until it worked" - we've all been there at some point on something!