Part sorting across boards in panel

[Jan]

Hi Toni!
As you added the new (cool!) panel feature to OpenPnP it seems, that
there is no sorting between identical parts on different boards of
a panel (panel with multiple instances of the same board). In the
current development version (without the new panel feature) there is
some sorting, while in the test version, there seems to be no. According
to my tests this parts are indistinguishable for the JobProcessor and
hence sorted into any order. Can you confirm that?
I support, that in order to fix that, the board name could be added
when collecting PlannedPlacements and then used it for the final sorting
round.

Jan

[tonyl...@gmail.com]

Hi Jan,

I can confirm that panels (and boards) don't provide any inherent sorting (and never did AFAIK). I believe the ordering of placements is strictly a JobProcessor function. In other words, the order of placements on a panel of boards is handled no differently than the order of placements of multiple independent boards in job.

Tony

[Jan]

Hi Tony!
Many thanks for the confirmation! I was under the (false) assumption
that I found (as part of the
https://groups.google.co/g/openpnp/c/ROFkuOUhURc/m/9tyJY5wIAAAJ
discussion) that the development version would behave differently, but
could not reproduce that. I also did not found anything in the code
suggesting that the development version might sort placements
differently then the current test version...
In order to improve the sorting and make it unique again (for panels of
identical boards), I just create PR #1658. It adds options to sort for
BoardIds in addition to the options we already have: part and part
height:part. I also added new options to sort by board id first followed
by part. That provides the ability to favor populating boards in a panel
one by one rather then the same part on all boards. Finally I added an
option to not sort the placements. This allows to optimize a job
externally and just run it (I added a tool-tip to the job order
drop-down that warns, that the ordering is not strict because the
JobPlanner will favor parts that can be handled by the same/already
loaded nozzle tip(s)).
If you (or anyone else) think there shall be any other sorting options,
please tell me. I'm happy to append them to the PR.

Jan

> --
> 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
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/openpnp/7ec9db99-8d1f-4c0f-815f-d0c684053bafn%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/7ec9db99-8d1f-4c0f-815f-d0c684053bafn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[vespaman]

Hi Jan,

Nice to see enhancements coming along!

While I don't have any inputs to your changes, I have questions, that has been building up, regarding this..

1. The "Part" sorting, is that sorting by part name, or something else? Part is a bit ambiguous too me.

2. Sorting on e.g. height, is that withing the same nozzle tip, or is it height in general? I.e. if I have a large component that I prefer to be lifted with a large nozzle, will that be placed before a smaller component/nozzle tip with greater height? (i.e. will extra nozzle tip changes be forced due to this?

 - Micael

[Jan]

Hi Micael!
When a job is started (not resumed) the job processor collects all open
(not yet placed) placements into a list of placements to executed. This
list is then sorted using the requested "Job order", which can be
configured via Machine Setup -> Job Processor -> Job order.
At present there are options for "Part" and "PartHeight". "Part" refers
to the ID column of the Job -> Placements or Boards -> Placements table.
"PartHeight" refers to the Height column on the Parts tab but actually
sorts for this height value followed by the partId just mentioned.
I think the idea for "Part" is to place C1, C2, C3, ... while for
PartHeight the idea seems to be to place short parts first and taller
parts later. Due to the addition sorting, part of equal height will
again be sorted by their id (C1, C2, ...).
So, if you have a panel of identical boards, all boards will have eg.
"C1" and hence are indistinguishable for the sorting leaving them in an
undefined order. This PR now provides options to use the BoardId (column
"Board/Panel Id" of the Boards table on the Job tab) as additional
sorting option making the sorting unique again.
Please keep in mind, that this sorting we're talking about is not
strictly followed: the JobPlanner favors to reuse the current installed
nozzles over the sorting. Eg. if a tall ceramic can be placed using the
current loaded nozzle tip it will be favored over a flat tqfp requiring
a nozzle tip change. For performance reasons that's IMHO a good design
and probably most users don't care but for pedantic once, it might be
unexpected.

Jan

> https://groups.google.com/d/msgid/openpnp/7ec9db99-8d1f-4c0f-815f-d0c684053bafn%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/7ec9db99-8d1f-4c0f-815f-d0c684053bafn%40googlegroups.com> <https://groups.google.com/d/msgid/openpnp/7ec9db99-8d1f-4c0f-815f-d0c684053bafn%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/openpnp/7ec9db99-8d1f-4c0f-815f-d0c684053bafn%40googlegroups.com?utm_medium=email&utm_source=footer>>.

>
> --
> 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
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/openpnp/a2fae813-c02b-439b-87a3-170e0b89b920n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/a2fae813-c02b-439b-87a3-170e0b89b920n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[vespaman]

Thanks for explaining, Jan.

Now it is clear to me. If possible, I think this text would be very useful in the docs!

So, for example, if I would want all 100nF 0402 picked/placed board by board, I would pick board and height sorting? 

Or will the Job planner override also if Part is selected instead of Height? I.e. if C1 and C3 is 100nF and C2 is 10nF, C1 and C3 will be exhausted on all boards prior to picking C2 regardless of Part/Height sorting?

 - Micael

[mark maker]

>     If you (or anyone else) think there shall be any other sorting options, please tell me. I'm happy to append them to the PR.

Haven't looked at the PR yet (no time 😭), but of course the best sorting order (short of a real planner solution), would be the part's feeder pick locations.

1. Collect the feeder's pick locations per placement (you are doing that already, right?).
2. Run all of it through a Travelling Salesman.
3. Use the index in the solved travel path as sort order.

It is not perfect of course. It ignores nozzle tip changes (as you said) and does not account for parts with multiple feeders where one can run out (feeder switch-over), and also not accounts for feeders with changing pick location (strip feeder, tray etc). Also it assumes that travel between feeders is much larger than travel between placement locations, i.e. it blindly favors feeder co-location optimization over board/panel placement co-location optimization.

So it is still just a heuristic solution, but it would go a long way towards optimizing the travel between picks, at least as long as you start the Job with two identical nozzle tips for the most numerous parts (passives), and typically those absolutely dominate the job time, right?

Bonus variant: Go through each nozzle tip. Group all placements that are compatible (some will have multiple takers). Sort by group size, descending. Go through the groups in that order, and remove all but the first taker. Then do 1. 2. 3. as listed above per group, then concatenate the resulting sort order lists. 😎

_Mark

[Jan]

Hi Micael!
There is currently no option to sort by partId as found in the IDs
column of the Parts tab (sorry, there is a ambiguity between the ID of
parts known to OpenPnP as found in the table of the Parts tab and partId
internally used in the JobProcessor refering to the placement id as
found in the ID columns of the Placements tables on the Job and Boards
tabs. Any export input is welcome to rule that out!)
If you select PartHeight as primary sort order, you may not be able to
distinish between 10n and 100n (at least for me they have the same
height in 0402 package). If you select Part as primary sort order, the
partId/type is ignored. A workaround would be make their height
different by a tiny little bit. It will be don't care for the nozzle
going down, but make a difference when sorting.
If you have a panel of identical boards and wont all their eg. C1's
placed one after the other before continuing with all their C2's, you
can select Part:Board. However, if you wont all part of board 1 to be
placed before the first part of board two, you have to select
"Board:Part" (please keep in mind, that the JobPlanner will still
continue with the currently loaded nozzles until a nozzle tip change is
required. So you'll end out placing all parts on board 1, that can be
placed, then all the same parts on board 2 and so on until a nozzle tip
change allows the planner to select the remaining parts for board 1.)
I've added an "Unsorted" option that allows you to sort the placements
as you like. But still the Planner will select what fits on the
currently loaded nozzle tips.

Jan

> https://groups.google.com/d/msgid/openpnp/7ec9db99-8d1f-4c0f-815f-d0c684053bafn%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/7ec9db99-8d1f-4c0f-815f-d0c684053bafn%40googlegroups.com> <https://groups.google.com/d/msgid/openpnp/7ec9db99-8d1f-4c0f-815f-d0c684053bafn%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/7ec9db99-8d1f-4c0f-815f-d0c684053bafn%40googlegroups.com>> <https://groups.google.com/d/msgid/openpnp/7ec9db99-8d1f-4c0f-815f-d0c684053bafn%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/openpnp/7ec9db99-8d1f-4c0f-815f-d0c684053bafn%40googlegroups.com?utm_medium=email&utm_source=footer> <https://groups.google.com/d/msgid/openpnp/7ec9db99-8d1f-4c0f-815f-d0c684053bafn%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/openpnp/7ec9db99-8d1f-4c0f-815f-d0c684053bafn%40googlegroups.com?utm_medium=email&utm_source=footer>>>.

> >
> > --
> > 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
> > <mailto:openpnp+u...@googlegroups.com>.
> > To view this discussion on the web visit
> >

> https://groups.google.com/d/msgid/openpnp/a2fae813-c02b-439b-87a3-170e0b89b920n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/a2fae813-c02b-439b-87a3-170e0b89b920n%40googlegroups.com> <https://groups.google.com/d/msgid/openpnp/a2fae813-c02b-439b-87a3-170e0b89b920n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/openpnp/a2fae813-c02b-439b-87a3-170e0b89b920n%40googlegroups.com?utm_medium=email&utm_source=footer>>.

>
> --
> 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
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/openpnp/1b653372-c069-4971-a4d6-3002a5646989n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/1b653372-c069-4971-a4d6-3002a5646989n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[vespaman]

Hi again, Jan!

I think Mark had a better way of describing what I was after; (1) once entering a new feeder pick location, stay with it, until all components are placed. And then on top of that, place as close to other nozzle tip component as possible.

But I'm sure this is also on your radar.

-  Micael

[Jan]

Hi Mark!
I've implemented your first suggestion, unfortunately with mixed
results: the implementation went easier then expected, however, the
results of the TravellingSalesman for six feeders are not optimal. Even
with very clear feeder all on the west side, the algorithm does not find
the one easy identifiable good solution. Please have a look at the
attached screenshot from my debugging session. I stopped the execution
at getTravel() after optimizing the pick locations. As you can see, all
six locations have almost the same X and Z and very distinct Y values.
According the code, the locations are sorted by the index property.
Following index, the route is far from perfect. By eye I would keep them
in the order they where. (I did not configure start and end locations.
So the optimum route shall only take the shown locations into account.)
I pushed the code I've used to the PR.

Jan

On 19.07.2024 13:34, 'mark maker' via OpenPnP wrote:
> />     If you (or anyone else) think there shall be any other sorting
> options, please tell me. I'm happy to append them to the PR. /

>
> Haven't looked at the PR yet (no time 😭), but of course the best
> sorting order (short of a real planner solution), would be the part's
> feeder pick locations.
>

> 1. Collect the feeder's pick locations per placement (you are doing
> that already, right?).
> 2. Run all of it through a Travelling Salesman.
> 3. Use the /index/ in the solved travel path as sort order.

>
> It is not perfect of course. It ignores nozzle tip changes (as you said)
> and does not account for parts with multiple feeders where one can run
> out (feeder switch-over), and also not accounts for feeders with
> changing pick location (strip feeder, tray etc). Also it assumes that
> travel between feeders is much larger than travel between placement
> locations, i.e. it blindly favors feeder co-location optimization over
> board/panel placement co-location optimization.
>
> So it is still just a heuristic solution, but it would go a long way
> towards optimizing the travel between picks, at least as long as you
> start the Job with two identical nozzle tips for the most numerous parts
> (passives), and typically those absolutely dominate the job time, right?
>
> Bonus variant: Go through each nozzle tip. Group all placements that are
> compatible (some will have multiple takers). Sort by group size,
> descending. Go through the groups in that order, and remove all but the

> first taker. Then do 1. 2. 3. as listed above/per group/, then

> https://groups.google.com/d/msgid/openpnp/8c286bdb-51d3-4d1e-9a60-05b32e93008d%40makr.zone <https://groups.google.com/d/msgid/openpnp/8c286bdb-51d3-4d1e-9a60-05b32e93008d%40makr.zone?utm_medium=email&utm_source=footer>.

[mark maker]

I don't understand, looks perfect to me. Sorted by Y.

Obviously, it only considers feeders that have parts in the placements of the job. So it skips feeders hat remain unused by the job, hence the gaps.

Am I missing something?

_Mark

[Jan]

Hm... I just repeated yesterdays debug setup and found the reason why I
had the impression its not working, while in fact the TravellingSalesman
is working fine, but there is an issue with the logic: the
sorting/optimization is done as part the plan-step for every pick/place
cycle. That means, that the travelling salesman is called multiple times
with a list of feeders and - as to be expected - can not distinguish to
take the route front to back or back to front as the costs are the same.
So for the first pick, it might select one end of the route and for the
second the other end of the route. Any suggestion how to solve that?
We could move the optimization out of the plan step into the job
preparation step which only runs once on job start. That would
performance wise be helpful but void the principle that jobs can be
stopped and changed everywhere and continue to run fully optimized. If
we add the current location as start location, the results might look
better, but I'm not confident, that it will really solve the issue. If
we put the bottom camera as end location, the same would apply as for
the start location...
Any suggestions?

Jan

PS: From my debugging, the code is fine, but the results are probably
not as expected...

> https://groups.google.com/d/msgid/openpnp/b99ef26d-d759-4994-9283-0b824efc4786%40makr.zone <https://groups.google.com/d/msgid/openpnp/b99ef26d-d759-4994-9283-0b824efc4786%40makr.zone?utm_medium=email&utm_source=footer>.

[mark maker]

> the sorting/optimization is done as part the plan-step for every pick/place cycle.

I had no idea! 🙁

> We could move the optimization out of the plan step into the job preparation step

No, I would keep it in the Plan step. But introduce a lazy evaluation flag, whether it is already optimized. If not, do the Travelling Salesman and copy the visit index onto the JobPlacement. 

Then in both cases, do the sort by the visit index.

> but void the principle that jobs can be stopped and changed everywhere and continue to run fully optimized

Not if you keep it in the Plan step. 

Whenever the job is paused or stopped, void the lazy evaluation flag. So on resume it will redo the Travelling Salesman with the fresh/changed data.

_Mark