New Release version 2.6

[Toby Dickenson]

Hi all,

I am pleased to announce that the new stable release, version 2.6, has
just been built and released. Many thanks to all the contributors and
testers who have helped with this version. The changes in this version
are https://github.com/openpnp/openpnp/blob/main/CHANGES.md

Toby

[Jonathan Oxer]

Nice! Thanks Toby!

There are some excellent quality-of-life improvements in this release. I've held off updating my machines for a while now but this release has enough good stuff in it to be definitely worth the potential disruption.

Thanks for all the work that's gone into this!

Jon

--
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 visit https://groups.google.com/d/msgid/openpnp/CAH35urfOi4HdKSsnKQeBtPrqZEQH17W5a2BmKYkNArhK4exdBw%40mail.gmail.com.

[Jan]

Hi Toby!
Many thanks for your hard work and all the new features this release
offers! That's very much appreciated!
While browsing through the change log, I found, that PR1905 might have
introduced a small performance penalty. It uses
CompletionType.WaitForStillstand which delays OpenPnP until the machine
has reached its final position, while CompletionType.CommandStillstand
would be sufficient to drain the motion queue. According to the
documentation in the PR, OpenPnP does not rely on the machine reaching
its final position, hence it could continue its duty while the machine
is moving.

Jan

[Toby Dickenson]

Hi Jan,

Thank you for the comments,

The performance impact of PR1905 should be negligible. The extra
machine coordination step is only used once per job, when the job is
complete. The code in openpnp that is supposed to run after the job is
complete gets delayed until after the machine has stopped moving, and
the job is actually complete.

This fixes a problem where the "after the job is complete" code was
running concurrently with the machine finishing the tail end of the
job, causing (in some cases) stuttering and delays for the final
placement.

In future I can see there might be a use for more sophisticated
concurrency in this code, for example with a feature that runs a
conveyor belt and automatically restarts the job. But PR1905 looks
right for openpnp as it stands today.

> --
> 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 visit https://groups.google.com/d/msgid/openpnp/5b9d9d69-3cf2-4015-8161-78533064f629%40googlemail.com.