Wondering if anyone has noticed the z axis not lifting to gcode value before moving to next cut start point during program execution. I’ve set home to 1mm above the stock, to avoid the bit dragging across as it moves. The screenshot shows that G0 Z4 has been executed, but obviously actual Z is right around 0, and usually is somewhere between +0.5 and -0.5mm and holds there till it has moved to next location. Just for information, I have a metalMaslow, I’m using Fusion 360 and Maslowcnc post processor, but the gcode is obviously right, just not being acted on by Groundcontrol or the firmware? I’m using all current forms of those. All other Z movements are right and dead on accurate.
Welcome in the Forum and to the second post @MajorBob!
Speed support happens with lots of Info to help.
What machine, what Z-Axis, what router…
With info there is solution. As a new user you might not be able to upload more then 1 image right away, a few likes and responses will get you over that and a picture can help.
The more info you provide for us to start with, the faster a solution might be found.
Thanks Gero, as I said its a Metalmaslow, I’ll attach a pic of the sled with the z axis and makita router. The previous pic shows the gcode how G0 Z5 is executed after the full depth of a cut, to raise the z axis to 5 mm before moving to the next G0 command, to a different X Y coordinate. It raises to around zero not 5mm, then moves to that coordinate. Nothing mechanical is of any issue, Z axis will obey all other gcode, my thought is that either ground control ignores any number above 0 in this instance. I’m curious if the coders out there have some insight or if anyone else has noticed such a phenomenon.
I had and may still have the same issue (MetalMaslow, GroundControl latest version, g-code compiled with Estlcam). In my situation it only has happened when performing a drilling operation.
Since that event I’ve switched to WebControl and don’t use the drill function anymore. However every time the system would drill a hole, the raise command was issued and executed about 90%, then the move started and the z axis continued to raise for the entire move albeit slower.
On another note, how are you attaching your vacuum elbow to the sled? I filed it down until I had an interference fit but it will still fall out occasionally. I’m ready to remove the part that provides the exhaust channel and figure something else out.
Hey Blair, yes, I did the same, just filed it a bit and pushed and turned it in for now. It’s not ideal but it hasn’t fallen out on me yet. I was thinking of heating or softening the pvc with solvent and then creating a better fit if it gives me issues. Or 3D print some sort of a twist lock when I find I need a better solution.
Interesting issue you present. It may just be the how the first post processor generated gcode. I don’t know much at all about the way commands are executed in Groundcontrol, and what it waits for in terms of feedback before executing the next command.
That looks like a solid Z-Axis and i would not expect anything mechanical if the set screws are tight on the flat sides of the shaft. Latest GC and FW are actually quite solid, but there is always someone first to find a new bug. If you can share the g-code, i’ll test it with my GC simulator. To narrow things down you could make a simple g-code just moving z -5mm and + 5mm to see the reaction.
controlpanelfinal.nc (158.3 KB)
Here’s the gcode that was running in the screenshot for you, or anyone who would like to, to simulate. All my other gcode files have performed identically to what i’m describing. Instead of raising to the retract height (G0 Z5)after a cut is finished, and prior to moving to the next cut start location, it retracts to only right around 0. (As illustrated in my first posted screenshot, indicated by the black arrows…) All other z axis retractions work fine, including the final retraction at the the end of the program, just prior to shutting the router down. Doesn’t actually cause me grief, now that I am zeroing my bit to 1mm about the actual material, though it comes quite close to dragging an ugly line on the path to the new cut…
I hadn’t thought of using glue to soften the pvc. Mine was fine until I banged it against something I guess. Since then I’ve found that I can just hang the hose from the hole. I also changed pretty much my whole system. I think I’m going to try the soften route when I finish rebuilding the system.
I know you weren’t addressing me with your reply but I’ve got a comment.
I checked my code and it was standard gcode. Standard in the respect that it was simply G1’s with the z changing until it finally executed the move to the next hole. I’m not aware of the ability to add a delay to a G1. Also, undoubtedly I was using GC as I wasn’t aware of WC yet.
I also reran the code without actually cutting and the performance was the same result. The last pass on drilling the hole, then raise the z to travel height but start horizontal movement would begin about 3mm before zero. It would continue to raise the z until it was time to drop for the new drilling operation.
The only time it didn’t happen was the last hole. It would raise the z completely before it returned home.
Is this really of consequence now? Hasn’t GroundControl been superseded by WebControl?
Looking at the g-code right now. One thing that strikes is a dot without decimals at the end of lines before some Z-comands, but can’t tell yet if that is the bug. GC is official called discontinued, but allot are still running it, so i’ll keep support up for a while. Webcontrol with holey firmware is currently recommended for the Arduino Mega.
I was not aware of Web Control yet, to be honest. Just got this all going in the last month or so and followed the directives into the GC direction. I’ve just downloaded it and will give it a try. Thanks for pointing me that way! I’ll post the results when I see if there is any change.
The hardest part of WebControl is finding the download, but that could just be me.
You are correct. On first glance it does not make sense to still try and debug GC, since it is not maintained any more. WebControl is recommended. Anyhow, i just ran the entire cut posted with FW/GC 1.26 and all z-moves performed as expected in the simulation. I was suspecting that ‘unclean’ g-code with a .(dot) where it dos not not belong could be a bug not caught by GC, but that was not the case. This means the issue is elsewhere, if the same versions have been used. Lets hope the problem just goes away with WebControl, still would like to know what caused it
This sounds like an issue with the z-axis feedrate. If it is being commanded to move faster than it is physically able to do it wouldn’t be able to fully retract in the allotted time.
I have the original DXF file and version of Estlcam. Would it be of benefit to recreate this? Both the gcode and cutting? The z axis continued lifting the entire x movement, so technically I wouldn’t even have to cut wood to do a test cut. Since there’s no z stops and the movement continued the entire time it potentially hits the top of the z (MetalMaslow sled with their stock motor).
what is your encoder and pitch set to?
try pitch of 18 and encoder of 5400
the true pitch is 2mm with encoder of 600, but it’s slow due to firmware settings. multiply both to speed it up, but if you multiply too much over 9.5x the motor won’t be fast enough to execute the commands.
this thread goes into detail.
these settings only apply to your setup, other kits we sell have differnet z axis pitch or gearing.
That works. My pitch was set to 26, and encoder was at the GC default at 7650. I had changed pitch only to get it moving accurately, initially, with this z axis gearing. I gather from what you are saying here, as long as the ratio is 300, the z axis will be accurate, but changes the speed depending on the multiplier. And like I had been wondering, the motor wasn’t fully executing the commands before the next command took over.
With respect, it would be good to include a few detailed instructions with your kit regarding these kind of specifics. The generic Maslow instructions are very much that.