search

hzeller / beagleg

G-code interpreter and stepmotor controller for crazy fast coordinated moves of up to 8 steppers. Uses the Programmable Realtime Unit (PRU) of the Beaglebone.
http://beagleg.org/
GNU General Public License v3.0
122 stars 51 forks source link

linking M114 gcode command to the pru motors status backend #29

Closed lromor closed 6 years ago

lromor commented 6 years ago

o connecting m114 to motor-operation's GetPhysicalStatus backend. o fixing some comments. o updating dummy and simulated GetPendingElements behavior.

hzeller commented 6 years ago

So this results in weird results. Here I am moving to (100, 100, 100) and query M114 in-between. It beautifully shows how the position is changing:

G1 X100 Y100 Z100 F100
M114
X:1.547 Y:1.548 Z:1.550 E:0.000 [ABS. MACHINE CUBE X:1.547 Y:1.548 Z:1.550] (Unsure: machine never homed!)
ok
M114
X:28.528 Y:28.531 Z:28.534 E:0.000 [ABS. MACHINE CUBE X:28.528 Y:28.531 Z:28.534] (Unsure: machine never homed!)

Now it arrived. I am asking again the position, expecting it to be (100, 100, 100) now:

M114
X:0.000 Y:0.000 Z:0.000 E:0.000 [ABS. MACHINE CUBE X:0.000 Y:0.000 Z:0.000] (Unsure: machine never homed!)
ok

Mmh, position (0, 0, 0) ? Let's try if the machine at least thinks it is at (100, 100, 100):

G1 X100 Y100 Z100 F100
ok
M114
X:0.000 Y:0.000 Z:0.000 E:0.000 [ABS. MACHINE CUBE X:0.000 Y:0.000 Z:0.000] (Unsure: machine never homed!)
ok

Machine does not move (as expected, because it is already there), but M114 still shows (0, 0, 0).

Now let's move to 0 again

G1 X0
ok
M114
Connection closed by foreign host.

Oops, crashed. The last log output of machine-control at exit is:

machine-control: motor-operations.cc:205: virtual bool MotionQueueMotorOperations::GetPhysicalStatus(PhysicalStatus*): Assertion `buffer_size <= (int)shadow_queue_->size()' failed.

I am rolling back this change for now, so that we can look at the reason without rush.