Too many z down clicks crash bit

Anyone else have the issue where too many z down clicks turns into runway “z down” crashing bit into table?

2 Likes

I myself might have had this problem a few times but I’ve not experienced this problem in a very long time

That said currently in the Facebook group this seems to be a reoccurring occurrence now with gSender.

I don’t know if it’s the application but I’m seeing three or four posts a day about it

Keith, are you noticing this behaviour only in the downward Z direction?

1 Like

Well gender just made me eat my words

I’ve been making signs for the last 3 or 4 days with no problems

gSender was supposed to create this name plate and then write the word Heidi in it

inside the gcode file, was 3 toolpaths,
1 - Finishing pass for the relief
2 - cut out a 2mm banner
3 - cut out a 2 mm name

all 3 where using the same bit, so I had them all in one Gcode file:

Just as it Finished the Relief Cut, I watched move from the outside edge, then move to where the banner or name should be, then Plunge 1" into the work.

  • I hit the E-Stop, then I clicked on Stop job.
  • In Visualizer the head stopped moving, however the Status still showed it as Running.
  • Trying to retract the bit out of the workpiece, I released the the e-stop button. -
  • however gSender was unresponsive.

I exited gSender, then re-launched and tried to connect with no luck, it was hung.

  • I unplugged the USB port from the controller, and re-connected, and I was able to regain control over the head.

To be clear from when it was working, to when it went off the rails, there was NO pause in the programming, though I know 100%, it was a toolpath change.

That’s a picture of the bit

The picture beforehand is how deep it went in

That is a picture from the visualizer

I included pictures of the visualizer, to show that the Heidi message, should be 2mm deeper then the ending of the last toolpath, however, gSender, plunged the Z head into the table about 1 inch in, and the Controller box locked up.

So just for point of reference

I did a 2hour roughing cut.
i did a 4 hour Finish Cut.

It was on the last few lines of the Gcode file, all it was supposed to do was carve out a rectangle, as well as the word HEIDI.

then it would be finished.

I have the ASPIRE file and the 2 gcode files used, if anyone wants to play with them

just ask

for reference, this is what the gcode was supposed to make, except a princess Carriage, instead of a train.

I have also, not powered down the machine, though the E-Stop is engaged now.

so if there is logs that can be had, please let me know

@chrismakesstuff Chris - I have had this happen as well when in precise mode and moving the Z Down - because the step is pretty low, I tend to click many times (because I am a patient guy :astonished:), but it seems like after three or 4 faster clicks, the Z takes off down as if the move value changed to something much larger than the default “precise” step or some sort of buffer decides to empty itself. I have not had it happen in any other direction, but I tend to not need precise mode as much (or as many clicks) on the x or y axis.

I think I had already reported this in Alpha and closed Beta testing. I am down right now pending our move to our new place so can’t check it again and/or check the other axis. I think this is the second time I have seen this in the last two days on the forum in the Z Down direction.

Steve

I’ve only noticed this in the z axis and I’m pretty sure only while in precise mode. stevendq described it perfectly. I’ll try to duplicate the condition and test this on the z up and xy after dinner. If I find something useful I’ll share it.

2 Likes

Made a video showing a very similar and possibly related runaway condition.

5 Likes

I think @KGN found a solution to this issue today so we’ll see if the issue is taken care of in the next release. Many thanks for the video, it helped us to replicate the problem! :love_you_gesture:

2 Likes