Z-Axis Plunge of Death

Troubleshooting
1

I am finally past calibration and into a solid operational mode. I am cutting the sample design from Frontier Design (beautiful stuff!) and making decent progress - except for this recurring z-axis anomaly:

IMG_0777
IMG_07773024×4032 5.54 MB

Twice now I have had the z-axis spontaneously plunge to it’s stops and beyond (skipping the belt) until I hit stop. As you can see form the photo above, My gcode says -9, but my slid shows 14.20 - when in fact it has plunged to it’s stops, with no sign of it stopping. I think this is happening at the end of

The possible issues I can contemplate, in no particular order:

  1. An issue with the GCode
  2. A bug in webcontrol
  3. Some kind of interference with the power / z-axis cables
  4. Interference on my z cable pin connection (it’s a little sketchy)

Would anyone have any clues to contribute?

2

Is that the first line in the gcode? If so, you need to include both a unit gcode (g20/g21) and a positioning gcode (g90/g91)

3

If it’s happening mid gcode, does it happen at same spot with same effect? Is there anything else happening? Pause/tool change/etc.?

4

It’s not the first line, but it is the first z move for that contour. It does seem to happen in 2 different “same spots” consistently, both at the z-move point on a contour.

G-code:
angso.nc (1.5 MB)

Generating gcode is new to me, so it would not surprise me to find that I have missed something. I already see many optimizations I want to make on this file.

5

Which line number seems to cause the problem. I can’t readily find it in the file.

6

I see the z-moves during a curve and that possibly could be the source of the problem. The ability to support this kind of move was added to the controller not too long ago. If you can find the offending line(s), maybe it can be fixed if it is a firmware issue.

7

Right around 8640, and then again around 14539.

8

What program did you use to create the gcode? It might be one of two things:

  1. Unsupported commands (like plane selection) is screwing up the parser in the firmware
  2. Certain commands (i.e., arcs with z-axis move) are causing the computations in the firmware to fail and produce bad values.

Can you create the gcode without z-axis moves while performing arcs?

9

Fusion360.

I suspect it’s possible. I’ll have to get educated on Setups (I think) and anew.

10

Theres a specific Maslow postprocessor for fusion 360… it’s somewhere linked to on this forum.

1 Like
11

I have the Post Processor installed now - thanks for pointing that out.

After watching a few yt videos I am still unsure of what is occurring. Does the Post Processing “translate” any out of scope commands for a given machine? If so, what occurs when you don’t have an equivalent command? Should I be worried about checking the resulting gcode in some way?

Would the post processing have remedied the z-during-arc moves you mentioned?

Does the post processor have to be maintained as the functionality of WebControl progresses?

12

I’ve never used fusion360 to create gcode, so I don’t have experience with it. But my understanding is that the postprocessor restricts the types of commands/gcode fusion360 creates so that its compatible with the firmware.

It’s not related to webcontrol… it’s a controller firmware compatibility issue. Webcontrol, at its most basic, just feeds gcode from the file to the controller.

1 Like
13

I think this is still a contender. Do you ever see issues when you manually command the z-axis to move up and down?

14

bad troubleshooting procedure, but I have solved my problem. The 2 steps I took were to

  1. Use a new post-processor.
  2. Better insulate my z motor connections.

My gut tells me that the later was the cause of my issues.

1 Like
15

I’m glad to hear it! Nice work :grinning: