[engraving] - Twice Gcode in the file

[nemesis]

Hi all.
since I'm playing more and more with path WB on my Fablab's Xcarve I first have to say that the this WB is awesome. I finally get a WB where I can use freecad to produce things from A to Z (not the case with 3D printing)

However, I recently face a strange situation on engraving.
If I use Draft_ShapeString to engrave some text, it looks like the gcode is exported twice within the gcode file.
indeed by changing the placement of the egraving operation, it appears twice in the 3D view
one in the "operation" the other in the "engraving".
Normal? bug?
see attached an example file.

engraveTwice.png (106.53 KiB) Viewed 637 times

I cannot upload the post processed gcode as it is a 1.5mo, but you can generate it with the FC file
see below the First duplicated line side by side in Kate and the

duplicateGCODE.png (287.59 KiB) Viewed 637 times

OS: Debian GNU/Linux buster/sid
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.
Build type: Release
Python version: 2.7.16rc1
Qt version: 5.11.3
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: French/France (fr_FR)

it is the same with both python 3 and python 2 version in Debian.
didn't find any path bug ticket in the tracker.

another issue here is the prost-processing time.
My target is to engrave 11 sentece as the one on the file, and the post-ptocessing, when it works, takes about 1 hour (I guess the double GCode doesn't help)
I also guess it is due to the quantity of segment in text strings.

I use those fonts to get 1 edge font for engraving, but it is indeed with 2 edges (TrueType requisite) Anybody has a clue whit 1 edge fonts other than designing text in the sketcher or removing hundreds of edge after exploding the shapestring? I saw on the web it was a recurring issue for fine detail engraving text.

[chrisb]

I use those fonts to get 1 edge font for engraving, but it is indeed with 2 edges

Can this be the source of the doubled gcodes?

[quick61]

In version 0.18.1 I get the toolpath twice but on the same coordinates, and it goes over the path back and forth twice. In the latest 0.19 appimage, I just get it once with the back and forth. So I don't think it is the fault of the font. With a regular ttf, I get the double toolpaths in both versions but no backtrace with the tool...

Versions info -

Code: Select all

OS: Kubuntu 18.04.2 LTS
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.1.
Build type: Release
Python version: 2.7.15rc1
Qt version: 5.9.5
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/UnitedStates (en_US)

and

Code: Select all

OS: Kubuntu 18.04.2 LTS (KDE/plasma)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.16502 (Git) AppImage
Build type: Release
Branch: master
Hash: 06962535fa9ff348acca1b893cc4239908fb8bae
Python version: 3.7.1
Qt version: 5.6.2
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/UnitedStates (en_US)

Mark

[nemesis]

thanks for the replies!
I ll try the 0.19 as soon as possible (internet issues those days....)
otjer question, how long does it take for you to post process this file?
eventually if you can make a test with 10 times thos string?
just for the benchmark....
I use a Imac i5 from 2011 with 16go sdram with debian buster and it takes about 1 hour and fulfill the ram...
as I said I can guess it is due ti the high quantity of segments in text strings, but just to get a comparison.

[quick61]

thanks for the replies!
I ll try the 0.19 as soon as possible (internet issues those days....)
otjer question, how long does it take for you to post process this file?
eventually if you can make a test with 10 times thos string?
just for the benchmark....
I use a Imac i5 from 2011 with 16go sdram with debian buster and it takes about 1 hour and fulfill the ram...
as I said I can guess it is due ti the high quantity of segments in text strings, but just to get a comparison.

If your talking about the TestEngrave.FCStd that you posted, it takes my box about 7 seconds to post processes that file - linuxcnc | grbl with --inches argument about 8 seconds. (crudely timed with my analog watch ) If it's taking an hour for your machine to processes that file, you have something on your system fighting very hard for the cpu cycles I would think.

Mark

[nemesis]

I ll try the 0.19 as soon as possible (internet issues those days....)

it takes my box about 7 seconds to post processes that file - linuxcnc | grbl with --inches argument about 8 seconds.

so I tried with 0.19 and indeed it works. but I had to remove my home/user/.FreeCAD folder, or it was running endlessly.
I tried again with 0.18 python2 (debian package) and with a new /.FreeCAD folder and it's running since 25 min now with 1CPU loaded at 100%.... but no gcode.

for a 10 line shapestring as in the file below, it is more around 5 minutes (10,5mo gcode file) .
if you can test a give me a feedback, just to know.
I have removed teh Engraved operation to lower the file size, so my parameters are 0.15mm step, with -0.75mm final depth.

[RatonLaveur]

I know it can be construed as merely a workaround, but whenever I'm trying to generate (and execute) complex G-Code in the machine I try to simplify as much as possible. Numerical Commands don't even like big files.

So for such a string I'd only generate the path once and then loop that in the raw code or in a master program with incremental Z position.

Sometimes While loops are a lot more economic from a computational point of view than generating all the segments of all the depths of cut.

Hope this contributes.

[nemesis]

Sometimes While loops are a lot more economic from a computational point of view than generating all the segments of all the depths of cut.

Hope this contributes.

sure, could be very interesting, unfortunately GRBL does not support loops
but for sure with a controller that support it, it could be very interesting if the Path_Array function, could automatically do it

[RatonLaveur]

I'm not familiar with GRBL and its capabilities. So you cant run your program once, go back to origin, add G91 Z[stepdown] and then go back to the start? Even using an Nnnn block with GOTOnnn structure?

[Russ4262]

Afternoon, Nemesis.
I downloaded your file. Warmed up FC and took a look. I created a new job in the file, just to incorporate any new properties or settings committed to master branch since your version. I set depth parameters the same. The op only took about three seconds to compute. No concern there.

... it looks like the gcode is exported twice within the gcode file.
...another issue here is the prost-processing time.

However, upon selecting the engrave operation and clicking "Inspect Gcode" icon in PathWB, things changed. It took multiple minutes just to load the inspection window completely. I went away to work on something else. Came back and it was ready to inspect. (I don't have an exact time frame for how long this took to complete.) I copied all the code to Notepad++ for inspection there. It does appear the code is duplicated. It looks like the required code is about 25,000 lines long. The pasted code from the inspection window is 50,442 lines in Notepad++.

Yes, I would say there is a potential problem here.

I did not attempt to export the gcode since inspection took so long. I may do that and let it run as long as needed. I will then look at the processed code to see if it looks to contain duplicate job path information.


Russell

OS: Windows 10 (10.0)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.16616 (Git)
Build type: Release
Branch: master
Hash: f94cdfd798d0c493efe9c7d45084ad2c5dd18caf
Python version: 3.6.8
Qt version: 5.12.1
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/United States (en_US)