I have been trialing the software VCarve Desktop before making the plunge and buying it. Overall, I have found it to be much better than Luban or Fusion in usability and features.
I followed the tutorial for making a Welcome to our home sign, ran the toolpath for the pocket and cut passes and watched the subsequent simulations. Everything looked good. I then exported the Pocket toolpass through the Post Processor for Snapmaker and put the Gcode on a USB stick which I then connected to my A350.
I set the start point on my stock and started the pass. As per the simulation the bit carved out the center of the letters O in TO and HOME. However, things then went awry. Instead of starting to cut the outside of those letters the tool just touched down again and then just wandered off, carving a line in the stock wood before heading off into thin air.
I opened a ticket with Vectric and sent them the original project file and the outputted Gcode. They checked and according to them everything should have worked as expected. They ran the code through a 3rd party app to analyze the Gcode and it showed the code worked as expected.
Does anyone have experience of VCarve or this kind of issue. I don’t think Vectric can help me anymore because their software did what was expected - it seems my snapmaker is having a problem with the code.
Sounds weired… Did you try yourself with a GCode simulator like https://ncviewer.com/ ? I’ve so far only used Fusion for milling jobs, so I cannot vouch for VCarve, but in my experience the SM2 interprets GCode generally correctly - if the simulator looks right, I guess it’s something for a ticket to Snapmaker support!
Thanks for the link - I uploaded the Gcode and ran it through and to my untrained eye it looks like it is doing what it should be - which means there is probably a fault with my machine?
Can someone else take a look and see if they spot something I am missing? Pocket 1.cnc (1.5 MB)
To me it looks strange that above/aside from the letters there are these circles/arcs - but I have no clue about how the end result is supposed to look. But reading your error description, the drill digging in outside the letters, matches these circles, which seem wrong to me.
I’ve seen these loops before on gcode posted from Microvellum. For some reason it backplots horribly on any outside curves. Notice it can do inside (counter-clockwise) curves fine (the inside of the C near your arrow is fine, but the outside of the top is wonk). Because it’s using G2 for clockwise curves, but breaking down counter-clockwise into tiny G1 movements instead of using G3. However, the gcode usually runs fine. It’s likely just some non-standard way it’s doing the I# J# locations in the G2 making it plot funny.
It might be just unoptimized movements. Finish a letter here, snipe a little wood there, come back and finish up later. If you let it run, it might give you the proper end result, it’s just going in a very unoptimized pattern to do so. In Fusion, that’s why there’s an option to ‘order by selection’ otherwise it can generate all sorts of mank movements and waste time. Also things like ‘order by depth’ and ‘order by islands’ keeps it in the same place until it’s reached full depth instead of wandering off.
Looking at the gcode, it seems all Z movements are fast retracts and plunges (it only moves straight up and down, no ramping).
Example:
G1 X30.879 Y-0.998 (Cut Stops here)
G0 Z5.080 (Z is lifted to a safe retract straight up)
G0 X21.581 Y-4.407 (Head moves to new location)
G1 Z-1.179 F240.0 (Z plunges straight down)
G1 X21.957 Y-4.849 F800.0 (Cutting continues to new location)
Keeping this in mind, if I search for the retract height of Z5.080, a pattern emerges. I see the first few retracts are coupled with deeper and deeper cuts, like it’s finishing hollowing out a hole;
G0 X-38.194 Y-16.241
G0 Z5.080
G1 Z-0.590 F240.0
G0 Z5.080
G0 X-38.194 Y-16.241
G1 Z-1.179 F240.0
G0 Z5.080
G0 X-38.194 Y-16.241
G1 Z-2.359 F240.0
Notice the X/Y location is the same, so it’s repeating the same cut, just deeper each time. However if you keep following, it begins repeating the first depth, Z-0.590 over and over with new X/Ys, then begins repeating the next depth after awhile.
So yeah, it’s just… really unoptimized movements. It’s making the first few cuts over and over to the set depth, but then it’s doing the rest of the engrave at one depth, then going back and redoing the entire thing at the new depth.
Sorry for being so long winded about this reply. but I’d say let it run, the biggest problem I can see is if you’re using a flat endmill, with it just plunging straight down, it might make Z lose a step and throw off the depth, otherwise, it looks fine.
EDIT: Another thing I noticed is at the beginning, it’s setting the G0 speed to F600, yet your cut speed on G1 is F800, which means your rapid movements are slower than your cutting moves.
G90
G0 Z10.00 F600
G21
M3 S19000
Changing this F600 to F800 or even F1000 would save some time, since it only applies to the G0 movements of retract and fast travel.
Thanks for looking at the code in such depth and taking the time to explain what it happening - very helpful.
I uploaded a video of what is happening every time I run this code. I would be happy to leave it running, but it is very clear to see it isn’t doing what it should because of the groove it carves into the block as it wanders off after finishing the center of the O’s in TO and OUR.
You can see where the tool is in the preview, right on the corner before the big looping circle. It’s also the first instance of G2. You’ll have to change the post options to not use G2/G3 commands for circles.
Yesterday when wrote all this up i hit the update firmware button the controller and it said i had the lastest version. Can’t remember exactly off the top of my head the number and i am away from my machine right now.
I think this is the most recent one. I’d agree with Skreelink’s assessment that there’s a problem in interpreting G2/3 and/or the way VCarve parameterizes these commands. Your video matches very well what ncviewer shows. While Skreelink’s suggestion to configure the post processor not to use G2/3 is the short-term way to solve this, it may turn out that VCarve does not allow this setting. So I’d suggest to reach out both to VCarve and Snapmaker support to understand if they can offer a solution. FWIW, I am very confident if you would do the CAM in Fusion, it would work - of course that is a poor suggestion - you want to use VCarve.
Wanted to provide an update and complete this thread. I sent all of the information I had to the folks at Vectric and they agreed with the comments on this forum that the arc commands were causing the problems and so they wrote me a custom post processor file.
I uploaded that into VCarve and it worked first time. Beautiful!
Hi Steve, I can attach the file here. I want to caveat this with the understanding that this was created for my setup and therefore might not work. It should, but it might not. Also, Vectrics wanted to call out that if they make changes this might not work in the future. Just FYI!
Download the attached file, unzip and save locally on your PC.
2. From the Vcarve software > Menu bar > Machine > Install Post-Processor… to browse and select the post. (This will add the post to your available set in the list but will also
copy the file to your PostP folder)
3. Then go to Menu Bar > Machine >Machine Configuration…
4. Ensure your current machine is selected in the drop down list.
5. In the Associated Post-Processors section click the ‘+’ button on the right to open the Post-Processor Management list.
6. Choose the post you just installed, which will be at the top of the list with a pen icon next to it.
7. Click Select (or just double-click it in the list)
Thank you so much! Judging by the simulation this has worked! Previous simulations would show the paths veering off course just as yours did. I will run on my machine soon.
but I’d say let it run, the biggest problem I can see is if you’re using a flat endmill, with it just plunging straight down, it might make Z lose a step and throw off the depth, otherwise, it looks fine.
