So I updated to CC build 777 and went to run jobs that were previously created on the previous build and I am getting major issues with the tooling suddenly plunging very deep into the wood when it isn’t suppose to.
I have historically and up to the point of updating to 777 had zero issues with any of the CC designs and subsequent running of the files on my Shapeoko 4.
I ran two different projects both built on previous CC build and both had significant problems about 5 minutes into the run. Interesting enough both times the tooling plunged when it was cutting a pocket.
You can always uninstall CC and install the version you want. I am on CC 777 and have had no problems on my SO3 which is very similar to an SO4. Intermittently here on the forum individuals have their router plunge into their work and usually it is something they are causing. Post your file to get other eyes on it and talk to support for help.
In researching a solution I noticed on the Post Processor window that I have selected :Basic G-Code". There is an option to select GRBL. I checked CM and it is indicating GRBL version 1.1f.
Is this a possible conflict?
Sorry further thought on Post Processor.
I run a Shapeoko 4.
There are 4 options to select from>
Basic G-Code
GRBL
Carbide 3D Nomad Pro
Carbide 3D Shapeoko
I do not currently do any 3D.
Watched a CC created video and it stated to select Carbide 3D Shapeoko. Is this problematic if not doing 3D?
Thoughts?
The basic and generic gbrl post processors are for 3rd party machines. The Nomad and Shapeoko make the BitSetter available so you can have multiple tool paths and change the bit between each tool path. With the basic/generic you have to run one toolpath at a time unless they both use the same bit. If you have multiple bits than you have to run your toolpaths one at a time on 3rd party machines. That was also true before C3D came out with the BitZero.
Sometimes when you install a new version your post processor seems to get changed to the generic/basic post processor so on each upgrade or new install it is advisable to check that as part of your setup.
Maybe C3D could add a check of the post processor during the “Setup New Machine” to make sure C3D machines get the proper post processor. Since 3rd party machines cannot run CM and cannot run the “Setup New Machine” it would make sure you get the correct post processor. @robgrz
The toolpaths saved in the C2D file use a different, optimized post processor for Carbide 3D machines so it doesn’t matter what post is selected in CC if you’re loading the C2D file into Carbide Motion. (Optimized, as-in, built to generate code as quickly as possible, rather than be configurable, since it’s used on every file save)
@robgrz I have seen posts in the past here on the forum that someone that had a Shapeoko/Nomad and used CC and CM and for some reason picked Basic Gcode/GRBL and the file failed to use the BitSetter to change multiple bits in a .c2d file.
So is the Shapeoko/Nomad post processor baked into every .c2d file saved in CC? Is that what you are saying? I thought to get the full functionality of an Shapeoko/Nomad you had to have selected the Shapeoko/Nomad PP to get your BitSetter to work for tool changes.
So when using the Basic Gcode/Generic is the Shapeoko/Nomad PP overridden during saving a .c2d file?
There’s nothing special required for the BitSetter to work. It’s triggered by a normal M6 command, which is standard G-code. (I believe the GRBL post in CC Pro doesn’t use M6 commands because those are not natively supported by GRBL.)
When saving G-code in the C2D file we have a special post that’s written in native code, not Javascript, so it’s as fast as possible because it’s called so frequently.
I have had the same issue on a 3d project. The first plunge occurred on the first line of code.
I deleted the entire project and started with a new work piece. On the 2nd attempt, after completing the entire project, it plunged again, this time at the start of the very last line of code.