New compensation component for engraving and 3D Printing

I've been using LinuxCNC with a RPi for 3D Printing for some years now. Along the way slowly developing functionality needed for a 3D printer. Bed levelling, I hope, is the last piece of the puzzle besides an integrated GUI.

I have found several approaches from over the years:

1. Correcting the G Code source
2. Mapping an STL triangulated surface and interpolating within the Kinematics - Probekins
3. A usr space Python component performing bilinear interpolation and intercepting the motor position commands - CNC-CLUB.ru

My first efforts were similar to the Probekins approach, but to use linear regression to map a quadratic surface to the surface probe data points and to use this within the kinematics to perform the correction. I had this working nicely but with one major drawback. As it is a surface of best fit there is errors at the probe points. Sometimes these errors defeat the purpose.

In another recent thread Andy Pugh made the suggestion:

"If I was doing this with current LinuxCNC I think I would still use the STL offset map, but would use a standalone HAL component that output a Z correction fir use by the external offsets inputs. "

Which got me back to the drawing board, and I'm happy to say that with the help of Covid-19 isolation I can share a Beta version of my compensation component that uses external offsets as he suggested, but uses interpolation to create a correction map.



I had added my compensation component to my GitHub and a short YouTube video of it in action. Some testers and feedback would be appreciated. The video shows this correction map in the picture above being applied.

Regards

Scott

Question does your component also reads standard printer G-code like Marvel and translate the mcodes and E-Axis towards linux used

Hi


This is really interesting for, i plan to use Linuxcnc later for 3D printer, so thanks a lot for this component.

For make things simpler i like to use external standalone temperature controler, i have start experimenting this type of controler with a smoothieboard on my little cnc, so unfortunatly i can't test your component (for now i only have a lathe working on Lcnc) but you can be sure one day or other i come back here !

But i have already some questions if you agree :
Did you use a Bltouch for probing ?
Did you plan to share also something for create the map ?


Br

Component does not care about the flavour of the G Code. BTW Prusa Slicer can output LinuxCNC/Mach3 compliant code very nicely.

The Extruder becomes the A axis then.

BR

Scott

Hi,

I really need to publish my new firmware for Smoothieboard clones, LPC1768 based boards. LinuxCNC running on a RPi talking directly to the PRU (the LPC1768 based board - Smoothieboard, Bigtreetech SKR etc) over the SPI interface, which handles real-time step generation, IO and heater control. Full closed loop functionality is also working.

Gives all the functionality needed for a CNC machine (engraver, router, printer) using readily available and mass produced (cheap) hardware.

I'm using a poor mans BLTouch as I have not had a great result with the cheaper versions of the BLTouch.

I'll share the subroutines for map generation over the weekend.

BR

Scott

Well I'm not sure i understand : Did you mean you have write some firmware for use a smoothieboard with linuxcnc ??? If this is that i'm really interested because these card software are not really great and from long time i have some regret to not use linuxcnc for my first retrofit...

I ask for Bltouch mostly for know how it is wired and configured with Lcnc ?

Closed loop with smoothieboard or equivalent ???


Br

Yes, correct. A new firmware that allows a smoothieboard (or clone) to be used with LinuxCNC!





BLTouch is wired to the control board (PRU) and the IO and PWM (servo position) commands are sent over the SPI interface. Custom M Codes in LinuxCNC as well.

For closed loop control there is an Encoder module which gives position feedback to LinuxCNC.

BR

Scott

Awesome this is something like a dream !!!

I have too many issue with smoothieware/smoopi...

I think this possible to use some long wire like 1 meter for spi so this is really perfect !

Unfortunately the SPI cable needs to be as short as possible to ensure reliable communication. Current HAL real-time component runs the SPI at 6.25MHz. A slower frequency could be used but then you would need to run the LinuxCNC servo thread at a slower rate.

Is your code:
a. compiled with vsc
b. only running 1768
c. possible to run TMC2209

Anyhow a very interesting aproach for small machines.
Mike