Multi-point probing for tilt compensation (for PCB milling) about fluidnc HOT 14 CLOSED

You're assuming 10x10 cm, which i think is not realistic. People will use this for various reasons, and not just pcb's. Some people might even want to probe the bed of their giant cnc for any milling.

But perhaps more important is that it's not necessary, since gcode senders already support it. If we were to implement it, we would have to support the code as well. If it were a feature that a lot of people would need (including me perhaps) and wasn't otherwise supported, I would have considered it - but currently there just isn't a need. That, and we already have a full plate as it is, so this would just go to the bottom of the list.

from fluidnc.

I say it is not a sender, because it just tells FluidNC to run the file from the SD card. The WebUI does not stream the gcode. Therefore it cannot tweak Z on the fly as it is sending it. It would need to be done in FluidNC.

I think the WebUI 0 problem is simple, like > 0 rather than >=0. If something needs to be changes on the WebUI, it might be best to take advantage of the new probing P parameter.

http://wiki.fluidnc.com/en/features/supported_gcodes#g38-probing

from fluidnc.

from fluidnc.

I've done dozens of PCB's using CNC, and my experience is that what you describe is not good enough. Keep in mind that you're milling off 0.06mm.

Bare PCB's are usually warped around the edges, roughly 1 cm off the edges. So they are a bit spherical so to speak. What you therefore want to probe is a grid, and then do bezier interpolation or something like that. To make matters worse, the milling itself will warp the material, and can even ruin holes, which is why I prefer to mill holes rather than bore them (and often do that before contouring).

Just doing 4 probe points is not good enough. Typically people probe every square cm2.

A sender like Candle does all quite good, and height maps can be applied to multiple jobs. I don't think an ESP32 has the required memory to do this properly.

from fluidnc.

This is typically built into many gcode senders.

from fluidnc.

My idea was to deprecate the requirement for a GCode sender altogether but I didn't think about the memory requirement - is it really that heavy having 100 floats in-memory?

from fluidnc.

@atlaste yea I meant a grid - there's no way probing the outer corners is gonna be any good

from fluidnc.

😢 yea I get it... thank you for your time anyway! :)

from fluidnc.

If it were a feature that a lot of people would need

Where can I sign up to the list? WebUI sender is useful for first test only, then I need height map to mill pcb, so I have to switch to other senders. But it would be cool to throw any senders and use my CNC fully autonomous

Can we at least have this open to gather interest?

from fluidnc.

The webui is not a gcode sender. It just sends commands to FluidNC. We can fix the 0 issue, but a full height map feature would need to be in FluidNC.

There are a lot of gcode senders that already do this. Therefore it would not be a priority for FluidNC

from fluidnc.

Yea, I fully understand that's will not be top priority right now

The webui is not a gcode sender

we can debate on terminology, but webui can send my nc (gcode) file to run, so it's gcode sender for me :) more or less feature-rich, but gcode sender.

my hope is that one day I do not need a connected pc to control my cnc and do the same stuff, just that, don't get me wrong. I already got fluidnc much much better than stock firmware for my mks dlc32, so thank you all here

from fluidnc.

we can debate on terminology

Not really. The GRBL community is well established and, within this community, "gcode sender" specifically means a program that runs on a host computer, accesses a gcode file on that computer, and sends it line by line to a controller using the GRBL serial protocol. There are gcode senders for other variant protocols like the one used by TinyG/g2core firmware, but they all share the "file on host, sent line by line" characteristic. The fact that the file is resident on the "sending" computer - which is usually a machine with plenty of RAM - makes it possible to process the GCode "on the fly" as it is being sent, for example to adjust Z values according to a height map.

A newcomer to the community might think of any program that provides a control surface for a GRBL machine as a "gcode sender", but such misuse of established jargon will cause misunderstanding.

from fluidnc.

which is usually a machine with plenty of RAM

I really not a pro in terms of hardware capabilities, but I have esp32 on my table which is capable of doing onboard face recognition and matching (aka esp32-cam). Isn't it enough to do height map?

AFAIK marlin can do mesh bed level compensation on the fly without any problem with at least 5x5 points (i didn't try more) on my skr 1.4 turbo with 64k ram (which is less than 512 kb declared on my mks 32dlc)

I'm not trying to be toxic, I'm just curious how all these things stack

from fluidnc.

It could be done given enough time and effort. It would require design, implementation, optimization, consideration of implications to other features and components, and ongoing support. My estimate of the true cost of such a project, if you are paying market rates to the select set of people who could do it without having to climb a steep learning curve, is north of $50K. Maybe one could find somebody willing to do it for free for whatever reason, but I would not hold my breath. The situation with Marlin is quite different. 3D printing is a fast growing field with many people looking to make their mark, and bed leveling needs to be done as a matter of course. In the FluidNC world, leveling is needed by only a small fraction of users, there are fewer programmers, and there are existing sender-based solutions. So the cost/benefit equation is wildly different.

from fluidnc.