Page 1 of 1

Another problem with incorrect G-code generation

Posted: Thu Jan 27, 2022 10:47 pm
by K0nrad
Hi,
I found another problem with g-code generation. Curves are imported from svg file and converted to polylines.
When I try to generate g-code from the 'cat' path I obtain strange effect (see picture below). Any idea?
My OS: win10, QCAD/CAM 3.27.1. Postprocessor: grbl offset mm.
Regards,
Konrad

Re: Another problem with incorrect G-code generation

Posted: Thu Jan 27, 2022 11:09 pm
by andrew
Unfortunately, the tool offset cannot be correctly computed in this case. This is often the case with polylines with very small segments or arcs with large radii or arcs that are almost tangentially connected, etc. where offsetting the contour fails.

In such cases, I would recommend using the offset tool (Modify > Offset) to create the tool offset manually, then correct if necessary and finally create a toolpath from that corrected offset setting the Side to On.

Re: Another problem with incorrect G-code generation

Posted: Fri Jan 28, 2022 9:43 pm
by K0nrad
I noticed that if I enlarge the shape enough, then everything starts to work properly (g-code is correct). Regardless the arc problem, in my opinion the main problem lies in QCAD g-code generator. I did the same in DeskProto 7.1 (for dxf saved in QCAD) and everything is ok (see pictures below). In my opinion it is a bug that should be corrected.
Regards,
Konrad

Re: Another problem with incorrect G-code generation

Posted: Sat Jan 29, 2022 5:34 am
by CVH
Konrad,

With your Cat.dxf
Extracted the source shape of the cat, a geometrical closed polyline.
What I don't understand is that your screengrab <cat_draw.jpg> seems to have a double contour line.

Under QCAD (I am not a QCAM user)
Polyline offset (OQ) ; 0.635 ; #1 ; Whole ; Round ; Clip
Pointed at the inside.
It fails at the problematic spot. :roll:

But one can offset a single segment there. :wink:

A) It isn't a small arc being 2.65821097 long, the smallest is 0.43781893 long.
B) The radius is only 10.89552296 units, the largest is 142.59945909.
C) It isn't tangent with its neighbors at all, 179.74697452° & 182.2153455°.
Even better: If the origin were splines from SVG we would expect it to be tangentially connected arcs ... :shock:
(Ifso, and because it is true for most of these arcs, I can explain what happened here)

D) 'etc.' ... I can't come up with a reason why the offset would fail.

The offset of both segments would indeed overlap by 0.00280424 and for some reason QCAD can't come up with an intersection point.
It's not that hard, it is @(28.95052771, 15.38288897) and NOT in the overlap. e_geek

Exploded the polyline.
Trimmed the problematic arc with both neighbors pairwise.
Re-combined to a polyline with OC, what returns a logical closed polyline. All fine.

Offset is now flawless and closed. :P
I suspect that any toolpath G-code will be fine too.

It boils down to my statement:
IMHO: Arcs/Lines segments should be merged as a polyline trimmed pairwise.

Regards,
CVH

Re: Another problem with incorrect G-code generation

Posted: Sat Jan 29, 2022 8:23 am
by Husky
Hallo Konrad,
K0nrad wrote:
Fri Jan 28, 2022 9:43 pm
I noticed that if I enlarge the shape enough, then everything starts to work properly (g-code is correct). Regardless the arc problem, in my opinion the main problem lies in QCAD g-code generator. I did the same in DeskProto 7.1 (for dxf saved in QCAD) and everything is ok (see pictures below). In my opinion it is a bug that should be corrected.
Sorry, my findings will tell a different story.
Comparing a result using different programs means you have to use the same parameter in both programs. I assume that isn't the case in your comparison. It looks to me that DeskProto 7.1 uses a different tolerance for an offset as QCADCAM does.

This said - I used your Cat shape unchanged(!) and played with the Offset settings for "Tolerance for clipping" in QCADCAM. A value of 0.0001 brought me a result where I'm not anymore able to tell a difference between QCADCAM and DeskProto 7.1.

Husky-2022.01.28-05.png
Path generated in QCADCAM
Husky-2022.01.28-05.png (35.45 KiB) Viewed 6301 times

Husky-2022.01.28-06.png
Husky-2022.01.28-06.png (25.68 KiB) Viewed 6301 times

Husky-2022.01.28-04.png
Husky-2022.01.28-04.png (11.46 KiB) Viewed 6301 times

Please test it by yourself and tell us what do you think.

Re: Another problem with incorrect G-code generation

Posted: Sat Jan 29, 2022 8:40 am
by CVH
Husky wrote:
Sat Jan 29, 2022 8:23 am
"Tolerance for clipping" in QCADCAM.
Is shared by CAD and CAM ...
Have a closer look at what happens @(28.95052771, 15.38288897)
And at 10 other places ...
Bridge gap.png
Bridge gap.png (2.01 KiB) Viewed 6299 times
Regards,
CVH

Re: Another problem with incorrect G-code generation

Posted: Sat Jan 29, 2022 9:26 am
by Husky
CVH wrote:
Sat Jan 29, 2022 8:40 am
Have a closer look at what happens @(28.95052771, 15.38288897)
If you have sleepless nights because you found a wrong entity which is 0.00004031 mm in length - then you should fix it! In this case it would make no sense to me to pay that fact any attention!

Re: Another problem with incorrect G-code generation

Posted: Sat Jan 29, 2022 11:42 am
by K0nrad
Cool! Thanks for all your answers. I did not really pay attention to the correctness of the shape. My mistake for which I apologize!
For vector graphics, I use Xara Photo & Graphic Designer and then convert it to SVG. I've noticed before that very often simple pictures get more complicated after conversion.
Regards,
Konrad