Thoughts on Panelizing Feature

[BendRocks]

Hi, I do a lot of work with arrays of smaller boards. I'm new to OpenPNP, having just learned that my TVM920 will soon have support for OpenPNP. My background is embedded RTOS and C#. I'm new to Java and Git. I usually learn best by jumping right in, and I've got a few features I need in the queue. 

My understanding is that in OpenPNP, you deal with panels by adding the same PCB to the job over and over and adjust the offsets for each. Very reasonable. But also a PITA for a panel with 16 or 32 boards. So, I've knocked up and have mostly working some UI and code that will autopanelize a board for you.

The way it works (see attachment) is you create a new board or add an existing board to a job. Two new icons have been added to the string of icons in the Job tab. These are shown in the attached. The left added icon will panelize the board based on a few obvious pieces of info. That is currently working. The right added icon will make it easy to specify any x-out options in another popup dlg. On a panel with 32 boards, it is extremely tedious to find the PCB you want to disable, and hopeless for a normal operator to do so, hence the popup.

So, the first question is whether or not folks think this might be useful as described. 

For the implementation, the code simply identifies the 0th entry in the Jobs list, does a deep copy on that object and sets the new location on the new object for each of the rows and columns. To do the deep copy, I made a copy constructor for BoardLocation (very common in C#). Java might prefer clone(), but there's seems to be a lot of debate about that. Some also advocate serialize/deserialize for deep copy. What would be the preferred way to do a deep copy on a BoardLocation instance for OpenPNP?

Thanks

[Jason von Nieda]

Hi BendRocks,

This looks really good. The copy constructor is fine. There's no real standard in Java for deep copies and I don't think I've had to do it before in OpenPnP, so whatever works for you works for me.

A few comments:

* You mentioned that it identifies the 0th entry in the list. Why not use the selected object? You can get this with getSelectedBoardLocation().

* Can you explain or screenshot the X out feature? I understand the need for it, but it's not clear how you've implemented it. 

One thing to note: If you are using a recent build, try selecting the Navigation tab. That makes it exceedingly easy to find and select boards and placements. You can just click on the one you want and it will be selected in the tables.

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/21eb7764-0a41-40c3-89e6-36fd01dcd40a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Cri S]

At least in the past, if you have a panel with 40 same boards, there is one job file and 40 different (same) board files, because if using the same board file, it don't worked well.

[Cri S]

Eventually add flip panels too.
Its a feature that is used a lot for small batch assembly because the same solder paste printer and same program work for both sides, top and bot. This saves cost on stencil, cleaning time and setup time.

[Jason von Nieda]

Hi BendRocks,

One thing I forgot to mention. There is a ticket open for this feature: https://github.com/openpnp/openpnp/issues/128

What you are developing below is a great first step, and I think it would be a great improvement to the system. Eventually I would like to support panels as a first class citizen in OpenPnP. I'd like for Panel to be an a sibling of Board so that changing the location of the panel can be done in a single step instead of having to update every board in the panel. In addition you would be able to set properties that are specific to a Panel that don't apply to a board. This would be things like panel fiducials, offsets, stepping, etc.

Anyway, none of that matters for what you are doing right now. Just something to keep in mind if the future if you decide you'd like to take this further.

Thanks,

Jason

[BendRocks]

OK, thanks Jason, I see where you are going with this. Maybe a staged approach might be:

1) Button to generate boards as described above in png. This would rely on individual board fiducials to align the boards as part of existing processing, even though it would be redundant. Once you generate the boards with the button, the system no longer has knowledge of a panel.  The button just saves you task of loading 16 boards by hand. 

2) Refine the button to have the parameters persist as part of job.xml file, including row and col count, overall offset, gap spacing, and 2 or more global fiducials. Here, clicking on the button and adjusting the params would update every board. Have you thought about how the work flow might change if there were just 2 global panel fids checked upon the start of a job? Is it a big change? This would mean that each board no longer needed a pair of fiducials to benefit from vision which would be really nice. From a UI perspective, the list of boards could remain the same, but perhaps the editing of the generated panels would be locked and you'd need to click the button again and edit params and re-generate the boards. This would support a single panel.

3) Move to nested hierarchy where you could have multiple board designs per panel, and even multiple panels per job (eg flip panels as Cri mentions). This would obviously have some large UI implications.

[Jason von Nieda]

Staged approach sounds good. I don't want to distract you from what you are doing - I think what you list below in 1) is a great addition and I'd be happy to have it in the system. I just wanted to mention the future so you'd be aware of it.

I have not given much thought to how adding global fids would change things. This feature is a little low on the priority list for me, so at the moment I'm just collecting notes on it as I go. To expand a bit, though, I'd think that the global fids would act similarly on the entire panel as they do now for a board. So, running a fid check would adjust the panel location only, and all the boards in the panel would have their offsets calculated based on that. I don't think it would be a big change.

I had not really considered having multiple board designs for panel. I'll have to give that some thought. My thinking was that a panel would be a sibling to a board and would have a single board as a property, along with rows, cols, spacing, etc. So, in that scenario, the job would effectively be a list of Board or Panel where right now it's just a list of Board. 

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/99fcb333-ace9-4c15-9b00-e7c5297caecd%40googlegroups.com.

[Cri S]

Example of panel taken from Internet.
It is a flip board and have another feature needed on several panels.
To avoid excessive bending or for clearance ussues or shape/connectors, panel have pcb rotated 180 degree.   I just wanted bring to attention this two things related to Panelization. What else, assymetrical fiducials, panel fiducials and single fiducial per pcb, here as coincidence, for other panels with more circuits and tight space its true.
Cri

[Lisandro B]

Awesome feature, thanks to you all!

[Mark Harris]

For reference, here's Altium's panellisation window:

It's quite sensible in my opinion.

Also, that board Cri linked is really terrible for manufacturing. If that board isnt just rotated,  but also mirrored (upside down) as it would look to be, its going to add to manufacturing and inspection cost a lot. Double sided BGA board is kinda awful - single sided BGA, second side being the passives/leaded chips/easy leadless is much cheaper and easier to reflow and inspect. Plus, those EMI shield outlines are going to be very expensive shields to make... Please don't get many ideas of board panelisation from that picture.

On 29 December 2016 at 08:11, 'Lisandro B' via OpenPnP <ope...@googlegroups.com> wrote:

Awesome feature,  thanks to you all!

--
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+unsubscribe@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/9d94d392-2e58-4598-90d7-76ed41e1ab92%40googlegroups.com.

[BendRocks]

I've pretty much finished. I've attached a pdf outlining how it works, and what the implications are and some areas for consideration by Jason et al. 

I've pushed it up to here https://github.com/BendRocks/openpnp/tree/AutoPanelize so that Jason et al can easily look at diffs and see where this is headed. Please let me know if you any diffs look like big headaches to you. I still have some minor cleanup to do and I'm waiting for the TVM920 support to be enabled so I can verify the panel fiducial is working. After that and your feedback, I'll re-push and then submit a pull request. 

No rush at all as the TVM920 support seems like 1-2 weeks away.

[Jason von Nieda]

Forgive brevity, I am traveling: first glance this looks really great. Will fully review when I return home Sunday night. Might take a few days to review.

Thanks,
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/328f7513-7180-4c49-9935-3e4d6debf6f9%40googlegroups.com.

[Jason von Nieda]

Hi BendRocks,

Took a look through the code and the PDF. Really solid work! Overall I am pretty happy with this. I do have minor concerns about the added complexity in JobPanel since this is already a fairly complex class, but I can't think of a great way to simplify it without making very extensive changes, so I am comfortable with just going with it for now.

I do want to raise an issue, but I want to point out before I do that I'd be perfectly happy to merge the code as it is and you don't *have* to do what I am about to suggest. I just want to bring it up so we've considered it:

I'm curious as to why you've created the limitation of only having a one panel in the job. I am wondering if that limitation could be lifted simply by adding a flag to BoardLocation that indicates that it represents a panel, and then having the associated panel BoardLocations have a flag indicating which one controls the panel. I think that overall everything else would work basically the same as you've implemented it. This would also make it possible to avoid the "magic" first row, and MAX_INTEGER stuff that restricts editing, since it could just check the flag on BoardLocation.

Just something to think about; no action required on your part.

One other thing I just noticed: I did not notice any modifications to ReferencePnpJobProcessor to handle panel fids on job start. Do you intend to add that, or did I miss something?

Jason

[BendRocks]

Thanks very much for the constructive comments. 

Just to clarify, are you thinking there could be an added column that would signify "is Panel" to the user? And if they clicked that on, then the "create panel" dlg opens and when they click it off then the derived panels went away? That could eliminate the panelize icon, and then the xout dlg would only appear. I definitely see your point about pushing the panel info into the boardlocation class and the benefits there and thus avoiding the special handling. 

I've not been able to run OpenPNP on my TVM920, so much of what I'm doing is without having been through the workflow even once outside of demo mode. But I was thinking that panel fiducial check is a one-time thing. You do it at the start of the panel and then never again until you load a new panel. I saw that there was the fiducial check button for a board and mimicked that. Can you explain a bit more how the board fid check compares to the fid check the in the job processor? I also saw a comment from you earlier in another thread that indicated you didn't like that logic being tinkered with too often unless it's for a really good reason. So, that made my rationale a bit easier too.

[Jason von Nieda]

I was thinking that it would work something like this:

1. Add a board to the job.

2. Select a board in the job. The panelize button becomes enabled.

3. Click the panelize button which opens the panelize dialog and set the panel properties. 

4. The panelize dialog adds the "child" boards to the job.

5. You can edit the panel properties by selecting any board in the panel (the "master" or any of the children) and click the panelize button. Since we can identify any board as the "master" board, a "child" board or a non panel board you can choose the right board to edit the actual properties. So, in other words, if you have created a panel, then selected a child and hit the panelize button the action would actually edit the master panel button rather than the child.

In the config, we'd add the panel pcb settings as an element of board-location, and we'd include a unique ID or something so that if the user is working with a child board we can reference it to find the master board for that panel.

There would be no need for additional columns, since all the logic that determines if a board is a panel master or child can be handled quietly behind the scenes. 

I do want to reiterate though that I think what you have already done is a great feature and I'd be happy to merge it completely as is. I only bring this other stuff up to spur conversation and additional thinking about this feature for the future.

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f9e18da6-4690-4ade-af89-d090542e1c8a%40googlegroups.com.

[SMdude]

HI Bendrocks,

Thanks for the work you are putting into the panellise feature. What you have done looks really nice. I look forward to giving it a run soon..

Cheers

[Michael Anton]

Have you given any thought to how you might populate only a portion of the panel?  Sometimes there are bad boards in the panel, and one normally doesn't populate the bad boards, so having a method to skip bad boards is a nice thing to have.

Mike

[BendRocks]

OK, this is very clear and indeed an improvement. I don't think there's a rush here and I'll aim to make the tweaks after some biz travel

[BendRocks]

Yes, there's the ability to x-out bad PCB in a panel. 

[Jason von Nieda]

Hi BendRocks,

Just wanted to check in and see if you had gotten around to finishing this feature? If not, would you like me to finish it up? It would be a shame for something to come so far along and not end up getting merged in.

Thanks,

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/6dcac301-b926-450d-881c-386955b769a0%40googlegroups.com.

[BendRocks]

Hi Jason, 

I've been waiting until I had my TVM920 working so that I could get the panel fiducial check working in the code you reviewed. And I'm close. First I had the video problems, and then I decided that rather than use Glenn English's solid work on the TVM920 driver, I wanted something that didn't need the intermediate control program and that was fully integrated in with the TVM. And I'm close on that too. 

So, while you are welcome to finish it up, it is my top priority once I have the TVM920 motion driver finished as I need the functionality for my first TVM920 placement on OpenPNP. I'd guess one more week. 

[Jason von Nieda]

Okay, great to hear that! Very excited to see how it turns out!

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4d2eadbc-52a4-499e-b867-7110523861b9%40googlegroups.com.

[BendRocks]

Hi Jason, I re-syncd with the latest develop branch and cleaned things up after verifying the panel fiducials work and submitted a pull request. Recall there's a fairly detailed pdf above on how the feature works. Since that PDF was done, I've also added the ability to specify panel fiducial size in the panelization dialog. 

You'll see some places in the code where some strange things were done to manage the panel fiducials. To those reviewing, panel fiducials aren't in BOMs. They are usually manually placed on the panel (not part of schematic) and thus aren't part of a BOM. Board fiducials are, however. So there is a conceptual difference to keep in mind.

In the panel setup, you indicate the XY location of these panel fids, board spacing as well as the size of the fiducial and everything is handled from there. No parts to create, no symbols to create. 

Jason, above on Jan 2 we had discussed an alternate way of doing the last 10 or 20%, but that you'd be happy to take it as is (after normal reviews, of course). Due to time and other things that I need to get done to actually make my machine useful to me, I need to take you up on the offer to add at this stage and I can aim to revisit down the road, or others can improve too. 

BTW, I have been using the imagecamera for testing. What an awesome part of OpenPNP. I am really seeing a path to getting a board completely ready for build at my desk and heading out to the shop and having it "just work" on first go. 

[Cri S]

Why not step and repeat automatic mode.
The machine know the alignment of PCB after fiducial check and know the PCB size.
Checking above and right at PCB size offset corrected by board angle+1mm, if it finds fiducial, and second fiducial is present, it could assume that PCB is valid.
Further this don't. Require board copy, it is as the board is made again.
Further if first fiducial is found and second fiducial not bad board is assumed.
Just tape over with non transparent tape or round stickers the second fidicial if this board have defects.
After it have discovered the size, update Z inside fiducial offsets for x.y repetition in order the scan is done only once.

[Jason von Nieda]

Thanks Matt, glad to see this! I'll pull the code down and take a look through the feature in the next couple days. Over the weekend, most likely. I have some trepidation about the fiducials since it sounds like there may be a special case being added, but I'll see what it looks like.

I am very keen to get this feature merged, so if some changes are made I'll go ahead and do that and get it in.

Thanks for all your hard work on this!

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/d43cecce-d726-4726-8126-f8cdfe7e47ba%40googlegroups.com.

[Cri S]

Fiducial normally are inside BOM. example:
https://www.adafruit.com/products/2378
Inside Schematic this are placed inside Description label box.
The components are JP5 and JP8 and package is FIDUCIAL.

>> <https://groups.google.com/d/msgid/openpnp/d43cecce-d726-4726-8126-f8cdfe7e47ba%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .

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

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "OpenPnP" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/openpnp/_ni0LK8LR8g/unsubscribe.
> To unsubscribe from this group and all its topics, 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%2BQw0jxZ7fouseZ1XZGcES5JHVqBX8bEoJz13phYK6CAppBUiQ%40mail.gmail.com.

[BendRocks]

Those are PCB fiducials, and yes, they are in the BOM. I'm talking about PANEL fiducials. PCB fiducials are on every board in a panel. PANEL fiducials aren't on any of the individual boards and are instead usually at the corner of a panel.  

In the attached, you can see a panel. There are several features that are created directly in the PCB layout software and not part of the schematic BOM. Those are indicated by white arrows. The red arrows indicate the PCB fiducials, which obviously are part of the BOM. 

[Cri S]

For fiducial, there are two distict functionallity working slight differently. The fiducial Button above the Job Panel Table and the fiducial functionallity inside assembly function.
I name it gui and assembly fiducial below.
It is important that the gui fiducial function have the similar behavior as the assembly fiducial function, ie. if panel fiducial is supported, do panel fiducial and then do single pcb fiducial updating the values
that one can check it. This is especially important where only panel fiducial are present.
What i suggest is to add on the list of PLACE or FIDUCIAL the FID-GLOB or FID_PANEL or whatever name you'r prefer.
FID_PANEL is always relative to first board, and after having aquired it, use it globally.
Inside boardLocationFiducialOverrides just insert the resulting relative, not absolute values with NULL as key inside that hash table.
Clearly i'm biased to that solution because i use them, but you should be avare of gui/assembly functional difference and not to be too different or that the differences are not difficult to undertood.
below is my actual implementation description for that that are interested in that.

I use the houghCircles function from OpenCvUtils.java or if part have picture the templatematch function. Someone have done a pull request of that after i have send him the code.
Further if there is only one fiducial, it is copied as second fiducial and updating only x/y and not rotation. This is a personal choice of prefering that approach.
Step and repeat,  example board foobar, if named foobar@@3:2 this means X3Y2 repeation, repeat is always board width/height+2mm, the fiducial recognition bridge the difference.
foobar@@3:2:0 means, it have started assembly the board 0, foobar@@3:2:5 means, it assembly the last board. foobar@@3:2_ or board#1_ means, assembly finished.
If fiducial don't bride the difference as example if 3.33mm is the difference and no board fiducial, then @@3.0333:2.0333 have to be used, values alway in mm , ie gap div 100 .
It works well with or without panel fiducials and allows having mixed panel assemby too. Previously i have used scripting.
I know, this is different from clicking wizard thing the mayority of you want.

I use the list with fiducials/place list a bit different, Jason maby remember that, and if part begin with FIDn it is a fiducial, FIDn-partid is part specific fiducials,
where n is 1 and optional 2, FIDn are the board fiducials, where FID0 is the bad fiducial je if present then the board are not to assembly, 1-4 are the fiducial to use.
Instead FID-n are Panel fiducials and stored into key null inside. If FID1 is not present and FID0 yes, FID1 is FID0. If 3 FID are used, the result of the 3 FIDS are
averaged, FID1/2 and FID2/3 and FID1/3 , if 4 FIDS are used, FID1/3 and FID2/3 are averaged. If no FIDn or FID-n is present the openpnp algorithm is used that
searches the most distants parts that begins with FID.
I use the list a bit different, Jason know that, and if part begin with FID it is a fiducial, FIDn-partid is part specific fiducials,
where n is 1 and optional 2, FIDn are the board fiducials, where FID0 is the bad fiducial je if present then the board are not to assembly, 1-4 are the fiducial to use.
Instead FID-n are Panel fiducials and stored into key null inside boardLocationFiducialOverrides .

Fiducial can be of 3 Types, template match (sticker in case of bad fiducial) , part size giving min,max of hough-circle, or part height giving color index and the color is segmented and searched.
In addition to colored colors, -0 is white and value < -0 is black. The above order is the priority , ie if picture is present, that is used. if part size is both 0, only then color is checked.
Fiducial code return size of fiducial found in rotation  value for houghcircle, negative color pixel size for color match and NdN for image image type.
On FID0 or FID-0, if fiducial is color type, board is skipped if found, otherwise board is skipped if fiducial not found.
---------------------------------------------------


 

[BendRocks]

>> What i suggest is to add on the list of PLACE or FIDUCIAL the FID-GLOB or FID_PANEL or whatever name you'r prefer.

FID_PANEL is always relative to first board, and after having aquired it, use it globally. <<

Thanks for the detailed note. If I understand correctly, this requires the user to remember a magic name and it requires entering information about the panel in two places: The panel specification dlg and the placements list. 

And, not only do you require the user to remember a special name, you require the user to remember a special rule (global fiducials are relative to PCB 0) and then mentally they need to filter out strange placements that they'll see where a part has a location of X=-50.6mm and Y=-70.23mm

I guess my question is this: Why would the user NOT want to enter all this panel information (number rows, cols, x and y gap, and global fid location, etc) into a single location? Why spread it out?

[Cri S]

No, i'm refering to add this:
public class Placement extends AbstractModelObject implements Identifiable {
    public enum Type {
        Place, Fiducial, Fid_Panel, Ignore
    }

I use pcb instead of board, because on source, board is a well known class. pcb is just the single board, panelized or not.
On gui panel fiducial check action, travel trought all pcb ignoring check fiducial settings, make a list of Fid_Panel , find out the most distants, perform fiducial recognition
if at least two fid_panel are present otherwise exit premature.
Now for every pcb :
  calc placement position of the two fid_panel locations relative to local pcb, making reverse/forward mapping of it's location.
  update pcb location appling the correction using calculateBoardLocation

Automatic assembly could call that action first.

As this feature is more Step and Repeat and for panel it is really a lot penalizing, it is debatable if naming it SR instead of Panel.
If openpnp in future don't have more advanced panelizing options, because this in enought for 98% of users, naming it panel is fine
and in this case the special panel fiducial code handling be justified.

Just to know, because i have not checked it out further and you can answer it without problems.
It  works if pcb don't have fiducials, only panel fiducials are present ?
It is works if not panel fiducials are present and pcb have it's own fiducials ?

Maybe it is worth adding a option to use only panel fiducials , or the two most distant pcb fiducials from whole panel when no panel fiducial are present and setting the fiducials to ignore.
This can speedup tact time when the precision is enought using only the panel fiducials.

Speaking from tact time, adding a iterate number for fiducial could make sense on machine wizard.
Actually there are 3 attempts to locate fiducials with extended camera settle time.
I have seen, the extended settle time was removed on actual code.
This works fine if camera is not calibrated and settle time is not set accurate or camera mount is not that stable.
If camera is calibrated, only 2 attempts are necessary, if using panel fiducials, the required attempts with calibrated camera is a 1.

If it's worth, of ir it cause more troubles creating excessive support, i don't know.

[BendRocks]

> It  works if pcb don't have fiducials, only panel fiducials are present ?
> It is works if not panel fiducials are present and pcb have it's own fiducials ?

Yes, it works just like before. If you have no fiducials (panel or board) it is exact same work flow.

if you have only PCB fids, it is exactly same workflow. 

if you have PCB fids and panel fids, after you specify panel fids in panel dlg, then it's the exact same work flow, although there's not much benefit to using PCB fids if you have panel fids unless your machine has really bad accuracy.

If you have just panel fids, then you specify panel details in panel fids dlg, along the panel, and then all PCB are automatically adjusted for you.

If someone is only using PCB fids, then nothing changes.

[Thomas Langås]

On Mar 4, 2017 18:29, "BendRocks" <mwtse...@gmail.com> wrote:

if you have PCB fids and panel fids, after you specify panel fids in panel dlg, then it's the exact same work flow, although there's not much benefit to using PCB fids if you have panel fids unless your machine has really bad accuracy.

This far from true. Professional assembly houses prefer at least one pcb fid, or panel fids really close to the pcb when dealing with various configurations. Last time I was told to do this with my pcb/panel because of panel size vs pcb size (48 25x27 pcbs in one panel). It's all about removing math errors when mapping over distances.