Understanding "allow continous motion" (Motion control)

[johanne...@formann.de]

Hi Marek,

after I got my machine running I tried the motion planer diagnostics and noticed that if using the suggested simple S-curve Motion control a move with three points on a straight line causes the machine to stop between, both segments. Running the same gcode on the console one fluent motion.

Has that a reason? Simulated 3rd order doesn't have that behavior, but is on the other side not suggested with tinyG...

greetings

Johannes

[ma...@makr.zone]

Hi Johannes

You mean me, _Mark, not Marek, right?

(same name, different language, different person ;-)

Up to the Advanced Motion Control project, OpenPnP was only able to move the machine in single straight segments, each segment made a full stop and OpenPnP was waiting (and the task blocked) until completion. The waiting also involved a USB ping-pong or even parsing for a state (TinyG), adding some delays on slow connections.

On the other hand, this system is very simple, you never have to think much about the machine state. Either OpenPnP is blocked and the machine moving, or the other way around. That's why I needed to make the migration backwards compatible. By default the configuration remains the same. Simple but slow.

That why there is the Allow continuous motion switch.

https://github.com/openpnp/openpnp/wiki/Motion-Planner#motion-planner

You have to actively enable it after the upgrade, to signal you are ready to face the consequences.

Now OpenPnP can generate whole motion sequences and the send them all at once. Furthermore, if code emits moveTo() commands, it will not wait around for completion. This will only be done when functionally needed, i.e. the code must tell when it needs completion:

https://github.com/openpnp/openpnp/wiki/Motion-Planner#motion-path-planning

OpenPnP will currently automatically complete Motion Paths in these cases:

• After homing
• Before Camera settle
• Before actuating an Actuator (option that is enabled by default)
• After actuating an Actuator (option that is disabled by default)
• Before reading an Actuator (option that is enabled by default)
• Between moves that contain axes from different and/or multiple drivers (interlock).
• After the Machine Thread has finished a task.
• Before a driver connection is closed (unless there is a M400 in the DISABLE_COMMAND, it will not actually wait for motion completion, just for commands to be sent).

So to go back to your test case:

You need to enable Allow continuous motion. Then it should work.

It does physically move right on my TinyG. No deceleration between segments. Same with Jogging many fast clicks.

BUT: my planner can't predict continuous straight S-Curves right. It just does not cover that, algorithmically. So the Diagnostics will be wrong, showing deceleration and too much time planned:

However, such moves never happen in OpenPnP, AFAIK. So this is mostly irrelevant.

You can set it to Full3rdOrderControl. Prediction does still not match in time, but in shape:

_Mark

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b09175db-553c-4ac1-95c3-8469ab3cf44an%40googlegroups.com.

[johanne...@formann.de]

Hi _Mark,

sorry, it was a bit late.

Yes, switched it on, and made one diagonal movement. It physically stops in the middle.

Switching in the AsyncGCodeDriver to Simmulated 3rd Order one smooth movement.

Switching back to S-Curve the movent stops again in the middle.

greetings

Johannes