Repeated small move

[jimtesson]

I'm trying to run repeated small move to approach the tool very closely to an object. The exact position of the object is not known before doing this operation. Thus while i'm pressing a button, small move commands (G0X0.005F300) are sended every 10ms. In previous versions of machine-control, this action worked well and allowed to get an accurate positioning of the tool.

Since the "new" planner has been released (2 years ago), this operation is not working anymore, moving only occurred when I stop sending commands. It seems to come from the planner. In the method Planner::Impl::issue_motor_move_if_possible, while the planning_buffer_ size is < to the planning_buffer_capacity, the planner wait to enqueue segments in motor_ops_.

 if (num_segments == 0 &&
      (planning_buffer_.size() == planning_buffer_.capacity()))
    ++num_segments;

In my use case, the move commands are thus treated when I stop sending commands, or when the planning_buffer get full.
In the past version, the segments were enqueue when at least 3 segments were requested.

Is there any idea to fix this ?

I tried another approach that is to send a large move G0X300, and send M0 to stop the move when I want. But it appears that the M0 is treated after G0X300. Maybe I missed something ?

[hzeller]

Thanks for the report.
Yes, I can imagine that this will change things as the planner attempts to make the best decision w.r.t. smoothing the overall flow, but of course, that goes counter with small increments.

It is on our list to actually have some smooth 'jogging' feature with input e.g. from a joystick, but sometimes other projects come into the way :)

@lromor do you think it would be possible to configure the queue length at runtime ? We could have an M-command that configures the planner queue length. This could immediately help in this case.

[lromor]

I have to think about it a little bit more, but it sounds indeed more straightforward than implementing the direct motors control on the PRU. I would probably just leave https://github.com/hzeller/beagleg/blob/main/src/planner.cc#L267
the size of the the RingDequeue the same, just enforcing a shortening of the buffer using indices.

[hzeller]

@lromor added a new command M181 to set the planner queue length. This allows to change the planner queue length which can help in this case.

• M181 S1 set the planner queue length to 1 so that each segment it receives will fully accelerate and decelerate. This might be more jerkey but should be fast to respond.
• M181 resets it back to the regular queue length.

Maybe a number a biit above one might be good, something like M181 S5 maybe ? Something to experiment with.