Currently Unrecognized G-Codes

CAD/CAM Software Tips
61

you don’t have to look far ahead, if you accept the next g-code line as soon as
you start moving on the current line, then you can look at the ‘joint’ between
the two lines and decide what speed you should be at when you end the first line
and start the second line.

This is what grbl does, and it’s fairly complex.

The first step would be to not worry about the joints, just plan on each
movement being stop to stop (stopping in all corners), accelerating and
decelerating on each movement.

The exiting PID loop will do a lot of the work, the problem is setting the
target position/speed that the PID loop is trying to comply with. Currently the
position moves at feedrate speed from the very beginning. What you would need to
do is to change this calculation so that at the beginning and end of each move
the target position accelerates/decelerates.

David Lang

62

just start a move at full feedrate with the “can’t keep up” error threshold set
to a small value and you will see the problem. Setting the error threshold
higher doesn’t eliminate the problem, it just keeps the problem from causing
user visible errors.

David Lang

63

Have you seen this run? Is 10 ipm steps small enough to not be jerky?

64

I don’t know what the speed steps or the distances will need to be to not be
jerky. I was showing what you can theoretically do in the g-code

It’s possible that the current firmware cannot avoid being jerky if it waits
until it finishes executing one movement before it starts parsing the next. We
know this is a problem when doing lots of small movements in curves. how long
the movements need to be to avoid being overwelmed by the g-code parsing
overhead, and what good steps are both need to be tested.

start with just doing one long movement at full speed, then go back to the
starting point and do the same distance with a bunch of short g-code lines, keep
increasing the number of lines until you see it taking significantly longer to
cover the distance (back up a bit to slightly longer lines.

then you can experiment with different speed steps for those different lines
(the line length is probably a function of time, not distance, so the slower
segments may be able to be shorter)

David Lang

65

I’ll run some tests tonight. I created a gcode file for a square by hand to test 10 ipm/inch acceleration/deceleration with the assumption that 20 ipm is ok for a 90 degree turn. I’ll create another for 10 ipm in corner and a last one that drops to 1 ipm for the final step. I might need to right a short program to generate different configurations since its rather tedious and error prone to do it by hand (but that might be a task for tomorrow though).

66

scratch that… 1 ipm in corner is a pain to do by hand… I’ll do 20 ipm and 10 ipm and see what happens first :slight_smile:

67

So, I ran a test with max 48 ipm that rampdown to 20 ipm at the 90 degree turn and it ran smooth, but I wasn’t actually running it with a router cutting into plywood (I’m still set up with my optical calibration banner on the plywood). Surprisingly (and maybe it shouldn’t be too surprising) but 48 ipm is slow. It would be interesting to double the size of the sprocket and see how fast you can run the sled.

Assuming 10 ipm steps isn’t jerky when actually cutting, then I it seems to me that preprocessing the gcode in webcontrol is the easiest solution. Break gcode into segments to do acceleration changes and obey speed zones at the top and edges (i.e., don’t try to run 48 ipm at the top of the board). I’ll post a video of the test run, but it’s hard to tell there’s much change… the change in motor sound is really the best indicator that something has changed.

68

Here’s the video (the move from center to bottom left is done at 20 ipm)

Here’s the gcode:

G20 G90 G40
(follow path 1)
G0 Z0.1
T0 M6
G17
M3
G1 X-9.0 Y-9.0 F20
G1 X-8.0 Y-9.0 F30
G1 X-7.0 Y-9.0 F40
G1 X6.0 Y-9.0 F48
G1 X7.0 Y-9.0 F40
G1 X8.0 Y-9.0 F30
G1 X9.0 Y-9.0 F20
G1 X9.0 Y-8.0 F30
G1 X9.0 Y-7.0 F40
G1 X9.0 Y6.0 F48
G1 X9.0 Y7.0 F40
G1 X9.0 Y8.0 F30
G1 X9.0 Y9.0 F20
G1 X8.0 Y9.0 F30
G1 X7.0 Y9.0 F40
G1 X-6.0 Y9.0 F48
G1 X-7.0 Y9.0 F40
G1 X-8.0 Y9.0 F30
G1 X-9.0 Y9.0 F20
G1 X-9.0 Y8.0 F30
G1 X-9.0 Y7.0 F40
G1 X-9.0 Y-6.0 F48
G1 X-9.0 Y-7.0 F40
G1 X-9.0 Y-8.0 F30
G1 X-9.0 Y-9.0 F20
M5
M30

During the run, the PE ranged from 0.30 to 0.75 (certain directions fared better than others). I assume those values are in mm. If so, it doesn’t bode well for 0.5 mm accuracy when the motors/controller/encoder consume you entire margin (i.e, calibration has to be literally perfect). I assume adjusting the PID values can improve things… or make them worse :slight_smile:

1 Like
69

OK - I’m going to preface this with I’m working from the theoretical. When dealing with motors turning them on and off is not an issue for the motor as it is the operator most of the time. That is from Zero to X in an instant, From X to Zero. The problem is fro things like entering a cut you want " Soft Start , to ramp into the speed and possibly the cut. " There is a maximum speed the “gear train” can go before the wear, skip, break ratio out flanks the desired operation. Also changing direction introduces weight / ringing issues. All this said there are routines out there for Delta 3D printers. We might be able to barrow from that. Our Weight is unique to this equation.

Just my thoughts

Thank you

1 Like
70

Go through the log and look the PE: lines, and pay attention to the values just after a gcode line is echoed back from the firmware (beginning of movement) to the lies just before (ok) that indicates that line of gcode is finished.
In the simulator with the random encoder noise turned off, I see the PE rise in the first one or two records (400mS) and stay pretty much constant until the gcode is finished. I thought that the PID loop would work to reduce that position error, but it doesn’t seem to get zeroed out until the sled comes to rest.
So a 10ipS run carries about .3mm error its full length. The amount of error is proportional to the speed (logica, I supposel) in the range of 0.28mm per 10ipS.
When successive gcodes line up in the same direction, the error rises as in this run which starts slow and speeds up then repeats in the other direction:

G20 G90
G1 X0 Y0 Z0 F50
G4 P2000
G1 X1 Y0 Z0 F10  [PE: -0.29, 0.29...]
G1 X2 Y0 Z0 F20  [PE: -0.58, 0.58...]
G1 X3 Y0 Z0 F30  [PE: -0.88, 0.87...]
G1 X4 Y0 Z0 F40  [PE: -1.17, 1.14...]
G1 X5 Y0 Z0 F50  [PE: -1.45, 1.39...]
(G4 P2000)
G1 X4 Y0 Z0 F10  [PE: 0.32, -0.29...]
G1 X3 Y0 Z0 F20  [PE: 0.58, -0.58...]
G1 X2 Y0 Z0 F30  [PE: 0.87, -0.86...]
G1 X1 Y0 Z0 F40  [PE: 1.16, -1.14...]
G1 X0 Y0 Z0 F50  [PE: 1.41, -1.41...]

If I start fast and decrease speed, the error starts high and decreases, still in proportion, and still not correcting. This run rises in speed in the first group and starts fast and decreases in the second:

G20 G90
G1 X0 Y0 Z0 F50
G4 P2000
G1 X1 Y0 Z0 F10  [PE: -0.30, 0.30...]
G1 X2 Y0 Z0 F20  [PE: -0.58, 0.58...]
G1 X3 Y0 Z0 F30  [PE: -0.88, 0.86...]
G1 X4 Y0 Z0 F40  [PE: -1.16, 1.14...]
G1 X5 Y0 Z0 F50  [PE: -1.45, 1.38...]
(G4 P2000)
G1 X4 Y0 Z0 F50  [PE: 1.45, -1.38...]
G1 X3 Y0 Z0 F40  [PE: 1.17, -1.13...]
G1 X2 Y0 Z0 F30  [PE: 0.87, -0.87...]
G1 X1 Y0 Z0 F20  [PE: 0.58, -0.58...]
G1 X0 Y0 Z0 F10  [PE: 0.30, -0.29...]

So all in all, I think there’s a built-in position error in the PID loop, that won’t be corrected by acceleration planning. Putting a very short pause between gcode lines ‘G4 P200’ would probably trick the firmware into zeroing the error doesn’t help, the error is still proportional to the feedrate.

1 Like
71

Yes, PE remains constant during the gcode action. I was surprised as well it didn’t zero out or at least improve during the gcode.

72

so this is PID tuning that we need to tweak first. One of the parameters is
supposed to adjust this tendency to never quite catch up.

David Lang

73

I’ve been going through @krkeegan’s excellent writeup, but haven’t seen anything like that, unless it would be overshoot in the Position Controller. That shouldn’t be speed related though? Can you spot a likely suspect?

74

see https://en.wikipedia.org/wiki/PID_controller

I don’t really understand why we have separate velocity and position
controllers (other than that having a single PID loop wasn’t working)

it looks to me like the velocity controller is working well, so well that it
never allows the position controller to catch up to where it should be. As you
see on the graphs, the position is ALWAYS going to lag step changes. But the
velocity needs to be able to overshoot so that the position can catch up. I
don’t understand how you can try to manage velocity AND position indpendently
from each other.

David Lang

75

They’re set up as a Cascade Control, (from the link you provided). From the article, “In cascade control there are two PIDs arranged with one PID controlling the setpoint of another. A PID controller acts as outer loop controller, which controls the primary physical parameter, such as fluid level or velocity. The other controller acts as inner loop controller, which reads the output of outer loop controller as setpoint, usually controlling a more rapid changing parameter, flowrate or acceleration.”

@krkeegan’s description in the Wiki writeup is “As mentioned the firmware uses two PID controllers in series for each axis - a positional controller and a velocity controller. The positional controller attempts to move the router to the desired position by outputting a desired movement speed. The velocity controller attempts to achieve the speed demanded by the positional controller by outputting a motor voltage.” That makes it sound like the position controller would be feeding movement speed to the velocity controller, so it should be able to adjust the observed position by adjusting the velocity.

1 Like
76

If that is the case, then it sounds like the P or I value of the position loop
needs to be boosted so that it catches up with the position and possibly even
overshoots a bit at the beginning.

David Lang