Carving Text Fails

Good Morning,

I have had success (eventually) with a few dozen projects on my X-Carve, but I am running into issues with some text projects.

The project in particular I need some help with is a sign with a name and a dinosaur cut out of it. 3 stages in total- dinosaur cutout, name cutout, contour of the sign. The name is just 6 blocky letters. The text was created in Illustrator, imported into Fusion 360 as an SVG, and extruded.

Here are the size of the g-codes:

Sign Contour - 1.6MB
Dino Cutout - 6MB
Name Cutout - 19MB

I did notice that the name seemed to be larger than it should be, but I didn’t expect any issues.

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.

Given my success prior and since, I don’t expect the hardware to be the cause here (and for the sake of discussion, lets assume that it’s not). I am looking to see if anyone has any input here.

Anyone see anything glaring that can help?
Can the X-carve not handle large g-code files?
Would a more powerful laptop be required?
How can you bring down g-code sizes in Illustrator/Fusion/Easel? (if necessary)

Thanks in advance everyone :slight_smile:

Jumping onto this thread to follow along.

This is almost always a hardware issue. G-code instructions are sent with absolute position information, not relative (in other words, instructions like “go to the intersection of Elmer and 5th streets”, not “go five blocks up and one block over”), so if you’re losing position, it’s because your machine has somehow lost it’s reference (home/zero position). Do you have set screws on your X and Y axes stepper motor pulleys? If so, tighten them, and consider using blue loctite. If not, check your stepper motor wires.

As for the carve that just stopped, that’s probably due to noise on your USB cable. Are you using a powered USB hub?

Thanks for the info regarding absolute positioning vs relative.

I have a powered USB hub and 1 foot USB cable, which were recommendations from a previous post. I haven’t noticed anything out of the ordinary with the motors. I may run it once more on scrap just to provide a video for reference.

Also, worth noting- it took roughly 15-20 seconds to begin the carve after clicking Carve in Easel, whereas all other projects I’ve done were instantaneous.

That’s not true. Gcode supports both relative (G91) and absolute (G90) positioning. Most probing operations are done in relative positioning since you don’t really have a good bearing of absolute quite yet.

The majority of users should be using absolute (and I think Easel does most of its stuff in absolute) because it’s more intuitive (to some) and doesn’t rely on starting position (meaning less likelihood of machine damage due to poor starting position).

there are a few practical applications of relative positioning but the ordinary user probably won’t ever encounter.

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?