Glad you were able to print a new piece! 3D printers are, indeed, awesome. I started in the RepRap hobby world with 3D printing some years ago and that is what led me to me MPCNC. 5 printers was enough and I needed something different (subtractive vs additive mfg). I do have one quick question for you. Looking at the pictures of the broken piece and the replacement, I see that your tubing does not appear to extend all the way to the other side of the bracket. I would think that any lateral torque on the tube would create uneven pressure on the inside (think torque multiplier - lever) and potentially cause just such a failure along the layer lines of the printed piece. Just FYI, as it could potentially happen again on that part, or the other corners, if they are the same way. If you used the cut calculator to measure your tubing, it should extend all the way through and end flush with the printed part.
Hmm, I did use the tubing calculator, but that is probably just me missing that aspect of the assembly. I hadn’t noticed that they were flush, but I see what you mean from your picture and others. I may have to change that out now too! I don’t think it would have caused much of an issue till the strong uplift from the plunges that were happening on the machine.
Wow, really frustrated. I am apparently not past this Z-axis issue. Is F900 still just too fast? I just had 2 cuts go too deep again. Posting G-code as attachment this time.
I have done everything I can do to test this, and it is just not a speed issue.
V9 post processor has high-feed rates that exceed the recommended speed for the Z axis. I have changed those in my version, and changed all the tool settings for plunge etc… to try to be sure that there is nothing going out that sends a Z feed that is too fast. Despite this V9 also doesn’t split the code by axis so the feed rate for X/Y is the same as Z and it will go too fast. To fix this I slowed every axis down to 500mm/min and even that is not enough. I am still having this plunge issue.
Clearly this is not being caused by speed. I have also already turned up my stepper’s current a bit and I am still having this problem. I am curious if the people who have not encountered this problem are using the lcd to send gcode or Repetier host?
Thank you for continuing to help. I know this is probably frustrating for you too!
900mm/min was my setting for the XY not the Z, Z was set to 500 earlier and I have run it at 200 and still had the plunge issue.
I attached all the cam settings I could think of including speeds from the toolpath, and speeds set on the tool. I will have to make a second post with my post processor settings.
I attached my post processor. I have commented everything I changed in the config on it. I only changed it after it did not fix the plunge issue, and I noticed from looking through that it had fast moves caused by the high-feed settings.
surface speed is extremely far off. Start by setting everything no higher than 30mm/s for your x and y and no faster than 4mm/s for you z, any move that could include the z like plunge or ramp no more than 4mm/s. Until you figure out where the mistake is, then start speeding things back up one setting per job.
set your ramp equal to your plunge just in case.
you know you have to set that for each cut you have on that tree right?
I need a screenshot of your prost process screen right before you hit generate. I know the post processor works but all the setting can be changed.
Please keep all the changes minimal, please no other 3d printer forums and stuff. this works you just have a bad setting somewhere.
You are saying to set everything under 30 mm/s but currently my settings are all at 500 mm/min which would be 8.333 mm/s which is way lower than 30. Plunge is set to (200mm/m) 3.333 mm/s currently. I can change the ramp to match it, but I have all the toolpaths in this tree set to only use plunge as the lead-in so that shouldn’t impact it.
Every cut in the tree uses the same tool settings, and I have all the same feed settings except the last one which I export as a separate gcode for a different tool, but that tool has the same speed settings also.
I attached screenshots of the post processor at the stage before it creates the g-code I think that is what you were asking for. Let me know if it is something different.
I have kept every change as minimal as I can. When I posted my gcode on this thread before you showed me that I had speeds on the Z that were way too high and I found out they were coming from the V9 processor not from my settings. That was why I changed it. I even re-downloaded it just to be sure. I hope you are right and that this is all just a setting I have that is incorrect. I do know that one of those forums specifically mentioned this problem though. They mentioned that marlin was having an issue where it was bypassing a setting when retracting on the z axis and causing missed steps and it was only happening on the Z.
This wouldn’t be a problem coming from Repetier host would it? It seems like everyone who is posting about this issue uses Repetier host, and not the lcd controller. I was just looking to see if there could be some connection there possibly.
The z axis issues for the last year have either been physical issues, too tight, no lube interferences, ect., or the software settings we have fixed. so that leaves physical issue or a bad gcode setting.
You seem very positive your gcode is correct, so now it is down to a physical issue.
I haven’t been able to try your code yet, I hope to be able to try it tomorrow.
I don’t think there is a physical issue, the coupler doesn’t pull off the z rod when I try to adjust it manually holding the other side. The rod moves fluidly through the nut when I turn it by hand, and there is no place where the router would hang on a bolt or anything.
I don’t mean to imply that my code is not the issue. I even imported the code into libre office calc (the excel clone) to sort the F speeds looking for any that might be out of line, but I couldn’t find any that were too fast or anything. Are the speeds that I have set based on what you’ve seen too aggressive? I would be glad to slow it down more if I could get consistently successful cuts.
The issue always seems to come up after the Z axis rises out of a cut to move to a different part of the tool-path. It doesn’t always happen at the same part, but it doesn’t seem to happen along a cut only after it has moved.
Your spacer and nut trap, which is on top which is on the bottom? (I put the spacer on top and nut trap at the bottom).
Have you disconnected and removed the Z motor from the bracket and replace it, leave the pineapple coupler on the Z rod and turn it all the way down and up by hand? (I had issues with my prints and discovered hidden binding when I did this. Required reprinting some parts)
Have you tried swapping the Z driver with one of the others? (If it moves, could be a driver. If it doesn’t, could be stepper or wiring. Perhaps interference on the wiring. Perhaps isolate the Z wiring to test that theory).
I appreciate the reply P3DCNC! My nut trap is on the bottom also and spacer is on top same as yours. We had people over all day today so I haven’t really been able to check much or run any code, but I did make one pretty significant discovery.
I went into Repetier host and manually used the jogger commands to raise and lower the axis for a while did it up 10 steps then down 10 steps about 10 times so approximately 100 moves with no fails. Then I ran it up and down at 10 steps at a time still no problems there. I then switched to manually imputing g-code. So I just alternated between G1 Z15 F500 and G1 Z20 F500 over and over again, and every so often I would get this horrible grinding halt that is undoubtedly causing my problem.
please excuse my children screaming in the background video
So, I guess now my question would be is this still because of the speed or is this a mechanical problem? 500 mm/m should be in the safe zone according to the info I’ve read so it seems like it would lean toward the mechanical end. Could my threaded rod or nut just be bad?
took my Z axis off and scrubbed my threaded rod good with a nylon brush then lubricated it with a little mineral oil on a rag. I ran the same test as before manually sending gcode from Repetier host and even increased the speed and I couldn’t get it to hang up so now I am wondering could this have just been sawdust gumming up my threaded rod? I also feel like there is no way that was my only problem if it was even a problem, but it does run smoother now.
I had the exact same thing with my machine. I can cycle the z all day from estlcam/repetier/lcd screen, but if I run gcode to raise z faster than 200mm/m it skips. This is with nothing on the tool mount. Replacing the all-thread with a straighter piece helped some. I’ve ordered a piece of single start lead screw and a ridgid coupler to see if that works better.
Also I realized if the motor is getting warm the shaft will be warm too. My motors don’t have a flat spot on the shaft and I printed with pla. I’ll assume if it warms up enough the pineapple coupler could slip.
@Matt , sounds like the same issue I’ve had (and others) in the past. The Z is very sensitive to binding. So spinning the stepper at near max speeds when there is anything to resist it will be problematic. I’ve also greased mine and it helps abundantly.
I do run mine at 8.5mm/s, but the truth is, you don’t really need to have the Z go up and down at high speeds to have a fast job. Repeatedly consistent operation of the CNC is preferable, as I’m sure you’ll agree.
So why not just set it to 30% less and see if it remains reliable. As your threaded rod wears, and becomes easier to turn, you may be able to bump it up. So maybe creating a gcode file that “burns in” your threated rod by running it up and down a bunch of times throughout it’s range might help. Running a die and tap wouldn’t hurt, but the burn in and grease should do the trick.
