Solder Paste Dispenser

[ΕΥΘΥΜΙΟΣ ΚΑΡΑΜΠΑΣ]

Hello,

i would like to add the Solder Paste Functionality to OpenPnP 2.0.

First step is that i just want to read a list of pads

In board class i see 

@ElementList(required = false)
private ArrayList<BoardPad> solderPastePads = new ArrayList<>();

so i think that i should use this.

 this list is created automatically when we import a new pos file and in which function?

The public void addSolderPastePad(BoardPad pad) where is it used?

In general its my first day looking at the code and i would like some guidance from where to start.

I know this was implemented on OpenPnP 1.0.From you experience what is the optimal way to start from and how should i design the process? My first thought is to get the Array list with the pads and calculate the area. Then for each pad send the head to the pad and depending on the area size i will output a pulse or something like float value.

Thank you very much in advance!

[LeoJ]

Hello.

Is there a hidden sub text here for which the answer would yes or is our experience of PNP for completely different reasons and context,?

Thanks

--
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/d160380d-c5e5-48b4-9ac8-38073609c37dn%40googlegroups.com.

[ma...@makr.zone]

Hi vinylrider,

That would be a large endeavor!

Jason justified the removal of that functionality here:

https://github.com/openpnp/openpnp/blob/develop/CHANGES.md#2019-05-27

    BREAKING CHANGE: The Paste Dispense feature has been removed entirely. This feature is used by very few people, does not work well, and is not well maintained. Removing the feature allows OpenPnP to focus on the pick and place user experience without having to maintain backwards compatibility with paste dispense.

    A version of OpenPnP with Paste Dispense will be saved and will be made available for users to download if they need that functionality for an existing setup. That version will receive no future updates.

Then here:

https://groups.google.com/g/openpnp/c/OmZ_WVVC0Kg

    The problem is that the code is trash and doesn't work well, and it doesn't work for anyone's actual use case. So every time someone tries to use it I end up having to answer a bunch of questions and it ultimately leads to "I'll just use Gcode". So, I don't put it back up because, as I said, I don't want to support it.

    Additionally, I have really limited time to do OpenPnP stuff now so I'd rather invest the little time I have into PnP, which is what the vast majority of people want to use OpenPnP for, rather than paste dispense, which a tiny fraction of a percentage want to use it for.

    And finally, if you go back through all the threads on this, you'll see that no one has actually come up with a paste dispenser design that works very well for automated dispense, so that's another roadblock to actually using it.

    Again, I'm willing to have paste dispense in OpenPnP, but someone is going to have to make it work well before I merge it.

Then here:

https://groups.google.com/g/openpnp/c/MaFf8eQ9iGk/m/sryFu7HwBAAJ

   

    ... if someone wants to revive the feature and bring it up to the current level of the app I'm okay with that.

     Last time I tried to make it far too integrated with the PnP job running code and that is what really made it hard to maintain. A rewrite should just have it's own separate job tab, job processor interface, etc.

There was a Gerber and Eagle import for the pads, quite sophisticated. You would have to explore the old sources (master branch) and reintegrate the good parts like the Gerber import. But rewrite the JobProcessor parts. You should create a new HeadMountable sub-class for the Dispenser and then use Actuator(s) to drive the actual dispensing (modern way).

I guess you would have to commit to a universally useful implementation, including to document and help maintain it.

_Mark

[John Plocher]

That would be a large endeavor! 

    ... if someone wants to revive the feature and bring it up to the current level of the app I'm okay with that.

     Last time I tried to make it far too integrated with the PnP job running code and that is what really made it hard to maintain. A rewrite should just have it's own separate job tab, job processor interface, etc.

Some thoughts.  On a very good day these might even be worth $0.02 :-)

Interesting ideas here - go for it!  Keep in mind:

Pasting should be kept independent from Placing.  Many people use stencils and have systems that don't support an auto-paste / Dispenser feature; you don't want to add complexity in their use cases.  This seems to be where the solder paste dispense feature "failed" in the 1.0 code base - it was implemented in a "wrong" place / with a "wrong" design pattern that had undesirable side effects. (using air quotes to indicate this isn't a judgement on merit or functionality, but simply hindsight) 

This makes sense (to me) if you look at things from the operator flow perspective.  Consider these two workflows:

1)

• Get a new PCB, place in "OpenPnP machine"
  
• Run a job
• Dispense paste on the pads
• Stuff it full of components.
• Remove Stuffed board from PnP
• Reflow 
• etc...

2)

• Get a new PCB, place in "pasting place"
  
• Put solder paste on it (manually with syringe, manually with stencil, robotic stencil, run a Job on your PnP machine with a solder paste extruder, etc etc etc)
  
• remove Pasted board from pasting place / load Pasted board into PnP machine (could be a NO-OP...)
• Run a job to Stuff it full of components.
  
• Remove Stuffed board from PnP
• Reflow 
• etc...

The first one "requires" a unified paste/place implementation, the second simply "allows" one.  Conceptually, there are now 2 jobs to run sequentially, not one.

This leads to my first suggestion - don't intermingle the two processes, they are sequential by nature. 

• Independence is a win-win - Place changes don't impact Paste ones and vice-versa, yet both can be built on considerable shared infrastructure and code.
• Make the auto-paste feature a machine-configuration item - if you don't implement it on your PnP machine, the feature shouldn't show up in the operator's workflow.
  
• Make the operator's job easy, even if it means more work by the builder or coder :-)
• If the machine builder wishes to implement auto-paste, take a page from Mark's Issues/Solutions work and lead the builder thru the required setup and configuration steps (actuators/heads...)

Pasting a board feels very similar to placing a board, but it has a different set of constraints and requirements that will require significant thought and new design effort in the job processor, assuming that the required information is even available in OpenPnP...

• Placing is built on centroids and rotations that comes from a BOM/Centroid file, Pasting needs specific pad information that comes from Gerbers
  
• Gerber files have the pad location and size info in the copper layer files, but don't carry enough info to reliably connect into OpenPnP's package or component centroid/BOM data.
  
• Stencil printers control the quantity of paste by the size of the holes in (and thickness of) the stencil, and the paste grain size.  Paste dispensers need to do the same thing by controlling the size and placement of the dispensed blobs.
• Optimal Placing takes into account feeder locations, travel time optimizations and a host of component / camera package ID stuff.  Pasting, on the other hand, doesn't care about feeders, but needs to optimize the pad-visitation route, with some physics knowledge of how solder flows (staggering different sized paste blobs on IC leads to prevent bridging, paste fill ratios based on pad size and pitch, ...)

  -John