I have experienced the same failures again with the Z axis not reporting on ground control when the z axis moves.
I ran an experiment - I turned off the aux pwr supply on the arduino board that powers the motors.
I then tried to jog the sled in x or y - Gorund control immediately stops the action with a warning that the sled is not keeping up and something is wrong.
I then tried to jog the Z axis up or down by a tenth 0.1 in motion. Ground control did not error in any way. It would seem that the position feedback of the Z is different that x and y ??
My original post was that I was losing Z reporting of position change of z in ground control. I thought it was due to my not having compiled the arduino correctly with the latest version of Arduino IDE.
But further testing has revealed that I would lose z track at specific places in certain gcode files.
To counteract this error, I am breaking the gcode into smaller files that are created by cambam for each section of the design. It is interesting that one file has 60 canned cycles of boring holes (8 z moves down to cut at 0.1 in depths and 1 long z move to extract the bit to safety height) and I get no errors in the z reporting even though there are more than 500 z moves - strange.
When I run the outline file (the cuts around the outside of the part) it always errors on the tab z motions after a certain amount of time. It would appear at first look that long segments of x-y motion with z motions up and down for tabs is when it errors most - more strange.
Not sure what is going on - but a fix would be that ground control does a quick check to see that the z axis actually moved the specified amount would be a good fix. When the x and y motions take off when the z is at the wrong depth bad things happen and it ruins the part. If the sled would stop if the z axis fails to change on ground control after the arduino has moved in z, it would prevent the damage to the part. It would require a power down of the arduino board and a reboot of ground control (that’s what it takes to clear the z reporting error) but that is only an inconvenience. The part would be saved and complex parts could be built.
Thanks again for your attention and help in finding a cure for this error that I am experiencing.
This is an example of code that errors whether in one cycle (0.6 to 0.5 for tab) or combined with several passes seem to error on one of the tab motions
Yes i am using a standard z kit with the recommended router exactly as it is specified. I have bungee cords to bias the router to more easily stay in sync with the lead thread. I read many of the post regarding the standard z and implemented the improvements. I find that keeping the outside aluminum barrel of the router lubricated so that it does not snag on the housing. The clamp is set to just be snug and the motion is quite smooth. I have checked each operation failure and the router moves exactly as directed by the arduino, but the failures start when the z stops changing on the ground control screen.
I break up the gcode for each transition (during tab operations) and carefully watch the z output on the ground control and when it stops - I hit the red button and stop the operation before failure. Then with a power down and reboot of ground control the readings on z come back. I re-calibrate the z if its different than the GC reading and start the cycle again.
Check that you are not hitting some mechanical limit (strain on a cable or
similar) at that point in your cut.
There is nothing in software that would cause this, but people have had the Z
cable pull tight or the Z motor hit the router at particular points in their
cut.
I also use CAMotics to visualize the gcode as it comes out to validate the breaking up of the gcode segments. It is a great way to pre-check for errors. I recommend it to everyone.
I have checked the mechanical movement and have a second person examine the router motion while I watch the GC z report. The failure is not a mechanical problem, it is that the reported z motion is frozen on GC, but continues to read the gcode as if it is still in sync.
Yes I separated them when I suspected noise and also added an em filter in the power lines to the arduino board and the laptop power thinking that it might help.
I do remember there was 1 cambam issue with GC and think to remember it was due to uncloased poly lines, but dement and drunk can’t link to it. The code would run perfect in CAMoticts but GC had a huge hickup. If you don’t want to post the full gcode here, you can pm it to me. Just to exclude the cambam aspect.
It looks like the Cambam setting for Z axis feed rate is 10 ipm, which should be reasonable. It might be interesting to set that to 45, same as the XY feedrate. I think I’ve seen something similar in a file with a very low setting for the Z axis feedrate. You could use an editor to search for instances of
It looks like the Cambam setting for Z axis feed rate is 10 ipm, which should be reasonable. It might be interesting to set that to 45, same as the XY feedrate. I think I’ve seen something similar in a file with a very low setting for the Z axis feedrate. You could use an editor to search for instances of
G1 F10.0 Z
And change them to
G1 F45.0 Z
Yes Thank you I thought also that varying the speed might affect it somehow. Also the canned boring cycles take too long, so it would speed them up. I kept them slower due to reading about mechanical failures on the standard spring clip that keeps the router moving with the turning lead screw.
I do remember there was 1 cambam issue with GC and think to remember it was due to uncloased poly lines, but dement and drunk can’t link to it. The code would run perfect in CAMoticts but GC had a huge hickup. If you don’t want to post the full gcode here, you can pm it to me. Just to exclude the cambam aspect.
Has errors 4 different times when I run it usually on layer 6 or 7 when the tabs have started
no matter what speed you put in the file, it’s not going to go faster than the
mechanical limits. It’s currently the motor RPMs that are the limit, not
anything else in the system
Are you saying that the z motor turns but the Z: number on the screen doesn’t change? Or that the z motor turns and the number on the screen changes but the router doesn’t change depth?
I’m trying to get the error to happen here on my setup, using the big file as well as the shortened set of commands here but so far I see my sled stop for each z change then resume as expected after the z moves to the proper depth.
It’s easier to fix a problem when it can be triggered on command. What should I do to make the problem happen?
