Feeder Slots / Movable Feeders

[vonnieda]

Status

This feature is now mostly working in https://github.com/openpnp/openpnp/tree/feature/%23399-slotted-feeders.

TODO:

• [x] Setting a feeder that is loaded in another slot should move it from that feeder to the new one.
• [x] Feeder and bank delete do not currently work.
• [x] Should be possible to unload the feeder from a slot. Currently not possible to set the dropdown to null.
• [x] Capturing offsets should subtract from the pick position. (Should be offsets)

Description

This is a new proposal for the slot feeder system. The old proposal did not take into consideration that hardware configuration is likely to be part of the slot and not the feeder.

This proposal is simplified in that it does not delegate to a first class Feeder. I believe this is a reasonable compromise since the slots are likely to only be used with an auto feeder anyway.

This proposal makes no external changes outside of a new feeder type, so it will be a good way to test this idea and what works and what doesn't.

• ReferenceAutoFeederSlot extends ReferenceAutoFeeder
  • string bankId
  • ReferenceAutoFeederSlot.Feeder feeder
  • static List feeders
  • getPickLocation(): return location + feeder.offsets
  • getPart(): return feeder.part
  • isEnabled(): return enabled && feeder != null
• ReferenceAutoFeederSlot.Feeder
  • Part part
  • Location offsets

bankId defines a set of slots that are interchangeable. Any feeder defined in a bank can be used in any slot in that bank.

The static List will be stored in an out of band configuration file named by the bankId. It will contain an XML serialized list of the feeders for that bank.

The ReferenceAutoFeederSlot will contain a wizard for configuring it's properties as well as the associated feeders. Currently thinking that there will be a dropdown with feeder and properties for the currently selected one. There will also be an option to add a new one and remove the current one.

Note: The original proposal (in a comment below) has the ability to suggest to the user which slot to put a feeder in when a part is needed. Due to the way this is designed that will not be possible. The user will be notified when a part is needed, but they will not know which feeder can be safely replaced. I think this is a reasonable compromise and we can extend the functionality later by passing Job info to the feeder.

Originally from #357 and based on #344.

There is additional discussion about this feature in https://groups.google.com/d/msgid/openpnp/aa380a0e085732e156dee535fa5773b6%40mail.mattbrocklehurst.co.uk

[vonnieda]

Just thought of a potential problem with this idea. We currently tie hardware configuration of feeders to the feeder itself. For instance the auto feeder defines actuators that it triggers to feed. But in the case of a slotted feeder you would probably want the slot to carry the hardware config since you want to feed whatever feeder is in the slot, not a feeder that has potentially be moved or removed. Need to think about this more. Maybe the slotted feeder is just a different auto feeder that makes it easy to move config (part and otherwise) between feeders / slots.

[vonnieda]

Old Plan

1. It should be possible to have a set of fixed, defined slots that can hold a feeder.
2. Each slot has a pick location that, in general, never changes.
3. A slot should be able to carry various Feeder implementations so that people can implement their own types of slot feeders.
4. It should be possible to notify the user that a particular configured feeder is needed and ideally be able to recommend which slot to put it in. This requires interaction with the JobProcessor to know which feeders are no longer needed for a job.

Initial thoughts on design:

1. New FeederSlot Feeder.
2. FeederSlot.feeder indicates which Feeder is installed.
3. FeederSlot.getPickLocation returns the defined pick location, optionally with the installed feeder's pick location added as an offset. In general the installed feeder's pick location will be 0.
4. FeederSlot.feed delegates to the installed feeder.
5. Changing FeederSlot.feeder sets the previous and new installed feeder's enabled to false. An installed feeder always has enabled = false so that the processor does not try to access it directly. TBD: How do we keep the user from setting enabled = true on a feeder that is intended for a slot?

TBD: How do we optimize the processor to not force slot changes before they are needed?

I think we're going to need to have the processor pass some kind of context to the feeder that says how many of each part are still needed for the job. This will allow the slots to make intelligent decisions about which feeders to load. Alternately, this may be something we want to handle at a higher level.

[vonnieda]

Done: https://github.com/openpnp/openpnp/blob/develop/CHANGES.md#2017-01-15

[vonnieda]

Screenshot of a new, non functional (yet) slot feeder setup panel. I think this is a lot more clear but it's quite a bit of work to get it all working properly and I'm deferring it until there's more feedback on the current system.