Y Axis Gcode randomly ignored

Mostly Printed CNC - MPCNC Troubleshooting
1

Hi all,

Sorry not posted for a while, I’m more of a registered lurker :slight_smile:

I’m having an issue where y axis commands are (seemingly) at random just being interpreted as “0”.

Seems to only occur in a trochoidal clearing operation, runs fine for a bit then Y just stops but carries on in X, the LCD also starts showing the Y figures as 0, it might do this for a minute or 2 then just carries on like nothing happened, I have deleted and recreated the file many times and it does not fail in the same spot each time.

  • The code looks ok to my limited knowledge, there is no big section where Y=0 (plus it has also affected a file that previously ran ok).
  • The simulation in Fusion shows all ok.
  • The Y steppers are energised the whole time, nothing is loose or overheating.
  • I can manually jog Y immediately after it happens.

Any advice appreciated, its driving me nuts, I’m guessing a reinstall of Marlin and post processor is the next step, but just wanted to check that I haven’t missed something easy.

(Ramps 1.4 - Fusion 360 - MPCNC_Fusion360_V2)

2

If it doesn’t happen in exactly the same spot every time with the same gcode file, then it isn’t in the gcode. So the pp isn’t at fault. You’ve said you delete and recreate the file. Does the same file fail in the same place? What about opening it in ncviewer?

Marlin doesn’t really fail that way. The software works because it is well coordinated, and any mistakes in the code would lead to larger problems.

The communication to Marlin might have problems. Are you running off of the lcd?

It sure sounds like a stepper driver is overheating, except the lcd showing Y=0.

3

Hi,

Yes running from lcd, different files fail in different places, sometimes not the first time of running, I have run a file ok once, then second time it fails without even removing the sd from the machine, but then does seem to fail at the same point.

Have tried 2 different formatted SD cards also to hopefully eliminate corruption.

I have not noticed any over heating with my calibrated finger, but will check properly with a laser thermometer, but the current failure point is so early into the operation it just seems so unlikely.

I will try swapping the axis and see if the problem flips 90deg, failing that maybe a unplug everything and check connections and reconnect, like a hardware “turn it off and turn it back on again” :slight_smile:

4

This is probably a poor connection or an electrical noise issue in the wires from the LCD to the Ramps board. Another forumite had a similar issue. The description of the problem further up that thread sounds very similar to what you’re experiencing…

1 Like
5

Is that the same problem? I thought of that, but the other thread went to y=0 for one vertex, and then came back. This sounds like the Y is just off for a minute.

Definitely a mystery. The electrical noise issue is promising, but I’m not sure how it is failing. It seems highly unlikely that it would only remove the Y coordinate from each gcode line, and not affect the other parts, or get partial Y coordinates.

6

Maybe? :grin: but, note the extensive use of weasel worlds like “probably” and “similar”. 8^)

There are so many commonalities (Gcode sent from SD card on LCD, randomly dropped coordinates), that I think they are likely related. <------even more weasel words. 8^)

As noted in the other thread, sending the gcode from a computer over USB with Repetier Host, or CNCjs, or from a v1pi, might help narrow the possibilities.

It would be interesting to know what spindle @someblokefromtheinte is using…

7

Yeah I’m not sure that’s the same issue, it occurs when the spindle (Katsu) is running or not, plugged in or not, everything except the spindle and last few inches of wiring to the board is shielded, nothing has really changed in 12 months except the addition of an enclosure around 4-5 months ago.

20200529_172253
20200529_1722532048×1152 816 KB

Made this 2 weekends ago after remaking the gcode twice, so it will work when it wants.

Again, completely deleted the setup and started again with an identical job and the file runs like it should, but now I have noticed the 2 clamps below the z stepper have a substantial crack in them and sounds like x is skipping steps each time the tool engages, which I had put down to the y axis thing, but it is not.

Time for a strip down and inspection I guess, thanks for the help though.

8

I did the same, but they were two SD cards that I had been using in the LCD controller. After I did a proper reformat (the slow way, not the fast way), I got dramatically different results. I think my issue was caused by continually ‘hot swapping’ the card in the LCD without powering down.
I’ve switched to Repetier Host and my issues have disappeared.

9

That’s a good point, I do that a lot so i’ll give that a try.

I did change the trochoidal operation for straight milling which worked ok for a bit but have still had the same issue where one axis was missed down one side, this was repeated for multiple passes so can’t rule out Fusion/Post Processor.

Thanks for the tip.

10

Hi all, I’m still really struggling with this, if anything its getting worse, now the y axis as well as being ignored is now also making some pretty violent movements.

Today I have checked continuity on every wire and the motors and that all seems fine, the drivers are not over heating and I think I have more or less ruled out interference by testing with nothing but the ramps board plugged in, also tried checking the stepper drivers, swapping etc and that makes no difference, so does that only leave the gcode?

I’t doesn’t help that my knowledge of gcode and its many mysteries is very limited, but I’m at a loss as to what to try next, the post processor is the same, fusion is the same, the Fusion preview looks correct and ncviewer looks correct, but I’m obviously making an error somewhere.

A sample of the code is below, its from a 2D adaptive making 2 holes, if one of the gcode experts has a few minutes to have a look I would be eternally grateful, I’m trying to get a prototype finished, but so far have spent a month, giving up, then trying it again in an incredibly frustrating loop.

Code

;Fusion 360 CAM 2.0.8624
;Posts processor: MPCNC_Mill_Laser.cps
;Gcode generated: Sunday, July 26, 2020 3:31:43 PM GMT
;Document: alternative v4
;Setup: Setup4

G90
G21
M84 S0
G92 X0 Y0 Z0

;Probe tool - Not yet implemented

;2D Adaptive3 - Milling - Tool: 1 - flat end mill
;X Min: -22.388 - X Max: 22.363
;Y Min: 9.632 - Y Max: 14.184
;Z Min: -3.9 - Z Max: 15
M400
M117 2D Adaptive3
G1 Z15 F300
G1 X-18.887 Y12.635 F2500
G1 Z5 F300
G1 Z2.5 F300
G1 X-18.944 Y12.725 Z2.496 F200
G1 X-19.009 Y12.81 Z2.493
G1 X-19.079 Y12.89 Z2.489
G1 X-19.156 Y12.965 Z2.485
G1 X-19.237 Y13.033 Z2.481
G1 X-19.324 Y13.095 Z2.478
G1 X-19.415 Y13.151 Z2.474
G1 X-19.51 Y13.2 Z2.47
G1 X-19.608 Y13.241 Z2.466
G1 X-19.709 Y13.275 Z2.463
G1 X-19.813 Y13.301 Z2.459
G1 X-19.918 Y13.32 Z2.455
G1 X-20.024 Y13.331 Z2.452
G1 X-20.131 Y13.333 Z2.448
G1 X-20.237 Y13.328 Z2.444
G1 X-20.343 Y13.314 Z2.44
G1 X-20.447 Y13.293 Z2.437
G1 X-20.55 Y13.264 Z2.433
G1 X-20.65 Y13.228 Z2.429
G1 X-20.748 Y13.184 Z2.425
G1 X-20.841 Y13.133 Z2.422
G1 X-20.931 Y13.075 Z2.418
G1 X-21.016 Y13.01 Z2.414
G1 X-21.096 Y12.94 Z2.411
G1 X-21.17 Y12.863 Z2.407
G1 X-21.238 Y12.781 Z2.403
G1 X-21.301 Y12.695 Z2.399
G1 X-21.356 Y12.603 Z2.396
G1 X-21.405 Y12.508 Z2.392
G1 X-21.446 Y12.41 Z2.388
G1 X-21.48 Y12.309 Z2.384
G1 X-21.506 Y12.206 Z2.381
G1 X-21.524 Y12.1 Z2.377
G1 X-21.535 Y11.994 Z2.373
G1 X-21.537 Y11.888 Z2.37
G1 X-21.531 Y11.781 Z2.366
G1 X-21.518 Y11.675 Z2.362
G1 X-21.497 Y11.571 Z2.358
G1 X-21.467 Y11.468 Z2.355
G1 X-21.431 Y11.368 Z2.351
G1 X-21.387 Y11.271 Z2.347
G1 X-21.335 Y11.177 Z2.344
G1 X-21.277 Y11.088 Z2.34
G1 X-21.213 Y11.003 Z2.336
G1 X-21.142 Y10.923 Z2.332
G1 X-21.065 Y10.849 Z2.329
G1 X-20.983 Y10.781 Z2.325

G3 X18.882 Y13.089 I0.219 J-0.205 F360
G1 X18.927 Y13.102 Z-3.896
G1 X18.971 Y13.116 Z-3.885
G1 X19.012 Y13.129 Z-3.867
G1 X19.051 Y13.14 Z-3.843
G1 X19.085 Y13.151 Z-3.812
G1 X19.114 Y13.16 Z-3.776
G1 X19.138 Y13.167 Z-3.736
G1 X19.155 Y13.172 Z-3.693
G1 X19.165 Y13.175 Z-3.647
G1 X19.169 Y13.176 Z-3.6
G1 Z15 F300

M400
M117 Job end
G1 X0 Y0 F2500
G1 Z0 F300

11

I pasted the code into ncviewer and it looks like this line is not correct somehow:
G3 X18.882 Y13.089 I0.219 J-0.205 F360

It looks like you’re not using Guffy’s postprocessor so try that first (and use ncviewer to check).

If it has the same or similar issue then you could try disabling arcs (G2 and G3) in CAM and see if you get the same problem. But I’m guessing Guffy’s postprocessor will work since it’s known to handle arcs properly in general.

12

There was no improvement switching post processor, but disabling G2 & G3 stopped the weird high speed movements.

But the old problem still remains, the operation should be switching back and forth clearing 2 holes, it seems to make a normal spiral ramp into the left (first) hole, but when it gets to the right hole it just moves forwards and backwards in Y then shifts back again.

I also tried switching the wiring for X & Y just to see if it repeats itself, but bizarrely now the first spiral only moves one axis and the second is ok.

The part has gone through a bazillion revisions so the cad is pretty messy, is it possible that some remnant is causing an issue, but then why not show in the previews, to my uneducated eye the tool paths all look the same in Fusion as they do in ncviewer, so I have no idea what I’m doing wrong.