We use cookies to personalize content, interact with our analytics companies, advertising networks and cooperatives, and demographic companies, provide social media features, and to analyze our traffic. Our social media, advertising and analytics partners may combine it with other information that you’ve provided to them or that they’ve collected from your use of their services. Learn more.
This machine keeps going off on it’s own path for no reason then picking up where it left off. has been the most frustrating experience for me. My many other much cheaper machines will run 50,100 hour carve sessions with 0 issues, this X Carve Pro can not handle a 20 minute contour.
It likes to randomly perform a full depth pass across my sheet for no reason, then continue on, like nothing happened. This is the 3rd time it has done it out of 7 sheets I have tried to carve. This last sheet cost me 160 dollars and I had to drive 2+ hours to get it.
Other problems included not being able to handle 3d adaptive tool paths, was losing position on every turn, and support had me lower the acceleration to 250.
I also spent over 6 thousand on a 80/20 enclosure to build for this machine. What is my option? Replace the controller?
So mad!!! I am now embarrassed and my reputation is damaged, and I am forced to refund my customers money and will no longer accept jobs for this machine.
There have been a few similar reports over on the xcarve pro Facebook group
If you haven’t yet, you probably want to submit an official support request.
I would also verify that $1=255
You can see this in the machine inspector (shift+crtl+D) in easel.
Can you post all of the grbl settings from in there at the very bottom?
(EDIT: support probably already verified these, no need to post them)
However if your making the gcode in fusion360 then there really is no reason to use easel as the gcode sender, in fact using easel as the sender kinda limits the capabilities of f360. Easel doesn’t support arcs, so that nice smooth curve is changed onto a bunch of straight line segments.
Instead you could use a dedicated gcode sender like UGS or Openbuilds Control.
I doubt the sender is the root cause of the issue. But by using easel as the sender you’re limiting the machines capabilities…
Hi Seth,
Thank you for the help. Can you suggest which of these senders are better for Fusion 360 on this machine?
The machine is running on a Surface Pro 7 with 8gb.
I tried turning down all the speeds, I am in no hurry just want it to function properly. At these speeds I was able to cut out a small square piece of MDF successfully, but it went right back to making its own toolpaths on a full sheet. Did not fix anything…
Just saw these error codes, no idea how to check them…
Hey Max,
Ugh. What a pain!
This has all the signs of EMI. Is the USB anywhere near the VFD or any mains circuit? It’s try to keep USB short and away from everything.
Can you run an air cut…no spindle and see how far you get?
Oh…tool numbers need to be below 255. Motion intercepts those, but most other programs pass them through and Grbl doesn’t like those 301s and stuff.
I just went on Facebook group and saw a BUNCH of people with the same problems… X-Carve Pro Owners
USB into the Surface Pro is on the opposite corner of the machine, so about 60 inches away from VFD.
The machine seems to do a great job cutting, just decides to make a full depth pass across the stock, then picks back up where it left off. This happens mid carve. It is not anywhere in the toolpaths. What gets me is it picks back up no lost steps, and continues, Wtf?
The acceleration and speed reductions I entered seemed to stop it from losing place on adaptive toolpaths, so I think that major issue was fixed, though it is now half the speed of a S3…
I did not know about the 255 limit, I was editing the tools and entering the last 3 digits of the Amana tool number. Will figure something else out for that, I guess I will try the last 2 digits.
Seems like the 255+ issue probably is not related to the wandering minstral that is my X Carve Pro…
How hard is it to replace the entire controller with something more reliable?
When the serial communication gets interfered with, bizarre things can happen. If some lines get skipped, the machine could move erratically and then resume the gcode like you said. You’re using absolute mode, so even when it goes off path, as long as no steps were lost, the position is still correct. It just does the next thing.
Definitely upgrade the USB cable.
Losing position as in going off path like above or actually losing steps?
I was unable to run adaptive 3d toolpaths. A .6 gap between frame and carve piece necessitated small oval toolpaths for a 1/4" tool, it would start out ok then after a minute was losing steps on each circular motion. Every time, a lot.
Support told me they made a mistake and the acceleration was set too high on the X axis. Put it to 250. I then slowed down max travel by 1/3 and set all axis to 250 hoping for some reliability. It seemed to stop losing steps but I did not test it much. Here is an example of what it was doing. Line is supposed to match the first layer.
Ordered a USB cable, not finding any double shielded or high quality replacements… Mostly Chinese braided…
I have no static buildup, the vac hose is 5 feet away from the machine… None of my other machines ever have any emi issues…
Just for clarity, if you are using Easel as a gcode sender, the NC file should not be changed when it is sent as far as I am aware. Easel currently does not support generating arc commands from its designs, but I do not believe it would go through the extreme hassle of looking at an NC file and changing all arc commands to line segments. I could be wrong about that, but it would really shock me if that occurred.
I looked at the original file and one generated by Easel after importing the original file for processing/sending. The only differences I saw were that M6 command and comments were removed.
Also, I did not see any G02 or G03 commands for arcs in the original file at all. It is all based on G1 commands which are linear interpolation (aka - line segments).
Easel doesn’t accept gcode with arc commands. @SethCNC is pointing out that, by using a different sender, one could post gcode with arcs.
Because he’s posting for Easel from Fusion.
Grbl linearizes the arcs anyway, but including them could have then benefit of much shorter gcode files without so many mini moves being sent to the controller.
you guys keep wining about easel, you might want to invest in something better instead of wasting your time. oh, wait a minute my internet will be back in a minute or two.
generate a circle in any other program (F360, Vetric, Carveco, etc) and when you select easel post processor, any lines of code will use G1, and X,Y coordinates.
When you select basically any other post processor, but let’s say a standard grbl one for this experiment, and you inspect that same file, you get G02, G03, and I and J coordinates which are the arc commands (you know this, I’m sure)
Why? it’s written into the Easel post processor that is being supplied and used, because Easel does not support I and J arc commands.
Here is an example. I saved one of my usual toolpaths from F360 with “G” being the grbl version, and “E” being the easel version. No changes were made other than selecting grbl post processor and Easel post processor. you can see the highlighted lines… the Easel Post processors will never include Arc commands.
And again in Carveco (this time I drew a simple circle and saved a profile toolpath one with Grbl, one with Easel)
In this circle example we are at 19 lines of code with GRBL and 170 lines using Easel PostProcessor.
that’s true, all I do is win, win, win; no matter what.
Easel doesn’t actually require internet once the page loads… so if you had internet to start this post, then assuming you opened the website at that same time, then you’d still have a working verson of easel already loaded up
Proof: (disregard the intro, this was made for someone else trying to point out intermittent internet connectivity as a reason for not using easel)
Granted, I also suggest not using Easel as the Sender, Easel is a perfectly good design software for simple 2.5D designs…
I was thinking that Easel would just be able to send the NC file without displaying it, but I can see that is not the case. I can understand that if Easel does not support arc commands internally that it can’t then produce the gcode nor could it visualize the toolpaths, so I guess they decided to just disallow sending it as well. That, in my opinion, could be an option where the software states that the gcode can not be visually represented due to “XYZ” command not being sorted, but it would still allow the file to be sent. I am sure, Inventables would not do that, but it is what I would do; I am all about options…
As @NeilFerreri1 stated, and I had already known, GRBL linearizes arcs anyway, so as long as Easel is linearizing arcs to a lower resolution or at least the same, it really is a irrelevant.
I noticed the USB cables are very thin and inside the controller they have the cable routed up behind the power supply and it is ran through the middle of quite a few wires. I ordered the best cable I could find and will attempt to re route it away from the power cables and will run it directly from the tablet to the controller board, bypassing the USB plug. Hoping this solves the problem.
Thank you Neil Ferreri!
