Open Source V-Carving

[scorch]

I have included the vcarve file and the clean file here.

From what I can see from the .ngc files it looks like you might need to increase the "Cleanup Search Distance" setting to clean up the areas that are being missed. (although it looks like you already increased this setting some so I may be wrong.)

In order to avoid cutting the outside of the image you may want to invert (negate) the bitmap colors before you bring the image into f-engrave.


I am guessing a little bit on these answers. To fully understand what is happening I also need the image file (dorman1.bmp).
Scorch

[ocadmiral]

dorman1.jpg
In the clean file that I uploaded, I cut it down to 3/4". I had an earlier cleanup set to 3" and it would have done the inside of the "frame" and all the letters, but it also wanted to do the outside of the frame for 3" and that exceeded the limits of my travel. I have added the bmp that i used.

Thanks again.
Joe

[scorch]

I think I understand better now.

The issue is that the cleanup was spot on for parts and off (missed cleaning up the waste) by about .125" for other parts.

For areas that are not getting cleaned up using the flat cleanup cutter you can try using the V-Bit cleanup. The v-bit cleanup will get into the areas the flat cutter can't get to. The v-carving tutorial (V-Carve Tutorial) shows the use of the different cleanup operations.

The second part of is that I am trying to figure out how to clean up only the inside of this sign and not the outside as that is just air or will be trimmed off.

Inverting the image colors before you import the image will help you keep the cutting paths within your machine dimensions. You may have to use an image editing program to increase the distance between your design and the edge of the image to meet your needs.

I hope this helps.
Scorch

[ocadmiral]

Scorch,
Thank you. I didn't think of inverting the image but that did the trick for the cleanup on the outside. I am still having an issue with the cleanup missing sections. If you refer to the image I posted in the previous note, as an example, about 1/16" on the right side of each 1 was missed while the left side was cleaned perfectly. This seems to hold true for almost every letter, the right side was not completely cleaned while the left side was perfect.

Just thinking out loud here, but is there a difference in the windows files .vs the Linux files? I do all the code generation on my Win XP Pro machine and then save the files to a flash drive to use on the linux machine in the garage. I am just asking because I loaded the latest 1.13 on the linux machine and when I go to the FILE I do not see the "Open DXF/Bitmap File" choice. It says "Open DXF File" and even though I have the .bmp files on the flash, it will not see them.

Is there somewhere in the files or program that I can try to tweak the setting that controls the cleanup standoff?
I did try this, and it helped some but not completely. When I set the cleanup bit size, even though I was using a .125 square end bit, I entered that I was using a .110 bit. My thinking was that the software takes 1/2 the diameter and then figures how close it can get. The results were that the uncleaned side was smaller but still needed hand cleaning and the cleaned side was slightly into the letter (but I can deal with the cleaned side if I have to).

The program is awesome, and it is working 97% as it should, but that 3% can still leave a bunch that has to be cleaned by hand.

Thank you again,
Joe

[scorch]

Thank you. I didn't think of inverting the image but that did the trick for the cleanup on the outside.

There is also another way to limit cutting outside of the design that slipped my mind. Just add a bounding box in the general settings window. With the bounding box you can control the size of the gap between the design and outside box within F-Engrave.

I am still having an issue with the cleanup missing sections. If you refer to the image I posted in the previous note, as an example, about 1/16" on the right side of each 1 was missed while the left side was cleaned perfectly. This seems to hold true for almost every letter, the right side was not completely cleaned while the left side was perfect.

I don't know about this one. I will see if I can replicate it.

Just thinking out loud here, but is there a difference in the windows files .vs the Linux files? I do all the code generation on my Win XP Pro machine and then save the files to a flash drive to use on the linux machine in the garage. I am just asking because I loaded the latest 1.13 on the linux machine and when I go to the FILE I do not see the "Open DXF/Bitmap File" choice. It says "Open DXF File" and even though I have the .bmp files on the flash, it will not see them.

The Windows and Linux files are the same. If you don't have Potrace installed on your Linux system F-Engrave will show only options that are supported by F-Engrave directly (the same is true for TTF fonts and the ttf2cxf_stream executable)

Is there somewhere in the files or program that I can try to tweak the setting that controls the cleanup standoff?

No, there is no adjustment for the "cleanup standoff"

Scorch

[scorch]

If you refer to the image I posted in the previous note, as an example, about 1/16" on the right side of each 1 was missed while the left side was cleaned perfectly. This seems to hold true for almost every letter, the right side was not completely cleaned while the left side was perfect.

I tried to find some indication of this in the .ngc files you posted. Here is a screen shot with both the base .ngc file paths and the _clean.ngc paths plotted. I filled the gap between the V-carve toolpath and the cleanup toolpath with red to highlight the distance between the two. It looks very consistent all the way around. I even spot checked the distance between the paths. The gap was .0625 plus or minus a hair which is correct for a .125 cleanup cutter.
ones.jpg

Scorch

[scorch]

I thought I would give a public update to the recent discussion surrounding poor cleanup.

After discussing the cleanup issue with ocadmiral through private messages the bad cleanup was determined to be caused by factors other than the code generated by F-Engrave.

Scorch

[CaptainVee]

Scorch, do you think there is a way for f-engave not to make multiple entries for the same segment that is to be engraved?

I engraved a 16.000 lines of code drawing last week and my machine spent most of its time accelerating and slowing down. Not having to enter the same segment several times would give a serious reduction of milling time.

[scorch]

@CaptainVee
F-Engrave already groups cuts that are end to end or near each other. For simple engraving F-Engrave will cut each segment that is imported only once after grouping them.

For v-carving f-engrave may cut the same location more than once depending on the design.

There is potential for improvement in the v-carving but it would require significant effort. It is on my list of potential improvements already.

Scorch

[scorch]

@CaptainVee
There is a chance that F-Engrave is not grouping your line segments because the default Accuracy setting is too small when working in mm.

Try setting the Accuracy in the general settings to .0025 or even .0250 to see if that helps.

If you give it a try please let me know if it helped or not.

Thanks,
Scorch

[scorch]

Has anyone seen this error when trying to run F-Engrave on Windows?
"application configuration is incorrect"

Someone on another forum is getting this error. I have never had anyone report it before.

Thanks,
Scorch

[lancut]

I run Vista and so far are no errors of this type.

[Vogavt]

Scorch,
Did you develop this with C++?

If so, then since it's a fresh install of Windows, I'd suspect the runtime components may be missing.

Have them try to install the Microsoft Visual C++ 2005 Redistributable Package (x86) from Official Microsoft Download Center which only installs the runtime components of Visual C++ Libraries required to run applications developed with Visual C++ on a computer that does not have Visual C++ 2005 installed.

Might be worth a shot!?

[scorch]

@Vogavt

I think you are onto it. I didn't use C++ directly for F-Engrave (although TTF2CXF_STREAM is C++). However, I did use py2exe to make the windows executable. Py2exe was compiled using Microsoft Visual C so there is a dependency. I will check it out.

Thanks,
Scorch

(Based on the py2exe documentation the 2008 version would be needed rather than the 2005 version Vogavt linked.)

[scorch]

F-Engrave V1.14 is now on my website. Here is a link: F-Engrave

Version 1.14 contains a fix for a bug that caused the Cut Depth Limit not work when using b-carving (ball end mill equivalent to v-carving). I also updated my website information in the Help Menu.

For those that have not noticed yet my website is now Scorch Works (scorchworks.com)

Scorch

[scorch]

F-Engrave V1.20 is now on my website. Here is a link: F-Engrave

Version 1.20 allows the use of extended characters with character codes greater than 255 (F-Engrave V0.9 fixed them up to 255)

There is a new option in the "General Settings" window to enable extended characters. For extended character to work you will need the new version of ttf2cxf_stream. The new ttf2cxf_stream is included in the windows download and the source is in the SRC zip file for Linux users.

Scorch

[sliptonic]

Scorch,
V1.20 looks great and fixed the problem I was having a couple months ago. Thanks.
One feature I'd really like to see is a simple way to use the app from the command line. I'd like to be able to launch it by passing in the path to an existing gcode file for settings, a new string to be engraved, and a parameter to cause the app to run 'headless'. In the headless flag is used, the new input string would be read and the gcode output dumped to stdout where it could be piped to a new file. The program would then terminate normally.

Ideally, the input string would take something for a newline character to allow multi line input.

I think this is pretty simple and I might give it a shot myself. Any guidance?

Thanks

[scorch]

@sliptonic

I uploaded a new version 1.21. That has a batch mode (-b) and text input on the command line (-t "text"). To input a newline character just insert a pipe character "|" in the text.

The -f option can now be used to specify the font directory, font file or image file (BMP, DXF, etc).


This is a dump of the new command line options:
Usage: python f-engrave.py [-g file | -f fontdir | -d directory | -t text | -b ]
-g : f-engrave gcode output file to read (also --gcode_file)
-f : path to font file/directory or image file (also --fontdir)
-d : default directory (also --defdir)
-t : engrave text (also --text)
-b : batch mode (also --batch)
-h : print this help (also --help)

As always the new version is available on my web page: Download F-Engrave

Scorch

[Miata2k]

Scorch,

I'm very impressed with your software. I only found it a few days ago and have been able to make some great looking signs. Okay, they have all been test runs, but they will look great when I'm finished. Just have to figure out all of the "Cleanup" settings.

I do have a few questions for you...

First, is there a reason that you limit the line spacing to 1.0?

I modified the code to change the lower limit to 0 and it still seems to render fine. I just haven't tested the G-code that was generated to see if it messed up when the text crossed over.

    
def Entry_Lspace_Check(self):
        try:
            value = float(self.LSPACE.get())
            if  value < 0.0:
                self.statusMessage.set(" Line space should be greater or equal to 1 ")
                return 2 # Value is invalid number
        except:
            return 3     # Value not a number
        return 0         # Value is a valid number
    def Entry_Lspace_Callback(self, varName, index, mode):
        self.entry_set(self.Entry_Lspace, self.Entry_Lspace_Check() )

See the Attached Images, the first has the line spacing set to 1, the second one has the spacing set to 0.8
Line Spacing 1.0
F-eng1.JPG

Line Spacing 0.8
f-eng2.JPG

On this default font is not a huge difference, but some I've look at just leave too much white space. Some fonts I looked at only used Capital letters so there is no need to leave space below the line.

Second question.
Is there anyway to display the "Bounding Box" information again?

It show up in the status bar when you hit recalculate, but then is gone with the Calc V-Carve button press. This is very handy information to have around. Maybe you could find some area of the screen to leave it displayed, or on a about box. It would be really great if it would be in the G-code file, so you could know how big the sign will be when you open the g-code file up in future to make another sign.


Finally,
Where did you find the Aztec Calendar that you milled? I've found a few on line in different formats, but nothing that imports correctly. I'm not sure if this is a bug in the F-Engrave software, or a problem with the original image. I'm not sure that I'd ever take the 20 hours needed to generate the g-code for it, but it would be nice to know that it worked.
aztec1.jpg

Thanks
-Chuck

[scorch]

First, is there a reason that you limit the line spacing to 1.0?

No, there is not a functional reason. You make a good case for changing the limit to zero. I will do that in the next release.

Is there anyway to display the "Bounding Box" information again?

No, but again you make good points. I will see if I can find a place to display the bounding box dimensions more permanently.

...It would be really great if it would be in the G-code file, so you could know how big the sign will be when you open the g-code file up in future to make another sign.

I am on the fence about adding the bounding box data to the output. If it is easy I might do it.

Where did you find the Aztec Calendar that you milled? I've found a few on line in different formats, but nothing that imports correctly.

I have no idea where I got it... It was an SVG originally but because F-Engrave is sensitive to how the DXF shapes are created (clockwise vs. counter-clockwise) I converted the image to a bitmap (instead of a DXF) and read it into f-engrave from the bitmap.

I'm not sure if this is a bug in the F-Engrave software, or a problem with the original image.

That is wacky looking. Does it open correctly in Inkscape? Or another program?