jspcb parses Eagle BRD files

[Karl]

After poring over Douglas' OpenPnP Eagle library, I was inspired to try my hand at a parallel effort in

Javascript to bring PCB board parsing to firenodejs, etc.

https://github.com/firepick/jspcb

FirePaste needs a way to determine where to put the solder paste and jspcb will provide that information.

I'm using the AdaFruit PCB ruler as my test case for FirePaste in jspcb. 

Eventually I will add Kicad support for handling, for example, Jacob's new FireMC board.

jspcb currently supports a subset of Eagle BRD: SMD, holes, wires and text. This should be enough for FirePaste

now, but if folks have other needs, I may be able to explore those as well.

[Rich Obermeyer]

Are you using the solder paste file to parse or are you just using the top and bottom gerbers and generating from there?

Since I do not have and will never have Eagle layout, using the Solder Paste file would be better for me.  Writing tools in Eagle scripts or based on Eagle based tools is not a good solution.

--
You received this message because you are subscribed to the Google Groups "FirePick" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firepick+unsubscribe@googlegroups.com.
To post to this group, send email to fire...@googlegroups.com.
Visit this group at https://groups.google.com/group/firepick.
For more options, visit https://groups.google.com/d/optout.

--

Rich

[Karl]

Rich,

It should be possible to read in Gerbers. I'll take a look at that.

I am not partial to Eagle, it's just that I like the AdaFruit PCB ruler, which uses Eagle BRD.

Since XML has a lot of information in it, it has potential utility for future projects, such as

verifying trace connectivity. I'm also exploring vision recognition of the PCB, and for that I

need all the information, such as silkscreen, etc., which are normally in separate Gerbers.

If you attach your favorite Gerber file, I'll be happy to use that as a test case

for jspcb Gerber processing.

:D Karl

[Rich Obermeyer]

Karl,

My point was if you use the file the tools generate for this purpose then it might make more sense later rather than doing it in a none standard way up front.  Your post is the second one this week where somebody is writing tool specific code to generate paste mask function for openpnp.  I would think writing code that can use the existing standard paste mask would be much more useful by everyone. IMHO.

I think you will find out the guys (or gals) that invented Gerber kept it very simple. Its just as easy to parse as XML and not vendor specific.  XML designs are great but everybody uses it differently.

Jason indicates he can already read in Gerber files in openpnp.

Altium can generate the correct file for a solder paste even if Eagle doesn't just from the BRD file.

Here is an Altium version of the AdaFruit Ruler with solder paste mask.

See if you can use that paste mask :-)

Thx, Rich

[Douglas Pearless]

Actually, using Gerbers is a problem as they do not contain any part information; is is a major pain to have to manually define all the parts for OpenPnP to be able to do anything useful.

Gerbers are good to make PCBs, not good to populate them.

The two options really are KiCAD or Eagle as their board files contain everything needed to process a board, which is why I wrote the Eagle BRD interpreter for OpenPnP, it is designed so you simply land a BRD file and everything is done automatically for you.

Just my opinion :-)

Cheers

Douglas

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

[Rich Obermeyer]

Douglas,

As I already explained. If the user does not have KiCad or Eagle then your interpreter is useless.  If it used Gerber it would work for everybody.

Using board files is non standard and unusable if you don't have that package.  The better tools can generate pretty much anything you want.  Why not support as many as possible?

[Douglas Pearless]

Hi Rich,

I agree with the requirement to cater for users who do not user KiCAD or Eagle, I was wondering what other programs do people use and how hard is it to generate an importer for those programs?

Having such a feature makes it very easy to set up jobs.

Cheers

Douglas 

[Michael Anton]

Every PCB tool I've ever used has some method of generating a report for the locations, and rotations of the components.  Often these are even customizable, so you can tailor the output.  Usually these are just text files which are pretty easy to massage into a format that the import tool can understand.  I'd be surprised, if KiCAD, and Eagle didn't also support this sort of export.  It always seems a bit odd to me to support a particular vendor's board format directly (which may change across software versions), rather than using the existing export utilities that were designed for this purpose.

Mike

Douglas 

To unsubscribe from this group and stop receiving emails from it, send an email to firepick+u...@googlegroups.com.
To post to this group, send email to fire...@googlegroups.com.
Visit this group at https://groups.google.com/group/firepick.
For more options, visit https://groups.google.com/d/optout.

--

Rich

--
You received this message because you are subscribed to the Google Groups "FirePick" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firepick+u...@googlegroups.com.
To post to this group, send email to fire...@googlegroups.com.
Visit this group at https://groups.google.com/group/firepick.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "FirePick" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firepick+u...@googlegroups.com.
To post to this group, send email to fire...@googlegroups.com.
Visit this group at https://groups.google.com/group/firepick.
For more options, visit https://groups.google.com/d/optout.

[Rich Obermeyer]

Hi Douglas,

Why do you need part information for paste?

Are you putting paste down for each part separately?

I would think you would parse the paste file and place the paste down line by line to the end unrelated to what it's for.

Rich

[Douglas Pearless]

Perhaps I wasn’t very clear, my design goal is that OpenPnP + Firepick opens a file (e.g. Eagle BRD file), the user decides which parts are being placed and where they are (reels, strips, etc), and then the Firepick loads the paste tool and pastes the pads for the parts that selected, then it unloads the paste tool and loads the PnP tool and proceeds to place all the parts; all done  :-)

[Michael Anton]

The commercial machine I run does this all from the component location report.  It has a library of paste patterns that match those on the board, so it knows how to paste the component lands, and can then do this selectively on a component basis.  This is more work, as the library has to exist, but universal then for generic location report input.

I have a custom piece of software that then takes this paste library, a list of feeders in .CSV format, a component location report, and a library of component sizes, which it uses to create the actual machine files.  This is done offline from the machine, and has the advantage of being able to work around some of the machine limitations in the process.

Douglas 

--

Rich

[Douglas Pearless]

Hi Anton,

Thats rather interesting, I have no experience with real PnP machines at all :-)

I am approaching this from a software engineering perspective where I would ideally have a library of all parts to be used and where they are on the machine so the software should be able to manage everything else for the user, once they have decided what parts are to be pasted and placed.

[Karl]

I have been looking at the Gerber extended format spec: 

https://www.ucamco.com/files/downloads/file/81/the_gerber_file_format_specification.pdf

This is a rather large document that points out the simplicity and limitations of gerber.

A solder pad is created by D03 command, which is a "flash" that creates an image 

of an "aperture" (e.g,, standard circle or standard rectangle or custom region) on the PCB layer. 

This means that a flash of a rectangle aperture on the solder mask would imply that 

"solder paste should go here" and such a file would presumably be used to create a solder paste stencil.

The AdaFruit ruler presents a very interesting case to consider. The SMD pads are clearly intended for

solder. However, the ruler tick marks are not--the tick marks are decorative and non-functional from an 

electronic perspective. We don't want to paste the ruler tick marks. The Eagle BRD does a great job of

identifying the "pastables" as <smd> xml elements while using <rectangle> for the tick marks. In Gerber

files, BOTH of these copper areas are created by D03 flash commands of a rectangular aperture.

The one thing that saves us from hair-pulling is that there should (?) be a Gerber file for the solder mask

which only contains the smd pads and not the tick marks.

I'm therefore inclined to treat indvidual Gerber files as layers that jspcb can aggregate into an svg file or

whatever. I hope I can rely on the Extended Gerber annotational metadata that identifies the functional

use of a file.

Anyhow, that's my proposed direction. Holler if the above is unexpected...

(and thanks for the ZIP file!)

[Douglas Pearless]

You may want to review the existing Gerber support in OpenPnP as that might save you a lot of time :-)

[Karl]

That would be (groan) Rs274xParser.java.  :D

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

[Douglas Pearless]

:-)

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

[Rich Obermeyer]

Karl,

By the way Altium also supports Gerber X2 extension for at least a few years so most current users will have it.  That adds some extra metadata you might be interested in, including pad functions.

[Michael Anton]

Normally one just creates a gerber file for the paste layer, at least when creating a stencil.  Regardless of how the objects are drawn (they could be flashes, or draw commands, depending on pad shape, and software used to generate the file), they would be considered to have paste on them.  I don't think you need to make this too smart if you are going to use gerber files.  I've attached a paste file for one of my designs from P-CAD.  It likely will contain multiple drawing types, as I know there are some odd shaped pads in this design.  You can find the design that this relates to here: http://manton.ca/open:bldc-motor-driver.

If you want to be smart, the paste library that maps a component type to a paste pattern is probably the most generic, and could support any CAD software quite easily.  Then the driving file is just the component location file, the part dimensions, and paste patterns are pulled from the library based on a match pattern, like component value.  The only problem with this method, is you need to generate the lookup libraries, and the only one that is new, is the one for the paste patterns.  These can be pretty easy to create though.

Mike

[Karl]

Rich/Michael,

Thanks for all the Gerber examples!

I have added them to the jspcb project as test examples:

https://github.com/firepick/jspcb/tree/master/gerber

Based on your recommendations, I think I'll just worry about the GTP files, since

that seems to match what I needed from the Eagle BRD.  I might eventually look at

the silkscreen gerbers for PCB image template generation. I know OpenPnP uses

fiducials, but I am curious to see if we can autogenerate OpenCV PCB image

templates to find our boards with FireSight. However, first I'll see if it is possible

to generate matching templates from the solder paste layer...

But first, time to look at parsing GTP files.

Wheeee!!!

[Rich Obermeyer]

Karl,

Don't forget about potential bottom paste layer on 2 sided boards.

[Rich Obermeyer]

Jason,

In openPNP how do you know a fiducial exists?

A component with a specific name?

On Oct 15, 2016, at 6:58 AM, Karl <ka...@firepick.org> wrote:

[Karl]

I will allow you to specify any number of gerber files. I will even allow you to include eagle brd file for same pcb. Jspcb will use what it needs from all the inputs.

E.g. jspcb --gtp foo.GTP -o svg

[Michael Anton]

I predict you will find this difficult to do, and here is why:  :-)

1. There can be quite a bit of error between the ideal position of the ident layer relative to the pads, and the actual location.
2. Solder paste on the pads will affect the position of the pads, and distort them quite a bit.  You don't want to align to where the paste is, you want to align to the pads underneath.  This would be the case if someone was stenciling paste.
3. There will likely be other pads on the board that do not show up in the paste files.  Fiducials are one example, but it is not uncommon to have others as well.

Why don't you instead try to locate all of the fiducials?  These are meant for optical recognition, and are at known locations relative to each other.  As long as there were always 3 on the board, it should be possible to locate the orientation of the board.

Mike

[Michael Anton]

They are treated as a component on the board.  When I do a PCB layout, I have a fiducial part that is placed, so that the locations get put into the component location report, that way the PnP machine knows where they are.  The process is the same for OpenPnP from the limited playing that I've done with it.  I could never figure out how to get it to scan fiducials (and I didn't spend any time on trying to get it to work), but they did show up in the job.

[Jason von Nieda]

Hi all,

Here's some info on this subject based on what I've learned while working on OpenPnP:

The data you need to pick and place a board and paste a board is completely different. No one tries to relate them, and there is no good reason to. For paste you need the paste layer(s) Gerbers as these define the exact shapes that were marked for paste. For pick and place you need, at a minimum, centroids (X, Y centers), side, rotation and part identifiers. Many pick and place shops just accept this as a CSV with the columns identified very simply.

Centroids are not used for paste, and Gerbers are not used for pick and place.

In OpenPnP, the board data file contains information able paste pads and pick and place centroid locations. To use OpenPnP for either of these tasks you need to get that data in. There's several ways to do it and they do not have to match for a given board. You can import the pick and place data as CSV, Eagle export, KiCad export and others. You can import the paste data from a Gerber. Since these are separate files, you typically have to import more than one file to get both the pick and place and paste data.

The benefit of Douglas' direct Eagle .brd importer is that since the .brd contains all of the data already we can fill out the entire data structure without requiring multiple files. This just saves you a step or two if you happen to have an Eagle file. An Eagle file is not required - it's just one of the several ways to import the data.

As for Gerbers and standards, that's the great thing about standards... there are so many of them :) Yes, there is a standard. Very few of the vendors that output Gerbers follow it to the letter. Your parser has to be hardened based on real world data. The OpenPnP one has had this done. I collected sample Gerbers from many different packages, users and versions of software and worked on the parser until it could import them all. There are still a few mnemonics I don't handle, but all the files parse without error and I generate shapes for something like 98% of the mnemonics encountered.

There was also a question about fiducials. Typically they are included in the centroid (pick and place) data and are given an easy to identify name, like FIDn. It's up to the PnP operator to mark them as fids and define their shape. There is documentation on how this is done in OpenPnP at https://github.com/openpnp/openpnp/wiki/Fiducials

Finally, a note on paste patterns: During the design of the solder paste code in OpenPnP, we discussed doing paste based on patterns or known packages. After polling a bunch of EEs we determined this was a bad idea. Many engineers use paste in different ways based on company guidelines, tribal knowledge or personal preference. One EE might want their paste 10% smaller than the pads and another might want it 10% bigger. Sometimes you want paste for a ground pad, sometimes you don't. The Gerber paste layer already contains all this information, so it's the correct way to go for generating the paste data.

Jason

[Rich Obermeyer]

Jason,

Do you expect users to partially place parts on the board with only paste for those partial parts?

[Jason von Nieda]

You can individually enable and disable placements and pastes, so yes, that is supported.

Jason

You received this message because you are subscribed to a topic in the Google Groups "FirePick" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/firepick/vL33HqT2XHk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to firepick+u...@googlegroups.com.

[Karl]

Jason, thanks for all the guidance and especially the caution on the looseness of "standard gerber implementations". I'll happily follow in your footsteps. :D

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

To post to this group, send email to fire...@googlegroups.com.
Visit this group at https://groups.google.com/group/firepick.
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 "FirePick" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/firepick/vL33HqT2XHk/unsubscribe.

To unsubscribe from this group and all its topics, send an email to firepick+unsubscribe@googlegroups.com.

[Michael Anton]

Comments are inline.

On Saturday, October 15, 2016 at 6:38:15 PM UTC-6, Jason von Nieda wrote:

Hi all,

Here's some info on this subject based on what I've learned while working on OpenPnP:

The data you need to pick and place a board and paste a board is completely different. No one tries to relate them, and there is no good reason to. For paste you need the paste layer(s) Gerbers as these define the exact shapes that were marked for paste. For pick and place you need, at a minimum, centroids (X, Y centers), side, rotation and part identifiers. Many pick and place shops just accept this as a CSV with the columns identified very simply.

The main reason to relate the two would be for partial population.  You many not want to paste everything if you are not populating all of the components.  That's why the ECM machine I use uses a library of patterns for dispensing paste.  Then all you need is the centroid file, and it can skip pasting for some parts if they will not be populated.  Once you get the library set up for the parts you use, it is a piece of cake to set up for a new job, and no gerber import is required.

Centroids are not used for paste, and Gerbers are not used for pick and place.

In OpenPnP, the board data file contains information able paste pads and pick and place centroid locations. To use OpenPnP for either of these tasks you need to get that data in. There's several ways to do it and they do not have to match for a given board. You can import the pick and place data as CSV, Eagle export, KiCad export and others. You can import the paste data from a Gerber. Since these are separate files, you typically have to import more than one file to get both the pick and place and paste data.

The benefit of Douglas' direct Eagle .brd importer is that since the .brd contains all of the data already we can fill out the entire data structure without requiring multiple files. This just saves you a step or two if you happen to have an Eagle file. An Eagle file is not required - it's just one of the several ways to import the data.

It also gives you the ability to relate the paste data to a given component, which would be difficult to do if using centroid data, and gerbers.

 

As for Gerbers and standards, that's the great thing about standards... there are so many of them :) Yes, there is a standard. Very few of the vendors that output Gerbers follow it to the letter. Your parser has to be hardened based on real world data. The OpenPnP one has had this done. I collected sample Gerbers from many different packages, users and versions of software and worked on the parser until it could import them all. There are still a few mnemonics I don't handle, but all the files parse without error and I generate shapes for something like 98% of the mnemonics encountered.

I'd be a bit surprised if all of them don't follow some subset of the standard.  There are many ways to output the data to get the same output pattern.  The gerber editor I use, which is very old, has never choked on anything I've thrown at it, and I've used outputs from a number of different tools.

 

There was also a question about fiducials. Typically they are included in the centroid (pick and place) data and are given an easy to identify name, like FIDn. It's up to the PnP operator to mark them as fids and define their shape. There is documentation on how this is done in OpenPnP at https://github.com/openpnp/openpnp/wiki/Fiducials

Finally, a note on paste patterns: During the design of the solder paste code in OpenPnP, we discussed doing paste based on patterns or known packages. After polling a bunch of EEs we determined this was a bad idea. Many engineers use paste in different ways based on company guidelines, tribal knowledge or personal preference. One EE might want their paste 10% smaller than the pads and another might want it 10% bigger. Sometimes you want paste for a ground pad, sometimes you don't. The Gerber paste layer already contains all this information, so it's the correct way to go for generating the paste data.

Not necessarily the best way to go for dispensing however, unless you can accurately cover the pad like a stencil would.  You may actually want to place dots in a different location than the center of the pad for instance.  Also, how are large pads handled?  Multiple dots may be better than one big one.  The library method would allow all of these to be dealt with easily, but then you have to create the pattern library, but to me this is not much different than creating a library of parts for layout.

[Jason von Nieda]

The main reason to relate the two would be for partial population.  You many not want to paste everything if you are not populating all of the components.  That's why the ECM machine I use uses a library of patterns for dispensing paste.  Then all you need is the centroid file, and it can skip pasting for some parts if they will not be populated.  Once you get the library set up for the parts you use, it is a piece of cake to set up for a new job, and no gerber import is required.

True, there is value in being able to relate the paste data to the placement data. OpenPnP doesn't currently link them but we did discuss methods to do this when the data is imported as separate files. 

Not necessarily the best way to go for dispensing however, unless you can accurately cover the pad like a stencil would.  You may actually want to place dots in a different location than the center of the pad for instance.  Also, how are large pads handled?  Multiple dots may be better than one big one.  The library method would allow all of these to be dealt with easily, but then you have to create the pattern library, but to me this is not much different than creating a library of parts for layout.

The data is separate from the method in which it's processed. The output of the OpenPnP Gerber parser is basically a bunch of 2D shapes with X, Y coordinates. Processing those shapes into a dispensing pattern is up to another piece of (swappable) code. Currently we just put a single dot at the center of the shape.  The code is designed so that we can plug more advanced paste strategies in once people want that. To date, there has not been a whole lot of interest in dispensing.

Jason

[Douglas Pearless]

Reply inline

I am very interested in dispensing, but I am tied up on the Smoothie2 project at the moment, when I have completed that and some other coding, then I will be coming back to OpenPnP

Jason

[Karl]

OK. I am able to read the ruler GTP gerber file (attached is the SVG output from that).

But it raises some nasty questions that scurry around in the dark when you look a little deeper...

1) the board dimensions are NOT in the GTP file. They are, in fact, in the Protel GKO file, which is very very improper, because that is a keepout file. Indeed, there seems to be no Gerber standard here

2) the board origin in the GTP file is (1,1), which is rather arbitrary and strange (the GKO implies this location in an obtuse way)

3) MIchael's BLDCV1 file also uses regions in the GTP file. That's pretty esoteric. What's my solder paste syringe supposed to do with a region? Very disconcerting...

WDYT?

[Douglas Pearless]

Hi Karl,

You are now tripping over the issues that I fell into before I gave up on Gerbers (no proper standards that everyone adheres to) and went and wrote the Eagle .brd file importer and interpreter (and hope the others write these for their favourite PCB design program); it took me about a week to do that.

Suggest you look at the OpenPnP Gerber import routines, and be prepared to write all sorts of exception routines to handle how every PCB program software designer's interpretation of how they can bend Gerber files to their own ends… :-(

Cheers

Douglas

--
You received this message because you are subscribed to the Google Groups "FirePick" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firepick+u...@googlegroups.com.
To post to this group, send email to fire...@googlegroups.com.
Visit this group at https://groups.google.com/group/firepick.
For more options, visit https://groups.google.com/d/optout.

<gtp-ruler-svg.png>

[Michael Anton]

Gerber files describe line artwork and for that purpose, they work very well.  There is no standard that determines how one must output said artwork, and what commands should be used for a given purpose.  As such, it may be difficult to determine exactly what is a pad.  In the case of solder paste artwork, they are all pads, regardless of the method used to draw them.  The artwork I supplied was picked because it has a polygon pad in it, and as such would be different than others, as it is a difficult pad shape to represent (my knife cutter really didn't like that one).  Other mechanical info is usually not included in the paste layer.  The board outline for instance would make no sense, as the stencil would end up with a big hole in it.  :-)  So, if you need to overall dimensions of the PCB, you have to get this elsewhere.

Probably you would have to figure out how to render the entire gerber file, determine where the locations of the various shaped blobs are (they probably don't have to be contiguous in the file, even if they likely are), their sizes and areas.  Then you would have the info required to finally generate your paste output.

Origins usually come from wherever the layout person locates the board in the workspace.  I always use (1,1) in inches for my layouts, so it is easy to deal with the offsets when generating the PnP report.  Starting at (0,0) is not a good idea in most packages, as often they do not support negative coordinates, which can occur if there is a part that hangs off the edge of the board.

About 3 decades ago, I wrote a program to take a Gerber file, and render it on a dot matrix impact printer.  I used this to print layouts at about 4X size, taped the pages together, and then had them shot on a large process camera to get a scale size negative, which I then used to fabricate the boards.  Back then the Gerber format was probably much simpler, as I didn't even have to support embedded apertures.

Mike

[Rich Obermeyer]

Karl,

Altium has always used the keepout layer to define the board size and location on the Gerber window.   During Gerber generation that is required to build boards.  I wouldn't call it an exception but the way board houses have always built boards.  They apply the keepout to each layer to mask out any unwanted extra stuff designers put there. 

So think of that as your reference layer.  That layer tells you where zero is.  Since each tool vendor may take a different approach to generating Gerbers, you just need to know what was assumed for that tool.

Did you see any difference from the Altium version of the ruler and the Eagle version?  I have a contact at Altium that would like to know about any Eagle translation issues or concerns.  They do fix any issues reported.

Since Altium database in not ASCII or readable text it's unlikely you will find anybody bold enough to decode the compressed image similar to what was done for Eagle.  Altium can be saved in another ascii format for debug but the files are huge.  Not sure if any data is lost in the operation.

[Karl]

Rich, the Eagle Dimension layer was what I used for the original ruler, which was (0,0) origin. The Altium code arbitrarily moved that origin to (1,1), which took me by surprise. Now that I know how Altium works, I believe that I can write specific code for handling the GKO Gerber, which works much like the Eagle layer 20 and allows for non-rectangular board outlines. I do think the Altium repositioning of the origin is a bit of a bug since it violates the Eagle semantics. I can work around it since the generated Gerbers are self-consistent. Perhaps the bug is in the Altium Eagle importer?

Michael, thanks for the polygonal pad explanation. I will summon the energy to slog through that nasty mess that is Gerber macros, although I cannot promise a quick turnaround. The semantics for solder paste syringe dispensing and macro regions precipitate a whole slew of issues to support area paste vs. point-blob paste. Although we will probably aspire to solder paste art in future versions, my own humble boards are much more like the Adafruit ruler in their stark rectangular-pad one-side-smd simplicity. For your pads, I am thinking that we could rasterize the areas and paste parallel lines onto your pad. As it is, we will probably need to paste a line anyhow for long pads, so it is not too much of a stretch. Would the rasterization approach suit your polypad?

Douglas, seems like this thorny gerber bushwacking has caused many of us grief. :o

Since we are signing up for exceptions galore, I will propose a new solution for jspcb, which is to put all that exceptional configuration into a single JSON file that can be read in to specify arbitrary configuration with a single program argument. For example, such a file could support explicit board outlines with bounds:[line,line,line,line]. The advantage of the data-driven approach is that code would not need to be changed for supporting different gerber conventions. At least, that is a hope...

Jason, if OpenPnP has a canonical file format that it prefers for paste or place, jspcb could certainly generate that if you like. Also, if the generated SVGs would be helpful in any way to OpenPnP, let me know...

[Rich Obermeyer]

Karl,

Good work.

When you say (1,1) are you saying X=1 inch and Y=1 inch and Eagle is 0,0? 

--
You received this message because you are subscribed to the Google Groups "FirePick" group.

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

To post to this group, send email to fire...@googlegroups.com.
Visit this group at https://groups.google.com/group/firepick.
For more options, visit https://groups.google.com/d/optout.

--

Rich

[Michael Anton]

Don't worry about implementing any special pasting methods on my behalf, as I'd probably never use them.  I'm very firmly entrenched in the stenciling camp, and haven't dispensed a board (other than for manual assembly), in more than a decade.  At this point, I'd never go back, even if it worked really well, since it always takes forever compared to using a stencil, and will never produce solder joints that are as reliable.  Rasterizing a polypad would probably work fine, as would dispensing a series of dots.

I just thought you might like an extra example file of how bad it can get, so I sent it.  Though, it looks like pretty much all Gerbers from P-CAD have macros in them, and it is probably done to support embedded apertures, but I'm not exactly sure how RS-274X is normally implemented.  I could probably output Gerbers in a simpler format, as there do appear to be some other options to control this.

The MDC guys from Japan, have another method called paste stamping, which is a bit different than traditional dispense: https://www.youtube.com/watch?v=lu_1iTU93kQ.  This might be easier to implement for small dot sizes, than syringe dispense.

If I had to guess, Altium is probably one of those CAD packages that doesn't tolerate boards having an origin of (0,0) well, so they have offset Eagle files by an appropriate amount to get around this.  It is usually possible to apply an offset when generating Gerbers, so it is possible that it was done there as well.  I suspect that if someone designed the board with a different offset, that would come through in the Gerbers as well, unless an offset was applied, so it might not be a good idea to make too many assumptions in this regard.

Mike

[Joshua Pritt]

That's a great video!  It shows a whole other way to "dispense" the paste.  Instead of trying to squeeze it out a little at a time, we can just PICK AND PLACE the paste!  ::mind blown why didn't I think of that::

--
You received this message because you are subscribed to the Google Groups "FirePick" group.

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

[Michael Anton]

I suppose if one wanted to make some multiple pin patterns for say 0805 parts, you could even dispense twice as fast.

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

[Karl]

Yes (1",1") and Eagle is (0,0). 

It may, as Michael suggests, be an Altium limitation.

[Michael Anton]

I know this limitation exists in Tango, and P-CAD, and these two products are related to one another.  Altium shares heritage with P-CAD, and Protel, though I'm not sure if Protel also requires all coordinates to be positive, as I've never used it.

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

To post to this group, send email to fire...@googlegroups.com.
Visit this group at https://groups.google.com/group/firepick.
For more options, visit https://groups.google.com/d/optout.

--

Rich

[Rich Obermeyer]

Tango and P-CAD have no common code with Altium or Protel.

I have copies of them all.

Altium bought P-CAD (Tango) but I never saw any added code which resembled anything from P-CAD.  Personally I think they just bought the customer list as the users were converted to the latest version of Altium for a small fee quickly but added an Annual maintenance fee and P-CAD was no longer developed.

I will simply ask Altium why they did the conversion that way.  As I said I know the guy we need.  Now would be a great time to ask any other questions.

[Michael Anton]

The only thing Altium does that seems to be related to P-CAD is import the files.  I have all three as well, and the only one I've never really used is Altium (worst money I ever spent).  It seems really broken to me compared to how P-CAD does things, so mostly I still use P-CAD, even as outdated as it is.  I really wished they had kept some of the nice features in P-CAD.

Annual maintenance existed for P-CAD before Altium bought them.  That is a pretty standard practice in the industry.  As I recall, at one point we were given a free upgrade to Altium (since we were on maintenance), as they were replacing everything with that product.

It is strange how things change.  Back in the mid '80s, P-CAD was the tool to own, but at something like $20K+ per seat, few could afford it.  Tools still seem expensive to me today (especially since I am self employed), even though they have come down in price significantly.

[Rich Obermeyer]

LOL, I was wondering if I was the only one that liked P-CAD.  Shame to see them sell out.

I am also a consultant but I got my clients to pay my yearly maintenance for Altium so they could play along.  For every new copy I sell I get better discounts on mine.  🤑

Can't talk a client into paying or using a package no longer sold.

Took a few years to get good with the tool.

I Emailed them.  See what they say.

I think I will be moving to SolidWorksPCB soon.  Have to find somebody to pay for it.  

Engineering Jobs in the US are getting less and less available every month.   Too many people just buy Chinese crap because it's cheap.  Wake up America!  Your kids are going to need jobs.

[Rich Obermeyer]

Altium suggests since they have Absolute and relative grids it is not a limitation on their part but Eagle limitation.

When Altium imports an Eagle file they can not bring it into zero as that will potentially leave areas not accessible.

So they import to absolute 1,1 to avoid the problem.  I usually build my boards at 1,1 with the relative set to 1,1.

This places the board at 0,0 for everything.

Altium has suggested that maybe when they import they should do just that.  

Set relative origin to 1,1 and make that the Eagle 0,0 for import.  

Then the databases would match.  Questions?

[Michael Anton]

Well, yes they have absolute and relative grids, but I suspect they like many others use an internal format that expects unsigned numbers.  So, for display purposes, they can put zero anywhere by using the relative grid, but the actual numbers stored in the file must be unsigned.  Otherwise, there would be no need to apply an offset.

On Tuesday, October 18, 2016 at 1:50:19 PM UTC-6, Rich Obermeyer wrote:

Altium suggests since they have Absolute and relative grids it is not a limitation on their part but Eagle limitation.

When Altium imports an Eagle file they can not bring it into zero as that will potentially leave areas not accessible.

So they import to absolute 1,1 to avoid the problem.  I usually build my boards at 1,1 with the relative set to 1,1.

This places the board at 0,0 for everything.

Altium has suggested that maybe when they import they should do just that.  

Set relative origin to 1,1 and make that the Eagle 0,0 for import.  

Then the databases would match.  Questions?

On Mon, Oct 17, 2016 at 5:40 PM, Karl <ka...@firepick.org> wrote:

Yes (1",1") and Eagle is (0,0). 

It may, as Michael suggests, be an Altium limitation.

On Monday, October 17, 2016 at 11:17:55 AM UTC-7, Rich Obermeyer wrote:

Karl,

Good work.

When you say (1,1) are you saying X=1 inch and Y=1 inch and Eagle is 0,0? 

On Mon, Oct 17, 2016 at 9:04 AM, Karl <ka...@firepick.org> wrote:

Rich, the Eagle Dimension layer was what I used for the original ruler, which was (0,0) origin. The Altium code arbitrarily moved that origin to (1,1), which took me by surprise. Now that I know how Altium works, I believe that I can write specific code for handling the GKO Gerber, which works much like the Eagle layer 20 and allows for non-rectangular board outlines. I do think the Altium repositioning of the origin is a bit of a bug since it violates the Eagle semantics. I can work around it since the generated Gerbers are self-consistent. Perhaps the bug is in the Altium Eagle importer?

Michael, thanks for the polygonal pad explanation. I will summon the energy to slog through that nasty mess that is Gerber macros, although I cannot promise a quick turnaround. The semantics for solder paste syringe dispensing and macro regions precipitate a whole slew of issues to support area paste vs. point-blob paste. Although we will probably aspire to solder paste art in future versions, my own humble boards are much more like the Adafruit ruler in their stark rectangular-pad one-side-smd simplicity. For your pads, I am thinking that we could rasterize the areas and paste parallel lines onto your pad. As it is, we will probably need to paste a line anyhow for long pads, so it is not too much of a stretch. Would the rasterization approach suit your polypad?

Douglas, seems like this thorny gerber bushwacking has caused many of us grief. :o

Since we are signing up for exceptions galore, I will propose a new solution for jspcb, which is to put all that exceptional configuration into a single JSON file that can be read in to specify arbitrary configuration with a single program argument. For example, such a file could support explicit board outlines with bounds:[line,line,line,line]. The advantage of the data-driven approach is that code would not need to be changed for supporting different gerber conventions. At least, that is a hope...

Jason, if OpenPnP has a canonical file format that it prefers for paste or place, jspcb could certainly generate that if you like. Also, if the generated SVGs would be helpful in any way to OpenPnP, let me know...

--
You received this message because you are subscribed to the Google Groups "FirePick" group.

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

To post to this group, send email to fire...@googlegroups.com.
Visit this group at https://groups.google.com/group/firepick.
For more options, visit https://groups.google.com/d/optout.

--

Rich

--
You received this message because you are subscribed to the Google Groups "FirePick" group.

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

To post to this group, send email to fire...@googlegroups.com.
Visit this group at https://groups.google.com/group/firepick.
For more options, visit https://groups.google.com/d/optout.

--

Rich

[Rich Obermeyer]

Not seeing why internal formats means anything unless you wanted to hack the compressed database..

If the board is put at 0,0 relative then all the gerber outputs will match the Eagle files which does not have relative at all.

Commonality of Gerbers was the point of this post.

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

To post to this group, send email to fire...@googlegroups.com.
Visit this group at https://groups.google.com/group/firepick.
For more options, visit https://groups.google.com/d/optout.

--

Rich

[Michael Anton]

Ok, got it.  P-CADs relative grid doesn't translate to Gerber output as far as I know, so I figured Altium might be similar.  My statement was that they have to apply an offset somewhere due to the internal representation, and that many packages are like this.  I don't see this as a disadvantage per se, but rather that one cannot assume that Gerbers will alway have an origin at (0,0), as there isn't any reason that they would need to.

[Rich Obermeyer]

From the test case we ran on Karl's ruler this change would result in Gerber being the same making parsing simpler.

[Karl]

Rich, thanks for checking with Altium. I'll go ahead with the GKO import, which should decouple Altium's resolution of the origin issue from my code. I.e., whatever they decide is fine by me. The GKO import does indicate the origin and bounds. I also plan on allowing users to specify origin and bounds via JSON as a GKO alternative that may be useful for handling other vendors. I should be done with that later in the week when I resume working on jspcb.

[Karl]

Not quite ready to release a new version of jspcb, but I'm feeling more comfortable with the Rich's Gerber recommendation.

Currently, jspcb can read in multiple Gerber files and produce CSV, SVG and PNG files.

The PNG I had posted previously was created from an online SVG to PNG converter.

Now jspcb does that PNG conversion itself natively with the --png command line parameter. Converting

Gerber arcs to SVG arcs was a bit of a mindbendy thingy, but I finally got it to work.

Attached is a PNG created from the Rich's Gerber files. I'll be adding a JSON configuration parameter

that will let you control the image size and the colors for various elements (e.g., SMD pads vs. silkscreen).

This is shaping up to be a very interesting way to create a PCB image template on the fly for OpenCV...

[Rich Obermeyer]

Impressive!

Thanks for thinking and supporting the rest of us not using Eagle.

--
You received this message because you are subscribed to the Google Groups "FirePick" group.

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

To post to this group, send email to fire...@googlegroups.com.
Visit this group at https://groups.google.com/group/firepick.
For more options, visit https://groups.google.com/d/optout.

<ruler.png>

[Karl]

Rich, your assessment of Gerber potential was spot-on. I especially noticed that for the silkscreen text, which is only accurately obtained from Gerbers. I have no access to Eagle rendering code, so it turns out that I did need the Gerber GTO to render the image.  :D

in other news....the ADAFruit ruler BRD does not match my ADAFruit ruler...Hmmm. I think I will go poke them and whine a bit

On Tuesday, October 25, 2016 at 10:23:32 AM UTC-7, Rich Obermeyer wrote:

Impressive!

Thanks for thinking and supporting the rest of us not using Eagle.

On Oct 23, 2016, at 9:36 PM, Karl <ka...@firepick.org> wrote:

Not quite ready to release a new version of jspcb, but I'm feeling more comfortable with the Rich's Gerber recommendation.

Currently, jspcb can read in multiple Gerber files and produce CSV, SVG and PNG files.

The PNG I had posted previously was created from an online SVG to PNG converter.

Now jspcb does that PNG conversion itself natively with the --png command line parameter. Converting

Gerber arcs to SVG arcs was a bit of a mindbendy thingy, but I finally got it to work.

Attached is a PNG created from the Rich's Gerber files. I'll be adding a JSON configuration parameter

that will let you control the image size and the colors for various elements (e.g., SMD pads vs. silkscreen).

This is shaping up to be a very interesting way to create a PCB image template on the fly for OpenCV...

--
You received this message because you are subscribed to the Google Groups "FirePick" group.

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

To post to this group, send email to fire...@googlegroups.com.
Visit this group at https://groups.google.com/group/firepick.
For more options, visit https://groups.google.com/d/optout.

<ruler.png>

[Joshua Pritt]

Awesome job!  How do you eat an elephant?  One bite at a time!  Then wash it down by drinking from a fire hose!

[Karl]

Since jspcb generates svg in order to create a png, it can control image colors semantically (i.e., pads, vs. silkscreen vs. board, etc.).

Here's an example of jspcb gerber to png conversion (ruler-tmplt.png).

Attached is also the image of the actual AdaFruit pcb (ruler-cam.jpg).

As you can see, the two look quite similar and support my hopes of using a GERBER generated

PNG as an OpenCV template for identifying board position with a PnP camera.

[Karl]

And success!

https://github.com/firepick/jspcb/wiki/PCB-Matching

[Jason von Nieda]

Karl,

The big issue with template matching is rotation, and of course, PCBs can (and will) be rotated to any arbitrary angle. Do you have a plan for handling this? The nice thing about round fiducials is that it doesn't matter how they are rotated.

Jason

On Thu, Oct 27, 2016 at 3:09 PM Karl <ka...@firepick.org> wrote:

And success!

https://github.com/firepick/jspcb/wiki/PCB-Matching

--
You received this message because you are subscribed to a topic in the Google Groups "FirePick" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/firepick/vL33HqT2XHk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to firepick+u...@googlegroups.com.

[Karl]

Jason, yes, there are a lot of nice things about circles. :D

I plan on mounting PCBs to a sliding table. One of the clamps is always fixed, 

so that reduces the angular possibilites to four. I'd probably just look for each of 

the four possible templates to determine orientation.

For OpenPnp, it makes more sense to stick with the circles because those fiducials

would be required in a large PnP production run anyhow. I don't have that need,

since I'm just building boards for fun and have no plans for mass production. 

The template approach is attractive to me because I typically make small boards and

am fighting for every mm of space--fiducials take up space.

On Thursday, October 27, 2016 at 1:24:25 PM UTC-7, Jason von Nieda wrote:

Karl,

The big issue with template matching is rotation, and of course, PCBs can (and will) be rotated to any arbitrary angle. Do you have a plan for handling this? The nice thing about round fiducials is that it doesn't matter how they are rotated.

Jason

On Thu, Oct 27, 2016 at 3:09 PM Karl <ka...@firepick.org> wrote:

And success!

https://github.com/firepick/jspcb/wiki/PCB-Matching

--
You received this message because you are subscribed to a topic in the Google Groups "FirePick" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/firepick/vL33HqT2XHk/unsubscribe.

To unsubscribe from this group and all its topics, send an email to firepick+unsubscribe@googlegroups.com.

[Jason von Nieda]

Karl,

Fair enough! I was secretly hoping you had come up with an amazing new rotate invariant template match! :)

Jason

On Thu, Oct 27, 2016 at 3:37 PM Karl <ka...@firepick.org> wrote:

Jason, yes, there are a lot of nice things about circles. :D

I plan on mounting PCBs to a sliding table. One of the clamps is always fixed, 

so that reduces the angular possibilites to four. I'd probably just look for each of 

the four possible templates to determine orientation.

For OpenPnp, it makes more sense to stick with the circles because those fiducials

would be required in a large PnP production run anyhow. I don't have that need,

since I'm just building boards for fun and have no plans for mass production. 

The template approach is attractive to me because I typically make small boards and

am fighting for every mm of space--fiducials take up space.

On Thursday, October 27, 2016 at 1:24:25 PM UTC-7, Jason von Nieda wrote:

Karl,

The big issue with template matching is rotation, and of course, PCBs can (and will) be rotated to any arbitrary angle. Do you have a plan for handling this? The nice thing about round fiducials is that it doesn't matter how they are rotated.

Jason

On Thu, Oct 27, 2016 at 3:09 PM Karl <ka...@firepick.org> wrote:

And success!

https://github.com/firepick/jspcb/wiki/PCB-Matching

--
You received this message because you are subscribed to a topic in the Google Groups "FirePick" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/firepick/vL33HqT2XHk/unsubscribe.

To unsubscribe from this group and all its topics, send an email to firepick+u...@googlegroups.com.

To post to this group, send email to fire...@googlegroups.com.
Visit this group at https://groups.google.com/group/firepick.
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 "FirePick" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/firepick/vL33HqT2XHk/unsubscribe.

To unsubscribe from this group and all its topics, send an email to firepick+u...@googlegroups.com.

[Karl]

Haha! No such luck. 

It's possible to overlay templates to get a multi-angle template, but location precision suffers. :(

On Thursday, October 27, 2016 at 1:38:56 PM UTC-7, Jason von Nieda wrote:

Karl,

Fair enough! I was secretly hoping you had come up with an amazing new rotate invariant template match! :)

Jason

On Thu, Oct 27, 2016 at 3:37 PM Karl <ka...@firepick.org> wrote:

Jason, yes, there are a lot of nice things about circles. :D

I plan on mounting PCBs to a sliding table. One of the clamps is always fixed, 

so that reduces the angular possibilites to four. I'd probably just look for each of 

the four possible templates to determine orientation.

For OpenPnp, it makes more sense to stick with the circles because those fiducials

would be required in a large PnP production run anyhow. I don't have that need,

since I'm just building boards for fun and have no plans for mass production. 

The template approach is attractive to me because I typically make small boards and

am fighting for every mm of space--fiducials take up space.

On Thursday, October 27, 2016 at 1:24:25 PM UTC-7, Jason von Nieda wrote:

Karl,

The big issue with template matching is rotation, and of course, PCBs can (and will) be rotated to any arbitrary angle. Do you have a plan for handling this? The nice thing about round fiducials is that it doesn't matter how they are rotated.

Jason

On Thu, Oct 27, 2016 at 3:09 PM Karl <ka...@firepick.org> wrote:

And success!

https://github.com/firepick/jspcb/wiki/PCB-Matching

--
You received this message because you are subscribed to a topic in the Google Groups "FirePick" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/firepick/vL33HqT2XHk/unsubscribe.

To unsubscribe from this group and all its topics, send an email to firepick+unsubscribe@googlegroups.com.

To post to this group, send email to fire...@googlegroups.com.
Visit this group at https://groups.google.com/group/firepick.
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 "FirePick" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/firepick/vL33HqT2XHk/unsubscribe.

To unsubscribe from this group and all its topics, send an email to firepick+unsubscribe@googlegroups.com.

[Karl]

To test the rotation usecase, I created a new camera image by simply rotating the original by 90 degrees.

Then I updated the FireSight pipeline to use the same template in four different stages, each of which matches

a different angle:

https://github.com/firepick/jspcb/blob/master/json/matchtemplate.json

The result is a successful match with a single template and a single FireSight pipeline.

[Joshua Pritt]

Very nice! Very fast turnaround on a feature request too!  :)

You received this message because you are subscribed to the Google Groups "FirePick" group.

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

[Karl]

Sometimes we get lucky... 

I thank Jason for his inspiration. :)

[Karl]

jspcb 0.1.1 is published and off to a wobbly humble start.

I also tossed in some documentation which should do for a while.

https://github.com/firepick/jspcb/wiki/JSON-Configuration

Looks like we're moving back into our house in a few days, so I'll be busy with that...

[Karl]

jspcb 0.1.2 is published.

* BUG: gerber silkscreen arcs and rectangles not shown in SVG

[Karl]

More bugs more fixes more docs. No function changes, just stability.

jspcb 0.1.6

*sigh*

[Joshua Pritt]

Stability is just as important!  Great job!

--

You received this message because you are subscribed to the Google Groups "FirePick" group.

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

[Karl]

Found a few more bugs when testing with Gerber files generated from EagleBRD using SparkFun sfe-gerb274x.cam job. The resulting image actually looks more like the actual board than the image generated from Altium Gerber files:

1) Altium text is generated in outline so the letters are fatter (SparkFun letters are very compact)

2) Altium generates some silkscreen lines with no aperture (!) so I applied a default aperture of 0.1mm to get them to show. Per UCAMCO spec, the Altium GTO Gerber isn't quite legal because of the missing aperture.

3) Sparkfun defines macros (UGH!) but never uses them (YAY!)

4) Sparkfun uses deprecated Gerber command IPPOS (ignored)

5) Sparkfun esoterically sets axis offset to...zero. (ignored) 

jspcb 0.1.8

[Michael Anton]

You may find that using the ident layer to do any alignment will be problematic at best, as this layer often does not have very good registration to the copper layer.  Having an offset of 0.010" between the ident and copper layers is not uncommon.

Mike

[Karl]

Michael, yes, you're right. I have been looking at the various layers and there seems to be a convention of using zero-width apertures to outline the PCB. For Altium that is GKO layer, for Sparkfun that is GTL layer. The GTO silkscreen layer is not a good board metric.

Fascinating stuff. I have what I need since I use Eagle, but if folks have other Gerbers they favor, I'm happy to see what their Gerbers do.

[Karl]

Mike's comment about silkscreen alignment was very thought provoking...

I decided to see what happens if we compare two templates of the same PCB region.

The sfe-gtp template uses just the SMD paste pads.

The sfe-gto template uses silkscreen and full copper layers.

As you can see, the sfe-gto looks more like the real board, but could be lead astray

by misaligned silkscreen markings. Compare that with the sfe-gtp template, which

is pretty minimalist.

Both templates match the same region. The sfe-gtp template required a more 

sensitive matching threshold because there are more discrepancies. However,

the positions matched are within 1 pixel of each other. That pixel difference represents a

~0.25mm offset which could possibly (?) be due to silkscreen/copper misalignment.

On Friday, October 28, 2016 at 10:32:21 PM UTC-7, Michael Anton wrote:

[Karl]

More details at: https://github.com/firepick/jspcb/wiki/PCB-Matching#silkscreen-vs-copper