G0 minimum movement

I did some more experimenting. It seems that there are combination of settings that cause the command to be ignored. I don’t have Internet on my workshop yet, so I might remeber some values wrong, but if I recall correctly, xvm= 2,000,000; xjm= 1,500,000,000; f=1000. Operating from terminal, so “/” means enter.

f 1000 for slow feed.

g0 / x300 / x0 does work, and relatively fast, too. 🙂

x10 does not move, no lights come up. “?” says that machine is still  at 0, so it didn’t even try.

g1 (without further commands) moves it to 10, and “?” says it is at 10, too. So, it did remeber where it is supposed to be, but somehow, it thought it couldn’t do it in G0 mode.

f 10000 / x0 does not move either. “?” and no lights indicate, that thisd was suspended, too.

f1000 moves to 0, so again, the machine knew where it should be, and only waited a suitable settings to be able to go there.

Conclusion: There are some limitations on small and fast movements, that are buffered for later, or something like that. Now the question is what these limits are?

Ok, thank you. I went back to the workshop and I now have internet there, too. 🙂 So, I have now the real numbers. But first, two things: First, this behaviour is not at all a problem to me. I’m driving the machine with my own program, and it is trivial to overcome any known bugs and use g1 for all small movements. But since this might be an indication of a real bug, let’s continue. Second, I’m building a pick and place machine, not a CNC, so movement speed is important.

I re-did the settings from scratch: I first put in the relevant motor parameters (sa=0.9, tr=40, mi=8). The gantry is heavy (heavier than I would like, but the machine design is another story), so the machine is acceleration (torque) limited (Even though the machine does not work yet, I already ordered some motors with more torque to see how fast I can make it. :-/ ). So, next I set jerk so that I don’t get ill effects on acceleration and the machine moves as it should. xjm turned out to be 1,500,000,000. Then, I increased xvm unless I didn’t perceive any faster motions. In other words, my 400mm travel is spent in acceleration and deceleration; xvm is now 50,000. This might still be bigger than it needs to be, this stage was a bit of a guess and I put in a number that I was sure about. Any problem in this method?

With these settings, the effect is smaller, but it is there. Starting from 0 in G0 mode, x 0.4 does not do anything, and ? reports zero position. g1 then causes movement to 0.4.

Indeed this is a belt driven machine. I don’t get any stalls on any xvm value; as I noted, the heavy gantry means that the machine is torque limited, so it stalls on large xjm values. Here are the settings:

tinyg[mm] ok> $1
[1ma] m1_map_to_axis              0 [0=X, 1=Y…]
[1sa] m1_step_angle               0.900 deg
[1tr] m1_travel_per_revolution   40.000 mm
[1mi] m1_microsteps               8 [1,2,4,8]
[1po] m1_polarity                 0 [0,1]
[1pm] m1_power_management         1 [0,1]
tinyg[mm] ok>
tinyg[mm] ok> $x
[xam] x_axis_mode                 1 [standard]
[xvm] x_velocity_maximum      50000.000 mm/min
[xfr] x_feedrate_maximum      10000.000 mm/min
[xtm] x_travel_maximum          300.000 mm
[xjm] x_jerk_maximum     1500000000 mm/min^3
[xjd] x_junction_deviation        0.0500 mm (larger is faster)
[xsm] x_switch_mode               1 [0,1,2,3,4]
[xsv] x_search_velocity        -500.000 mm/min
[xlv] x_latch_velocity          100.000 mm/min
[xlb] x_latch_backoff             2.000 mm
[xzb] x_zero_backoff              1.000 mm

By the way, I see the issue on large feedrates with tiny movements, too (// = my comments):

tinyg[mm] ok> f 10000  // too fast for tiny adjustments
tinyg[mm] ok> ?

Line number:         0
X position:          0.000 mm  // <== At zero
Y position:          0.000 mm
Z position:          0.000 mm
A position:          0.000 deg
Feed rate:           0.000 mm/min
Velocity:            0.000 mm/min
Units:               G21 – millimeter mode
Coordinate system:   G54 – coordinate system 1
Distance mode:       G90 – absolute distance mode
Feed rate mode:      G94 – units-per-minute mode (i.e. feedrate mode)
Motion mode:         G1  – linear feed
Machine state:       Stop
tinyg[mm] ok> x 0.01  // A tiny adjustment
tinyg[mm] ok> ?

Line number:         0
X position:          0.000 mm  // <== but nothing happens
Y position:          0.000 mm
Z position:          0.000 mm
A position:          0.000 deg
Feed rate:           0.000 mm/min
Velocity:            0.000 mm/min
Units:               G21 – millimeter mode
Coordinate system:   G54 – coordinate system 1
Distance mode:       G90 – absolute distance mode
Feed rate mode:      G94 – units-per-minute mode (i.e. feedrate mode)
Motion mode:         G1  – linear feed
Machine state:       Stop
tinyg[mm] ok> f 1000  // Slower feed. There is a tick on the machine.
tinyg[mm] ok> ?

Line number:         0
X position:          0.010 mm  // <== And it moved.
Y position:          0.000 mm
Z position:          0.000 mm
A position:          0.000 deg
Feed rate:           0.000 mm/min
Velocity:            0.000 mm/min
Units:               G21 – millimeter mode
Coordinate system:   G54 – coordinate system 1
Distance mode:       G90 – absolute distance mode
Feed rate mode:      G94 – units-per-minute mode (i.e. feedrate mode)
Motion mode:         G1  – linear feed
Machine state:       Stop
tinyg[mm] ok>

Thank you, nothing to worry about it then (not an indication of a more serious issue). As said, this is not a problem at all, I just need to use setting values that work. (Like I could get away with settings that don’t… 🙂 )

More a philosophical than practical issue, but a noob would think that the correct thing to do would be scretch time; in other words, use fastest speed that allows the movement, even if slower than specified. Better to be late than in a wrong place?

I’ll keep you updated.