OpenPnP 2.0

[Jason von Nieda]

Hi folks,

I'm very excited to announce a huge update to OpenPnP! This set of changes is the culmination of several years of design, planning, and one very long weekend of development :)

This new version changes how OpenPnP works so much that I'm choosing to call it OpenPnP 2.0. Depending on how well received the changes are, this will either become the new version of OpenPnP or it will become a separately maintained version with OpenPnP 1.0 being left in maintenance mode.

The main purpose of these changes is to make OpenPnP far more friendly for production use, and to fix a number of long standing, difficult issues that were all dependent on each other.

Release notes for the new version are here: https://github.com/openpnp/openpnp/blob/test/CHANGES.md#openpnp-20

You can download the new version from the Test Downloads section: http://openpnp.org/test-downloads/

Note that there are a large number of breaking changes, so please back up your production configuration, job, and board files before using this version. Additionally, many of the changes are not backwards compatible, so you may need to hand edit your machine.xml or just start from scratch.

I will be working on backwards compatibility in the coming week, so if you'd prefer not to mess with your config, you can wait until this version is pushed into Latest.

Please read the release notes, and try the new version, and let me know what you think!

Thanks,

Jason

[Marek T.]

Hi Jason,

Changes list sounds impressing!

Thoughts, proposals:
- during pick, why not to check vacuum level while the nozzle is lowered and raise nozzle when the level is detected partOn (need few tests in the loop repeated). And after raising confirm it with another vac test?
- discard in pickRetry is not necessary. I did this discard here and removed it very quick, in practice it gives nothing but taking a time only.
- after placement you turn on vacuum and check vac level, post place test. It requires a lot of time (dwell time after place) to wait until the vac level raise if nozzle is really dirty. If you make the test at once the returned level will be always partOff. Another loose of time. Better works turning vacuum on at this moment but performing the test at some later moment (like before the pick, prePick test). Note that even if after the placement you will get partOn test returned, potential place repetition is stupid (nozzle is rather dirty not part remains on nozzle, so placing again can only destroy the part already placed properlybon the board).

All the rest sounds very promising :-).

[Jason von Nieda]

Thanks Marek! Comments below:

On Mon, May 27, 2019 at 4:54 PM Marek T. <marek.tw...@gmail.com> wrote:

Thoughts, proposals:
- during pick, why not to check vacuum level while the nozzle is lowered and raise nozzle when the level is detected partOn (need few tests in the loop repeated). And after raising confirm it with another vac test?

I assume you mean to speed up the pick here? The idea would be as soon as enough vacuum is generated we can lift, instead of waiting for a long pick delay?

I think this is a good idea, and it would be easy to add. Now we can check if the user has part detection (Nozzle.partDetectEnabled) so we can do this when it's available.

- discard in pickRetry is not necessary. I did this discard here and removed it very quick, in practice it gives nothing but taking a time only.

What happens when a part is picked on it's edge, or very near the side? I think there is a situation where a part is picked badly and ends up hanging off the edge of the nozzle. Here we would want to make sure that the part is not still there when we try to pick again. You're right that it does add time. It would be easy enough to make it an option checkbox on the job processor.

 

- after placement you turn on vacuum and check vac level, post place test. It requires a lot of time (dwell time after place) to wait until the vac level raise if nozzle is really dirty. If you make the test at once the returned level will be always partOff. Another loose of time. Better works turning vacuum on at this moment but performing the test at some later moment (like before the pick, prePick test).

Good idea. So if I understand, you mean a sequence like this:

1. Place.

2. Lift nozzle.

3. Turn on vacuum.

4. Finish other placements.

5. Plan.

6. Check isPartOff()

Right?

 

Note that even if after the placement you will get partOn test returned, potential place repetition is stupid (nozzle is rather dirty not part remains on nozzle, so placing again can only destroy the part already placed properlybon the board).

You're right. This is another good argument for doing it after Plan.

Jason

[Marek T.]

Inlines too!

W dniu wtorek, 28 maja 2019 00:21:36 UTC+2 użytkownik Jason von Nieda napisał:

Thanks Marek! Comments below:

On Mon, May 27, 2019 at 4:54 PM Marek T. <marek.tw...@gmail.com> wrote:

Thoughts, proposals:
- during pick, why not to check vacuum level while the nozzle is lowered and raise nozzle when the level is detected partOn (need few tests in the loop repeated). And after raising confirm it with another vac test?

I assume you mean to speed up the pick here? The idea would be as soon as enough vacuum is generated we can lift, instead of waiting for a long pick delay?

Sure. Constant dwell time is not necessary in this situation to use at all (but no pain if remains of course).

I think this is a good idea, and it would be easy to add. Now we can check if the user has part detection (Nozzle.partDetectEnabled) so we can do this when it's available.

A code ready to use you can see in my repo (of referenceNozzle) I sent you a git link. Highly likely that you will write it better, however it was made two years ago with CriS help so I trust it's made well.

- discard in pickRetry is not necessary. I did this discard here and removed it very quick, in practice it gives nothing but taking a time only.

What happens when a part is picked on it's edge, or very near the side? I think there is a situation where a part is picked badly and ends up hanging off the edge of the nozzle. Here we would want to make sure that the part is not still there when we try to pick again. You're right that it does add time. It would be easy enough to make it an option checkbox on the job processor.

You're right about the edge. But in practice it's rare situation. I have found that even if part is picked by the edge, the vacuum is still good like partON and only the bottom vision size script can really detect it and refuse to continue.

Checkbox is good idea if you don't mind.

 

- after placement you turn on vacuum and check vac level, post place test. It requires a lot of time (dwell time after place) to wait until the vac level raise if nozzle is really dirty. If you make the test at once the returned level will be always partOff. Another loose of time. Better works turning vacuum on at this moment but performing the test at some later moment (like before the pick, prePick test).

Good idea. So if I understand, you mean a sequence like this:

1. Place.

2. Lift nozzle.

3. Turn on vacuum.

4. Finish other placements.

5. Plan.

6. Check isPartOff()

Right?

Right. But we must remember that someone may find it as troubling. It forces keeping vacuum pump loaded for some time , so weak pumps may have problem with this maybe.

Only we need decission (hardcoded or another checkbox) whether want turn vacuum off after "6. Check isPartOff()" or perform picking with vacumm being on during lowering the nozzle. Slow lowered nozzle (maybe) can pull part from the tape? I don't see this but as mentioned my head is relatively fast. Industrial machines I have, depend of firmware, some performs picking with vacuum turned on before lowering but some does this after. For me otpimal is "before" but maybe this is not universal? I don't know.

BTW: the same mechanism like during picking can be also used during the placement. I mean to control the vacuum level droping after the vac is off and lift the nozzle immediatly when found the level representing partOFF.

So also no need to use the DwellTime(place) and possible to cut the time of placement. The code is also ready :-).

[Marek T.]

"You're right about the edge. But in practice it's rare situation."

I have meant not that picking by the edge is rare situation, It happens of course, at 0402/0201 quite often.

But rare situation is that the vacuum is too low in this case, usually is telling the partOn and in the vision our hope only.

[Jason von Nieda]

Thanks Marek, I will think more about it. I think that with the new JobProcessor it’s very easy to add these kinds of things as options so I will consider that. And likewise, it’s just a single line of code for most of these things now, so easy to add or remove in a branch. 

Adding options to improve performance is very good, and now I think we have a good platform for it.

Also, thanks for reminding me of the vision size script. I’m going to be adding size checking to bottom vision soon. Will have to think more about retry in that case. Probably a vision failure should not result in the placement being errored but instead retried.

Jason

--
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 post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b02969d0-dfae-43ef-ae4a-4fffb60d13ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Sent from my BeOS enabled toaster

[Marek T.]

Do you want to add the stage "size" to the pipeline or what? There is a scriptRun stage and the script for size detection was published on the group if remember well (at least I have this in use).

I suggest to add AlignRetryCounter to the feeders yet. When bottom vision fails we should discard, pick part again (with feedRetryCounter and pickRetryCounter) and repeat the vision - all this within the loop with using AlignRetryCounting.

[Jason von Nieda]

No, not in the stage, but in ReferenceBottomVision. I want to have size checking be part of the native vision. Without it there is no way to know if the part is actually there or not, if it's tombstoned, etc. It will be optional for users.

The AlignRetry one is tricky. I'm struggling with that one. Here is the situation I am worried about:

1. Machine has 4 nozzles - picks 4 parts.

2. Perform align, and it's good on 1 - 3, fails on 4.

3. Discard #4.

4. Go back to feeders, pick, maybe fail, pick again, etc.

5. Now we go back to align. Do we re-align the other 3 parts? What if they have moved around while doing all the above?

I think it's better if we do this:

1. Machine has 4 nozzles - picks 4 parts.

2. Perform align, and it's good on 1 - 3, fails on 4.

3. Mark #4 as error.

4. Place 1 - 3.

5. Plan - #4 is still in queue, so we try it again.

This way we don't possibly mess up the other 3 while retrying #4.

The way the code is now (as of this email) is #4 will be marked error and user is notified at end of job - then they can retry. I know this is not ideal, because it may happen often, so I will fix this soon based on feedback here.

Jason

On Mon, May 27, 2019 at 7:02 PM Marek T. <marek.tw...@gmail.com> wrote:

Do you want to add the stage "size" to the pipeline or what? There is a scriptRun stage and the script for size detection was published on the group if remember well (at least I have this in use).

I suggest to add AlignRetryCounter to the feeders yet. When bottom vision fails we should discard, pick part again (with feedRetryCounter and pickRetryCounter) and repeat the vision - all this within the loop with using AlignRetryCounting.

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/7968156a-74ab-459b-ae39-4bb580b04706%40googlegroups.com.

[Marek T.]

"What if they have moved around while doing all the above?".
I have sharedC (higher risk for rotation mess for nozzles holding the parts) and I can't see the problem like that. But the way you propose sounds really more safe. However it still requires to use some AlignRetryCounter to tell the repetition is requested and limit the repetitions' number.

What in case when #1and #3 fails?
Place #2 and #4. Plan, pick #1 and #3, vision... Seems be really good.

[Jason von Nieda]

Quick update: Two of the coming soon changes have now been implemented: https://github.com/openpnp/openpnp/blob/test/CHANGES.md#2019-05-27

1. The entire paste dispense feature has been removed.

2. Placement.Ignore has been removed and a new Placement.enabled has been added.

See the release notes above for reasoning on each.

Thanks,

Jason

[Jason von Nieda]

Thanks Fish, good catch! It's fixed now. Binaries should be updated in < 10 minutes.

Jason

On Tue, May 28, 2019 at 5:04 AM fish <lefish...@gmail.com> wrote:

Hello Jason,

Error found: place() in GcodeDriver.java (--> sendGcode() is missing there).

On Tuesday, May 28, 2019 at 11:21:45 AM UTC+2, fish wrote:

Hello Jason,

After fetching new test-branch from git and migrating machine.xml (new vac variables, remove of paste-dispensers, park-when-complete, auto-save stuff etc.) i tried to setup new vaccum window values for my eight tips and realized that discard is not working.

The place command is initiated, pump off command is made, but no valves switched.

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/8b8a8476-b9af-482d-8c5a-d8df231f9caa%40googlegroups.com.

[Jason von Nieda]

Vacuum check used to be done in the Nozzle.pick() and Nozzle.place() methods. Now it's only done in the JobProcessor. So, it won't be used for manual picks.

Do you think it should be? It would be relatively easy to add it to the manual stuff by adding a helper class that is used everywhere. I've been considering doing that anyway.

Jason

On Tue, May 28, 2019 at 8:15 AM fish <lefish...@gmail.com> wrote:

Thank you Jason,

I wish i could find the magic switch where vacuum sensing is enabled - did'nt not run a job yet, but when at pick / discard manually there is no more vaccum sensing. Where should i dig?

To unsubscribe from this group and stop receiving emails from it, send an email to ope...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/8b8a8476-b9af-482d-8c5a-d8df231f9caa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b3a1229d-2cce-45e1-8a33-615bbbf577d5%40googlegroups.com.

[Marek T.]

What the switch are you talking about?

[pinolec]

Hi Jason,

I have 2 Nozzles and the second nozzle pick part but does not place it. I get the strange error MessageBoxes DEBUG: Job Error: Can't pick null part

I suspect there may be a missing place for the second nozzle. Here is my log: https://pastebin.com/3cxch9uu 

Kind regards,

Piotr Trembecki

[Jason von Nieda]

Hi Marek,

Sorry - I don't understand what you are asking. Can you explain a bit?

Jason

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/2348f729-e819-4ce6-9149-366bbee37382%40googlegroups.com.

[Jason von Nieda]

Hi Piotr,

Thanks for testing the new code. It looks like I introduced this bug in a last minute change. Will resolve this later today.

Jason

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/533fd4fd-dd98-4379-bc11-c05dcccadae4%40googlegroups.com.

[Mark]

Hi Jason

 

great news!

 

The CHANGES read very good in deed. Thank you very much!

 

The only thing that triggered a question mark was this:

 

Removed the post pre-flight nozzle tip calibration from job processor. I can't see why this would be useful since the planner may immediately change out the nozzle tips. Calibration is now performed after tip changes for any tips that are not already calibrated. If this change is detrimental to your setup please speak up.

 

If the description were accurate, then I think it would be wrong, because if a tip is already loaded on the job start, it would not be calibrated. But I’ve looked at the code and if I understand the new stepImpl() correctly, the nozzle tip is always checked for isCalibrated() before each plannedPlacement, not only after a tip change.

 

So it is correct.

 

My PR handles additional use cases for machines that have so much runout, that they need nozzle calibration even for nozzle tip change, and even between the change, for the naked nozzle. Otherwise: “crunch!” But we can discuss these use cases and I will help merge these in.

 

Video showing the naked nozzle calibration:

https://youtu.be/zfJVG5YJ-y8?t=23

Ref PR:

https://github.com/openpnp/openpnp/pull/825  

 

I have bought a new nozzle tip holder to replace my banged-up one (having 0.4mm runout diameter!), but I thought it would be nice to just keep the old one installed to demonstrate how the PR can even compensate for that much runout, including with the unforgiving Liteplacer nozzle tip changer.

 

_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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jwLk%3D0A4_O_GW6%2Bxj%3DgTqqVFW3BZGdX57xufYrGBUg-XQ%40mail.gmail.com.

[Marek T.]

Hi Jason

@fish said: "I wish i could find the magic switch where vacuum sensing is enabled" and you have answered with question "is this needed"...

[Marek T.]

Sorry, I haven't download this test release yet as testing this on my machine is impossible without a lot of customization I need to do priorly.

So I thought to wait few moments yet wait untill the version is little more tested and cleaned. Unfortunately I need a machine for work not testings only :-(.

The switch that Fish says sounds like "read" the actuator button???? Or reading vac values by the Openpnp during the manual picking?

[Jason von Nieda]

Hi Marek,

There's no switch - I think just a language thing. Fish was basically asking why vacuum check wasn't happening in a manual pick. It's not happening because I removed that functionality. Now we discuss whether it should come back. Seems like the answer is yes, so I will work on that.

Jason

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/a8318c11-55eb-4cd8-af3e-977ed514e671%40googlegroups.com.

[Jason von Nieda]

Hi Mark,

Thanks!

Yes, I think we are on the same page. Now every nozzle is checked isCalibrated() before running a cycle (a cycle is defined as feed, pick, align, place).

And yes, let's discuss the use cases. Should be no problem to merge the changes in now that JobProcessor is mostly fixed. Much easier to add changes without breaking the world now :)

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/013401d51565%24f94f9480%24ebeebd80%24%40makr.zone.

[Marek T.]

Ok, clear now. I didn't know you removed it so it was sounding strange.

And yes, my vote is also for "yes" :-).

[Jason von Nieda]

Thanks Fish, I'll start a new thread for GUI stuff and we can chat there. I'm very interested to hear your thoughts.

And yes, this is going to be a bit of a rough transition, but it's necessary. For years now I've been unable to make major progress on OpenPnP because of the bad JobProcessor design. Now I think that's fixed and many other things that have been waiting on it are unblocked. I'm taking this as an opportunity to try to fix every major issue. I figure that if people are going to need to make big changes to handle a new version we might as well get as much done as possible all at once, rather than force people to mess with their config over and over.

Jason

On Tue, May 28, 2019 at 10:39 AM fish <lefish...@gmail.com> wrote:

@Marek

I can not run my machine without adding my customized code, too.

So i do have to add my modifications for my machine to pulled code from git and recompile.

The hole process it is a little bit annoying but at the end it is worth because of all the structual improvments made by Jason's and his contributers.

@Jason

The stony way to a true openpnp 2.0 is the goal and i am happy that you let us take part. Maybe we could discuss some new concepts regarding the gui. 

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/499fdd1a-f4ae-49fe-a92a-9d6e33858c48%40googlegroups.com.

[Mark]

Hi Jason

 

No rush …  after things settle down, I would be grateful if you could lay out how the branches in OpenPNP will continue.

 

·         Will “test” be the 2.0 branch for the (longer) time being?

·         Or will 2.0 be merged into develop soon, and separate version 1 develop/master branches created instead? (preferred)

 

It’s just that I have a new feeder in development and I would like to integrate with 2.0 as soon as possible … :-)

 

Thanks a lot.

 

_Mark

 

> …

 

 

[Jason von Nieda]

Hey Mark,

Here's the plan:

* Tonight I'll merge develop to master and tag it. This will be the last major feature release for 1.0.

* Barring any major problems with test, I'll merge it to develop no later than 2 weeks from now.

* I'll let develop bake for a minimum of 3 months. If things seem to be going well, I'll plan to merge develop to master then. OpenPnP 2.0 will simply become "OpenPnP".

* If this all turns out to be a disaster, I'll either revert the whole mess and start over, or I will create 1.0 and 2.0 branches and maintain them, and their downloads, separately. I don't think that's likely, but it's an option.

Ultimately, most of the work I did this weekend is not user facing. It's a pretty major re-architecting of the JobProcessor but I tried very hard to keep most of the functionality the same. So, my hope is that aside from the configuration changes (which I am working on making backwards compatible) most users won't notice the difference aside from incremental improvements.

Jason

--

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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/017301d5156f%24e01eb680%24a05c2380%24%40makr.zone.

[Jason von Nieda]

This is now fixed Piotr, thanks for finding it!

Jason

On Tue, May 28, 2019 at 9:42 AM pinolec <pin...@gmail.com> wrote:

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/533fd4fd-dd98-4379-bc11-c05dcccadae4%40googlegroups.com.

[pinolec]

Hi Jason,

Thanks for a quick fix. It works great now. I had a chance to run a few boards now.

What I noticed is when I start another board, the first component on each nozzle is placed 90 degrees off of the correct orientation.

I have mixed fillings about after place checks if the part is off the nozzle. It's great because it really works but it takes a long time. I think it would be nice to have the option to switch it off. For heavy parts (0805 and bigger) its usually not the problem.

Piotr

W dniu środa, 29 maja 2019 06:03:42 UTC+2 użytkownik Jason von Nieda napisał:

This is now fixed Piotr, thanks for finding it!

Jason

On Tue, May 28, 2019 at 9:42 AM pinolec <pin...@gmail.com> wrote:

Hi Jason,

I have 2 Nozzles and the second nozzle pick part but does not place it. I get the strange error MessageBoxes DEBUG: Job Error: Can't pick null part

I suspect there may be a missing place for the second nozzle. Here is my log: https://pastebin.com/3cxch9uu 

Kind regards,

Piotr Trembecki

--
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 ope...@googlegroups.com.

[bert shivaan]

I was hoping to see a checkbox to disable the safe Z movement. I suppose it is not there?

[Jason von Nieda]

@Piotr: Glad to hear it worked out, and thanks for testing. I think making the after place check an option makes sense. Where do you think it would be? Placement, Part, Package, Feeder?

@Bert: Can you briefly remind me which Safe-Z movement you need disabled, and why?

Thanks,

Jason

On Wed, May 29, 2019 at 4:16 AM pinolec <pin...@gmail.com> wrote:

Hi Jason,

Thanks for a quick fix. It works great now. I had a chance to run a few boards now.

What I noticed is when I start another board, the first component on each nozzle is placed 90 degrees off of the correct orientation.

I have mixed fillings about after place checks if the part is off the nozzle. It's great because it really works but it takes a long time. I think it would be nice to have the option to switch it off. For heavy parts (0805 and bigger) its usually not the problem.

Piotr

W dniu środa, 29 maja 2019 06:03:42 UTC+2 użytkownik Jason von Nieda napisał:

This is now fixed Piotr, thanks for finding it!

Jason

On Tue, May 28, 2019 at 9:42 AM pinolec <pin...@gmail.com> wrote:

Hi Jason,

I have 2 Nozzles and the second nozzle pick part but does not place it. I get the strange error MessageBoxes DEBUG: Job Error: Can't pick null part

I suspect there may be a missing place for the second nozzle. Here is my log: https://pastebin.com/3cxch9uu 

Kind regards,

Piotr Trembecki

--
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 ope...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/533fd4fd-dd98-4379-bc11-c05dcccadae4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/19863419-8252-4f7e-8971-28a2e83bc40a%40googlegroups.com.

[bert shivaan]

Hi Jason, basically I need all of them disabled. They only slow thngs down for me - to a crawl it feels like. My nozzles are pnumatic, so a Z move does not cause them to retract anyway. It could, but I do all that in the pick/place movement area. My Z is common stop for the 6 nozzles. Now, lets say we want to go pick up 6 parts from a strip, 1 on each nozzle -

the machine moves to position

Z is lowered to position needed for the nozzle to stop,

the nozzle does its thing, extending, vac on retract,

THen

Z moves to safe height before moving to next part.

I know this does not sound like it should be a big deal, but it cost me at least a second for each move. Better if Z stayed where it should since thats where it needs to be for the next 5 parts.

Same issue with bottom camera and placement.

I did think of a possible work around but need to give it more thought. I do have the safe Z moves commented out in a local copy, but it would be much nicer to just hit a checkbox everytime there is an upgrade. My goal is not to have local special code.

[Jason von Nieda]

Thanks for the reminder Bert, that all makes sense now. I think that's why I filed this issue: https://github.com/openpnp/openpnp/issues/751.

The problem is that Safe-Z is implemented as a standard move, instead of a special move, so - as you found - it has to be commented out everywhere.

I just had an idea though. I'm not sure what controller you use, but maybe you could implement something in the controller to ignore Z moves to a specific position? Then you could set the Safe-Z to something like -999 and anytime the controller sees a Z-999 it just ignores it?

Jason

--

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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNz1NmbitK5%2BqjH7ypSzcsL2-qN71-MBPZdtUp3G0gxE%2BA%40mail.gmail.com.

[bert shivaan]

Or even better, could I do it in my move command? like if Z<15 do move else skip

Mind you I only have 15 mm travel

Something like I am doing with the Z variables when positive going or negative going

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jxwHTpSD58eKLa_GU59RDF%2BskJEWm-T5o2FJRDVpoTWxg%40mail.gmail.com.

[bert shivaan]

It seems like we could just set our move command to do Z first when move is positive, or last when move is negative.

for instance:

is Zpositive{

G0{Z:Z%.4f} {Rotation:C%.4f} F{BacklashFeedRate:%.0f}

M400

G0 {X:X%.4f} {Y:Y%.4f} F{BacklashFeedRate:%.0f}

M400

}

if ZNegetive{

G0 {X:X%.4f} {Y:Y%.4f} F{BacklashFeedRate:%.0f}

M400

G0{Z:Z%.4f} {Rotation:C%.4f} F{BacklashFeedRate:%.0f}

M400

}

Then Z is always safe. but for those that don't care like me, just have standard move. This way we do away with the safe z move all together

[Jason von Nieda]

Hi folks,

Quick note: I'm working on https://github.com/openpnp/openpnp/issues/183, which is going to really screw up configurations pretty bad. I figure I might as well get all the big, breaking changes out of the way all at once. So, if you were thinking about re-working your config to try the new code, maybe wait another day or so.

Jason

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNwbt%3DF3Wh0qj%3DBfD%2B_K9bzNdGV%2B_Fp3_H3GOS7HU1ge7g%40mail.gmail.com.

[ma...@makr.zone]

Hi Jason

thanks for this:

On Tuesday, May 28, 2019 at 6:22:36 PM UTC+2, Jason von Nieda wrote:

Here's the plan:

* Tonight I'll merge develop to master and tag it. This will be the last major feature release for 1.0.

* Barring any major problems with test, I'll merge it to develop no later than 2 weeks from now.

* I'll let develop bake for a minimum of 3 months. If things seem to be going well, I'll plan to merge develop to master then. OpenPnP 2.0 will simply become "OpenPnP".

...

Just to understand: why wait between step one and two? develop and master will then be at the same state for two weeks. To what end?

I'm just asking because merging test into develop would make handling my existing PR (needs resolving some conflicts) and the new one I'd like to make (new feeder) much easier. If I have to merge test into the PRs at my end, all the diffs from 2.0 show up in the PRs...;-)

_Mark

[pinolec]

Hi Jason,

I think it would be nice to have a chance to disable post place vacuum checks for selected parts. For me, it makes sense to make the option to skip post place vacuum checks in Part settings.

The issue I reported earlier with the rotation of the first component disappeared. I couldn't recreate it again. If I find a way to recreate it then I will report it. 

Piotr

[Marek T.]

So makes sense to check it after place and before the pick. Note what I said - post place to check it you must turn on vacuum, without it the test says nothing. After turning vacuum on you must wait untill it grows to the value partOn if part is on nozzle or nozzle is dirty - it takes some time because when you turn vacuum off during the placement it decays always to partOff value.

Probably the best for begining is to test it optionally twice (after place and before pick) with checkboxes configurable, let it to test by the people and get a feedback.

[NAR]

+1. Maybe even 2.0 can be on a separate structure with the .openpnp2 directory for its setup

On Thursday, May 30, 2019 at 2:26:51 AM UTC-5, fish wrote:
> Hi Jason,
>
>
> As config files will not be compatible for switching between version one and two a command line parameter or similar that selects the appropiate directories would be very helpful to keep both config's on same machine.
>

[Jason von Nieda]

That option exists: https://github.com/openpnp/openpnp/wiki/FAQ#how-do-i-use-a-different-config-directory

Jason

On Thu, May 30, 2019 at 2:26 AM fish <lefish...@gmail.com> wrote:

Hi Jason,

As config files will not be compatible for switching between version one and two a command line parameter or similar that selects the appropiate directories would be very helpful to keep both config's on same machine.

On Thursday, May 30, 2019 at 6:11:58 AM UTC+2, Jason von Nieda wrote:

Hi folks,

Quick note: I'm working on https://github.com/openpnp/openpnp/issues/183, which is going to really screw up configurations pretty bad. I figure I might as well get all the big, breaking changes out of the way all at once. So, if you were thinking about re-working your config to try the new code, maybe wait another day or so.

Jason

On Wed, May 29, 2019 at 2:25 PM bert shivaan <bert....@gmail.com> wrote:

It seems like we could just set our move command to do Z first when move is positive, or last when move is negative.

for instance:

is Zpositive{

G0{Z:Z%.4f} {Rotation:C%.4f} F{BacklashFeedRate:%.0f}

M400

G0 {X:X%.4f} {Y:Y%.4f} F{BacklashFeedRate:%.0f}

M400

}

if ZNegetive{

G0 {X:X%.4f} {Y:Y%.4f} F{BacklashFeedRate:%.0f}

M400

G0{Z:Z%.4f} {Rotation:C%.4f} F{BacklashFeedRate:%.0f}

M400

}

Then Z is always safe. but for those that don't care like me, just have standard move. This way we do away with the safe z move all together

--
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 ope...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNwbt%3DF3Wh0qj%3DBfD%2B_K9bzNdGV%2B_Fp3_H3GOS7HU1ge7g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e5ec8efb-1698-44ed-9780-8f0bef2f8427%40googlegroups.com.

[Jason von Nieda]

@Piotr and Marek: Yes, I think two changes will happen:

1. Will add a checkbox option for this and a couple other checks.

2. Will change it so vacuum is turned on after place is complete but the check doesn't happen until the start of the cycle.

Jason

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/8600256d-702a-4b46-9bda-a38cf1661419%40googlegroups.com.

[Jason von Nieda]

Hi Mark,

My main hesitation is that quite a few people have auto-update turned on for develop, and I don't want to break their configs if they are doing production. Similar to Smoothie's "edge", quite a few people use develop rather than master for production.

You should be able to resolve the PR just by targeting it at test instead of develop. You may need to `git rebase` your changes on top of it.

Optionally, just hang tight for a little while longer :) This is all still very fresh and somewhat fluid. I may merge it sooner if I don't start hearing reports of everything being terrible.

Jason

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/5b316c63-2ea8-4485-b391-cb359a4b38bc%40googlegroups.com.

[Mark]

> My main hesitation is that quite a few people have auto-update turned on for develop, and I don't want to break their configs if they are doing production. …

 

Ah, I didn’t even know that OpenPNP has auto-update, thanks.

 

> Optionally, just hang tight for a little while longer :)

 

Yeah, seeing that you are working on PR #183 and assuming that this one will introduce quite some conflicts with my pending PR #825, I’ll wait.

 

I’ll rebase the new feeder on “test”. Will be my first git rebase :-)

 

_Mark

 

[Marek T.]

Hi Jason,

Regarding to the Bert problem with the SafeZ. In my oppinion using PICK_ and PLACE_ commands to control pneumatic heads, or wider every heads not using motors but actuators - is crippled. Using it, it's hard to coordinate Z controls with vacuums testings during pick and place. Much better seems be the way I used to do. It means adding actuator synchronized to the Z position. When Z<value (nozzle down) Z.actuator.true, when Z>value (nozzle up) Z.actuator.false. So using Z motor control there is no problem to control pneumatic heads position coordinated wit SafeZ and SafeZ is not then any pain then at occasion. It could be two values Z.down and Z.up configurabe somewhere.

It is not proposal type "let's do this now" but just asking what do you think about it? Or maybe some other, better idea you have?

Another proposition being usable for me at least: checkbox to "check home_fiducial at the job start".

[bert shivaan]

Hi Marek, Jason actually put things in place to be able to do that and it works fine. But it doesn't solve my issue. First let me explain what I can do that I think is what you mean:

There are booleans available to indicate the direction of motion for all axis. So consideting Z set the move up like this:

If (Zpositive){

retract nozzle

M400

G0Zposition

M400

}

If (Znegative){

G0Zposition

M400

extend nozzle

M400

}

This is not the exact correct syntax but the gist is there.

Now for me there are other things to do like turn the vac on when in position on pick and off on place.

But my safe Z issue STILL exists even if it works like that.

I think my machine may work a little different then yours does Marek. I only have a moving stop to set how far my nozzles extend. it is programable and is in fact my Z. It travels 15 mm. It is commonb for all 6 nozzles. So if I need to move down 12 mm from the top, first Z moves to -12mm. Then nozzle extends. When Done the nozzle retracts. At this point everything is SAFE! BUT now open pnp will move my Z stop back up to 0 position. Move X 15mm (thats the distance between nozzles). move the stop back down to -12mm. extend the nozzle. retract the nozzle. Again head is safe now! Move Z back up to 0 and do whatever is next.

I know it sounds like a trivial thing, but it actually tripples the time it takes to pick,place,or do camera vision.

When I ran that test with 300 parts for you, the first time I ran it it took me 75 mins. I had all the Z distances as they should be so like 10-12mm travel for each part .

Next time I changed all the heights so it only had to move 1mm, the same job ran in 15 mins. SAFE Z IS KILLING ME.

But I understand I am the only one affected by this, so normally I don't want to cry about it. I was jusyt hoping if a lot of recoding was happening maybe something could change.

:)

[Jason von Nieda]

Okay, let’s try to fix this. I understand Bert’s situation I think. Marek, you don’t have the safe-z problem but in your case you just have pneumatic nozzles and you fire them from pick and place commands which limits vacuum check functions, right?

Jason

--

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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNxy9AYPCWWNUVHrgxSUF0iRcs5V6Hs2w49Ztk24uxdsKg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Sent from my BeOS enabled toaster

[bert shivaan]

Marek has some special addins to his code so I think he uses just move commands. I know he can use his jog arrows to actuate his nozzles. I am not clear on how he controls the depth.

Something that came to me - can I set my safe z to like -15mm, then it will always just move to the bottom of the stroke instead of the top? This would be much closer to where it normally needs to be.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jxV-siSntbYqDYLkDx8mv3h-gZ661DuOCK2g-bWgy6jRA%40mail.gmail.com.

[Marek T.]

Yes I use move_to to control heads.
Imagine settings: Board or feeder is Z-5. I have actuator with threshold at Z-2. When Openpnp sends nozzle to Z-5 (so below -2) an actuator is set true and gcode puts the nozzle down. Next when Openpnp makes safeZ it means makes move_to Z0. Z0 is above the threshold -2 so actuator is set false sending gcode lifting the nozzle. Hope it's clear...

[Marek T.]

And No, it's Bert is using pick/place commands that limits vacuums check (but on the moment he's not using vacuum sensors as I know). I'm fine using solution with an added actuator. I think Bert could be also fine with this and have no problem with safeZ. And this does not eliminate using Z value as height limiter.

[Marek T.]

Bert sorry. If you are sure that killing safeZ is the only solution for you, it's okay, it's not any problem for me :-). But it just seems to me that you complicate the thing that is quite simple and that my solution is better :-). Maybe I'm wrong...

[Marek T.]

Ok, got your problem I think. I haven't imagined that speed of your depth limiter is so slow and you don't want return it up (retract) after every nozzles lifting and loose a time for it. Correct?
Btw, I don't control a depth at all, my machine does not allow it, but I can live with this without pain.

[bert shivaan]

Yes Marek, I think we both are thing yours works like mine and mine works like yours. But tell me if I am correct - you have no ACTUAL machincal movement with Z? So any Z command is done instantly sine nothing moves. I have depth adjust for each Z move, and it is slow IMHO. Here is the video I posted before showing the "Z" going up and down for every safeZ move.

https://youtu.be/FODfIeHQYJE

[bert shivaan]

Also I don't wish to be a pain with this, as I said just throwing it in the mix if it was easy to add during the upgrade. Then I have taken a lot of posting space bout it where it is not needed.

-Sorry folks :(

[Jason von Nieda]

Nothing to be sorry about - I did ask :)

I think the best solution here is a very, very simple extension of ReferenceNozzle. This is a *perfect* example of why OpenPnP is designed as it is. It's trivial to add a new class that models your machine behavior perfectly. I think we can probably include these classes in OpenPnP. They'll do no harm, and will be easy to maintain.

Marek, here is yours: https://pastebin.com/zUEu2Fry

Bert, here is yours: https://pastebin.com/qagAQG08

Marek, yours overrides moveTo to handle your actuators. Bert, yours overrides moveToSafeZ() so that it does nothing. Other functionality remains the same.

To use these, in your machine.xml you just use PneumaticNozzle or ZStopNozzle instead of ReferenceNozzle.

Another way to approach this would be to add this functionality to ReferenceNozzle, but this bloats ReferenceNozzle for semi-rare use cases and leads people to ask "Why is there an option to disable safe-z? Why would I want to do that?"

By making simple class extensions we can get the exact behavior that you want without adding unnecessary options to the reference code.

If these classes meet your needs, let me know and I'll include them in the official distribution. If they don't, see if you can modify them to work and send it back to me, or let's discuss what is needed. That goes for anyone else too. If you have specific use cases that don't quite fit the Reference* classes, write a new one and submit a PR, or talk to me and let's see if we can work it out.

Thanks,

Jason

On Fri, May 31, 2019 at 9:47 PM bert shivaan <bert.s...@gmail.com> wrote:

Also I don't wish to be a pain with this, as I said just throwing it in the mix if it was easy to add during the upgrade. Then I have taken a lot of posting space bout it where it is not needed.

-Sorry folks :(

--

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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNxMVKv8NPkbYY7Q0P%3DreWJVG3Mh37%2B5v5NymUNEhp%3D%3DTA%40mail.gmail.com.

[bert shivaan]

Wow Thanks Jason!!! Looking forward to giving this a try for sure!!

Not sure I get how to use it, But it is late so likely it will make more sense tomorrow.

:)

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jxT8QCf7QN2MaN_5yaQeRNY5_05jcNWFReKzR5seoBXPg%40mail.gmail.com.

[Jason von Nieda]

Hope it helps Bert. If you struggle getting it going, let me know and we'll figure it out.

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNzXybP%2Bk5ExFgjQFOCNMywdDvqh9v1B1punoPOM-sjUQg%40mail.gmail.com.

[Marek T.]

Cool Jason, thx, I didn't realize it's possible to make the class file and machine extension like that ;) (not surprising, I don't know a lot yet).
This is moreless a code as I have in RefNozzle now. I will need little extend your code probably. So I'll take a play, test and send you some file asking to add but a bit later after my 2.0 upgrade probably.
Bert it must be great for you! :-)

[bert shivaan]

" Bert it must be great for you! :-)"

It feels like it must be my birthday Marek!

[Jason von Nieda]

Change of release plans:

Based on feedback I've received, my own testing, and a lot of thinking I think it's best to move forward with OpenPnP 2.0 as quickly as possible. I'm going to be working on a lot of more serious changes in the coming weeks and will be breaking everything repeatedly. On one hand, sorry for that, but on the other hand I hope to come out of this with a fresh piece of software that will solve many of the problems that have cropped up over the past decade of development.

A few things on the list are: Global NozzleTip refactor (nearly done), Z Probing (done, needs documentation), removing Reset / Apply, implementing limited Undo, and a whole host of UI and workflow improvements.

This last part I am most excited about. I'm going to be making changes that make OpenPnP "opinionated". For those not familiar with the term in software development, this means that program will expect you to do things a certain way, rather than trying to let you do things in any way you like.

That probably sounds scary and like a loss of flexibility. In a way, it is. But OpenPnP is far too flexible right now. The flexibility makes it difficult, and unpleasant to use. It takes far too many clicks and tab switches to accomplish simple tasks. Things that need to happen often are buried deep in dialogs and things you barely ever need to do are exposed at the top level. It's a mess.

A couple examples of the types of changes I want to make:

* I'll remove the tool selection dropdown on the left. There will be no currently selected tool. Instead, OpenPnP will automatically select the tool for the action you are performing.

* Picking a part will be fully automated. OpenPnP will select and load the correct NozzleTip, select a feeder, perform vacuum checks and retries, and end with a bottom vision check.

* A common interface for feeder functions will be bubbled up. In general, you should not have to dig around to adjust the pick location for a feeder. It is the most common operation you need to do with feeders in production after feeder changes, so it should be exposed at the top.

* You'll be prompted to home the machine on startup, and the machine will park after homing. In general, I intend to use Park much more extensively. The default state of the machine will be Parked with no nozzle tips loaded. This will keep the head out of the way and hopefully lead to far less manual jogging. In general, I'd love to reduce the manual jogging to an absolute minimum.

* Overall I want there to be less buttons, less options, and less things you have to do manually. Once your machine is set up you should not have to remember a million tiny details to do simple tasks.

Note that the above are examples, and are not fully fleshed out. I know some details are missing :)

So, today I will merge develop to master, and test to develop. Develop will be OpenPnP 2.0 until it's ready to merge to master, in some number of months. Develop will point to .openpnp2 for configuration rather than .openpnp, so it will not try to upgrade or break existing configs. A dialog will pop the first time it's started to let the user know what is happening and how to switch over to master to get right back up and running if they don't want to join in on testing.

I'll make another announcement when the merges happen, and after that you will be able to download OpenPnP from develop / Latest. I do expect to break configurations a couple times along the way, so I recommend keeping backups whenever you update.

Thanks,

Jason

On Sat, Jun 1, 2019 at 6:02 AM bert shivaan <bert.s...@gmail.com> wrote:

" Bert it must be great for you! :-)"

It feels like it must be my birthday Marek!

--

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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNzrz_hfMhmoPERVkS%2BOzRa_qj5PtJccAFH6z%2B8oYh2%3Dbw%40mail.gmail.com.

[Sandra Carroll]

Hi Jason

Glad to see these changes and the "Opinionated" is good to hear.  One of my concerns with OpenPNP is trying to be everything to everyone you increase complexity and introduce bugs.   
I know my view wouldn't be shared by most but I would love for you to (at some point) say Here the HW supported by OpenPNP,  this is what its designed for.   if the user wants to support other things being open source they could do so but the main stream is limited to this HW.   I really think that would enhance stability.    Again I know it's not likely to be a view point shared by many.   Scope creep is always a problem in software design and setting that steak is what get you producing quality software (IMHO) then later adding support for other hardware as long as the design was implemented as HW agnostic from the start becomes easier.

Like I said probably not a popular view but i do think the "opinionated" part is a very good direction.

great work, looking for to the V2 of OpenPNP

Sandra

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jxV%3DAEOfj-wZGtN35GmOv%3DySomyj6nLROYa7URTUA1b0w%40mail.gmail.com.

[Jason von Nieda]

Hi Sandra,

I share that view. I'm not purposefully going to try to leave anyone's machine behind, but I think for OpenPnP to be very useful there will have to be a set of minimum requirements. I'm going to try much harder in the future to limit scope creep in the Reference* classes and instead push more unique use cases into extensions.

Thanks for your support!

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAKP5OO05r_JE32O4fnSjWJ0m6EH8O23kwe1-7PqK3kOLwa-bDw%40mail.gmail.com.

[bert shivaan]

Sounds all very well indeed Jason.

On the automatic part picking, will that also be available from the job? What I mean is can I select a part, then tell the machine to go get it?

Also if we can do that, maybe a place button could be available? that way we could place single parts one at a time for debug purposes? And of course the creme de la creme let us manually adjust to be centered over bottom then place. ;) I know it is not widely understood what the value is here, but there are times during prototyping when fussing with the vision is harder/longer then just manually adjusting the part real quick then hit place.

Will you consider implementing a true backlash system to all the axis instead of just the one now on X,Y? This could be helpful I think. Also I think I could use backlash for my shared C.

[ma...@makr.zone]

HI Jason,

Most of this is great news!

But I'm also hearing some inner alarm bells. Simplifications in the form of automatic, semantic behaviour is good. Designing a layered user experience, where the top-most layer gives you straight access to the most often used functions, while the rest of the functionality is a bit tucked away, but still accessible, is good. Using true object oriented design where a specialization only exposing complexity when it is actually instanciated, is good (you just posted two examples for special Z handling yesterday).

But removing good functionality or more generally orthogonality, just because it is not used by the majority of users is the dark side! That's currently happening to a lot of software and products all around. Stuff is dumbed down to the average user or worse to the utmost noob (like all the "App" crap). Nobody seems to be realizing that this is an endless spiral, leading to awful crap products. It's a bit like with democracies and cheap populism vs.minorities. Supposedly simple solutions for the masses. No thank you. Unfortunately, both phenomenons are Megatrends :-(

But I have the fullest of confidence in Jason to do the right thing and leave the finely crafted universal and orthogonal design in OpenPNP intact, even if it means that we have a bunch of choices more to make, have to switch on our brains and learn! :-)

And yes, a big thank you for all the things I learned using OpenPNP so far. Some things I learned the hard way, but almost all of it openend up my horizon. Just trampling in the footsteps of the herd, kills all innovation.

OK that came out way too emotional, but hey I had some glasses of wine :)

_Mark

[Jason von Nieda]

Hi Mark,

I very much appreciate your insight. Please feel free to raise the alarm if a feature starts to go sideways.

I don't intend to change much about the core internal design of OpenPnP. In general, I think the overall object model is pretty decent. We're keeping scripting and I expect to add to it. Pipelines will still be there but they may start to take a back seat to "smarter" multi-pass vision systems. Nozzles, Actuators, Feeders, etc. will all remain largely unchanged. This is primarily going to be a UI refresh with a focus on the production workflow.

The bottom line is that right now it's pretty hard to build boards with OpenPnP. OpenPnP is (moderately) good at being a machine configuration system, but when it comes to it's main job - building boards - it's pretty hard to use. I think I can do better.

The upside for developers, like you, is that I'm going to be much more willing to accept breaking changes and big ideas during this transition period. This is an opportunity to make big improvements based on all we've learned.

Jason

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/a4e4dbf9-f2fa-4299-b1bb-8b8dc3f6440f%40googlegroups.com.

[Jason von Nieda]

Hey Bert, yes, I am planning a "run the job just for this placement" feature or at least a shortcut for it.

Manual bottom vision - probably not high on my list, but one thing that IS high on my list is simplifying the bottom vision immensely so that tweaking is kept to a bare minimum. Right now it's way, way too hard to tune the bottom vision and fiducial pipelines. I'm hoping to improve that.

This is where things will get opinionated. I'm going to expect users to set up their cameras to produce a decent image with enough contrast, and will give them tools to do so. But beyond that, the bottom vision should do the rest without having to tweak pipelines. I think it's critical that we have a minimum standard for what a proper image looks like from either camera so that the vision algorithms have something useful to work with instead of trying to handle every single possible random case. If that means users have to put a cover over their camera to keep out ambient light, or use a better lighting system so it's not just a bucket of specular reflections, so be it.

Backlash... sigh. I wish the open source controllers would handle this better. It's something that should be done by the motion controller, not the high level software. It's something I think about - I don't like the current backlash system - but it's low on the list.

Jason

--

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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNx7pfOn1mmxqrV_dvin%3DpnHh%2BeiuR4iLvOegLLUKLdQkQ%40mail.gmail.com.

[Sandra Carroll]

Totally agree backlash does not belong in OpenPNP,   Looking at many of the motion controllers out there we're talking ones used for 3D printers are predominately used.   OpenPNP is not a 3D printer and using a controller designed for one is a limitation.

again IMHO,  maybe something that should be a requirement is some thing like backlash is a controller that supports it and keep that function out of OpenPnP.  

On vision, I know we talked about this previously and looking at allot of higher end machines (online not in person just for clarity) it looks like they us still image capture over video streams.   is that maybe a direction you're thinking of for vision.

For my need vision is important as I'm placing small parts on a small board very close together so vision helps allot but my specific need shouldn't' drive design

Sandra

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jw9sDcCPDL7Xec%2BPBc2R1U_n7oVpfUC1ofHoO3SsAE3jQ%40mail.gmail.com.

[Jason von Nieda]

Hi folks, the merges are now complete. Stable / master is merged from develop as of today, and Latest / develop is now OpenPnP 2.0. A dialog is added and the configuration directory is changed. You should see the dialog pop up the first time you start the new version, and it has instructions on how to proceed. You can see that document here: https://github.com/openpnp/openpnp/blob/develop/OPENPNP_2_0.md

Enjoy!

Jason

[Jason von Nieda]

Hi Sandra,

I don't have any current plans to change capture. When I looked into the difference between still and video the differences seemed to be not very well defined, if they existed at all, at least when it comes to high level camera APIs.

What I'm mostly referring to is trying to make the vision algorithms smarter and moving away from the pipelines per object system. It's not reasonable to think that every OpenPnP user is going to understand computer vision in detail, and they shouldn't have to. So my hope is that if we can tell users something like "If you can get your camera to produce an image that looks basically like *this* then bottom vision and fiducial vision will "just work". If you can't get your camera to produce such an image, ask for help until it does."

And I should note that I think one of the ways to get a clean image would be to have a single "filter" CvPipeline defined for the camera. The result of the pipeline would be to output a good, high contrast, greyscale image.

This is all in flux. We'll explore the vision stuff more as I get further along. Right now it's a little further down the list.

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAKP5OO229eLZHT%2BKn77fQm8JeF-V8GTHVf-dhOfVW17UjeWE2Q%40mail.gmail.com.

[bert shivaan]

I can still make a script or even make something work with help from you and/or Marek. It is hard for me to explain why I want the ability to adjust manually, then hit the place button and place it using the current offset. Maybe it is just left over frustration from my commercial machine. on it all the pads had to be defined and it looked for them. So next thing you know you have a TQFP144 with a slightly bent pin and the machine would trash it because the pin was bent. Now that was a good feature, unless you are building niche stuff and just want to place that part. Or you have some crazy part like I have now, that sometimes openPNP sees it as 90deg rotated because the overall found rectangle is just not perfect. So you see to make 2 boards just so I can test the board, I would love to have that ability.

As for backlash, Yes maybe it would be nice to have it in the controller, but I think you are 90% there already with the direction booleans. The current version has the advantage that people don't need to actually know what their backlash is. But for me I find it painful that the machine jerks that little bit needlessly.

If I wanted to tackle that, how would I do it NOT in gcode driver?

Also on the wish list can you break visual homing out as a seperate callable function from a script? I actually did it, but still in the gcode driver. I then made a script to call it for homing.

[ma...@makr.zone]

OpenPnP is (moderately) good at being a machine configuration system, but when it comes to it's main job - building boards - it's pretty hard to use. I think I can do better.

I think this is the real heart of the problem. Clearly separating two GUI domains - one for production and one for setup - could be a good way not to step into the oversimplifications trap.

In every field of inquiry, it is true that all things should be made as simple as possible – but no simpler. (And for every problem that is muddled by over-complexity, a dozen are muddled by over-simplifying.)

Sydney J. Harris,1964 after a saying attributed to Einstein

_Mark

[ma...@makr.zone]

Pipelines will still be there but they may start to take a back seat to "smarter" multi-pass vision systems.

Having worked with different pipeline quite a bit now, I think the key to success would be to parametrize the pipelines more. Instead of tweaking values inside each of many pipelines. The user should have control of the most important parameters from the ouside. Critical thersholds, mask and hough radii etc. The latter should come from true knowlegde about the physical word (like it is already done with the fiducial diameter, for instance), rather than from trial and error. Parameters are also key to sharing the same pipeline across all parts/tips etc..

I think it's critical that we have a minimum standard for what a proper image looks like from either camera

For bottom vision and fiducials, yes! But there are exceptions, like nozzle tip calibration, when such a thing is hard to guarantee. With CP40 nozzles being black on black it is just difficult. But it could be done with proper parametrics.

_Mark

[Jason von Nieda]

Hey Mark,

I wrote a long email explaining why this won't work and realized that's the wrong response. The right response is "How can we improve it?"

My main issue with parameterizing the pipelines is that we end up adding pipeline specific UI to non-pipeline code, but I had an idea: What if we add a checkbox to the pipeline stage parameters called "User Editable" and we add UI to OpenPnP so that any user editable fields are exposed in OpenPnP?

Then you could have a pipeline that is maybe 10 stages long, but you just mark a couple critical parameters as "User Editable" and these appear in the main UI in OpenPnP, instead of being buried in the pipeline. We could even let the pipeline designer give the parameter a helpful description to show the user.

So, for instance, on the bottom vision pipeline maybe we expose MaskHsv.hue as "Nozzle Color".

This still leaves the issue of passing non-pipeline data into the pipeline, which I think is a critical issue. The template, for instance. That whole situation is just a very, very roundabout way to get the pipeline to generate a template instead of having it generated in OpenPnP. For hough we need to pass in fiducial diameter, for bottom vision we need to pass in part size information, etc. And often we need to do some basic math on these values. Hough actually needs a range - so do we program OpenPnP to pass in that range, or maybe we change the stage to calculate the range.

Now I'm getting back to my long email... but this brings me to my main concern with the pipeline system: I feel like we're just trying to find ways to write programs in the pipeline editor, and maybe we should just use the pipeline editor as a discovery tool and then distill what we find into code.

Jason

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4e0619fa-7204-4ecb-a4eb-c4c48bae012b%40googlegroups.com.

[Niels PA1DSP]

Hi Jason,

Great to see this happening. Thank you!

Regards,

Niels.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jzDRA7sJYFJt8Cvkn350o3tO8wv%3DYDuaOFF3782ybt5%2Bg%40mail.gmail.com.

[bert shivaan]

thoughts about pipeline from novice pipeline user but experience commercial PNP user:

Maybe there is a way to have a setup place that would help to tune the camera to give the best input to openPNP. I agree we need to maybe settle on a camera or 3 that work and just put it out there that here is what will be supported. Other cameras may be used, but results will vary and may not work at all. After all we are not talking about 1000's or even 100's of USD here.

Back to the setup idea. On the camera setup page there are some number of sliders that I must admit are fine to play with but I have no idea what they do to help or hurt. Just because the picture looks better or worse to my eye does not mean the computer will like it. Is there a way to have the computer give us feedback like better - worse - no good . Or even better, can we have the computer set the sliders for us? Maybe the computer looks at the image and sees too much red so it applies a filter for that. I don't really know but maybe someone gets what I mean.

I also think it would be great if we could at least autogenerate a proper mask circle based on the expected size of the part. So if the part is 1mm x 1mm it would fit in a 1.414mm dia circle, so the mask may need to be 3mm. But certinally NOT the default size it is now. That default mask circle should come from the part description when the part is setup.

The same with the part size (I think this has been mentioned). We can call a script to check for the size of the found rectangle vs some passed parameters to decide if the part is correct. With this we can know if it is tombstoned on the nozzle, or if it is not there at all.

And last thing I am thinking about is actually something I filed a bug report for. Visual home will return true if NO FUDICAL is found. Personally I find this a bug.

[John Plocher]

This move towards opinionated is good, but needs to remember that there is no "generic, universal" machine, each supported machine should have its own portable named configuration.

Presume a new user flow of

• install openPnP, 
• install (or select, or even 'create new'...) the "CharmHigh CHMT48B machine definitions" (or the "Bert Machine Custom", or "Marek's test from Friday config"...)
• Calibrate the machine based on the just-installed definitions
• Load board stuff
• run the job

That is, the flow of tasks needed to set up or tune a machine's mechanical and electrical design should be logically distinct from the flow needed to simply process a job, and the config files needed for a given machine should be maintained in their own namespace'd zip file or directory that can be maintained independently from the core openPnP program.

Yeah, teaching Grandmother to suck eggs :-)

  -John

(Wikipedia:  Teaching (your)grandmother to suck eggs is an English language saying that refers to a person giving advice to another person in a subject with which the other person is already familiar (and probably more so than the first person).)

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAKP5OO05r_JE32O4fnSjWJ0m6EH8O23kwe1-7PqK3kOLwa-bDw%40mail.gmail.com.

[Marek T.]

Hey John, here we say "don't teach Father how make the children" ;)

[Jason von Nieda]

Hi John,

The idea of having a a way to load and save distinct machine profiles is an interesting one! I could see how that could be useful.

But in general, yes, this is what I'm going for. I have always maintained that the machine data should remain separate from the job, part, and package data. The object model reflects this, but the UI doesn't. I'm working to improve that.

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAKFrckrdV7r1czOJGKFFJH_aYjCvS2Rj0Kr7tCJUYAzst0HtJA%40mail.gmail.com.

[Marek T.]

And feeders.

[Jason von Nieda]

That's a good idea Bert. How can we tell users they need to improve their image if we don't define what a good image is. This could probably start with some examples on a Wiki, and then auto tuning could come later.

The sliders are a bit of a mess. I added them all because suddenly we had the ability to control all those things, where we didn't before, but I think it's information overload in many cases. Probably it would be better if most were moved to an "Advanced" settings page, and the main settings just had 2-3 important ones, like exposure.

Masks: This goes back to parameterizing pipelines. This needs further exploration.

Part size in bottom vision: Yes, coming soon.

Jason

--

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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNyA7C5dysjZR-T5OgrMuJVN9ziZG%2BzpHr4gT7xVK1s9tg%40mail.gmail.com.

[Jason von Nieda]

Can you expand on that Marek? What fields in particular? Certainly you don't want to swap out the hardware configuration like actuator name, pick height, and that sort of thing for each job, right?

Jason

On Sun, Jun 2, 2019 at 12:38 PM Marek T. <marek.tw...@gmail.com> wrote:

And feeders.

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4bb847c5-3a92-4a07-a5ca-fb09c7de22df%40googlegroups.com.

[Marek T.]

Why not?

Creating each next job we always need to use other set of feeders, so need add new feeders and remove some not used (if want have on the list only the one being in use). After some time I have there a mess with many feeders.

After one month I need to come back to the old job as I have many clients repeating their series in every one month or so so. So except loading the job I need to actualize the feeders for it.

I'd prefer have full feeders data kept in separated file like feeders.xml or maybe in file somehow connected to the job (?). Then I can name them feeders_board1.xml, feeders_board2.xml etc.

That's why we have discussed some time about it and Jaroslaw (Jarek sorry, forgotten to say "thank you" for it) made a python script to export/import modules from the machine.xml.

Maybe some other, better, idea than module swapping is possible to find, we can think about it.

W dniu niedziela, 2 czerwca 2019 19:45:33 UTC+2 użytkownik Jason von Nieda napisał:

Can you expand on that Marek? What fields in particular? Certainly you don't want to swap out the hardware configuration like actuator name, pick height, and that sort of thing for each job, right?

Jason

On Sun, Jun 2, 2019 at 12:38 PM Marek T. <marek.tw...@gmail.com> wrote:

And feeders.

--
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 ope...@googlegroups.com.

[Jason von Nieda]

Hi Marek,

A few questions about how you use feeders:

1. When you start a new job do you generally unload all feeders from the machine, and load all different ones just for the job?

2. Do you tend to keep reels loaded in feeders, or do you remove them when done?

3. Do you ever leave a feeder on the machine if it already has the part you need?

I suspect that the disconnect here is that you are doing more like contract manufacturing, and OpenPnP is more designed for individual use. The way that I want to use feeders is if the part is already loaded in a feeder on the machine, I don't want to mess with it. I just want to change the feeders that are missing for the job.

Jason

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/df29e5a6-bad6-4798-b424-473352bb728f%40googlegroups.com.

[bert shivaan]

Is there a step between the wiki and the autotune? For instance:

In the edit pipeline, I can adjust threshold, it will have some effect on the Drawn counturs. But what effect? Oh just click on the draw countours stage and see. Hmm not what I was hoping, go back and change more.

Maybe what I am trying to describe is a real time display showing the result from a change as it is changed. and maybe expose all the adjustable things in the pipeline at one time.

Am I making any more sense yet?

[Jason von Nieda]

Hi Bert,

In the pipeline editor there is a little thumbtack icon. If you select your draw contours stage and click the thumbtack it will pin that stage to the display. Then, when you change anything else anywhere in the pipeline that will instantly update. I think that is basically what you are describing?

As for putting all the adjustable things in one place - that's difficult. Each stage has many options. If we took all the settings from the bottom vision pipeline and put them in one list it would be dozens of options, many of which would be duplicated since some stages are repeated.

Jason

--

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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNythF4-PY59v8PGYOuMsAUHRUpwYk%2B46zZzEvQXnO6rFw%40mail.gmail.com.

[Mike Menci]

Hi Jason 

There are several Companies that produce feeders and feeders are in a magazine or TRAY or SET. 

For example my Dima feeders - 7 feeders /8mm tape go in one  Dima Optimat feeder magazine (SMPM-5000) 

web page link here; http://www.twentech.com/feeders/feeder_Dima.html 
With Job change - I would than change a  1-2,... X magazines and load into PnP that set of feeders file....

I can load 5 mazines x7 = 35units 8mm feeders (or less for / if I use more 12, 16 or 24 size) 

Same way works MyData Mycronic TM12C 8 x 12MM any many others...

Mike

[Mike Menci]

[Jason von Nieda]

Hi Mike,

I'm familiar with this type of system, and with the feeder trolleys that some machines use. My questions were to collect some data on Marek's actual real world use.

I think there is a fundamental difference between how a contract manufacturer (CM) uses their pick and place and how a DIY / hobby / small business (OEM) building their own product uses it.

A CM has the need to manage parts on a per customer / per job basis because they may be stocking parts for that customer. They are also more likely to have many spare feeders.

An OEM will want to share parts as much as possible, and avoid reloading feeders if there is a compatible part already on the machine. They probably have fewer feeders, because feeders are expensive.

I designed OpenPnP for OEMs, not for CMs. When a user loads a new job I expect them to only want to swap out the feeders that are different for this job, not all the feeders. The OEM use case is more important to me, since that is the market that is under served. I expect most CMs are going to just buy industrial pick and place machines.

That's not to say I don't want to support CMs, but not at the expense of OEMs. So, let's collect some more real world data and then we'll discuss ideas. If you can describe how you use OpenPnP that will help too!

Thanks,

Jason

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e5b695cb-94e6-43ec-8a35-f303425456ca%40googlegroups.com.

[John Plocher]

1. When you start a new job do you generally unload all feeders from the machine, and load all different ones just for the job?

CHMT48 examples from a hobbiest that helps out a few others in the model railroading community with not-really-commercial support, with 1x to 12x matrixed boards per panel and batches in the 10x to 40x panels-per-job range

The machine has a set of relatively fixed feeders that are a pain to change over to new components.  Mostly 8mm:4 but a few larger sizes as well.

This lead me to standardize on a library of common components for my designs, and to impose those choices on my not-really-customers

It is easy to add/change tube fed parts with a vibrating feed plate, so I use them for most ICs.

If a design needs unique parts, I either mount a tray of components - or simply hand place them after a board has been machine placed.

 

2. Do you tend to keep reels loaded in feeders, or do you remove them when done?

Reels are permanently loaded in feeders (a limitation of this kind of machine design...) 

3. Do you ever leave a feeder on the machine if it already has the part you need?

Always :-)

 

My workflow is customized for the CHMT - 

• Use EagleCAD for brd design
• I maintain a Google Spreadsheet of all the feeders I have in use:  https://docs.google.com/spreadsheets/d/1HuY1-9Z5yyQwUiivPqE5rH7m6A_Cvw6qmvkwXvpyZ-k/edit?usp=sharing
• I run a python script to convert eagle.brd and this feeder list into a "DPV" file that can be loaded into the CHMT.  (derived in spirit from the one done by SparkFun...)
• This DPV contains the final mapping of centroid placement data, component type and feeder arrangement for a given board and feeder setup.
• I load the DPV file into the CHMT, walk thru a manual machine, board and feeder calibration and test checklist that includes FIDs and other stuff
• On the first design on the first panelized board of a job, I single step thru the first few placements to verify correctness...
• ... at which point I run the rest of the job at regular automated speed.

This only works because the feeder list rarely changes - because the damn feeders are so hard to change...

If I were to convert to a Yamaha-style interchangeable feeder machine (drool, prayer for stuuupid US tariffs to go away...), 

I would need to refactor the feeder-location-to-component logic to a later point, preferably with a machine that could automatically use its top vision camera to scan QR codes on each feeder and compare against a database of all feeders as part of job setup.

That is, the workflow changes to

• design a brd
• import it into the "system"
• OpenPNP ingest tasks:
• compare existing machine feeder setup to this job's requirements
• indicate unused feeders, list missing components, "click on a donor feeder location and a missing part" to swap out an unused for a needed feeder load, 
• repeat until all needed components are satisfied.
• Calibrate and run job...

The latter workflow is a superset of the former; it could implement a fixed feeder system by using a fixed database of feeders and setting all "no feeder found" components to "do not place"...

 -John

[Marek T.]

Hi Jason,

Inlines.

W dniu niedziela, 2 czerwca 2019 20:35:14 UTC+2 użytkownik Jason von Nieda napisał:

Hi Marek,

A few questions about how you use feeders:

1. When you start a new job do you generally unload all feeders from the machine, and load all different ones just for the job?

It depends. For some clients we keep their personal parts loaded onto the feeders and don't take the reels off untill need a feeder get free. But we have some 300 feeders so it is not needed too often.

So when the job is finished we try to hide the feeders with the parts on, or sometimes even just take out whole the plate with 40 feeders and mount another one with new feeders set.

But for some clients we use our parts. Then no need to take the parts (reels) off the feeders e but continue using them for another client's job.

2. Do you tend to keep reels loaded in feeders, or do you remove them when done?

3. Do you ever leave a feeder on the machine if it already has the part you need?

hmmm, for #2 and #3 an answer for #1 explains everything...

I suspect that the disconnect here is that you are doing more like contract manufacturing

usually yes, but we also do assembling for our own production.

, and OpenPnP is more designed for individual use.

but I guess using OpenPnp for contract assembling is not forbidden ;)

The way that I want to use feeders is if the part is already loaded in a feeder on the machine, I don't want to mess with it. I just want to change the feeders that are missing for the job.

Jason

On Sun, Jun 2, 2019 at 1:25 PM Marek T. <marek.tw...@gmail.com> wrote:

Why not?

Creating each next job we always need to use other set of feeders, so need add new feeders and remove some not used (if want have on the list only the one being in use). After some time I have there a mess with many feeders.

After one month I need to come back to the old job as I have many clients repeating their series in every one month or so so. So except loading the job I need to actualize the feeders for it.

I'd prefer have full feeders data kept in separated file like feeders.xml or maybe in file somehow connected to the job (?). Then I can name them feeders_board1.xml, feeders_board2.xml etc.

That's why we have discussed some time about it and Jaroslaw (Jarek sorry, forgotten to say "thank you" for it) made a python script to export/import modules from the machine.xml.

Maybe some other, better, idea than module swapping is possible to find, we can think about it.

W dniu niedziela, 2 czerwca 2019 19:45:33 UTC+2 użytkownik Jason von Nieda napisał:

Can you expand on that Marek? What fields in particular? Certainly you don't want to swap out the hardware configuration like actuator name, pick height, and that sort of thing for each job, right?

Jason

On Sun, Jun 2, 2019 at 12:38 PM Marek T. <marek.tw...@gmail.com> wrote:

And feeders.

--
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 ope...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4bb847c5-3a92-4a07-a5ca-fb09c7de22df%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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 ope...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

[Scott Wilson]

John,

That is almost exactly my situation as well. The only real difference is I'm using a modified liteplacer and 3d printed 0816 feeders. The feeders work well, but are a huge pain to swap out, so I also use a library  of standard parts, and then either manually place or use cut strips for parts I can't do without.

-Scott

[Mike Menci]

Hi Scot, 

You see this is why magazine is used. You keep standard or more often used tapes in there ( 2  or 3 magazines) and instead of replacing one by one feeder you can get one set or all that removed and replaced with new magazine- work outside machine on that tray/feeder and not near machine with limited space available... My Dima used feeders cost less than 3D printed 0816 one ....    https://www.ebay.de/itm/SMT-Tape-feeders-for-Dima-Optimat-SMPM-6080/132417752069?epid=2285172926&hash=item1ed4b68c05:g:EGMAAOSwCJxaIE-f&frcectupt=true

Mike

[Mike Menci]

Jason I am a hobby user !

Mike