[FEATURE REQUEST] Automatically link Rapid Feeder to parts list

[Shaische]

Feature Request

Describe the Feature

Ability to link a Rapid Feeder to a part in OpenPNP before it is mounted to a machine.

How Will It Look?

Proposal 1

1. A user would need a barcode/QR scanner connected to the PC running OpenPNP.
2. You select the part from the parts list tab simply by highlighting it and click a "scan QR" icon (scan QR icon can be located near pick icon on top).
3. Openpnp automatically adds a Rapid Feeder in the feeders tab once the barcode detects a QR and links the highlighted part to the feeder.
4. The existing function of scanning Rapid Feeders would then just update all the feeder locations once they are mounted to the machine.

Alternate proposal 2
Use the downward camera with a designated XYZ location to scan new feeders to be linked to parts. Or simpler - without designated XYZ location.

Alternate proposal 3
User hits the scan icon and doesn't need to click anything else. OpenPNP automatically goes down the list of parts, highlighting every part while the scan icon is active. It will look for a QR code to associate with the part. As soon as it detects one, it adds the feeder with its' address and moves on to highlight the next part, waiting for the user to scan a new QR code. This process continues until either all parts have a feeder associated or the scan icon is manually turned off to take OpenPNP out of "scan mode". Can use the downward camera or a barcode scanner.

Why Do We Need It?

Right now users have to find the feeder after it has already been mounted to a machine by labeling the feeder with a sticker or keeping track of it in some other fashion. This solves a labor intensive problem and speeds up the process by allowing a user to link the feeder to a part before it's mounted to the machine.

Provide Examples

Traditional SMT machines allow users to scan feeders prior to inserting them into a machine to link the parts to the feeder via a larger ERP software. This is just a small step in that direction and would save lots of time.

[markmaker]

Hi Shai,

For my understanding: Are you saying the feeder QR label does not contain the part information? Is it just a neutral serial number that is only associated in OpenPnP?

If yes: Is this at all practical? I mean once you have a cupboard full of stored feeders, how do you find the right one?

Would it not be much better to include the part info on a label sticker? Each smart-phone can nowadays make these appear as clear text.

If it must be an association that only lives in OpenPnP: how do you propose to handle feeders that are not yet or no longer currently mounted to the machine?

_Mark

[Shaische]

The QR is just a UUID that is the feeder's unique address. The current function in Openpnp for rapid feeders just scans across an axis for any QRs and captures feeder addresses and positions and adds it to OpenPNP. Watch Jason's video here: https://www.youtube.com/watch?v=VlpsAToBvS0&feature=emb_title

Is my feature request practical you ask? Yes it is because the data is stored in OpenPNP only. Nothing gets stored on the feeders. OpenPNP just automatically matches the part to the feeder. That's the whole feature. Right now users have to click on each feeder and manually choose the part associated with it. Imagine doing that for 50 feeders and accidentally swapping the part between feeders. Yikes!

My idea gets rid of the sticker. It's also a labor intensive task.

For feeders that get removed from the machine, the user must remember to remove them from OpenPNP. But if they happen to forget, then the machine will attempt to pick the part but there won't be any feeder there, so they'll get an error like they currently do already (vacuum or camera check) and realize their mistake. Edit: This is true for all feeders currently used. I don't see how this applies to the rapid feeder only?

[Shaische]

My personal favorite way to do this would be proposal 3 I outlined in my first post. Just one click and you can quickly sync all the parts to the feeders. It would save users lots of setup time.

[markmaker]

The QR is just a UUID that is the feeder's unique address.

OK. As a practical solution: just create the RapidFeeder in OpenPnP, assign the part, then enter the Name edit, and use one of these handheld scanners in keyboard emulation mode (HID emulation) to enter the UUID.

Can also be used in the search box to look up a feeder, e.g. for the case I described, where you take a feeder from the cupboard and want to know what part is loaded.

For feeders that get removed from the machine ... This is true for all feeders currently used. I don't see how this applies to the rapid feeder only?

Yes, but ReferencePushPullFeeder and the BlindsFeeder that use OCR or any barcode like QR (albeit with the part encoded) handle this case. Feeder are scanned/confirmed before the job starts (optionally). Feeders are automatically moved to their new location (slot), or the assigned part is changed, or the job paused for the user to remedy the situation, such as when feeders are missing at the expected location. This is optimized to only confirm parts actually used in the job, and employing a Traveling Salesman path planner.

My personal favorite way to do this would be proposal 3

IMHO, such rigid/modal/sequential functions are not practical in real-world situations. A reel might be missing, some might be in a different shipment, or it might be more practical to unpack them as they come, or you want some parts in different types of feeders, or you're short of empty RapidFeeders of the required tape width, or you find a reel in your shipment that strangely has no part, or the phone rings and you need to look something up elsewhere in OpenPnP, etc. pp. So the function would have to be interrupted, resumed, parts skipped etc., All very complicated.

Practically it would have to be scan driven. Select a part in the list and scan (press the trigger on the handheld scanner). Some handheld scanners can send special key-strokes up front (keyboard shortcuts such as Fn keys), so you could trigger the right function. The function could take the currently selected part and assign it to a newly created feeder (it would first have to check for duplicates). Maybe the function should be a script that one can pre-select as "active". So the scanning functionality can be customized. As such a generalized scanning interface it would be much more useful for a wider OpenPnP audience.

That's just feed-back... I'm not saying I'll implement it. 🤭

_Mark

[Shaische]

Hi Mark,

I get that you are thinking about all the user errors that can happen but I think these problems can be applied to any feeder like the 0816 feeder for example since it's just a generic feeder, right? I don't see how adding a scan function to automatically link parts to a feeder's address makes it more prone to user error.

All this feature is doing, is replacing the requirement for a user to click a dropdown inside every feeder in OpenPNP to assign a part to it. That's it. It's super helpful because checking the reels once they are mounted is more difficult if you have many feeders squeezed together. Your eyes need to figure out which feeder the camera is looking at and figure out which component is in that feeder by pulling out the reel. And printing labels, cutting them and to put on each feeder is labor intensive for 50 feeders on every job. Not to mention that you also then have to take them all off when switching jobs.

IMHO, such rigid/modal/sequential functions are not practical in real-world situations. A reel might be missing, some might be in a different shipment, or it might be more practical to unpack them as they come, or you want some parts in different types of feeders, or you're short of empty RapidFeeders of the required tape width, or you find a reel in your shipment that strangely has no part, or the phone rings and you need to look something up elsewhere in OpenPnP, etc. pp. So the function would have to be interrupted, resumed, parts skipped etc., All very complicated.

This is absolutely correct, which is why I said it would be active while the scan icon is pressed. If the user needs to pause/stop scanning, they un-press it. Or if they need to skip a part, they can click up/down arrows on keyboard.

Practically it would have to be scan driven. Select a part in the list and scan (press the trigger on the handheld scanner). Some handheld scanners can send special key-strokes up front (keyboard shortcuts such as Fn keys), so you could trigger the right function. The function could take the currently selected part and assign it to a newly created feeder (it would first have to check for duplicates). Maybe the function should be a script that one can pre-select as "active". So the scanning functionality can be customized. As such a generalized scanning interface it would be much more useful for a wider OpenPnP audience.

That's fine too. If you prefer that a user goes down the list of parts manually in the parts tab and clicks the scanner to scan a feeder's address, I think that works as well. I'm just trying to reduce mouse movements and key strokes when choosing parts for a feeder :)

I'll hope it gets bumped up your list of features :)