probing and auto leveling

[jschoch]

https://github.com/vlachoudis/bCNC/blob/c144f28960aa03bad59132ae06ea9fe3f518dd4d/bCNC/CNC.py#L394

It looks like "compile" checks for the autolevel config and "splitLines" does the autoleveling. it requires you run setZero first in a bit of a wonky procedure.

https://github.com/vlachoudis/bCNC/blob/c144f28960aa03bad59132ae06ea9fe3f518dd4d/bCNC/CNC.py#L4550

Orient (next function after splitLines) is also interesting, you can pick a set of points with the camera and it will compensate position, for a double sided pcb you select drill holes and it does the x,y and skew correction for you.

A quick look at klipper reveals it actually has some tests!!!

guessing most goodies are here: It looks like the transforms, lookups, probe routines, config processing are here

https://github.com/KevinOConnor/klipper/blob/master/klippy/extras/bed_mesh.py#L59

I believe you can scan before each print or just use the stored mesh (what I do with my printer). It does scan the whole bed as defined in the config with configurable probe offsets.

the two modes are 'lagrange', and 'bicubic' documented here:

https://github.com/KevinOConnor/klipper/blob/46d0c6bdfc346ee6d3e6db704578679cb9fe55c5/docs/Bed_Mesh.md

[jschoch]

regarding priorities i'd prefer to have corner probing, circle center finding, and cylinder center finding before autolevling. Have thought about how a plugin system would work or if you'd prefer having this in the main sender code?

[terjeio]

The app is kind of plugin based already, the main sender code is small but dependent on a number of libraries (dll's) for most of the functionality. I've made it like this in order to be able to reuse the libraries to build different senders, e.g. I have already made a custom library and sender for my CO2 laser.

In another project I made some years ago I have code that allows "real" plugins, dll's that are added to the app via a config file. I believe this can be reused more or less directly for this app. Until I get around to making the UI user definable (the main tab) it would be restricted to adding tabs.

Are there any senders that supports probing in a way you like?

[jschoch]

bCNC has a lot of the features but the workflow is not great. UGS seems buggy. I have only dabbled with others.

I'll try to get VS installed so I can poke around tonight and see if I can learn enough C# to do anything useful.

[terjeio]

Ok, great.

GrblViewModel.cs in the CNC Core project is where most of the data for the controls originate. Typically controls subscribe to data changed events in that to keep themselves up to date. Many of them are suprisingly simple...

JobControl.xaml.cs in the CNC Controls project is where streaming takes place.

I have tried to layer the code as best as I can, ask me if you get lost...

[jschoch]

found some c# autolevel code

https://github.com/martin2250/OpenCNCPilot/blob/6bfd8243a42299f0eb7dae9adac9b9cfe96e71a0/OpenCNCPilot/GCode/HeightMap.cs

[terjeio]

Thanks, good find - never heard about this sender before. A plus it does not crash when connecting to grblHAL. 3D rendering is fast too, will have to look into that part of the code as well as the autoleveling.

[jschoch]

i has first C# and first wpf ever!!!!!

I have not done objects in a while, so much hidden magic!

any tips on where you are picking up your WFP c#, wondering where you got started. You put VMMV but dont' you mean MVVM!?

I was thinking the "console" window would be a good place to start my stumbling around c#. Do you have any objections to making the main window view 800 pixels tall?

[terjeio]

Oops, I've misspelled MVVM... Will fix that.

IMO a good place to start is https://www.wpftutorial.net/Home.html

For a lot of stuff I've googled for ideas - often ending up with discussions on stackoverflow guiding me along. And yes, there is a lot of magic to unveil - not always easy. I am still learning.

A design goal for the sender is to layer the code and split it into several projects brought together in the top solution or project (GCode Sender). Preferably this should contain very little code, using the magic of WPF and MVVM to glue the whole together.

I suggest you create a new project for your code and add that to the GCode Sender solution, this will force you to adhere to MVVM pattern. I've already created one for probing, I will add one or more viewmodels handling that - a bit similar to what I have done for the lathe controls. Perhaps an idea to collaborate on that and use it as a head on way to learn for you?

I have already made a simple console control, but not added it to any view. There are two lines in JobControl.xamls.cs commented out that disables viewmodel handling:

            //if (model.ResponseLogEnable)
            //    model.ResponseLog.Add(data);

I did not enable this in the current build as I think some kind of filtering should be implemented.

By the way the DataReceived() function in JobControl.xamls.cs should be moved to the viewmodel...

If you have a good reason for increasing the window size go ahead - I have not settled on the design of the main view yet and are open for suggestions. However I do not want to make the main window too large - I do not like cluttered windows, and the application should be usable on a laptop.

A tip: when you add a view to the main window it will by default inherit its DataContext - the GrblViewModel. You can then bind properties from that to your controls and they will be updated automatically when the viewmodel changes.

[jschoch]

thanks for the tips!

i've done react and elm so it seems I should be able to get up to speed with MVVM but my time in functional programming land has tainted me quite a bit and i'm likely to make lots of mistakes due to forgetting basic OO concepts and having no experience in WPF.

I'll try to do a bit more homework and make sure I can work in an isolated project.

[terjeio]

Getting closer to something useful, would like input on workflow and options for tool length probing. A lot of testing is required and parts of probing code is a bit messy...

Anyone want to help in getting probing completed?

[jschoch]

I'm still interested. I moved and I also got a tig welder so I have been a bit distracted but my new cart for my mill is all melted together now and I should be able to do some testing and write a bit of code. What do you want to get tested/finished first?

Also quick question: your area to probe section is setup for handedness (B,U,R), maybe it should be setup with the coordinate axis labels e.g X+/X-. Thinking out loud perhaps a machine setup screen would allow the user to specify their layout with axis labels and end stop locations based on their machine. That or be very clear what the standard/expected layout is.

Another general thought: I'm not sure how you feel about a workflow/setup style system but some things you really want to be sure you've set correctly and some options you generally set and forget. This could be done a few ways, if you had a probe/probe-plate library it might be easier to setup things first and then select the correct probe setup prior to probing.

Option 1 height map (most complex):

Screen 1: select probe type Screen 2: select diameter Screen 3: setup scan area (maybe auto grab from gcode and prompt if no file loaded) Screen 4: display all options and enable probe start.

Option 2: probe setup Screen 1: select probe type ( continuity, continuity + plate, non-conductive touch, vise, general workholding) Screen 2: (if plate) enter plate dimensions, diameter, probe length, probe offsets Screen 3: configure probing speeds and offsets display option to save

Option 2a: probe with saved setup. Screen 1: select probe setup and configure orientation display probe start. or prompt for new probe setup screen.

The setups I would use would be:

outside corner touch plate outside/inside corner touch plate with circle cutout cup plate (essentially a circle probe) continuity probe to work continuity to vise offset fixed X,Y probe non-continuity probe ( 3d taster type) non-continuity probe ( binary contact type)

[terjeio]

Great, I want to do this bottom up - get the primitives working and then refine the UI.

This is what I have done this far:

• Tool length: least complete, I need to understand best how to do this. E.g. grblHAL supports 9 coordinate systems so I want to have the option of using g59.3 as touch plate location (same as LinuxCNC). Also, it is possible to configure support for a tool table that is stored in EEPROM. This should also be possible to populate from probing. The LinuxCNC documentation may provide some good input.

• Edge finder and center finder: I believe these are working fairly well at the primitives level, a bit of UI work remaining for the center finder before I publish for test.

• Height map: probing seems to be working, can get the area to probe from loaded gcode. Some initial tests for Z-interpolation of linear moves completed successfully. Load and save of height map ok. Working on interpolation for arcs now. Currently I am using some code from OpenCNCPilot so it is a bit messy - I want to replace that with my own code when I get a better grasp of how to do this. One reason is that my sender supports up to 6 axes.

• Saved setup(s), not started yet.

My GGode parser needs a bit of attention too, as does the 3D renderer - full support for stuff such as canned cycles is not there yet. This is required for gcode > tokens > gcode translations.

Currenty I am testing with my mini CNC router and a loose spindle - no chips made yet.

[jschoch]

is there a branch I can test with?

I was thinking that it may be easier to start with plain old text files for probe/probe plate setups to start out.

[terjeio]

No branch yet, give me a day or two and I will upload a new alpha release. I just got XY-plane arcs working with height map so ready to look into tool length probing next - I want that a bit more presentable first.

I prefer XML for configuration files, easy to serialize from/to classes.

BTW: do you own some probes/plates? I have none so I am thinking about using a piezoelectric element for probing.