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
Another problem with incorrect G-code generation
Moderator: andrew
Forum rules
Always indicate your operating system and QCAD version.
Indicate the post processor used.
Attach drawing files and screenshots.
Post one question per topic.
Always indicate your operating system and QCAD version.
Indicate the post processor used.
Attach drawing files and screenshots.
Post one question per topic.
Another problem with incorrect G-code generation
- Attachments
-
- Cat.dxf
- (1.39 MiB) Downloaded 280 times
-
- cat_draw.jpg (113.38 KiB) Viewed 6331 times
-
- cat_cut.jpg (46.69 KiB) Viewed 6331 times
Re: Another problem with incorrect G-code generation
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.
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
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
Regards,
Konrad
- Attachments
-
- catSim_lo.jpg (58.83 KiB) Viewed 6277 times
Re: Another problem with incorrect G-code generation
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.
But one can offset a single segment there.
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 ...
(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.
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.
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
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.
But one can offset a single segment there.
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 ...
(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.
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.
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
Hallo Konrad,
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.
Please test it by yourself and tell us what do you think.
Sorry, my findings will tell a different story.K0nrad wrote: ↑Fri Jan 28, 2022 9:43 pmI 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.
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.
Please test it by yourself and tell us what do you think.
Work smart, not hard: QCad Pro
Win10/64, QcadPro, QcadCam version: Current.
If a thread is considered as "solved" please change the title of the first post to "[solved] Title..."
Win10/64, QcadPro, QcadCam version: Current.
If a thread is considered as "solved" please change the title of the first post to "[solved] Title..."
Re: Another problem with incorrect G-code generation
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!
Work smart, not hard: QCad Pro
Win10/64, QcadPro, QcadCam version: Current.
If a thread is considered as "solved" please change the title of the first post to "[solved] Title..."
Win10/64, QcadPro, QcadCam version: Current.
If a thread is considered as "solved" please change the title of the first post to "[solved] Title..."
Re: Another problem with incorrect G-code generation
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
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