[scorch]

Interesting.

Do you have a comparison, or rough feeling for how paths / smoothness would compare between identical source material presented as both DXF and TTF?

I actually had a bit of difficulty getting a path into F-Engrave over the weekend and was considering just making it into a character in a .ttf --- presumably that would have been sub-optimal, but the new version would improve that result --- sufficiently that there's no reason to use a DXF? Or would a DXF still provide a smoother path / result?

In the end the same input from DXF or TTF should give the same (or very similar) results. The problem that I am fixing is that curves in the TTF are currently being represented by 4 lines regardless of the shape of the curve. The new version will provide better curve representation (similar to how F-Engrave currently treats DXF data) .

[scorch]

Would this just be part of a new release of f-engrave, or is it something separate that needs to be installed?

If you use the pre-compiled windows executable file it will be included in the next release. If you run on Linux or use the python source file you will need to update your ttf2cxf_stream executable.

[Bashere]

Interesting.

Do you have a comparison, or rough feeling for how paths / smoothness would compare between identical source material presented as both DXF and TTF?

I actually had a bit of difficulty getting a path into F-Engrave over the weekend and was considering just making it into a character in a .ttf --- presumably that would have been sub-optimal, but the new version would improve that result --- sufficiently that there's no reason to use a DXF? Or would a DXF still provide a smoother path / result?

I don't know about ttf's , but what I do when dealing with a difficult path is to print it 1 to 1 to a pdf. I then get a screen capture of the pdf so I'm left with an image.

It's a convoluted approach, and the size isn't 100% accurate, but f-engrave processes the image much faster than a dxf.

Sent from my SAMSUNG-SM-N900A using Tapatalk

[scorch]

In addition to smoother TTF output I am going to add some new cut types to the next version of F-Engrave. I am adding an option for doing pocketing with a straight cutter and an option for doing prismatic letters (or image) with a v-bit. The prismatic letters should allow for making v-carved inlays.

Here is a picture of a couple of my initial test cuts (the lower block fits in the v-carved "N" on the upper left)
Attachment 287178

Here is a picture of my first attempt at an inlay. (Made from the parts in the previous picture.)
Attachment 287180

[lagore]

Looks fantastic I can't wait to try it.

[scorch]

I released the new version of F-Engrave and a video showing the process to make inlays. More information is available here: Scorch Works BLOG: F-Engrave 1.50
Attachment 288096

[voltsandbolts]

That looks really nice!

Sent from my XT1080 using Tapatalk

[scorch]

I released a new version of F-Engrave (V1.51). The only significant change is the addition of a separate Plunge Rate. The Plunge Rate controls the feed rate when the tool is moving straight down into the workpeice. If the Plunge Rate is set to zero the normal feed rate is used.

F-Engrave Download Link

[tdiehl]

Hi, when using F engrave 1,51 i get the following result - i see a couple of lines (in the upper right corner there are three of them going from the middle line to the outer line) that don'*t look...Attachment 297874

[Vogavt]

I see this occasionally too. I just load the processed GCode and manually delete the lines of code. I've also ran the file with them there and really can't see a difference in finished results since the extraneous lines are ramping up and out of the valley anyway.
Removing the lines of code (on my part) is only done to speed up the engraving process.

[lagore]

By changing the "Sub-Step Length" in the V-Carve settings you can control those little lines. In the first picture I used a sub step of 0.1mm and it gave the lines to the left but by increasing to 0.3mm all of the lines are gone.
Attachment 297886
Attachment 297888
I have found that it is better to get rid of the lines as it gives a much smoother curve on the finished product.
This is a much easier way to 'cleanup' the gcode rather then edit the code itself.
As Scorch says in the manual re. Sub-Step Length
"The v-carving algorithm steps along the font or DXF outline and performs tool location and depth calculations at a fixed interval. The fixed interval is the "Sub-Step Length" a large substep length will increase the speed of the v-carve calculation but could result in a more faceted looking v-carve. Reducing the "Sub-Step Length" too much can cause excessive calculation time and reduced CNC machine performance (due to excessive short G1 commands). If in doubt start with a larger step size and reduce the value until the results seem reasonable."

Edward

[scorch]

By changing the "Sub-Step Length" in the V-Carve settings you can control those little lines. In the first picture I used a sub step of 0.1mm and it gave the lines to the left but by increasing to 0.3mm all of the lines are gone.
Attachment 297886
Attachment 297888
I have found that it is better to get rid of the lines as it gives a much smoother curve on the finished product.
This is a much easier way to 'cleanup' the gcode rather then edit the code itself.
As Scorch says in the manual re. Sub-Step Length
"The v-carving algorithm steps along the font or DXF outline and performs tool location and depth calculations at a fixed interval. The fixed interval is the "Sub-Step Length" a large substep length will increase the speed of the v-carve calculation but could result in a more faceted looking v-carve. Reducing the "Sub-Step Length" too much can cause excessive calculation time and reduced CNC machine performance (due to excessive short G1 commands). If in doubt start with a larger step size and reduce the value until the results seem reasonable."

Edward

Nicely said Edward. One additional thing to note: If the extra lines are visible in the finished carving the F-Engrave setting for the v-bit angle is probably not exactly correct. Some v-bit angles are off a couple of degrees from what they are supposed to be (e.g. 58 degrees instead of 60 degrees)

[Vogavt]

Good to know!

[tdiehl]

Hi, again me, sorry for beeing boring, but i can't make it. I tried with different values (see pictures) in the Sub-Step Length. And the v-bit angle parameter is the original from setup (90 degr. / 12.7 mm). thanks for any help - ThomasAttachment 298204Attachment 298206Attachment 298208Attachment 298210Attachment 298212

[lagore]

Can you upload the image and a can have a go at it?
Edward

[tdiehl]

Hi Edward, thanks for your help. I tried 2 different ways. First as a bmp File (see attachment) and Second, i used the text mode in f engrave 1.51. I used the font "English Gothic, 17 th c.ttf". more ore less the same results... Thomas

Attachment 298220

[scorch]

The .5mm and 1mm step versions above look good (from the screen shots). There is always going to be one tool path running from the edge of each "loop" or boundary of the image to the center of the cut. These are the entry tool paths for each cut. These entry tool paths are there by design so that the cutter does not plunge straight down into the material at the beginning of the cut. Plunging straight down into material with a v-bit can cause problems (i.e. bogging down or chatter) especially for weaker machines.

[WillAdams]

Instructions on installing it on Mac OS X:

1.Launch a Terminal.
2.Make a directory to hold the final F-Engrave files: mkdir ~/Applications/f-engrave
3.Make a temporary directory to work in if you don't already have one: mkdir ~/tmp
4.Change to the temporary directory: cd ~/tmp
5.Download the F-Engrave source from here F-Engrave
6.Extract it to a temporary directory using unzip: unzip ~/Downloads/F-Engrave-1.52_src.zip
7.Change to the extracted directory: cd F-Engrave-1.5.2_src
8.Copy the F-Engrae Pythonfile to the final application directory:cp f-engrave-152.py ~/Applications/f-engrave`
9.Change to the included tt2cxf source directory: cd TTF2CXF_STREAM
10.Launch TextEdit and edit the Makefile in this directory to point to the proper freetype headers. Change the line g++ -o ttf2cxf_stream ttf2cxf_stream.cpp -lm -I/usr/include/freetype2 –lfreetype to g++ -o ttf2cxf_stream ttf2cxf_stream.cpp -lm -L/usr/X11/lib -I/usr/X11/include/freetype2 -lfreetype. You can also use vi in the Terminal if you're comfortable with it: vi Makefile
11.Run make to compile: make
12.Copy the new binary to the final application directory: cp ttf2cxf_stream ~/Applications/f-engrave
13.Change back to the temporary directory: cd ~/tmp
14.Download the potrace binaries for OSX from here Peter Selinger: Potrace
15.Extract it to a temporary directory using tar: tar –xzf ~/Downloads/potrace-1.13.mac-x86_64.tar.gz
16.Copy the extracted binary to the final application directory: cp potrace-1.13.mac-x86_64/potrace ~/Applications/f-engrave
17.Change to your final application directory: cd ~/Applications/f-engrave
18.Update your PATH environment variable to include this directory so F-Engrave can find potrace and tt2cxf. You’ll need to do this every time you launch the Terminal or add the line to your ~/.bashrc: export PATH=$PATH:~/Applications/f-engrave
19.Run F-Engrave using Python: python ./f-engrave-152.py

From: https://discuss.inventables.com/t/f-...e-on-osx/16187

[scorch]

Thanks Will, Looks like useful information for Mac users.

I love how he mentions you can use vi for the text editing. If you are hard core enough to use vi no one needs to tell you it is OK.

[sajurcaju]

Scorch, first I continue to be amazed at how nice a job your software does. Thanks very much.

I'm having some issues saving g-code. Here are a couple of scenarios:
Load image, load existing g-code file. Change sub-step length in V-carve settings. Recalculate v-carve. Try to save--no save happens.
Load image 1, load existing g-code file. Now load a different image that you want to use the same settings on. Try to save--no save happens.

Is there a way to specify default directory for images and g-code?

Thanks again,
Steve