While implementing some motion commands with mobject-commands, I ran into the issue of not being able to use Tc2_MC2 to add buffered PTP moves, since it would wait for the previous move to be "Done". This is a bit of a mismatch in the logic behind the Done and Busy signals that the motion system uses, versus that of mobject-commands. Regardless, if I was able to execute two commands simultanesouly, while having a queue to keep feeding this execution pool, I could get the same results that I am after.
I have a small proof of concept example in my fork, under the 'dev' brand which has a QueuedPoolAsyncCommandRunner. It has configurable pool and queue capacities, configured via the constructor. Every call to ExecuteCommand will add the command either directly to the pool or to the queue. Upon cyclical calls, the command runner will remove completed commands from the pool, and dequeue any waiting commands.
While implementing some motion commands with mobject-commands, I ran into the issue of not being able to use Tc2_MC2 to add buffered PTP moves, since it would wait for the previous move to be "Done". This is a bit of a mismatch in the logic behind the Done and Busy signals that the motion system uses, versus that of mobject-commands. Regardless, if I was able to execute two commands simultanesouly, while having a queue to keep feeding this execution pool, I could get the same results that I am after.
I have a small proof of concept example in my fork, under the 'dev' brand which has a QueuedPoolAsyncCommandRunner. It has configurable pool and queue capacities, configured via the constructor. Every call to ExecuteCommand will add the command either directly to the pool or to the queue. Upon cyclical calls, the command runner will remove completed commands from the pool, and dequeue any waiting commands.