XY Moves before Z Axis stops

Software
1

I’ve tried cutting a part (toolchain openSCAD ->kiri:moto) which is a disc with tabs. The result is this:

https://photos.app.goo.gl/iyhjS3NNtsYVuiap2

All is well, except for the light cuts on the top. These are due to the Z axis not completing it’s move before the XY axis moves. This was reported as an issue (#266) which was closed, but there seems to be either a similar problem or the old one again. The code is at 0.91.

The nc file is here:
filament_center1.nc (56.0 KB)

2

We have seen this before. This can happen of the z-axis is commanded to move more quickly than it is able to do. When it can’t keep up, the next move happens before the z-axis is finished. I believe we added a limit to the maximum speed the z-axis can be commaned in the firmware, but even that won’t always be enough because different routers have different thread pitches on the adjustment mechanism. A router with a finer pitch will result in a lower maximum speed. I believe that the pitch is actually taking into account when calculating the limit, but I might be wrong on that.

Sometimes CAM programs will allow the z-axis (or plunge) feedrate to be set separately. That is the first thing I would try, but it’s not a real solution. Really we need to find a way to make it impossible for that to happen.

Does your router have a fairly fine pitch adjustment?

3

Do you know if the zaxis sounded funny when this happened? The rotations should be smooth and continuous, but when I saw things like this the movements if the zaxis were very jerky.

1 Like
4

I noticed this yesterday with the pen holder installed in my Ridgid rig.

5

Is there a way to set the maximum speed per axis, something like the 3D printer M203, in the Maslow firmware? It’s somewhat complicated to set dynamically by move in the CAM program, although not impossible. A one mm Z move while traveling 100mm in X and Y is lots different than if X and Y only move, say, one mm. That’s ignoring the Maslow’s more complicated kinematics…

6

So I actually put in code meant to solve this issue a while back. It limits the zaxis based on rotation speed, so the pitch (the actual distance traveled) of the router shouldn’t matter. The rotation limit I set of 12.5RPM is way conservative, based on more recent testing the motor is capable of 15RPM without issue.

There are two things I suspect are causing this (and one extraneous point):

  1. The current PID controller still has an issue with Integrator windup which seems to happen in this exact type of scenario. It has a very definitive appearance and sound, as the motor gets very jerky. This should go away with the new PID fixes.
  2. I don’t understand why, but we have issues with using Delay() in the code. It seems to act very erratically and I can’t figure out why. Figuring it out looks hopeless as everyone discourages the use of Delay() in favor of a while loop, since there is only one thread, there is no benefit of delay over looping. I have been replacing Delays(), but I know that one still exists in the zaxis movement and I will be removing it shortly.
  3. We don’t confirm that the machine has moved to the desired position before leaving any of the movement loops. We shouldn’t need to if the Firmware is all working properly. But we could add a function that waits until the machine is within a reasonable error from the final point and notify the user if this error is tripped. Again, this shouldn’t be necessary if the Firmware is all written correctly, but this keeps happening, so maybe we need some training wheels?
2 Likes
7

Actually what we really need is to get the Z axis fully coordinated with the
other axis. if the Z is not moving fast enough, the coordinated_move function
should slow the other axis to keep up.

The machine knows how fast each axis is moving, and how fast it’s supposed to be
moving (thanks to the encoders).

In addition, if one motor isn’t keeping up, it’s error position will keep
climbing and the PID loop will ramp the power up to max. We should also have an
alarm if the motor power hits max for anything more than a very short time.

8

The zaxis is still moved as a singleaxis independent of itself. No other axis is moving at the same time.

And I think you are voting for option 3.

1 Like
9

I missed that post (that’s what I get for responding via e-mail :slight_smile:

We really do need to expand the coordinated move. It’s not just checking that
it’s hit the desired location before leaving the movement loops.

Take a look at the movement that’s needed for this sort of thing:

that requires that the Z axis be fully coordinated with the other two axis.

The Maslow would be a fantastic machine for creating big signs, but to do that,
it really needs to be able to do this sort of movement.

It’s not there today because the initial vision was to always be cutting all the
way through (with manual Z axis movement at that) and not thinking about these
other issues.

We should not put another band-aid on this problem, but instead make the
coordianted move handle all three axis and fix it for good.

2 Likes
10

Oh we already have the code. I wrote it a long time ago. Coordinated movements for lines is done, it just needs to be updated and can be merged in. The arcs in 3D planes has some issues (turning in the wrong direction) that I stopped working on a while ago. I can split it up so that we are not waiting an eternity for me to fix things.

And I agree it may be worthwhile to have a check that we have completed a movement before exiting a loop.

I am not however in favor of monitoring the error rate and trying to adjust the feed rate from that.

  1. users should learn to sets feeds correctly, the firmware should only prevent what it clearly cannot do.
  2. Adjusting the feeds based on errors starts to look a lot like yet another PID controller.

I tried a rudimentary function that allowed the G00 moves to happen at faster then normal rates when the error rate remained low. I ran into an issue where the movement oscillated. You could keep tweaking things, but at some point the rules become unwieldy.

At best, I would accept some catch for extreme errors, but at that point, I think the best solution might be to stop for safety’s sake.

3 Likes
11

AND upgrade the Ridged to a rig like @czimm74 made. I have already replaced parts on the ridged, and had to add bushings to tighten up the action. His device is great an looks like it could improve and increase the Z action on the sled.

12

@jetrock Back to the initial issue.

If you are comfortable using an unreleased version, I think the Movement_Fixes branch will solve your issue. Just let me know how you normally upgrade your firmware and ground control (git or direct download) and I can help you out.

13

My Z Axis pitch in the settings menu is -1.819. I’m not sure if that’s fine or not.

14

The Z axis was moving smoothly, I couldn’t see any jerkiness at all.

15

I’m happy with unreleased firmware. I had a look for this branch on the repository but couldn’t find it.

16

That branch is here for now. It could be merged into the MaslowCNC main branch in a day or so. Note that you will need to use this version of GroundControl with that firmware as the PID tunings have changed and those defaults come from GC.
See the summary of changes here for a list of changes/improvements/things to watch for as you use it - some very welcome improvements!

17

Oh we already have the code. I wrote it a long time ago. Coordinated movements for lines is done, it just needs to be updated and can be merged in. The arcs in 3D planes has some issues (turning in the wrong direction) that I stopped working on a while ago. I can split it up so that we are not waiting an eternity for me to fix things.

please do.

And I agree it may be worthwhile to have a check that we have completed a movement before exiting a loop.

I am not however in favor of monitoring the error rate and trying to adjust the feed rate from that.

  1. users should learn to sets feeds correctly, the firmware should only prevent what it clearly cannot do.
  2. Adjusting the feeds based on errors starts to look a lot like yet another PID controller.

I tried a rudimentary function that allowed the G00 moves to happen at faster then normal rates when the error rate remained low. I ran into an issue where the movement oscillated. You could keep tweaking things, but at some point the rules become unwieldy.

At best, I would accept some catch for extreme errors, but at that point, I think the best solution might be to stop for safety’s sake.

G0 should move as fast as the machine is able to, it doesn’t need to be
coordinated (it’s assumed that you are clear of the material). This may or may
not be worth a special case (beyond ignoring the defined feed rate)

we do need to detect when one axis of the machine is not keeping up.We’ve had
reports of machines literally tearing the sled apart when things went haywaire
and both motors went on full power pulling the sled straight up. I don’t know if
the best way to detect this is if the error gets “too large” or if the output
power hits max (±255) for “too long”

I was not thinking of a dynamic feed rate, but rather a ‘this is too much, slow
everything down by 50%’ type of one-way change, and something that would be
obvious while not nessasarily ruining the work.

but a quick stop with a good error message could work (I’d be much happier if it
could shut off the router as well, leaving the router spinning against wood
could start a fire if someone hasleft their machine unattended)

18

Hmm,ok, what are the command lines I’d need to get that code?

19

Here is the test Firmware: https://github.com/krkeegan/Firmware/archive/Movement_Fixes.zip

Here is the test GC: https://github.com/krkeegan/GroundControl/archive/Default_PID_Settings.zip

1 Like
20

G0 is currently designed to move as fast as consistently possible for linear motion.

To actually move at the maximum velocity, the paths would not be straight particularly for horizontal moves. I played around with this, and the paths are disturbingly curved. A long move across the bottom could cause the sled to drop 12 inches below the work surface. This doesn’t seem safe.

The compromise of maximum linear motion seems reasonable.

That is more reasonable, and probably doable. I think we should be tying things to error and not motor voltage, we are hitting 255 on a frequent and at times sustained basis so as to maximize the G0 moves discussed above.

1 Like