Losing steps on X axis whilst cutting air?

Hi all,

Looking to cut a complex piece of walnut (750mm x 750mm) using a 3d path from Aspire.

The first cut I did, worked well for 4 layers or so, then randomly lost about 10cm of steps and so went bonkers and cut through a hold down clamp, destroying the bit on the way.

Then (given Carbide Motion’s lack of any resume or ‘continue from x%’ ability), I re-ran the job from the start, in the hope I could carry on - however it’s just jumped again by about 1cm and this was while it was cutting air, so can’t imagine it’s any overloading or the like. Was hoping with ballscrews and linear rails, the S5 Pro should have fewer issues like this?

Any tips most welcome - also any approaches to save having to start every job from scratch again would be great also, surprised Carbide Motion hasn’t got this yet and don’t really want to jump to Sienci Labs or AN Other in the middle of a cut!

Did something (dust collection, power cord, etc.) interfere with movement to the right at that point in the process?

1 Like

Nope - not even got dust collection on at this point and power cords completely clear.

I was watching it by chance the second time and it just skipped at a seemingly completely random point.

Couldn’t see anything at all as a symptom??

I can’t imagine that Carbide Motion is at fault, unless your post processer is incorrect. You would have already eliminated that possiblity on earlier projects. I would be looking for mechanical reasons, possibly steppers out of sync, which might be at the connections. I could look at the Aspire file for you if you want, but short of taking too deep depth of cut it’s probably not that. I use Aspire with Carbide Motion all the time. It is possible to edit the gcode to resume if you know where it faulted, although I have never had the need.

Possible causes of lost steps:

  • mechanical interference (note that having a datum in a Vectric file is a frequent cause of this)
  • wiring fault
  • insufficient belt tension (for machines w/ belts)
  • loose pulley set screw (for machines w/ belts)
  • mis-adjusted eccentric nut/V-wheel (for machines w/ V-wheels)
  • loose coupler set screw (for machines w/ couplers)
  • insufficient lubrication (for machines w/ linear rails/blocks)

Thanks Will.

So given it’s a S5Pro, I think a lot of your suggestions can be immediately dismissed (ie no belts or v wheels)

Can you explain how the vectric file would cause mechanical interference?

I think given it’s a few weeks old, I assume Carbide send with enough lubrication initially??

Other than that, the only thing relevant on your list is the coupler set screw - which I checked two weeks ago, but can check again?!?

Any other thoughts?

I’m not sure where I would start for a wiring fault - given it’s happening every 6-7 hours of cutting, it’s a hard thing to replicate!

Thanks Charles, agree it’s unlikely to be the file or motion - the fact it was just cutting air and the fact it happened at totally different places each time kinda discounts that.

What’s the trick to resume a GCODE file? This would save me a huge amount of wasted time with this!

When you say “resume” I assume it’s in the context of re homing your machine, and having it start in a specific section of your code.

You can’t. Either have to start at the beginning and cut air, or redo your file to start. There’s been talk of implementing a “Run from here” feature.

1 Like

Ah ok, that’s disappointing as very hard to diagnose in a very long cut!

But yes that’s what I meant - ie the ability to continue from a certain point like 50% through in the GCODE like in other software (eg gSender)

There is a discussion on that topic here: Restart part way through It might be more trouble than it is worth. You are essentially creating a new job file. Since you are working a 3d file I am assuming that you missed steps on the roughing pass. You “could” change the tool speeds in Aspire and then way slow it down in Carbide Motion when you get to the area where it faulted. I feel your pain. That’s a big chunk of walnut you’re working with.

Ah, helpful - yes I might have a nosey at ncviewer then.

Be great if this could be added as it’s a pretty simple feature (hence it’s possible by text file editing).

You might want to look at the gcode in NCViewer

1 Like

For a rapid, if there is a Datum which causes the machine to want to move beyond its working envelope that will result in lost steps.

More likely is that the previous toolpath resulted in lost steps, probably due to high tooling engagement:

Where possible avoid slotting and add geometry and cut as a pocket


and consider leaving a roughing clearance and taking a finishing pass.

Sorry, not sure if you’re reading my posts Will - it was cutting air when it jumped. It had been cutting air for over an hour.

Not sure what you’re meaning regarding slotting as friction is is close to zero in air?!?

How could you be certain that it lost steps while air cutting and not in the previous operation?

If you look at the first post, you can see there’s a left edge (and there’s naturally a right edge too), as it’s a 3d carving it had been moving back and forth between each of these edges for an hour from the bottom of the piece.

Given it messed up at another point previously, I’d restarted it, so it was cutting air between these left and right points for over an hour beforehand - if it had skipped steps earlier, then surely I’d have seen this?? (Ie it would have cut into either the left or right side)

Not sure if you’re suggesting that it lost steps two hours before and somehow they only manifested at a random point while cutting air??

Only times I’ve seen my machine lose steps while cutting nothing was due to poor/bad connectivity in the connector from stepper motor to wiring harness. I’ve either secured all connectors so they cannot be twisted/vibrated/strained, replaced them, or hardwired from stepper motor to wiring harness.
If you jog your machine around & lightly wiggle/strain the stepper motor connectors, you can quickly determine if it’s good/bad as the moving axis should not stutter/stall/grind.
I have found that the wiring connectors are quite prone to intermittent failure, especially if left to just hang in the air & vibrate.

1 Like

Thanks Joel - some great thinking here and sounds sensible - especially as this gives me something to test and see if I can replicate.

Just to sensecheck my thinking - given it’s skipped on the x axis, this suggests that it would be an x axis stepper that’s dodgy (ie either side of the x gantry).

From memory on assembly, this runs along the x axis gantry through the drag chain and then up the yaxis drag chain.

So theoretically it could be anywhere along this point, although given no y movement at the moment it happened, might suggest it to be more likely along the x axis run.

I’ll see if I can replicate it as you describe tomorrow and at least that will narrow it down - if as you say they’re prone to failure, then it could be the culprit - certainly don’t think any were hanging loose, but it’s quite possible as a theory… and every theory needs tested! :wink:

Thanks for the expertise and i’ll report back!

Ok, no obvious loose wires - I actually thought there was a secondary stepper motor on the x axis, but as only one on the right, the wire runs are pretty simple really. There could possibly be some sort of wiring issue out the factory, but couldn’t simulate any either manually or with the multimeter.

So it appears pretty stable and remains a mystery…

However, a very helpful fella in the Vectric forums has helped overcome the limitations of Carbide Motion, by pointing out the Tape Splitting option in Aspire that has let me output my GCODE as segments, thus allowing me to then continue from the same point and save hours of pointless air cutting…!

So in short - I should be able to nurse this over the line now, but remain cautious about the mystery cause!

I had something similar happen. In MY case the dust boot was hitting my BitSetter stopping it from moving and causing it to lose its position. I believe I read that you don’t even have dust collection setup right now so it may not be exactly the same case, but it sounds exactly like what happened to me. My machine got off track and I didn’t know why, I thought I just had my feed rate too high and I overloaded the machine, but then it happened again when cutting AIR. I wasn’t watching because I didn’t think the machine needed supervision since I slowed it down PRESUMABLY solving the problem. So I restarted for the third time and this time I was watching every movement and that’s when I saw it make contact with the BitSetter. Your machine seems to be showing the same pattern whether or not yours is hitting the BitSetter, it SOUNDS like it’s encountering enough resistance that it is causing the machine to lose track of its position.

1 Like