Carving Text Fails

My apologies, you’re correct. I should have specified that Easel uses absolute referencing. I think most X-Carve post-processors do as well.

USB issues are one of the most common X-Carve problems and certainly the most frustrating. It can be interference from outside the system (lighting of other motors running) but often it is just the physical connection between the computer and controller. Unfortunately, there is no silver bullet fix as there are just too many variables. When I first built mine I suffered the same. It seems you just need to stumble on to the right combination of hardware.

My suggestion is to try several different cables and perhaps a different hub - or different cables and no hub. Just keep swapping things around and odds are somewhere along the line you will find something that works. I found my working assembly and it has run flawlessly for two years. Wasn’t fun getting here but worth the hassles.

btw - FUN FACT - do you know some USB cables are made with steel wire rather than copper. Yep, got one right in front of me now and I have seen several. All of then look great but perform very poorly if at all. Grab a powerful magnet and check them.

Actually, steel-based electrical wire can be found in many imported cables. First noticed it in my boat when I moved a wire across my compass and it caused it to swing. Stripped open the insulation and found copper colored steel strands. I will say so far they have all been low voltage type cable but …

I have made two attempts so far. The contour of the sign and the dinosaur came out beautifully on both. The name failed both times- once, the x-carve just stopped in place with no motion from any axis (the progress bar continued on in Easel funny enough). The second attempt, a few minutes in, it suddenly lost its place and became misaligned by about an inch.

The first behaviour sound awful familiar to my experience regarding stopping mid carve (I’m not using Easel though, so I don’t know about the progress bar). If you experience more like this my suggestion would be investigating mid carve stopping issue here in the forum (I’ve made a list about this here)
The second issue to me sound more like loosing steps or any other hardware issue, but it’s just a gut feeling.

Thanks for the info everyone :slight_smile: Will try and post a video soon for review. X-carves are noisy and babies sleep a lot.

Dominik, I am going to add your list of things to try to my agenda.

RayMacke, I will check if the cable is steel. From what I read in the last post, what worked for a handful of people was short cable with an active powered hub. Got the best of both that I could find on Amazon

I will be trying all of what I mentioned as suggested (theres no harm in it), but logically speaking, this is where I am getting hung up:

15 carves in a row - average file size, started instantly, zero failures
2 carves - larger file size, started after 15 seconds, both failed
3 more carves in a row - average size, started instantly, zero failures

Admittedly a novice, I know you guys have seen it all. Just wondering if anyone has an alternate explanation or similar experience.

The connection from the controller board inside the X Controller and outside USB jack on the controller box proved to be the weak link in my system. I ran a high quality (Belken) USB cable from the mini USB port on the board directly to the computer. That cured all of the USB drop outs in my setup. I am using a 6’ cable, and no hub. The computer is a cheep old used Lenovo notebook computer that is running Win 7.

As another suggestion, I dry run longer programs. What I do for the dry run is create the test g code with a high cut speed - as I am not cutting anything but observing where the cutter is going and if there are any surprises or potential collisions with clamping.

Yeah, realized a dry run wouldve been a better idea right about the time it started failing. Shame on me.

I wonder if Inventables has had anything to say regarding users tapping directly into the board?

Still working on getting tests done, but in the meantime, Fusion360 mentions something called “Data Starving”. It’s pretty self explanatory (see photo). Curious if anyone has run into this before?

1 Like

I use Fusion 360 for pretty much all of my CAM. I always set the tolerance on all of my operations to 0.001".

Switched the tolerance on the G-code from .003 to .05.

Brought the file size down from 19MB to 6MB.

Cant wait to test both of these out.

I’ve used .00x on all my previous projects as well, but then again, I haven’t done any jagged style block text before.

Sorry for the late response guys, but I need to deviate a little here. This is specific to Fusion360.

As I was checking out my 2D contour workpath for the image above, I noticed that one of the contours "opened up, and the path spilled out into the material (best way I can describe it).

I’ve experienced similar issues like this when in CAD (needing to close loops by creating an offset) but never in CAM. Need to resolve this first before I can try again. Anyone seen this before? Tried my best to find a solution for this, but I don’t think I can articulate it well enough for a good search.

Can you share the Fusion project?

Please forgive the inefficiency and poor practice, I’m still learning alot. Thanks :slight_smile:

With this being a separate issue, should I start a new thread?

Looks like I was able to resolve this. Recreated project from scratch, extruded the svg into empty space rather than carving it out of a block. Did the trick, and it’s performing exceedingly faster as well.

Will report back on new carve results as soon as I can.

I had success this weekend with the carve. I changed the COM port, baud rate, and removed my vac from the picture.

I will be replicating the carve with the vac to see if results are the same.

Side note- I also noticed my tabs were too short and some waste material was “kicking” into the path of the mill. This may have had something to do with it as well.

More results to come…

Same successful results with the vac.

I’m going to say this is a possible win for the COM port/baud rate fix. Topic can be closed.

Can you explain the “COM port/baud rate fix”?

See DominikMai’s post here for more details:

I am not positive this is what did the trick, but it may have, so that’s worth something…