Can OpenPnP automatically scan for feeders across an axis?
Philip Kristoffersen
mark maker
Not exactly like that.
What it can do:
- Detect the next one in a row with just one click. The user is
still supposed to have a glance and check if everything was
detected alright. Then they can click again.
https://youtu.be/5QcJ2ziIJ14?t=295 - Once all the feeders were registered for a first time, you can
then physically swap them out as you wish.
https://youtu.be/cNCjjvCT4Fc?t=330
There is an automatic (optional) job preparation routine that visits each feeder at its formerly known location and checks the OCR/QR code. You can either let just let it confirm if is still correct, or swap out feeders, or even automatically create new ones, if a new part ID was detected.
https://github.com/openpnp/openpnp/wiki/ReferencePushPullFeeder
_Mark
--
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 on the web visit https://groups.google.com/d/msgid/openpnp/f3df6a3e-733a-4844-8b4d-b0b8e74cd658n%40googlegroups.com.
Philip Kristoffersen
1) Parts match the local database in the server.
3) Packages match the local database in the server.
4) Software can tell you wether or not parts are available and if a Feeder already exists with these parts.
5) Ensure full compability with internal software so no hands-on action or "programming" of OpenPnP is needed. Simply boot the software and it handles everything and initiates the job for you.
Given the software only interacts with the .xml files, it would be forward compatible if the company decides to upgrade OpenPnP as it develops. Once I am done, they have no resources or time to ensure compability or update - they may just stick with the version of OpenPnP that as available when the machine is done and never update it.
Thoughts? From how I see it right now, OpenPnP requires quite a bit of hands on to set everything up. This software would, for our setup, make it automatic in the most tedious parts of the process.
- Philip
mark maker
> Where does it pull these coordinates? Already registered
feeders?
Yes. But they are also recalibrated in the same go, i.e. they only need to be roughly at the same location (+/- 2mm I think).
> I assume, as you switch feeders around, these must be
pre-registered feeders in OpenPnP? So it says "Aha, I know you -
this QR code is for Feeder 13, not Feeder 7!" - Do I understand
that correctly?
Yes.
> Current thought is to create a piece of software that
modifies and ensures compabilities before booting OpenPnP.
It would be much easier and better and more future proof to
develop all this inside OpenPnP. There has been talk about
"Feeder Groups" of various kinds, that can be exchanged
(offline/online) and relocated (transforms). So this is a common
feature request that would be welcome. You would have to make the
implementation somewhat "universally useful" for it to be accepted
into OpenPnP.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c089da0a-a299-4bf1-b40e-7a4bb1dfa221n%40googlegroups.com.
Philip Kristoffersen
Has there been any discussions of a pipeline and standard for hub communications? Such that a hub can inform OpenPnP about parts, packages and feeders presently installed in the Hub? The prime example would be the SMT 0816 Feeders and their setup, but essentially everything has to be configured by hand given that the Feeders have no logic on them. It seems that once logic is on the Feeders and the Hub to which they connect, OpenPnP has basically zero support to communicate with it to take advantage of it - is that correctly understood?
The closest I can find would be the setup you did with the ReferencePushPullFeeder of using the camera, but that would still require a database of all Feeders - a nice upgrade would be you give it a X/Y Axis to travel along and just automatically find Feeders and reconfigure the coordinates of pick locations on the fly, but it would still require a database of Feeders up front. Since the Feeders hold their own "data", what would be nice is if OpenPnP could,
1) Scout for Feeders
2) When Feeder is found, scan QR code (which would contain an ID of sorts)
3) Ask Hub for Feeders information by its ID
4) Hub calls the Feeder and retrieves information
5) Hub sends information to OpenPnP
6) OpenPnP recieves information and registers the Feeder itself in Machine.xml
7) OpenPnP locates pick location and automatically tests the Z-axis (we have the LitePlacer setup)
8) Feeder is found, registered and calibrated - continue search along the given X/Y Axis.
Does this make sense for OpenPnP? Even as a general standard for automatic hubs? Or is it too specific and niche for our case?
Cheers,
Philip
Mike Menci
mark maker
Hi Philip,
I get the distinct feeling that I'm missing background in "industrial" production settings (I'm just a hobbyist). So take this with a grain of salt 😅
The way I understand how OpenPnP works today, the E-CAD and
its library is pretty much the thing you could consider a
"hub". I would assume that you do organize shared part
libraries in your company. And once you really want to produce
something, you always need to import the board placements into
OpenPnP. When you do that, all the info about parts and packages
are imported too, new parts/packages added old one updated
(optional). Some E-CAD's import even gets the footprints (pads).
Once a part/package is imported, a feeder for it can be
auto-discovered and assigned via feeder QR-codes/OCR (BlindsFeeder
and ReferencePushPullFeeder) and perhaps by other (future) means
(like electronically).
Note: in the case of ReferencePushPullFeeder it includes
auto-creating new feeders. From the recognized part ID and
assigned package, it will clone settings from the "most alike"
existing feeder, while geometrically translating and rotating all
coordinates to the new location. "Most alike" is determined by
common package or row-proximity among other criteria. So for
instance if you have rows of similar feeders and insert a new one
among them, it can be automatically set up.
This only works among the same feeder models of course, and makes it necessary to organizes feeders in neat groups and rows, and for the very first use, discover them manually (one-click setup). But for any subsequent use of the same group/row it can be fully automated (I guess this hasn't been tested much, but I'm ready to fix bugs 😎).
So some of your points are covered that way.
Working like this will only be free of extra work, if everything
else can pretty much be standardized, made "self-tuning", or
auto-calibrated, like the bottom vision settings/pipelines etc. We
worked hard towards that goal, and I'm quite confident now, that
if properly used, newly imported parts will almost always work out
of the box. When the E-CAD import includes footprints, that even
includes oversize parts, where we need multi-shot vision, it is
automatically activated by the size of the footprint. Extra setup
work will only be required for the most exotic parts.
All this can eliminate the need to share extra
package/part/feeder info via a "hub" or otherwise.
That's about it.
So no, there are no means to communicate extra information, like
the composition of preloaded feeder trolleys or the likes between
multiple instances of OpenPnP, or with a standalone central hub.
But unless I'm missing something due to lack of industrial
experience, there are pragmatic ways to achieve almost the
same level of automation and ease.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ced56b6f-28e5-4328-8889-b58f0a9c6063n%40googlegroups.com.
Philip Kristoffersen
Thank you for a thourogh response :)
One wish is also that they know each time a part is picked succesfully, so that they can pull the data and update their internal logistics and be warned when its about time to order new parts.
mark maker
I see.
The part height can also be auto-calibrated.
For those parts with Bottom Vision, it can be automatically done
in the very first alignment of that part:
https://github.com/openpnp/openpnp/wiki/Up-looking-Camera-Auto-Focus
For those parts without Bottom Vision, it can be done with the Contact Probe Nozzle (you said you have a Liteplacer):
https://github.com/openpnp/openpnp/wiki/Contact-Probing-Nozzle#part-height-auto-learning
But of course this does not cover other things such as stock-keeping etc.
> I just have this slight feeling I will be doing
"double-work" given it isnt being integrated into OpenPnP. So
I'm just happy to hear your thoughts and insights about it so I
dont waste time in certain areas.
Some of these ideas, I guess, are really outside the scope of
OpenPnP. Even if we were to support ganged-up installations of
OpenPnP and share a data base of settings for parts and feeders
(which completely makes sense), this would hardly be extended into
stock-keeping, goods management, purchasing etc., i.e. it will
hardly become an ERP 😉 (my company actually makes an ERP, so I
know how ridiculously vast and deep the functional coverage has to
be... phew... 😅💦).
You should be aware of the scripting interface, though:
https://github.com/openpnp/openpnp/wiki/Scripting
If you need extra triggers, these are quite easily added. Some already existing might not be documented in the Wiki.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f011cf5f-ffb3-475f-8b2f-fa50bfcae878n%40googlegroups.com.
Mike Menci
Philip Kristoffersen
How much information is needed in the Machine.xml file in order for the feeder to work? The pushpullfeeders have significantly more variables attached to them and their operation and to make a parser that reads, holds and overwrites all of this would be quite the task compared to ReferenceAutoFeeder, which is 2 lines :)
mark maker
Hi Philip
as before I strongly recommend against doing things through the
XML.
Use scripting instead, it makes sure, all the "business logic" is
taking place. When you create a ReferencePushPullFeeder, for
instance, it will be properly initialized. Many settings are fine
with their defaults. Setters and Getters will make sure things
remain consistent from there. Functions are available to you, like
setup, cloning, calibration etc.
https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)
If you still want to go through XML, I recommend using
the ReferencePushPullFeeder interactively in the UI, then save the
config, then extract feeder XML fragments. Play around with the
settings and see how it affects the XML fragment. That would
probably work reasonably, but only as long as the feeder software
does not change much. As soon as we start changing the
ReferencePushPullFeeder in a future version, be prepared to redo
your fragments. Scripting would be much more stable.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/af9bba3a-de8a-4755-b81e-f7505fcc02b5n%40googlegroups.com.
Philip Kristoffersen
So, if I'm understanding correctly, a different way to go about would be:
1) Have our software layer get all the information of all feeders on the hub.
2) Store feeder data in a file.
3) Run script in OpenPnP that reads said file and removes / adds Feeders.
5) Run calibration.
6) Ready to go.
Since all OpenPnP needs is that a feeder exists and where it is at - the calibration does the rest, correct?
And dont worry about all the small details, just picking your brain to see if you know of any majors issues I may run into.
Again, thank you for taking your time.
- Philip
Mark
Yep, I guess that would be a valid approach.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/55122a5e-7eac-46ac-91c0-1a42fef22b15n%40googlegroups.com.
Philip Kristoffersen
Or should I go take an extra look at the PushPullFeeder video? :)
- Philip
Mark
> Or should I go take an extra look at the PushPullFeeder video? :)
Not only watching the video, but trying them out and figuring out
the optimal settings for your kind of feeder. You should be intimate
with them before you can even think of scripting them.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/9795d170-0318-414c-80f7-f28ecdc3d80an%40googlegroups.com.