Z axis problem

Turns out I’m still having this issue as well. I just tried running some new gcode and had the problem again. I had a specific gcode file that was repeatably having this problem while on fw380.08 and it went away when I changed to fw412.01 so I thought it was fixed. Very strange as I’ve run my machine a number of times now without this issue, but this new gcode was longer than the previous ones. It happened approx. 40 minutes into the program, so testing for it will be pretty time consuming. I don’t have the gcode available right now to attach but I can later if you guys want it. I was using tgfx on a Win7 machine to send the file. Also, mine always plunges into the workpiece (negative z). I can try to measure the part tomorrow to try to determine how far it went off, but it’s probably pretty close to the same amount as sparkcrafter (~4.5mm), just negative instead of positive. I think it occurred during a rapid +z move, so I guess it’s possible that it was case of missed steps. I reduced my z velocity and jerk values after my last go around with this and it seemed to be running pretty good – no funny noises or any obvious missed steps while jogging or running. I’ve got an acme thread z axis coming this week too so maybe that will help if it is missing steps.

@grim – Yes, please post the Gcode, your settings and the build number. Did I read correctly that the problem went away once you dropped your Z velocity and jerk values? Can you please post the newer values as well?

What is the mechanical HW for the Z? I don;t remember what machine you are running. .. Thanks in advance for the info.

I may have made some progress this weekend. I started out with more strange behavior, this time my y-axis was shifting, which I haven’t seen before. Program would be running along and then decide it’s new y-position was about +20mm from where it should have been. I was proving out a gcode file in wood prior to attempting in aluminum so I had sped up all the g1 feed rates to 1000 mm/min. This seems to be the cause of the problem. Anything over 250 mm/min causes my machine major grief. I continued to modify the gcode file with slower feed rates until it made it through the entire program. It seems like the slower the feed rate, the longer it takes to see a problem. I’m fairly certain the max feed rate I can achieve is highly dependent on the gcode file, in particular the number of curves in the file. I suspect that if I were making long straight moves, allowing more time between one block to the next, the code would run OK. Just a hunch, but it seems like either the processor or planner can’t keep up when the feeds are higher. Unfortunately I’m at work now and can’t post my settings or code, but I should be able to get them up later today. The good news is I was eventually able to get my part made 🙂

Here’s a link to an experimental hex file
https://www.dropbox.com/s/tvz765z7b58kbs6/tinyg_421.06_dev.hex

The default settings are mostly sparkcrafter settings, with the exception of the Z axis (motor 4) pitch which I set for my shapeoko.

It also has fixes for the repeated tn element in the {c:n} readout, and the double axis report, so [zzvm] should go back to [zvm]

It’s not been tested with tgfx, so I do not expect it will work with it (it might). Please realize that this is experimental and don’t beat me up too badly if it doesn’t work!

Thanks for the feedback. Points:

– I’ll look into the $st. Probably something dumb I did.

– I have on my list to write up the new pages for the wiki, as there are a small number of new settings and functions available. In the absence of new documentation, hopefully most of this can be gleaned by looking at the text-mode $ dumps. I try to list the options in the text that follows the setting.