Maslow Home Maslow Community Garden Newsletter

Z axis stops reporting position on main ground control screen v1.20 - Happens again!

#1

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.

FAKE_SERVO and Z-Axis position reporting
#2

If you can find a particular example of gcode which causes the issue that would be huge for helping us track it down!

I agree. We have this on the other two axis we should add it to z also.

2 Likes
#3

Sharing parts of the gcode (or all) is a great method to dial in.
From chain motors it was reported the encoders had come loose and glue helped out.

Seems to point to a mechanical issue. Is that the standard router with the orange knob?

2 Likes
#4

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

( Made using CamBam - http://www.cambam.co.uk )
( mirror_box_element2_outline 10/5/2018 3:28:27 PM )
( T0 : 0.25 )
G20 G90 G64 G40
G0 Z0.125
( T0 : 0.25 )
T0 M6
( Profile1 )
G17
M3 S1000
G0 X-11.7871 Y2.8905
G1 F10.0 Z-0.6
G1 F45.0 X-11.7868 Y0.0155
G3 X-11.6617 Y-0.1095 I0.125 J0.0
G1 X-0.35 Y-0.1082
G0 Z-0.5
G1 X0.1 Y-0.1081
G1 F10.0 Z-0.6
G1 F45.0 X11.7133 Y-0.1068
G3 X11.8382 Y0.0182 I0.0 J0.125
G1 X11.8379 Y2.8932
G1 X11.8013 Y2.9298
G1 X11.8379 Y2.8932
G1 X12.3379 Y2.8933
G1 X12.3745 Y2.9299
G1 X12.3379 Y2.8933
G1 X12.3382 Y0.0183
G3 X12.4633 Y-0.1067 I0.125 J0.0
G1 X21.4625 Y-0.1057
G0 Z-0.5
G1 X21.9125 Y-0.1056
G1 F10.0 Z-0.6
G1 F45.0 X30.0258 Y-0.1047
G3 X30.1507 Y0.0203 I0.0 J0.125
G1 X30.1503 Y3.5203
G3 X30.0497 Y3.6429 I-0.125 J0.0
G1 X22.5203 Y5.1426
G0 Z-0.5
G1 X22.0789 Y5.2305
G1 F10.0 Z-0.6
G1 F45.0 X12.4868 Y7.1409
G3 X12.4624 Y7.1433 I-0.0244 J-0.1226
G1 X-0.025 Y7.1419
G0 Z-0.5
G1 X-0.475 Y7.1418
G1 F10.0 Z-0.6
G1 F45.0 X-12.4126 Y7.1404
G3 X-12.437 Y7.138 I0.0 J-0.125
G1 X-19.8813 Y5.6546
G0 Z-0.5
G1 X-20.3226 Y5.5666
G1 F10.0 Z-0.6
G1 F45.0 X-30.0112 Y3.636
G3 X-30.1118 Y3.5134 I0.0244 J-0.1226
G1 X-30.1114 Y0.0134
G3 X-29.9863 Y-0.1116 I0.125 J0.0
G1 X-20.5296 Y-0.1105
G0 Z-0.5
G1 X-20.0796
G1 F10.0 Z-0.6
G1 F45.0 X-12.4117 Y-0.1096
G3 X-12.2868 Y0.0154 I0.0 J0.125
G1 X-12.2871 Y2.8904
G1 X-12.3237 Y2.9271
G1 X-12.2871 Y2.8904
G1 X-11.7871 Y2.8905
G1 X-11.7505 Y2.9271
G1 X-11.7871 Y2.8905
G0 Z0.125
M5
M30

#5

This is an example where many cycles of z motion (boring holes) do not fail at all for hundreds of z operations:

( Made using CamBam - http://www.cambam.co.uk )
( mirror_box_element2_holes 10/5/2018 3:44:39 PM )
( T0 : 0.0 )
G20 G90 G64 G40
G0 Z0.125
( T0 : 0.0 )
T0 M6
( Profile1 )
G17
M3 S1000
G0 X-15.9202 Y1.0813
G1 F10.0 Z-0.1
G1 F45.0 X-15.9053 Y1.0619
G1 X-15.8959 Y1.0393
G1 X-15.8927 Y1.015
G1 X-15.8959 Y0.9908
G1 X-15.9053 Y0.9682
G1 X-15.9202 Y0.9487
G1 X-15.9396 Y0.9338
G1 X-15.9622 Y0.9245
G1 X-15.9865 Y0.9213
G1 X-16.0107 Y0.9245
G1 X-16.0333 Y0.9338
G1 X-16.0528 Y0.9487
G1 X-16.0677 Y0.9681
G1 X-16.077 Y0.9907
G1 X-16.0802 Y1.015
G1 X-16.077 Y1.0393
G1 X-16.0677 Y1.0619
G1 X-16.0528 Y1.0813
G1 X-16.0334 Y1.0962
G1 X-16.0108 Y1.1056
G1 X-15.9865 Y1.1088
G1 X-15.9622 Y1.1056
G1 X-15.9396 Y1.0962
G1 X-15.9202 Y1.0813
G1 F10.0 Z-0.2
G1 F45.0 X-15.9053 Y1.0619
G1 X-15.8959 Y1.0393
G1 X-15.8927 Y1.015
G1 X-15.8959 Y0.9908
G1 X-15.9053 Y0.9682
G1 X-15.9202 Y0.9487
G1 X-15.9396 Y0.9338
G1 X-15.9622 Y0.9245
G1 X-15.9865 Y0.9213
G1 X-16.0107 Y0.9245
G1 X-16.0333 Y0.9338
G1 X-16.0528 Y0.9487
G1 X-16.0677 Y0.9681
G1 X-16.077 Y0.9907
G1 X-16.0802 Y1.015
G1 X-16.077 Y1.0393
G1 X-16.0677 Y1.0619
G1 X-16.0528 Y1.0813
G1 X-16.0334 Y1.0962
G1 X-16.0108 Y1.1056
G1 X-15.9865 Y1.1088
G1 X-15.9622 Y1.1056
G1 X-15.9396 Y1.0962
G1 X-15.9202 Y1.0813
G1 F10.0 Z-0.3
G1 F45.0 X-15.9053 Y1.0619
G1 X-15.8959 Y1.0393
G1 X-15.8927 Y1.015
G1 X-15.8959 Y0.9908
G1 X-15.9053 Y0.9682
G1 X-15.9202 Y0.9487
G1 X-15.9396 Y0.9338
G1 X-15.9622 Y0.9245
G1 X-15.9865 Y0.9213
G1 X-16.0107 Y0.9245
G1 X-16.0333 Y0.9338
G1 X-16.0528 Y0.9487
G1 X-16.0677 Y0.9681
G1 X-16.077 Y0.9907
G1 X-16.0802 Y1.015
G1 X-16.077 Y1.0393
G1 X-16.0677 Y1.0619
G1 X-16.0528 Y1.0813
G1 X-16.0334 Y1.0962
G1 X-16.0108 Y1.1056
G1 X-15.9865 Y1.1088
G1 X-15.9622 Y1.1056
G1 X-15.9396 Y1.0962
G1 X-15.9202 Y1.0813
G0 Z0.125
G0 X-14.0802 Y1.0152
G1 F10.0 Z-0.1

after this it repeats for some 60 holes and never ( 3 or 4 -complete operations) fails

1 Like
#6

I checked the first and it’s clean.

1 Like
#7

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.

1 Like
#8

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.

David Lang

#9

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.

1 Like
#10

So it’s not in the gcode. Mechanical or interference in the z-cable.

#11

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.

#12

Is you z-cable separated from the power cord of the router?

#13

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.

1 Like
#14

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.

#15

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
1 Like
#16

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.

1 Like
#17

The Z axis is very slow, 10 is probably still too fast.

David Lang

#18

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

Here is the whole file:
mirror_box_element2_outline.nc (8.1 KB)

#19

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

David Lang

#20

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?