vCarve Desktop and S3XXL (post processor?)

I design in inches and use the Shapeoko (mm) post processor included with VCP and haven’t had any issues except for getting tired and not paying attention. Works fine with GRBL 0.9 and v1.1.

I usually set my Zero point to bottom left corner top of stock.

Remember to zero your machine on all axis before running the file.

How large is your file you are trying to run? Which g-code sender are you using to send the file?

1 Like

That sucks @EvanDay! Sorry you’re having such troubles! Does the gcode vc9 puts out render correctly in a previewer like camotics? I use the shapeoko inch post processor and it works just fine. Hm… What gcode sender are you using? Through your gcode up here and I’ll have a look.

There is def a difference between the gcode vc9 generates and CC or fusion. vc9 is very “simple” in my experience - that is it contains very few safety or convenience code chunks. You hit Start and it just instantly hops to and starts cutting. Once I got used to it I now like it better than some other postprocessors that put in lots of tool changes and the like :slight_smile:
I’ve been sending code with grbl-panel with great success, since there’s currently at least one bug in CM with the XXL

I would worry more that the problem was caused by EMI.

Always best to test incrementally, and in scrap or foam before committing.

Sorry you are having problems.
I use V Carve Pro with Carbide Motion. I always save the file as Grbl (inch) and have never had a problem. I really don’t believe the problem is in VC but I never tried the Shapeoko post processor. One thing I will add is, I have never upgraded my CM since I downloaded it a year and a half ago. I don’t even know what version it is without checking. I like the “if it ain’t broke don’t fix it” theory. Maybe (as you said) try the generic Grbl and see if that makes a difference. I know it’s frustrating but you’ll eventually find the problem.

2 Likes

@Lewscrew: I will try the Shapeoko (mm) post processor tonight. My zero was the left corner and I knew to zero all axis. My workflow hasn’t changed at all aside from designing in VCarve instead of Fusion. I don’t suspect operator error as my workflow is correct, tested, and proven. I use Carbide Motion to send code to the SO3.

@Adam_Xett: I don’t use Camotics to preview, but the toolpaths do preview correctly in VC9. Sending using CM. I’m at work so will post G-code later if I have additional problems after trying different post processors.

@WillAdams: EMI was my first thought, but I changed literally nothing in my workflow or setup from the way I operated before successfully.

@Bjohnes: Yeah the generic GRBL processor is on my list to try tonight as an additional troubleshooting step.

That actually makes EMI more likely, though I think I left out the likely culprit — worn brushes. Please check and see if the job will run as an “air cut” w/ the spindle off — if that’s the case, check your brushes and see if they’re worn.

Another (remote) possibility is a change in your electrical service — when we first moved in to our house, compact fluorescent bulbs would burn out pretty quickly — turned out there was a failing transformer supplying our neighbourhood w/ electric and when it was replaced that problem went away)

1 Like

Well @WillAdams, you may be right. So after work today, I tried the same toolpaths I had built before with various post processors (randomly) in VCarve: The built in Shapeoko (both inches and mm) ones, the generic GRBL one, and even the generic Gcode one. They all worked, including re-running the original toolpaths. So I think it was either one of two things:

  1. EMI: Possible, but I still don’t feel this is very likely, as nothing else in my physical machine setup, workflow, or electrical service (as far as I can tell) changed. I can’t imagine that the VCarve produced G-code would react any differently to EMI than any other code. As far as brushes are concerned, I still have well under 50 hours of use on my Makita.

  2. The other possibility: So when I first tried the VCarve code yesterday, my dust shoe got hung up on a clamp, due to the unexpected behavior of the code compared to the outputs from Fusion 360 or CC. This caused me to miss some steps before I shut it off with the E-stop. I fixed the issue, and re-homed and then re-zeroed and tried to run the same toolpath again. That was when I was getting the behaviors that would normally follow an EMI issue or a static shock to the machine (I’ve had those happen when I was first learning the basics). I wonder if it was possible that some “trash” got left in the controller board memory after my first issue? The main difference between today and yesterday is that last night I powered everything off completely, and the machine had time for any stored energy to dissipate.

Everything was fine today with any of the post processors. Ultimately, I got Vcarve to do some inlay work. First project is some coasters in cherry with a walnut inlay. Band logos for my daughter. I will continue to test, but I guess just chock this one up to gremlins in the machine for now. I do find VCarve to be slightly more user friendly than Fusion for text or engraving and it certainly does a tremendously better job of handling vectors. Trying to work with .SVGs in Fusion is a pain the butt and trying to do inlays that way proved to be impossible for me to figure out.

Thanks for the helpful suggestions all. Hopefully in a few weeks, I will have some finished projects to show. I’ve got a test inlay project glued up now so will see how it looks tomorrow.

1 Like