[Solved] This machine ruined yet another project of mine

I’m shooting at about 25% of everything I do ends up in the junk pile. Something is seriously messed up with the z axis in this machine. This time I was running at 25 IPM with a 60 degree bit. I’m not running the machine too fast. The program ran on the first piece with no problems. The second piece the head didn’t pick up and dragged across the piece and ruined it. I ran the program a third time and it was fine.

The power could not be any better in my building. I’m using the USB cables provided with the machine. I’m using a $1,000 Microsoft laptop. This machine is running on it’s own 20amp breaker with absolutely nothing else on the circuit. The belts are perfectly tightened. I was not running anything else in the room and the vacuum was not on. I was running the machine very slow. It just randomly messes up in the z axis at random times. I’m at the point to where I no longer trust this machine.

Yes. $1 is set to 255

Now what? I don’t want to run the machine on anything but cheap pine now. I have cut boards that are worth $200 just for the raw wood. What if this thing does this cutting a juice groove?

Posting a link to the file would be a helpful start. Ill take a look and see if anything looks funky.

Since it ran fine on the third run it’s probably not the file though. Have you checked all the z-axis pulleys and made sure the acme screw turns easily?

I’m not at my pc at the moment to verify the toolpath, but I can see that you have ramping turned on, and that cold be part of the issue.

Ramping when it was first beta tested bad similar issues, but were fixed. Personallt I don’t use ramping when using vbitssince the bit has a taper to begin with.

Again, I haven’t checked the toolpath to verify that this is the specific issue, and that its not related to other z dropping seemingly on its own that many other XCP owners complain about :man_shrugging: but its a possibility to check for

1 Like

Weird. It doesn’t seem like youre loosing steps on the x axis because all the letters are a consistent depth. The only thing I can think of is a glitch within easel.

I see that you’re using a 20deg plunge and the error looks like its probably around 20deg. Maybe try using a vertical plunge instead.

Screen Shot 2022-02-10 at 4.37.15 PM

1 Like

I just finished up another part with the same program with the ramps and nothing happened. So, 3 out of 4 turned out with the same program. Only the second one glitched. I have the worst luck with everything. My machine probably has a bad controller or a bad z axis. It just doesn’t fail all the time. Just enough to give me a false sense of hope.

In the future I will remove the ramps from v-bit stuff just in case. That’s unrelated, but sound advice. Thank you.

Hi @PatrickVerner,
Could you please reach out to our CS team at help@inventables.com? We have a couple of things we like you to try to get you carving with a 100% success rate!


1 Like

While there have been a couple of issues with plunging and toolpaths in the past, I can not seem to generate any errant toolpaths with the file, and the issues that I am aware of were resolved several months ago.

To me, this appears like it is another issue where the Z-Axis did not retract, possibly due to noise within the controller or something that is not quite tight within the Z-Axis. Also, the fact that 3 out of 4 were successful also makes me suspect it is not a toolpath issue.

When you have multiple pieces to carve that are the same file, you can generate the toolpaths for everything. If everything looks good in the preview, download the gcode files, and then use them to carve each piece. If one messes up, you know the toolpaths are already good and nothing was changed, so the issue would then definitely be in the machine/controller itself.


Brandon Parker

1 Like

Why can’t you post the solution here? It might help other people. Tell me what to try first.

1 Like

Hi Patrick,

We recommend contacting our customer success team directly so that they can work through your specific issue with you to see what steps might be required and track it in our system to make sure we can respond to you most effectively.

While we try to help out on this forum when we can, it is not the best channel for getting support from our customer success team.


1 Like

I’d been having the same problems for several weeks. One time my 1/32" ball nose bit plunged through the workpiece, its backboard, and my wasteboard, and was attempting to drill even further, missing a clamp mounting insert by less than a 1/16 inch. Another time it snapped a 4 mm ballnose into pieces.

I reset $1=255, isolated the X-Carve Pro circuit, edited the Windows laptop USB port sleep settings, rechecked the vacuum hose ground, upgraded to shielded USB cables, and finally bought a new dedicated desktop computer. We even installed a modified grbl.hex file, but still it persisted.

Working closely with Inventables Support, I think (hope) we’ve finally narrowed it down to the Motor Lock/Unlock feature. It appears that for the X-Carve Pro, using the Motor Lock function between bit changes was causing my detail carve to mess up on the Z-axis.

It appears that for the X-Carve Pro, at least, that we should not use the Motor Lock function at all. Easel’s Walkthrough Tutorial for Rough/Detail Carving does state that: “It’s not necessary to lock or unlock your motors if you have homing switches as you will re-home the machine after changing the bit.”

I’d been following 2-Stage Carve instructions apparently meant for non “Pro” machines and had been using the Lock/Unlock. Since then, I’ve not had any more issues…

I hope this helps.

I did. 14 hours ago. It’s hasn’t been a day yet, so I’m still not that concerned.

Well, I hate to say this but per the manual provided, the cnc must be fully powered off and unplugged during every bit swap, so using the lock feature should not do anything while the XCP is powered off and unplugged :man_shrugging:

I have to admit that I have not been shutting my system off for bit changes (per the Safety Manual) - of course I always make sure that the spindle isn’t running. But, other than for legal/liability issues, I’m not really sure it’s necessary. Is there history of the Pro’s starting up on their own?

Easel’s “Walkthrough Tutorial: Two-Stage Carves” does not mention shutting off or unplugging the X-Carve Pro for the bit change. Here’s what it does say:

This is the trickiest part of completing a two-stage carve. Turn off your spindle. In Easel, click the “Carve” button again to open the walkthrough. Use the machine controls to raise your Z-axis high enough to remove the roughing bit from the collet.

Once the bit is raised enough to remove it, use the machine controller to lock the motors.

Then, being careful not to move the spindle along the X-axis or Y-axis, remove the roughing bit from the collet and insert the correct detail bit.

Unlock your motors in the Easel machine controller and lower your Z-axis back down to the material. Zero your Z-axis the way you normally would for a carve.

If you are using the z-probe and homing switches, please follow the order of operations at the beginning of the article. It’s not necessary to lock or unlock your motors if you have homing switches as you will re-home the machine after changing the bit.

I’m thinking that Inventables should disable the motor lock feature altogether for the X-Carve Pro machine profiles and then revise this tutorial.

Meanwhile, I’m going to continue hoping that my “random” Z-axis plunge problem has been fixed.

I have only run half a dozen or so projects on my 4x4 X-Carve Pro so far. On two of these, I had the machine all setup for the project, probed the Z-probe and set my origin. Then when I ran the project the machine immediately buried the bit into the workpiece and cut a large gouge in the project and broke the bit, before I could stop it. After the second instance I did some thinking to try to figure out what I had done differently in the two failed efforts, as opposed to the other perfectly successful runs. What I discovered is that, after I probed the Z-probe, I raised the Z-axis to clear the workpiece and facilitate installing the dust collection boot. Both of the unsuccessful runs, the Z-axis was accidentally run all the way to the upper stop in this process. My theory is that, in doing this, the machine lost the true position of the bit and thought it was higher than it was actually able to go because of the stop. Since coming to this realization, I have avoided hitting the upper stop and, if I do accidentally go that far, I subsequently re-probe the Z-probe before running the project. I have not had any ruined projects since then. I hope this helps.

1 Like

If you set $20=1 then you will get an alarm when you do hit a switch, then you’ll at least have a chance to redo the probe and try again without the lost steps…
While you’re there double check the $1=255 as well.

$20 is the soft limits and setting it to 1 will turn them on…im not sure why inventables ships all three units with this off. Most cnc companies turn it on by default :man_shrugging:

Inventables sent me new firmware through email and the correct GRML settings. They were different. I don’t remember what changed, but it did seem like at least 3 or 4 settings were different. There was a newer version of Easel driver available. They really need a banner at startup telling you Easel driver needs to be updated.

I’m not sure what made the change, but I’ve ran 6 projects now without any indecent.

Possible causes for my problems…

$1=0 wrecked stuff
Easel Driver malfunctioning and wrecking stuff
Easel glitching and wrecking stuff (ramping v-bits. don’t do this.)
GRML settings not exactly right
Firmware not running the machine correctly (possibly motor locking issue?)

Things Inventables fixed…
New version of Easel driver
Easel update
They told me the correct GRML settings
They updated the frimware

We’ll probably never know what the exact cause was. If this thing runs for a entire week, I’ll post back here again.

Get in contract with support and make sure everything is up to date and your GRML settings are correct.

Looks like @PatrickVerner issues were resolved. Each machine problem we want to treat uniquely and we encourage anyone with our hardware who is experiencing issues to contact our CS department.