CNC Machine with built in radius compensation

Here's the place for discussion related to CAM/CNC and the development of the Path module.
thomas-huber
Posts: 13
Joined: Wed Jan 26, 2022 4:02 pm
Location: Oberneukirchen, Bavaria

Re: CNC Machine with built in radius compensation

Post by thomas-huber »

Thanks for your posts, they really clearified things for me.
I find it most useful to not use CRC at all and use Path to do all offsetting. I only make one-off and small run parts so that works for me. If I need to adjust the offsetting value, it's easy enough to change the tool in Path and re-post the file. If I was running a production shop and needed the operator to make fine tuning adjustments to the path, I would use CRC but only for the wear compensation. As others have noted, using CRC for full tool radius offsetting is dangerous.
Yes I can see why It can be dangerous. eajmarceau explained a issue that I already ran into but did not fully understand to this point.
But one thing I don't get is how to use CRC to only compensate the difference? eajmarceau also talked about this but was is a compensation register?

Let's say i have a "design" bit with 10 and the actual value is 9.89. How would I tell the maschine to only compensate 0.11? As for our maschine it always compensates the full tool radius. (For sure you can't know how our maschine works, but how would you do it with a LinuxCNC?)
JanneK
Posts: 13
Joined: Sun Feb 01, 2015 9:30 pm

Re: CNC Machine with built in radius compensation

Post by JanneK »

Path (and CAM in general) is about calculating gcode. Cutter radius compensation is about the controller interpreting and moving those gcode coordinates. Therefore there's nothing for Path to do in this regard, (other than spitting out a G41/2 during a tool change.)
This cannot be correct? G41 and G42 specify offset to the left/right of the path, and should have everything to do with CAM, as that's what is deciding on what operation is currently being carried out, in what direction and why.

As in, "let's do a pocket CCW, thus G41 (and G42 for CW direction), and let's also do a cleaning off a potential nib in the middle, so let's do G40 and touch off the middle"?

You can certainly use this feature, in multiple ways. You can have Path calculate all moves 'on the line' and use CRC to set the final offset. Or you can do offsetting with path and use CRC for the final adjustment to compensate for the difference between programmed tool diameter and actual diameter.
It seems to me that the PP would need to know pretty extreme details of the current operation in order to manage to do the right thing? Is it a pocket-operation? Then stay on one side, if it's a profile, the opposite, if it's a climb-cut, then reverse what was just said, if it's a "touch-up-dress-up" that temporarily reverses the direction, then don't switch sides or everyone will die.
This makes me think that G41/42 is a CAM decision based on what path is generated and why.

I find it most useful to not use CRC at all and use Path to do all offsetting. I only make one-off and small run parts so that works for me. If I need to adjust the offsetting value, it's easy enough to change the tool in Path and re-post the file.
Yes, this was my "philosophy remark" from earlier. It simply needs to be set in stone what that actually is (which it already may or may not have been) with the consequence of possibly disabling proper support for the features of controllers like the 840D (and the other one mentioned in this thread).

I would use CRC but only for the wear compensation. As others have noted, using CRC for full tool radius offsetting is dangerous.
Maybe there is a misunderstanding here. On the 840D, the G41/G42 are calculated by the combination of tool radius and tool wear (and I would call the latter for 'compensation').
In fact, my machine has an actual physical key that needs to be used if one is to change the radius of the tools. The operator can only change the "compensation" part, which only allows miniscule changes.

The programming manual is very clear on G41/G42 being used to stay inside/outside of a path. That is, to offset the tool radius.
JanneK
Posts: 13
Joined: Sun Feb 01, 2015 9:30 pm

Re: CNC Machine with built in radius compensation

Post by JanneK »

Let's say i have a "design" bit with 10 and the actual value is 9.89. How would I tell the maschine to only compensate 0.11? As for our maschine it always compensates the full tool radius. (For sure you can't know how our maschine works, but how would you do it with a LinuxCNC?)
Top
This is exactly why I think that it is the CAM that needs to implicitly offset with "G41/G42" and calculate the paths with the provided tool information, so that the radius can be tweaked on the machine. On my machine it is tool radius + wear offset. In your case (according to you) it is only the tool radius, but that shouldn't matter for the Path workbench.

PPs for machines that do not support G41/G42 would then need to query the +/- tool-radius offset-path (depending on G41/G42) and strip away G41/G42?
User avatar
sliptonic
Veteran
Posts: 2896
Joined: Tue Oct 25, 2011 10:46 pm
Location: Columbia, Missouri
Contact:

Re: CNC Machine with built in radius compensation

Post by sliptonic »

JanneK wrote: Tue May 10, 2022 2:20 pm
Path (and CAM in general) is about calculating gcode. Cutter radius compensation is about the controller interpreting and moving those gcode coordinates. Therefore there's nothing for Path to do in this regard, (other than spitting out a G41/2 during a tool change.)
This cannot be correct? G41 and G42 specify offset to the left/right of the path, and should have everything to do with CAM, as that's what is deciding on what operation is currently being carried out, in what direction and why.

As in, "let's do a pocket CCW, thus G41 (and G42 for CW direction), and let's also do a cleaning off a potential nib in the middle, so let's do G40 and touch off the middle"?
Are you regularly switching back and forth between climb and conventional milling in the same jobs?
I understand your point. A more comprehensive approach is possible so that a G41/42 is output before an operation depending on whether it's set for CW/CCW (Climb/conventional).

Let's open an issue on github.
I would use CRC but only for the wear compensation. As others have noted, using CRC for full tool radius offsetting is dangerous.
Maybe there is a misunderstanding here. On the 840D, the G41/G42 are calculated by the combination of tool radius and tool wear (and I would call the latter for 'compensation').
In fact, my machine has an actual physical key that needs to be used if one is to change the radius of the tools. The operator can only change the "compensation" part, which only allows miniscule changes.

The programming manual is very clear on G41/G42 being used to stay inside/outside of a path. That is, to offset the tool radius.
[/quote]

The set tool value on machine is 0.0 and the toolpath is compensated in CAM. Then G41/2 is enabled with a P value for the offset wear compensation. If the control allows both tool radius and wear compensation and combines them, you'd have to still set the tool radius to 0. I've heard this discussed as 'east coast' vs 'west coast' style.
JanneK
Posts: 13
Joined: Sun Feb 01, 2015 9:30 pm

Re: CNC Machine with built in radius compensation

Post by JanneK »

Are you regularly switching back and forth between climb and conventional milling in the same jobs?
I understand your point. A more comprehensive approach is possible so that a G41/42 is output before an operation depending on whether it's set for CW/CCW (Climb/conventional).

Let's open an issue on github.
I'm not regularly anything to be honest. At least not yet. I'm here because I bought a machine that has these capabilities and the documentation states that this is how things are expected to be programmed. <more on this later>
Opening an issue seems reasonable if we somewhat agree on what the responsibility of the CAM-part should be and why.
To be extra picky on the above: CW/CCW vs G41/G42 doesn't necessarily map to climb/conventional (as it depends on spindle direction), but explicitly whether or not you intend to pocket or profile (left or right side of the direction-vector).

I've heard this discussed as 'east coast' vs 'west coast' style.
Very nice explanation in that link! Thanks!
On my machine, clearly the thought is "east coast", and the reason was quite clear (easily mill from a blueprint). but like I mentioned earlier, it also has the best bits from west-coast, as the tool-wear compensation is separate and not protected by a physical key, the "tweaking" is as clear and easy as with west-coast, since you specify the that tweak-offset with the value that you want to increase/decrease a pocket with.
The set tool value on machine is 0.0 and the toolpath is compensated in CAM. Then G41/2 is enabled with a P value for the offset wear compensation. If the control allows both tool radius and wear compensation and combines them, you'd have to still set the tool radius to 0.
One could do that, but that would mean you would need to delete the tool-information from the machine (which requires a key / which means that we are doing something that we aren't necessarily supposed to do), and worse - The modern Sinumeriks (not mine) have both material simulation which would no longer work, and collision detection, which also would no longer work.

Sorry for going to such great length, but when I get into something, I really want to get to the root of things and try to figure out whether a chosen convention can be arbitrary (which is fine), or if there are reasons to believe that there is a "correct way" (based on some definitions/philosophy, of course - which to me is currently "why not be a replacement for professional software?").

I will change my mind the moment you point out my mistake (at least I hope I will).
eajmarceau
Posts: 73
Joined: Tue Feb 22, 2022 9:16 pm

Re: CNC Machine with built in radius compensation

Post by eajmarceau »

I believe JanneK and thomas-huber are looking for a PATH "mode" switch, which will generate the cutter-contact path as output, instead of cutter-center path as output, for gcode generation.

Conceptually, without having seen source-code, I can visualize that the "edge/contact" path definition might be an essential middle step in the current approach, and therefore I think it should be relatively straightforward to extract, before the core logic moves on to the generating, thru transformation in direction of contact normals and tool radius, the final tool-centered path we now get for the current style of PATH output.

Such an "edge/contact" path would imitate the CNC controller's logic where it basically uses part geometry for cutter path and does all the offset internally, based on the code selection for which side is cutting metal (relative to direction) to do actual cutter radius offset. While I have never been a fan of letting machine-tool controls perform the tool-radius-standoff "live", if that is what machine-shop owners and machine-tool operators want ... and are prepared to accept the full risk, ... that is for them to decide.

However, ... if the "actual" cutter path is not fully calculated by the CNC as a separate step, and not stored/reviewed before initiating the metal cutting process, then I have to say that the manufacturer is complicit in pushing an approach which, at face value, appears to be time-saving and simpler ... but is, in reality what I call, without hesitation, a categorically reckless approach which has great implicit, if not frequent, potential for damage to operator/part/cutter/machine ... depending on how extreme the "glitch" could show itself to be, as confirmed by
thomas-huber wrote: Tue May 10, 2022 2:07 pm Yes I can see why It can be dangerous. eajmarceau explained a issue that I already ran into but did not fully understand to this point. ...(snip)


From a standpoint of risk-avoidance ... in a hi-pot environment ... without mentioning potential legal liabilities if someone gets hurt, or business loss if equipment is damaged, I think it is best to avoid adopting such an approach ... and stick to cutter-center programming approach.

For me, such a post-processor implementation must involve a conscious, documented, mode selection , performed manually via interraction at the GUI, so that it can be recorded in the reports (or gcode comment) who made that option selection along with date and time. (Yes, I am aware of how extreme and over the top that may sound to others.)
JanneK
Posts: 13
Joined: Sun Feb 01, 2015 9:30 pm

Re: CNC Machine with built in radius compensation

Post by JanneK »

However, ... if the "actual" cutter path is not fully calculated by the CNC as a separate step, and not stored/reviewed before initiating the metal cutting process, then I have to say that the manufacturer is complicit in pushing an approach which, at face value, appears to be time-saving and simpler ... but is, in reality what I call, without hesitation, a categorically reckless approach which has great ....
As stated above, I'm not a CNC-operator, but the manual to my machine emphasizes the importance pressing the "simulate" button on the controller prior any job. :)

As for the solution with a switch, that was exactly what I proposed as a solution in the feature request that I opened.
thomas-huber
Posts: 13
Joined: Wed Jan 26, 2022 4:02 pm
Location: Oberneukirchen, Bavaria

Re: CNC Machine with built in radius compensation

Post by thomas-huber »

One thing I would have you think about is the number of path points at sharp corners, whether you are doing an arc around that corner or if you are cutting past to tangent for the next cut. If you have the system generate a number of points which all end up on top of each other, your control might not be able to distinguish (zero-distances involved) which side of the Path is on the right side, and the cutter might gouge the part.
This is a problem that can araise und should be taken care of. But I'm pretty sure that could be solved in FreeCAD. (One way could be to the original curve than look for problematic points and remove these points from the original).

I think it should be documented well in the open ticket and have a good name (like Path Offset Point Overlapping - POPO :) ). Also FreeCAD is probably not the only CAD/CAM facing this probleme so it would be interesting what others are doing (I have no idea).
eajmarceau
Posts: 73
Joined: Tue Feb 22, 2022 9:16 pm

Re: CNC Machine with built in radius compensation

Post by eajmarceau »

JanneK wrote: Sat May 14, 2022 7:44 am ... pressing the "simulate" button on the controller prior any job. :) ... (snip)
Doing a simulate, without saving the gcode instruction sets generated for that simulation, implies the control will re-calculate at every run ... while cutting. That is not safe because calculation glitches happen all the time and you could never predict when, or how severe, an impact that glitch will have. That is, in my view, like playing russian roulette with each path-point calculation, increasing the likelihood of such a glitch event actually occuring during any one run. Those are not odds that I would want to gamble on.

Generating the gcode, then having the control simulate from the gcode for visual confirmation, then drive the cutting process from that verified gcode is safe. The severity of any failure in the axis servo-controls using pre-defined gcode register values is likely to be significantly less than that of a randomly generated number that is pointing to a location (glitched and therefore different from a previous run) and tool axes moving to position to that unwanted and unknown location.

This is the exact same issue that I have with the whole STEP-NC approach. Yes, maybe you can do it, but should you do it? That is the question. For me, the only answer is a clear no ... because you can't control when cosmic radiation will affect/damage your electronic hardware.
Post Reply