What would cause the subsequent passes to step over?

So I am knee deep in set build season and my LR4 has been wonderful , Except for this weird situation that I can’t figure out. I’m running full 4 x 8’ sheet of various materials. 2" foam down to 3/4" plywood.

I’ve had success with all of them, however I have these 2 dxf files that no matter how I orient them when the endmill goes to start a subsequent pass, it does so almost the endmill’s diameter over. any ideas?

I’ve tried deleting and re-outputting the gcode from estlcam, hard-booting the jackpot board, reorienting the layout (thinking something mechanical could be binding) all result in the same …1st pass is fine , secound pass is over approximately 1/4"…weird !! and its costing me $65/ sheet of ply when it happens…

any insight appreciated.

Are all the grub screws tight I got bit by the grub bug the other day.
Here is an example of what mine was doing.


With the machine energized can you add some tension to the belts and see if you can move the belt with the stepper energized and locked ?
Don’t force it much just to see off the belt cog slips on the stepper shaft.

i’ll give it a check tomorrow…just seems weird that it happens on 2 files in the exact spot (of the dxf file) regardless of orientation. A loose grub I would think would be more random… but if it is it would have to be the X motor …Can’t hurt to check, thanks for the suggestion.

1 Like

Hello Travis!

Happy Saturday. So I checked all of the grub screws, which I did install using blue loctite, all where tight.

This one has me pulling my hair out. I’m wondering if transferring files using the Jakpots wifi is causing some of the files to be corrupt? Also could this be a firmware problem? I’m running whatever firmware Ryan installed before shipping me the board…grasping at straws.

Think is, once this problem is resolved, this tool will become an amazing asset. right now its potluck that i may booger up a $65 piece of plywood…

1 Like

Gcode files are human readable text have you opened one of the problem ones and taken a look?

I have not… what would I be looking for to reveal an issue?

Also, The machine is in my HS Shop so I can’t look at the files on the micro SD card, I can check them on my laptop, however I feel that the issue could be a corrupted transfer via the jackpot’s wifi…

In that case I could look at the files on the card vs the laptop and see if there are any discrepancies…hmmm. that has to wait till Monday.

There’s progams like notepad++ that will compare 2 files side by side and highlight differences.

2 Likes

Please upload one of the g-code files to post and we can take a look. I doubt the g-code is directly causing the issue, but you can always take a look at what the g-code is attempting by running it through a g-code simulator. There are many web-based ones. I tend to use this one. To use:

  • Open the g-code file in any text editor
  • Select and copy the text to the clipboard
  • Switch to the simulator
  • Put the focus in the small window with the g-code
  • Type Ctrl-a to select all the existing text and then paste (Ctrl-v)
  • Click simulate

As for your issue, I have to wonder if your issue is occurring all at once, or if you are losing steps throughout the initial carve.

First, check the feedrates for both the carving moves and the travel moves. Usually carving is G1 moves and travel is G0 moves. If the feedrates are set too high, you can lose steps. It may be the carving federate is just fine, but the travel move federate is set too high. If you post your g-code file, we can take a look at the feedrate.

If it is not the feedrate, then look for a mechanical issue. It could be something simple like the clearance hight is not set correctly so the bit is catching on the stock, or there may be an issue with the machine.

I’ll post what’s on the SD card since that’s what is feeding the file to the jackpot. It will be monday night.

Just to chew on in the meantime. I’ve run full sheet designs using the same speeds and feeds on the same material (gcode created by Estlcam) and they’ve run flawless, and then some will fail the same way (in the same spot on the file regardless of orientation) any attempt to run the file.

I’m a CNC noob, BUT that screams “file issue” to me…

When you post the file, it would be helpful to know where it is failing.

18.5mm_Carriage_Side-n-Wheel.gcode (647.0 KB)

This is the file from my laptop. the problem happens at the start of the 2nd pass of Part 1

Part 1 starts on line 9604

The newest Release version is Fluidnc 3.9.4.

Honestly… I haven’t touched the firmware. It is running whatever Ryan loaded before he shipped it to me last oct/Nov.

I would love for it to be that simple of a fix…

What version do you have? If it’s 3.9.1 or newer, I doubt it’s a firmware issue. You can see the version by running the $SS command.

I also don’t have a good picture of the problem. There aren’t enough details here for me to wrap my head around it.

I’ll have to check when I’m back at the school Monday evening.

Basically… When I run 3/4 plywood, sometimes I can run a full sheet without any issues, and then sometimes it seems like on the second pass of a cut the x axis drags or bogs and steps out of line like a spirograph (I’m dating myself here)
I will try to send a Pic of a bad sheet on Monday…
Here’s some perfect cuts…


9 Likes

Wow that’s a lot of work. It looks fantastic you should be proud of that! Wish I could give you some help to figure out the issue however I’m pretty new to this.

2 Likes

That looks awesome.

That should be helpful.

Hmm, that was in the window when FluidNC went through problematic firmware versions. I think there was a brief window where they were flashed with a 3.8 version. Those versions had problems. I’m not sure they would cause the issues you are seeing, but if you do have a 3.8 version, I would upgrade.

The current recommended version 3.9.1 was released on October 31.

It seems that you are skipping steps. Note that while there are 2 motors on the Y axis, there is one on X so I think that would mean you would run into issues skipping steps on X before Y.

Looking back through this thread:

I think that’s reasonable to check. I don’t think that’s the issue here but good to rule out.

In the gcode file, I see a feedrate of 2700 mm/min (45 mm/s). That’s with a 1/4" bit and 6mm passes. That seems pretty aggressive. I know the LR4 is more capable, but that’s certainly more than I’d attempt on my LR3 anyway. Is that the same as the other files?

Note that if this worked before but is becoming an issue now, it could be that your endmill is getting dull. If you’re approaching the limits of the machine with a sharp bit, a slightly dull endmill might cause issues sooner than you might think.

What router/spindle are you using? What speed/dial setting are you using?

Is the X belt loose? I had an issue on my LR3 before where the belt started sliding out of the holder and that caused strange issues.

It looks like it starts the second pass on line 11137. I guess normally my gcode stops XY, makes the Z move, and then returns where this is transitioning but that seems ok.

11135: G01 X571.1526 Y507.3641
11136: G01 X584.7803 Y516.3978
11137: G01 X589.1113 Y519.2688 Z-9.0000 F1548
11138: G01 X584.7803 Y516.3978 Z-12.0000
11139: G01 X602.5911 Y528.2044 F2700
11140: G02 X612.1063 Y534.9976 I105.4719 J-137.6731
11141: G02 X639.5761 Y552.5265 I452.6742 J-679.1047

My working theory is that maybe your endmill is getting dull, which caused some minor skipped steps during the first pass. (Or maybe some other reason but still skipped steps). Since steps were skipped, during that second pass, you end up needing to cut a full 12 mm for some of it since it doesn’t line up with the first pass. That would cause more skipped steps and “spiral” into chaos?

I would be curious to see a picture of the endmill after experiencing these issues.

Have you been able to run other files with these same settings (1/4", 2700 mm/min, 6mm passes) on the same material with the same endmill without issues since these issues?

I would also post your config.yaml file. It should be compared against Ryan’s latest. I know he made some changes to the stepper amp settings. I’m not sure if any of that would help here or not.

Hmm, probably not. I don’t think home or hold amps has anything to do with this.
10_31_24update · V1EngineeringInc/FluidNC_Configs@27cd1b6

Yes, oddly enough. which makes dull endmills less likely the cause. Crazy. It has to be something simple, and once I get past this problem…HOLY S!!! The things I’ll be able to blast out for scenic design.

Can you share a link to any threads that might mention the issues people where having? Also, how do I check the version …how do I “run the $SS” command. I haven’t spent much time in the fluidNC UI. Honestly I only open it to upload my gcode via wifi to the Micro SD card on the Jackpot. (Im also wondering if shoddy wifi on the ESP32 may be causing issues with the gcode upload. Doubtful, but an easy check to just manually move the card and files between the LR and laptop.)

The Kobalt Router set at 3 1/2 for plywood & MDF, 3 for XPS foam (that’s all i’ve cut so far)

No, I thought it may have bee and tightened it up a bit which didn’t change anything

How the heck can you decipher that…I didn’t get my decoder ring with my LR4 order :laughing:

I agree totally with your thinking here…so, Jason, Let’s say I install a new endmill, what speed and feed settings and router speed would you suggest I try to see if it all goes away. I realize that this is throwing a few solutions at the problem, however if I don’t waste a $65 sheet of plywood that would be a small win. then I can push back up till the problem reoccurs.

I still want to rule out firmware and corrupt files as the randomness of the issue has me baffled!

Thank you so much for your insight!
Happy Sunday!

I’m off to film Pippin (and then strike the set)

Oh and I just picked up a 5-pack of these to try… 2 flute spiral upcut… Any thoughts, experiences?


look for the amana 46315-K chipload and thats your target/initial values (do your own tests in some scrap material you have left/damaged and go up or down from there)

1 Like

I’ve been watching this conversation with interest. Seems like a tough one.

  • Does the shift happen exclusively in an X-direction? Y cuts are still aligned?
  • Does the shift happen toward X min or X max? (Y too if its affected?)
  • Is this intermittent with a file that sometimes cuts well, or does it always happen with a specific file(s)? Have you tried loading it directly to the SD card rather than a wireless transfer? (Maybe that’s how you loaded it.)

I guess one of the possibilities passing through my mind is that the CAM is pushing the carriage so close to one of the XZ plates (or other extremes) that its skipping a few steps. When it comes back into the cutting area, it would be a few steps off in the opposite direction of the interference.

If it is told to move 100mm toward X max but it can only move 97mm, then when it’s told to move 100mm back toward X min it will move 3mm further than you expect. This would also only be a problem in files where the carriage moves a few extra mm toward the interference, which means that some of the files likely would never show the behavior.

The interference could be a wire or cable, or tension on dust collection, or anything that might only occur at the extremes.

Interesting puzzle, and I absolutely hear you on the cost of materials. Plywood is ridiculous in my area. Pictures may help.