Help with Vcarve tool paths in Gsender

I’m a frustrated newbie attempting to cut a welcome sign
where I’ll have to change bits a few times. I can only enter 1 of the cut paths into Gsender at a time and the cut begins at the bottom left corner start (0) point rather than moving up and to the top of the 16” high x 24” wide board where it should start.
I was also thinking that I could load all the tool paths into Gsender and the program would stop allowing me to change bits.

I’ve made other simpler projects without too much trouble.
Any help would be appreciated

That’s what you want a sender to do. If you want all operations to be in one file, you’d have to set that up in your CAM program. What CAM program are you using?

As long as your the location you set work zero to be on your actual stock matches the work zero set in your CAM program, you shouldn’t have any issue.

Not sure what you mean here…

1 Like

I’m using Vectric V-Carve. Sorry I forgot to include that. Vectric shows a message that reads to the affect that Gsender Grbl doesn’t work with multiple tool paths. I noticed inside Vectric that all the tool paths start at lower left of model where I set my machine at zero each path starts the cutting just off that zero mark.

Are you saying that it cuts what should be at the top of the sign at the bottom? Or just that it seems weird that is does the bottom first. Like @NeilFerreri said if the zero position you selected in Vectric matches where you are setting zero on the machine then that part should take care of itself.

None of the G-code senders that I have tried work that way. They work on one file at a time. That file may contain multiple tool paths from Vectric. I have never tried to set up a tool change with a pause to change the tool but I think it can be done, it’s just not important enough for me to learn how to do it. I have combined multiple tool paths that used the same tool e.g. drill some holes, make a pocket, then cut the perimeter all with a 1/8" end mill.

I think a lot of the functionality that you expected from the G-code sender actually takes place in one of Vectric’s customizable post processors.

1 Like

Um this stuff doesn’t work that way unless you have a ATC. You can combine tool paths in the Vectric software only if the same cutter is used. That is also where you would set your start point. All of the important stuff happens BEFORE you send it to the post processor. Don’t tinker with pp settings unless you know exactly what you are doing. It’s all good, we can sort this out!

Thanks Rick
Like I posted, I’m a rookie with good intent. The only thing I did with PP was enter my 30x30 Longmill and when trying to make things work, changed the mm setting to inches. I did the same in Gsender. The model is inches and I am confused here. I prefer metric inball my work but need to learn about these settings also.
I appreciate your input

You can save multiple toolpaths with multiple tools to one file if you’re using the right post processor and have a way to manage the tool change. gSender is excellent and providing options for tool changes.

How far off?
Remember, your XY origin (work zero) should be set with the center of your endmill or, easier, with the tip of a Vbit.

Also, don’t bother with inches. You can design in inches, but I recommend post processing and running the machine in mm.

I set my xy zero with a v-bit, and what happens when I run is my machine runs the cut starting at zero and wants to cut the entire path next to zero and cuts at a scaled down size within an average 2” square section. I get the same results with whatever path I try. ;(

The scaled down size of the path could be a unit problem if the path is 1/25.4 the size it should be. It’s like grbl is reading the numbers as mm but the numbers should be read as inches.

I would double check that you are using the grbl mm post processor and that $13=0 in the grbl firmware. You can type $$ to view the current settings in the grbl console. Then if $13=1 type $13=0 in the console. Alternatively you can use the firmware tool in gSender and set $13 to off.

1 Like

The reason I recommend using mm in post processing, regardless of the unit used in the design, is a precision and rounding thing. Grbl uses mm internally and just does the math if the gcode is in inches. There are cases (arcs) when the rounding of inches causes precision issues.
You definitely want to keep $13=0.

1 Like

Hang on now, I use inches exclusively to 14 decimal places…
There is the rounding thing though

1 Like

I’m definitely new here, and while waiting for delivery of my longmill, I’ve years of time with Vcarve and CNC routing, albeit at an advanced hobbyist level. I don’t want to offend and please take this with a grain of salt but…

  1. The prevailing issue here is not the tool change, abandon that. As you become more acquainted with CNC you’ll advance to programs that support combining multiple tools and incorporate tool changes. Focus on single tool, single path for now and hone your feeds, speeds, and depths. Quality over convenience.

  2. Your design software unit of measurement and your post processor unit of measurement should match. Don’t mix and match. It’s confusing and not needed. If your post processor doesn’t like it, there’s a problem. It sounds like you’ve tried to keep everything imperial, which is fine. Just don’t waiver.

In this instance, it sounds like something, either Vcarve or gSender is creating MM instead of inches. I would double check, starting with Vcarve.

Resave the first toolpath you will run.

Makensure gSender is up to date.

Open the updated file in gSender.

Check gSender and make sure it is both set to imperial and that it appears to be scaled right in the visualizer.

Zero your tool, then raise it and inch or 2 so it is won’t touch you stock and is clear of all obstructions. Don’t start your router.

Send your code and see where the path goes.

If it’s not fixed you have alternatives. You’ve had successful carves before so this is a glitch. You CAN copy all of your vectors in Vcarve and paste them into a fresh project and start fresh in case something in that file is simply corrupted. It’s a pain but could be a solution.

You could try a different PP… I currently use UGS. I’m not recommending that unless you REALLY want to do that. It’s very similar to gSender but install is a little quirky and support is not there. I’m actually looking forward to using gSender once my longmill is here and in service.

I hope this helps. I’ve been where you are. Sometimes trial and error is needed to sort out issues. Wood isn’t cheap but use the trick of raising your Z and running code to see if you’ve sorted it out and you’ll spare yourself some cost when troubleshooting.

@CncJim Welcome to the group, Jim.

Respectfully, I suggest that your instructions may be lacking one step. You say that we should zero out the tool, then raise it a couple of inches so that the test run doesn’t have the bit hitting anything. However, if Z0 is not set at the new height, I believe when the code runs, it will drop the Z down from the original zero point and drive the non-spinning bit into the material.

It would not be the first time that I am wrong about this, so by all means set me straight.

1 Like

Absolutely correct! I probably should have finished at least one cup of coffee before posting that!

1 Like

Yep, did that once. I just take the bit out for a test run if I have any doubts. And I do agree, one tool path at a time until things feel comfortable.

Just to clear things up. This isn’t true.
The design units of measurement do NOT need to be the same as the unit chosen in post processing. They have absolutely nothing to do with each other. This is the case for small diy plotting machines made from dvd drives to many industrial level machines. The post processor does not generate toolpaths, it simply translates the toolpaths data into gcode compatible with your machine.
Grbl based machines can take gcode in inches or mm, and the default unit is mm. These means that every gcode command (Motion, feedrate) in inch mode (G20) is converted on the fly to mm. None of it is really a big deal and either will work, but there are occasional cases of arc endpoint errors that are due to the lower precision using inches. The precision had nothing to do with the machine’s capabilities and we’re talking a few µm, but it can throw errors in Grbl.
That said, you’re correct that a good post processor shouldn’t have issues. My vectric ones are linked above. (Vectric linked customers to my GitHub page for those using Grbl with toolchange needs).

While true in the technical sense, a new user that’s struggling with trying to figure out errors in their designs will benefit from being able to see that the dimensions they entered into their design have translated through to the final interface without needing to calculate between imperial and metric. I didn’t mean to imply that it was going to create a problem, rather, it was a "new user best practice " to make sure you stuck with one, familiar unit of measurement throughout to keep everything clear in your mind.

Sorry for any confusion on that point.

I have things figured out at this point. Thanks to all of you.

@keigeman As you seem to have resolved your issue, Ryan, I am closing the thread. Feel free to start a new one if the problem recurs.