-
-
Notifications
You must be signed in to change notification settings - Fork 583
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JobProcessor Improvements v2 #280
Comments
Note, per discussion in https://groups.google.com/d/msgid/openpnp/4b284469-fb53-4e17-a5f4-45b696c23f7a%40googlegroups.com there is a bug where discard might discard for the wrong nozzle. I think what is happening is that skip is not taking the right planned placement into account. |
Hi, I just crashed the nozzle into a 2.5mm high chip, while placing a C0805 next to that chip. The job processor seam to decided to place the big chip first, because the big nozzle was inserted. After that the small parts got placed, an the crash occurred. Is there any chance for the user to see, what is going to happen? |
@KarlZeilhofer Sorry to hear that. No, there is currently no way for the user to see or modify the order of placements. That's an important part of this issue's work. |
Referring to the point...
...is this rework in any way related to #686 ? If so, some thoughts about this:
The Planner should then have a simple API, mostly just being notified when it is time to do the planning. The Planner should in turn have access to the full job and machine data, because it may vary wildly from machine to machine by which criteria the Planner will order/group the placements. A multi-nozzle machine might want to order/group parts by feeder proximity to reduce moving time between pickups. Conversely a single nozzle machine user doesn't care about feeder position and might favour assembly by PCB X or Y. Another [retrofitted] machine with small Z headroom might require strict part height sorting. Yet another one might want to implement this crazy idea :-). See also: Perhaps the rework could also include the following considerations:
_Mark |
Hi @markmaker, Yes, the two are certainly related. OpenPnP used to have a separate planner interface. I removed it because it was complex, hard to maintain, and did not fit well with the first major refactoring of the JobProcessor. And I also didn't think anyone was really using it. One thing I'm struggling with is the competing requests of:
I have been thinking that the order of placements might just be defined by the order in the table, and that the planner would be something you can run as an action to set the order of placements. I would say that there have been far more requests for the ability to modify the placement order than there have been for a custom planner. I'd be interested in ideas on how to manage both. Finally, I should note that the addition of a new planning system will probably be secondary to the JobProcessor refactor. My primary goal with the refactor is to solve some major bugs, and to fix some major usability issues. Adding the planner later on should not really be much more additional work since the area where planning happens is already quite self contained. Jason |
@markmaker See #219 for some more information and discussion on this. |
Hi Jason thanks for your response.
Yes that's why I asked for the implementation to include states "not yet planned", "auto-planned", "manually planned". This way both demands could be met and even mixed. This can be implemented very simply, say ordinal unplanned=0, auto-planned < 0, manually planned >0. The JobProcessor would then take the abs(ordinal) to sort the placements. The only thing that would be nice at this point is for the ordinal handling/storing to support such a thing. The actual Planner on top of it can wait. Why the states? The idea is that the [future] planner is free to change the ordinal <= 0 on all placements but not those > 0 determined by the user. The best analogue that comes to my mind is auto-routing with Fritzing. Not that I use Fritzing nowadays but this was a very nice experience. _Mark |
This is a second attempt at the JobProcessor Refactor which was originally done in #265. The work accomplished most of the goals we needed, but it left a couple important ones out and it resulted in a somewhat inflexible system. Based on learning since then, and comments from users, I think we can do better.
This issue can be considered an epic for the following tasks:
Improvements
JobProcessor API Changes
Notes and Ideas
With the recent Placed status addition ( new approach to follow up: https://github.com/openpnp/openpnp/pull/626 #632 ) I'm starting to see a way this can come together without adding a whole new UI.
The idea here is that users can select all or none to see all the placements in the job. In this state they can set ordinals to reorder placements and this will be the order that placing happens. This state can also be used to easily monitor the entire job as it runs - you will be able to see each placement as it happens.
Move lesser used placements columns into a popup dialog.
The placements table is getting too wide. Should move "Check Fids?", type, and maybe the coordinates into a popup dialog. The type can be implied by a row color.
References
The text was updated successfully, but these errors were encountered: