QCAD.org Forum

Hi,
I have encountered the following problem: when generating the path for my profile (see files), the lowest part of the path is lost. It looks like a very long tab but I did not declare it in that way. Is it my mistake or problem with the CAM module?
Regards,
Konrad

I can confirm.

Can you change the length of the tab at the bottom from 4 to 3.5 and try again?

I have changed the tab length as you suggested. Unfortunately, it had no effect (see picture)
Regards,
Konrad

I cannot reproduce that (with tab length 3.5) Could you attach your DXF and G-Code again?

Also, please indicate your QCAD/CAM version and operating system (see forum rules above).

Fixed. I changed the length from 4 to 3mm and it works
Any idea what might have been the cause?
I work with the latest release of QCAD/CAM. win10 OS.

Regards,
Konrad

Hello Konrad,
what software did you use to visualize the g-code file, as per your attached image test1.dxf in the post? The visualisation takes into account material thickness and tool diameter and gives a realistic view of the outcome of the cutting process. With such visualisation it is impossible not to spot the issue with the TABs.
I am asking as I am having TAB troubles as well and that visualisation could have spared me wasting some sheet material.

Thank you for your help and pointers,
Kind regards
LB


--> EDIT: I think I gathered it was CAMotics

Dear all,
since I have encountered the exact same proiblem, and by chance using 4 mm tabs I was wondering if this was a known problem, whether it was solved or not,

thank you for yor time
LB

newyd_cnc wrote: ↑

Fri Oct 20, 2023 8:29 am

whether it was solved or not

If you are using the latest release of QCAD/CAM and encountered the same issue then I think not.

The why eludes me.
In the case of K0nrad:
The cam entity was long enough so that the TAB is cleared before it ends.
Why the TAB down is missed and continues for the path that follow until the next TAB down is a mystery.
TAB's can perfectly cross several distinct cam entities.

Now from the looks of it in Test3.jpg, it seems that the TAB starts at the connection point between the arc and the line segment.
As if the cam entity was chopped into a line segment and a null-length line segment what could matter.
But then I don't get why a 1mm reduction would generate Test4.jpg there the line itself is 9.8mm long.
With 4mm and a mill of 1mm it still should be 2.4mm straight, up, 5mm straight, down, 2.4mm straight.
2.4 or 2.9mm at either side should not matter.

Regards,
CVH

Hello CVH,
thank you for your feedback. For info I am using
Version:
3.27.9.0 (3.27.9)

Now I agree that perhaps the tab issue is due to some sort of geometric discontinuity in the main path within the span length of the tab, I mean to say the tab starts on a certain feature of the path (be it a line, arc, spline) and then the path changes nature before the tab length is "elapsed". Waht is odd is that I had this behavior both over a spline and a straight line, the latter being much longer than the tab length.

Since having the issue I'm using CAMotics to visualize the g-code end result simulation, and that helps identifying these sort of problems before committing to a cutting job.


Kind regards
LB

newyd_cnc wrote: ↑

Fri Oct 20, 2023 1:52 pm

Version:
3.27.9.0 (3.27.9)

Current art is 3.28.2
There are no entries in the Changelog concerning this.

newyd_cnc wrote: ↑

Fri Oct 20, 2023 1:52 pm

is due to some sort of geometric discontinuity in the main path within the span length of the tab

Can't be the case as TAB's can span over several cam entities.
Prove of that is Test3.jpg where it spans dozens of entities, faulty but still.

Discarding null-length segments is the most probable cause.
To cross a TAB a cam entity is chopped into parts so that the second or the middle part can be elevated in Z.
Or the first part up to the TAB end when already elevated for a prior cam entity.

A null-length segment occurs when the position to chop coincides (or almost) with a segment ending.
Or at segments intersection ... Here between arc-line or line-arc.
It seems that the Zup is included but the Zdown at 'nothing' is 'forgotten' ...
Still, that doesn't fully match with given example values, the TAB is 4mm long plus the diameter of the mill, not 9.79999999...
As said: "The why eludes me."

newyd_cnc wrote: ↑

Fri Oct 20, 2023 1:52 pm

odd is that I had this behavior both over a spline and a straight line

Any chance that you could attach an example of that?
Remind that a spline is not handle in G-code directly.
It can be broken up in tangentially connected arcs or in line segments depending your preferences.

newyd_cnc wrote: ↑

Fri Oct 20, 2023 1:52 pm

Since having the issue I'm using CAMotics to visualize the g-code

Avoid when using 'Cutter radius compensation'.
See first entry of: https://camotics.org/gcode.html#missing-linuxcnc-codes

Regards,
CVH