I am having difficulties figuring out how to create a GCODE file that will mill out between text letters instead of just the path outline.  When done, I want the letters to be higher and the space between the letters to be milled lower.  I think I should be using the "AREA" gcode extension, but I haven't been able to get it to work.  All it seems to do is create GCODE that does the path outlilne.  Any help would be apprecaited.

Welcome to the forum!

Besides using the Area extension, you probably also need to create a special path which contains the area.  It's called a compound path.  Try this:

• Duplicate the text
• Draw a rectangle around the whole project.  The rectangle would represent the size of the wood block
• Select both the new rectangle and the duplicated text/path
• Path menu > Combine

Now using the Area extension, be sure to look at and set the options on all the tabs of that extension.  You should see something different on the canvas too (different from your previous tries), after you apply that extension.  If I recall, it shows you the paths which the cutter follows in green.  And of course the gcode file should be different.

If you still can't sort it out, please feel free to share your SVG file, and it will allow us to give you very specific steps.

I appreacite the fact that you want to help, but I've tried what you described and it doesn't appear to be working.  I have attached a simnple file that explains what I'm trying to do.  All I want to do is to be able to create the GCODE that will mill the path shadded in black in the associated file at a specific depth leaving the words untouched.  Project is making a sign where the portion between the letters are milled at a depth lower than the words themselves.

Well, I'm having the same trouble here.  In the past, it would create green lines where the tool was supposed to pass.  You can set them as zigzag or spiral.  And when I would feed the gcode file into a simulator, you could see the cutting head was following the green lines.  But I can't seem to configure it  so that it draws those green lines.

I did find a couple of problems with your file.  But fixing them did not produce results.  One is that you have the Scale set wrongly for inches.  So this would just result in something not the right size.  But it still should work otherwise.  For inches, the Scale setting in Document Properties should be 96.000. 

And the other is your object is a Group of 1.  It probably should be ungrouped.

To be honest, there are a lot of settings in these extensions which I have no clue what they're supposed to do.  And not having any kind of machine myself, I'm not sure what proper values should be.  So I could easily have missed something or set an unrealistic value.

For example, your test file is 5 inches wide - the drawing is, athough the page is much larger.  The tool diameter is 10.  So if that means 10 inches, we have a big problem!  No wonder it can't draw the cutting lines, if the diameter of the tool is larger than the whole project (and the spacing of the cutting lines depends on the diameter of the tool).  Of course I realize a cutting head of 10 inches in diameter would be used to cut a sign the size of a battleship!   But I still don't know what a proper diameter should be.

Maybe someone else will know what to do?

After almost 7 hours of messing around with it, I finally figured it out.  I apologize for the mistakes in the file regarding the tool diameter.  I had tried changing it in other test scenarios but still was not able to get it to work.  But bottom line here, that extension must have been written using "mm" and not "in" (inches) in mind.  Which goes along with why the default tool diameter would be set to a value of 10 initially.  But even a "1" inch tool diameter would still be a rather large tool.  So I just tried it with a realistic tool diameter of (1/4 inch - 0.250) and it does work.  But one of the most mis-leading issues with the extension is that the "Fill Area" tab uses the "tool overlap" value on the "Area" tab and that value must be less than 1 or you get a very misleading error.  It will say "Tool diameter must be greater than 0!".  I think this is a bug.  While it does use the value in the "tool library, it also checks the tool overlap value.  I guess it could make some sense, but it's just a bit confusing.  Bottom line, I have attached a new test drawing along with the produced GCODE that does this properly.  I hope others will not have to go through the learning curve I did.  I explain it fairly well in the drawing.  I havre also run this through the free CNC simulator CAMOtics and it looks good.

TroyH

Yeah, I also tried manually changing the tool diameter, but I still didn't get the results I was expecting. 

I also was confused with the Max Area and Area Width.  I don't know why 80 and 75 should work, when your drawing is just 5 inches wide??  It must mean something besides what it sounds like. Also, my orientation points were always different from yours.  They showed the same values, but they were placed differently.  All very confusing!

Ok, here's a few steps you can skip.  There's no need to copy the group into Paint, and then import and trace it.  Just ungroup it.  That's all you need to do.  There's already a path inside the group.  ....oh....oops....  Well, there was in your other file.  In this file, it's text.  But you can convert it to path like this

• ungroup
• select the text only
• Path menu > Union
• select both the new text paths and the rectangle around
• Path  menu > Combine 

In my previous experiments, I did not need the inverted coloring, to get a proper result.  So I'm not sure if that's required.  My previous test was with version 0.91, and I didn't have any fill color at all.

You still have the Scale wrong (for inches), so your sizes might not come out as you expect.

Well, for the record, from what I've heard, unless we can find developers to almost re-write these extensions, they might be removed from the program.  (I think this means they won't be in 1.0, but it might be 1.1 before they are removed.)  It was quite frustrating for me (in the position of providing support) when the developers of these extensions stopped providing support shortly after getting them packaged with Inkscape.  (A Russian team, which might explain some of the odd terminology.)  They seem to have so much potential, but are nearly impossible to figure out and use.  So I hope they can be improved.

Thanks for the suggestion reagrding unioning the text letter paths and then doing a path combine on the rectangle and the letter paths.  This worked without having to create  bitmap image.  Once I did that, I did more extenive testing reagrding the "Gcodetools" "area".  I am runing version Inkscape 0.92.4 (5da689c313, 2019-01-14).  I found that the problem is that on the "Area Fill" page, even though the radial button says "zigzag", it seems to default to "radial" and not "zigzag"even thuough the UI under "Area Fill" syays its running "zigzag".  This was very confusing, but I ran test after test making sure to close the file without saving changes to any of the values in the "Area" or "Area Fill" and yet the first time I would run it after restarting application, the path always came out as spiral.  Checking the radial box for "spiral" running the path one time, then do a CTRL-Z to undo that path, check the "zigzag" button, and then rerunn area path gets it back in sync.  Also, the "spiral" seems to have more errors in its calculations than the "zigzag".  For instance, when I ran "spiral", I would get a few paths actually cutting through the first "T".  Running it under "zigzag", it works everytime.  I finally have this working exactly how I wanted originally.  Finally, the last thing I'll say is this:  I originally wanted to have the gcode do the first pass by doing a normal cut where it would just outline the letters, then come back and mill in between the letters, that way the second cuts were not actually cutting all the way up to the letters.  As I suspected, if I selected both paths when doing the "Path to Gcode", it does in fact create both paths in the GCODE file.  I have not been able to get the original path to be first, but worst case, I'll edit the GCODE file manually and switch the order.  I suspect if I messed around with it long enough, I could get it to do it in the proper order without having to modify the output file.

Thanks for your help

Well, I wish I could have been better help.  But congratulations on getting it all worked out!