EEVblog Electronics Community Forum
Electronics => PCB/EDA/CAD => Topic started by: ScribblesOnNapkins on August 18, 2016, 08:55:01 pm
-
PCB-RND is a fork of PCB from gEDA that a few of us have been working on. At the end of last year it became more obvious that development of PCB was grinding down. PCB's last release was in 2014 and I am not going to bad mouth anyone but it looked apparent that a new release was not going to happen any time soon. The rapid development and clarity of direction caused the mainline of PCB to consider adopting PCB-RND and Igor2 (it's leader) but that was rejected by the current project lead. So we are two different groups both sharing solutions when possible.
What is the difference?
* A lot of cleanups to the code. For example no more use of longjmp() and etc in the DRC subsystem.
* Parametric footprints mean less hunting for footprints. It also does fun things like defining screw holes as M4 tight or loose fitting.
* A mechanism to automatically pull footprints from geda-symbols and or any other web accessible repo means less leg work when you want to use a new component.
* Footprints are now stored in an arbitrarily defined (user) tree instead of a 2 level one for easier searching when you have to.
* Scripting in the language of your choice not just C the following are new awk, lua, scheme, stutter, php, perl, pascal, ruby, and yes python too.
* The file format is still compatible with PCB but we made the format a plugin. Our intention is to add support for more formats (Eagle/KiCAD) in the future with a DRC list like mechanism to let you "fix" features not available in the format you are exporting too.
* Exporters are now plugins and a lot of bugs in them have been fixed.
* We support a purely 64 bit environment not just a 32 or 32/64 bit one.
* We support MacOS.
* We have an experimental Windows port and if more interest in it comes we will make this a proper release.
* Bugs in the UI of PCB were also fixed (notably the twin hole bug)
* Reduced dependency on glib which made our memory footprint a lot smaller. Our eventual plan is to add another HID for libSDL to the list
In the near future we want to...
* Find users on Windows, MacOS, and other platforms (BSD, OpenBSD, FreeBSD, Solaris) who are willing to use the software and submit bug reports.
* LTSPICE users who want a PCB package
* QUCS users who want a PCB package
* Route as bus. (we have a patch that enables this but we want more users first for testing reasons)
* Back annotation We actually could ship with this but it only works for non-hierarchical netlists if you patch gEDA to support it. (they are reviewing the patch now for their next release)
We are trying to be more responsive and less antisocial than the gEDA mailing list. If you are interested please join us.
http://repo.hu/projects/pcb-rnd/ (http://repo.hu/projects/pcb-rnd/)
It should be noted that all of this has also caused PCB mainline to pick up their work a little. I don't wish to be unkind but a new release from them will probably not happen until we finish our next two or three.
-
Thank you very much for this news and your work. I wasn't aware of the project until I saw your post. There are indeed a few things I'd have seen included in gEDA PCB, which I've considered nice-to-have as I've gripped the essential and I'm doing fine with it. Now what your work added really is interesting. Pulling footprints from gEDA symbols, for instance, is but an important feature — note that I mostly end up not finding the footprints I want there but that's secondary. "Cross-compatibility" with Eagle and other programs definitely is what makes it a "must-have", thank you very, very much again.
I'm going to try it soon and report.
-
We are going to do another release soon. It will have a considerable set of new features. I don't want to say everything now but it is the start of some big changes.
-
We released a new version. The key features are...
1. Query based DRC system - we now have a 2nd DRC that is programmable so that things like "route these lines in diff pair" or "route w/ matched length" and etc. can be checked via DRC.
2. Support for more file formats
2a) kicad legacy
2b) kicad's new s format (experimental)
2c) lihata our new format - The original format is still supported but the new format lets us do things that were never possible before. Including adding comments and attributes to any arbitrary feature.
3. More plugins from the mainline of pcb's unused branches most noteably openscad export.
4. Improved grid - the new grid lets users handle larger boards more easily by scaling near the areas of interest.
Next up is Eagle compatibility, and other stuff we expect to save user aggravation.
-
My biggest problem with PCB is/was that traces aren't fixed to a net. If you connect a long trace to a different net somewhere then it may hop over to that net which makes it impossible to quickly discover where the problem is.
-
We actually have a solution to the shorted net problem in pcb-rnd. It's called Minicut. Please look at our documentation on it. We are not PCB we are PCB-RND so if you have another problem with usability please tell us.
-
So a few things happened this week.
1. An older version of pcb-rnd (1.1.4) going to be in the next release of Debian and we are going to be in the next Ubuntu release as well.
2. We released 1.2.0 http://repo.hu/projects/pcb-rnd/releases/changelog-1.2.0.txt (http://repo.hu/projects/pcb-rnd/releases/changelog-1.2.0.txt)
Among many fixes and other changes was an over haul of sorts of the old gsch2pcb. gsch2pcb-rnd now packages all updates from the schematic as commands in a cmd file for pcb-rnd so the days of loading elements and then netlists and etc are gone.
-
I'll give the Mac version a spin and see what it looks like.
-
Are you a gEDA/PCB user? What is your current PCB layout tool and what is your current schematic capture utility?
-
Hey ScribblesOnNapkins,
Thanks for the updates and all solution. I am a gEDA/PCB user.
-
I'm going to test it on my Gentoo computer. Any particular hint or trap for young players? May I base my ebuild on the initial "pcb" package?
-
windows version ?
-
We have an *experimental* windows release but it has only been distributed internally. We don't want to release it publicly until it has real testing. If people (more than 2) are willing to volunteer to do real world testing of it then we could make it public.
Personally I know that to grow past a certain point we have to support windows but doing a first windows release with bugs will make the users who try it allergic to any future work we do.
-
VinzC I am also a gentoo user. You can have the regular version of pcb and pcb-rnd installed at the same time. You can also run it from the src directory after you build it. You might have trouble with using the old pcb-mainline ebuild as a base for this since it uses autotools (configure) and we don't. For cues on how to deal with the differences try looking at brlcad's ebuild.
Trap for young players: We tried not to have any. If you are used to regular old pcb it should be the same. Currently there are 2 things new people should know.
1. Self intersecting polygons will cause you pain. Drawing copper arcs that are almost circles inside of a polygon will cause them. All other arcs are perfectly safe. (This is a bug we found in the original pcb code)
2. For people who used gsch2pcb for importing more complex projects (multiple schematics to one layout) pcb-rnd has replaced gsch2pcb with gsch2pcb-rnd and it has a slightly different interface. -m import is the one you probably want. If you used *.prj files then you need to convert them using pcb-prj2lht which is a script we included in the release.
We try very hard to be user driven so if you are a young player and you find something that feels cumbersome please *tell* us.
-
here is a couple of things you may want to add into the tool ( things that i am missing in a lot of PCB cad software )
- design rules in the library builder so i can run DRC when i am building a footprint.
- clipping silkscreen. if i place silkscreen over copper it should clip automatically according to a rule. so i don't have to fix that in the gerber editor ( and i can drive it from rules. some board vendors can get silkscreen registration more accurate than others.
- decals that autosize to their bounding box so i when i print out the assembly layer the designators autoscale to fit the component size.
- mechanical tolerances on parts
-
- Design Rules in the "library builder". We let you tweek footprint pad sizes and etc later on once you have a layout started. Footprints should be drafted to manufacture standards.
- Silk screen clipping happens at the fab level. You don't have to worry about it overlapping copper in the gerbers. I have been letting them run over each other for years with out issue.
- Can you explain more about decals? I think you are onto something there.
- "Mechanical Tolerances" on parts? You mean like hight? We have export of the board to openscad and have been thinking about pulling 3D part models into openscad to check for collisions (with the case and etc)
-
- Silk screen clipping happens at the fab level. You don't have to worry about it overlapping copper in the gerbers. I have been letting them run over each other for years with out issue.
That is making the assumption that some third party is making the boards. That is not warranted; many people make their own boards and they are, I suspect, exactly the class of people most likely to use FOSS.
-
There are separate export modes for home etching in PDF, PS, and PNG formats among others in both PCB and PCB-RND. Both projects developers do a fair amount of etching at home. We also support g-code export but I don't know how many people on ether project have mills to test it on.
-
- Design Rules in the "library builder". We let you tweek footprint pad sizes and etc later on once you have a layout started. Footprints should be drafted to manufacture standards.
Let me fill you in on a couple of things. The design of a pcb stands or falls wth the library. There is NO tweaking at pcb design level. Footprints are stored in a library. Once placement is done , ony routing remains. There is no such thing as 'editing' in situ. The reason is that the next iteration it will reintroduce a problem. Or an instance of a footprint may not get updated.
This leads to endless rework cycles and having to do too much manual checking.
If a problem is found it is fixed in the library and this then propagates into the designs.
Footprints are drafted not only to part manufacturer standards. Also tuned to pcb manufacturer for things such as soldermask slivers, copper clearance, pad to pad , hole to hole, annular ring etc. those things require design rule checking. That needs to happen for every part created before it is stored in the library. Some data is not stored as constants but as variables that are overriddden from layout. Other data is static.
So. I want to be able to check my footprints when making them in the library.
- Silk screen clipping happens at the fab level. You don't have to worry about it overlapping copper in the gerbers. I have been letting them run over each other for years with out issue.
BAD practice. The fabs should not modify your data.
- Can you explain more about decals? I think you are onto something there.
- "Mechanical Tolerances" on parts? You mean like hight? We have export of the board to openscad and have been thinking about pulling 3D part models into openscad to check for collisions (with the case and etc)
Not only that. Lets take a sot23 package. Every manafucaturer has small permutations. A nxp one may have pins that are 0.2 to 0.3mm. A TI one may be 0.25 to 0.35 range. The body may have different tolerance.
I do NOT want to create 500 different sot23 footprints. I want to feed a table into the library. For nxp : here are the numbers for ti : here are the numbers. The library editor then scales the pads.
I also would like to see parametric libraries that can use equations (like solidworks) so i can use variable names at board level or instance level to control attributes.
This goes through into 3d space including scaling of the 3d model.
For example : an electrolytic capacitor. They are specked as 10.5mm tall and 10mm diameter +/- 0.5mm
That means my courtyard needs to be oversized to max tolerance to guarantee the part will always fit. Same for my silkscreen outline. The 3d model also needs to be enlarged to max tolerance.
I do not want to perform those calculations. Or store this as a 11mm by 10.5mm cap in the library.
It is still a 10x10.5 : the cad software is fed the tolerance and does the correction
-
Editing in situ exists if people don't want to use it that is fine. They can edit the footprints in their library directly. In situ edits only change the one instance and are meant for doing *very* minor *one* *off* changes. Footprints should be drafted to spec. and if deviations are made they should be well documented. That is a user issue not a problem for the layout tool. Users of PCB mainline asked for this feature and they got it, we were not going to remove it from PCB-RND. (I have only used it once.) Insitu editing only lets you change pad/hole sizes and silk screen line thickness. You can't go remaking things completely
There is no fab I have ever seen that prints silk over directly over copper. There is there for no reason to care if someone has drawn silk over copper in their footprints. They are not modifying my data. They don't have the ability to print silk over copper directly.
"Mechanical Tolerances" - We have a footprint generator built in that makes the footprints based on common patters with pads and etc based on user defined variables. If you had ever used the tool you are trying to school me in then you would know we already have this. By default the footprint generator uses pads of the ISO/ANSI standards for the type requested. http://igor2.repo.hu/tmp/pcblib/ (http://igor2.repo.hu/tmp/pcblib/) to see how this works see the simple example of screws http://igor2.repo.hu/cgi-bin/pcblib-param.cgi?cmd=%20screw(3.2mm,%206mm,%20circle:hex) (http://igor2.repo.hu/cgi-bin/pcblib-param.cgi?cmd=%20screw(3.2mm,%206mm,%20circle:hex))
-
They don't have the ability to print silk over copper directly.
Of course they do! It's not some magic process which doesn't stick to copper, or any or the plating options..
-
Ok well I have never seen that but I also don't draw silk over copper in my footprints and etc. If you don't want silk over copper then *don't* draw silk over copper.
-
Why would anyone draw in silk and then not want it produced?
-
Fabs can perfectly print silkscreen over copper. It s the same ink as the soldermask.
When gerber data is read-in it is pst processed and checked for fab violations. One of these steps is to perform a clipping operation between silkscreen and exposed. They set a retracting factor to make sure the silkscreen does not bleed into the soldermask cavity and they accommodate for registration tolerances.
This means that my data is being manipulated. I do not want that.
I am not asking you to remove functionality. I am asking you to add functionality !
When creating a connector footprint i want to draw a silkscreen line that looks like this :
-0--0--0--0--0--0--0-
The - is silkscreen. The 0 is a pad (exposed copper).
In macro view it actually looks like this :
___
== | o | ==
-----
The box is the opening in the soldermask. Just like there is a rule defining how close the soldermask comes to the actual pad, there is a rule (manufacturer dependent ! ) that defines how close the silkscreen can actually come to the edge of the soldermask opening.
Want to be able to simply draw a single laing across the pads , and the cad tool will convert this into a 'dashed' line that automatically creates the correct clipping , respecting the rules.
The clipping distance is driven from a parameter. That parameter is not set as static in the library , but picked up from a rule in the pcb. Depending on who will manufacture my board i can feed the clipping distance and the silkscreen will trim itself.
I would make a 'smart silkscreen' trace and 'smart silkscreen polygon' object. ( leave what is in there 'as-is')
Any instance of these in a library listen to the rules set in the PCB layout.
For both you can define 'silk to solder' and 'silk to copper' distances. These work as 'furthest distance wins'.
For the smart trace you can also override the width from the pcb tool.
That way, if my manufacturer can only handle 6 mils i can simply set that and all the silkscreen will widen / shrink accordingly without me having to go manually edit this stuff each and every time.
And i am not trying to school you in the tool. I am trying to chool you in how pcb layout is done. Come off yor throne and listen to actual pcb designers ! This is my gripe with this knd of projects. The tools are developed by programmers that have no firm grasp of pcb design and manufacturing.
-
..[snip]..
We are trying to be more responsive and less antisocial than the gEDA mailing list. If you are interested please join us.
..[snip]..
Editing in situ exists if people don't want to use it that is fine. They can edit the footprints in their library directly. In situ edits only change the one instance and are meant for doing *very* minor *one* *off* changes. Footprints should be drafted to spec. and if deviations are made they should be well documented. That is a user issue not a problem for the layout tool. Users of PCB mainline asked for this feature and they got it, we were not going to remove it from PCB-RND. (I have only used it once.) Insitu editing only lets you change pad/hole sizes and silk screen line thickness. You can't go remaking things completely
There is no fab I have ever seen that prints silk over directly over copper. There is there for no reason to care if someone has drawn silk over copper in their footprints. They are not modifying my data. They don't have the ability to print silk over copper directly.
Yeah, sure....
Free_electron's advice is pure Gold, but you guy's don't want to listen....
-
..[snip]..
We are trying to be more responsive and less antisocial than the gEDA mailing list. If you are interested please join us.
..[snip]..
Editing in situ exists if people don't want to use it that is fine. They can edit the footprints in their library directly. In situ edits only change the one instance and are meant for doing *very* minor *one* *off* changes. Footprints should be drafted to spec. and if deviations are made they should be well documented. That is a user issue not a problem for the layout tool. Users of PCB mainline asked for this feature and they got it, we were not going to remove it from PCB-RND. (I have only used it once.) Insitu editing only lets you change pad/hole sizes and silk screen line thickness. You can't go remaking things completely
There is no fab I have ever seen that prints silk over directly over copper. There is there for no reason to care if someone has drawn silk over copper in their footprints. They are not modifying my data. They don't have the ability to print silk over copper directly.
Yeah, sure....
Free_electron's advice is pure Gold, but you guy's don't want to listen....
Exactly.
From a recent post FE made and just to outline his small ;) knowledge on this matter:
One of my latest is a 22 layer and has 37.000 via's, 100.000 nets and 4000 components using 3 mil track and gap. using blind and buried and laserdrilling. Another one has 200+ ampere running through it on 8 layers using 4 ounce copper on inner layers.
-
Other useful things to have :
- body check : verify no silkscreen exists underneath any bodypart of a step file touching the pcb surface. This is especially important for things like SOP , DFN and other leadless packages. The thickness of the physical ink is enough to create pillowing problems during soldering.
- automatic sliver removal. A rule is set that no solder mask structures smaller than x should exist. X is a parameter set in the pcb file. Any violating object is automatically stripped. Some fabs can make 3 mil soldermask features, some can only do 5 or 6. I can simpy set the rule and if there are slivers. (Espcially on 0.5mm pitched parts and below ) they are removed automatically.
Sliver detection works on soldermask and silkscreens ( should be an independent rule for both )
- automatic via tenting with pullback rule. It is a bad idea to completely cover a via with soldermask s it traps moisture in the hole. The soldermask needs to be 'opened' over the hole. Even then setting the soldermask opening to the hole size is not good. It needs to be (via holesize + constant). That constant is settable through a rule. Of course, if the via is assigned as fab or assembly testpoint ( top or bottom) then that side is opened fully, the other on closed
- thermal bleed prevention. In a library part i want to be able to specify that a pad is a not only electrical but also thermal . This creates automatically a "via farm" and a lattice pastemask that avoids the via holes. Lattice spoke width , via hole is driven from a rule , or can be set per instance through a dialog.
Backside has option to enable flood th same size as oldersize, and option to create bleedstop-rings in soldermask. That will require me showing you a drawing of such structure. These things are a pain to make by hand , but can be done in code very easily. If the software can do this it solves hours of spit and polish on a design...
- thermal spoke width assignable per net / class / device / pad.
I can throw a collection of nets , or parts in a class. To this class i can apply a rule that, if the via needs thermal spokes into the plane : this is the width, and the plane cartwheel opening. No most cad tools use a uniform width setting for the spokes. That does not make sense for high power traces connecting to the planes. Even achip like the broadcomm used on the rpi has pulsed currents of several amps on several balls.. you cant do that with 4 mil spokes...
- circular thermal / power via stitching. Click on a pad and have the tool place vias around the pad , at a set distance set from the hole , with a given via to via space (driven from rules either global or class based)
Essentially the tool needs to look at the via diameter , add the offset and create an imaginary circle of that number. On the circumference of that circle it places as many vias as possible of a given size ( hole and via size ) using the hole-to-hole clearance rules. Now these cloverleafs have to be made by hand. With this thing you simply specify the objects that need this and the tool injects them ( kind of like teardropping )
You can set rules like:
If (holesize >= 1.2) and (innet [busbar,vcc,gnd,v12]) and (incomponent [c12,c4,c19,relay9]) then createcircularstitch (holesize=0.2mm , padsize = 0.5mm , offset = 2mm hole2hole = 2.1mm)
This would create a stitch only on pins of 1.2mm that belong to components c2 c4 c9 or relay9 , and are wired to any of the given nets. Other nets / pinsizes/ parts are untouched.
It would create acircle of 1.2mm + 2mm = 3.2 mm diameter , with on its circumference vias of 0.2mm holesize and 0.5mm padsize. How many ? ((3.2mm * pi) / 2.1) degrees apart.
I have a truckload of other idea's but you can start with this...
-
"Writing About Music is Like Dancing About Architecture" - I am not trying to reject ideas only differentiate what people are describing from what we already have. If people are willing to help break down the differences more specifically by using what we have now then I can try to bump their ideas up the queue. We have a lot of stuff currently in the works already from greater file format compatibility, and more involved layer management to field solving. I can't prioritize features requested by forum members over those from users and other developers.
-
You have none of what i am describing. It all has to be done manually.
If writing about music is dancing about architecture then you have the equivalent of pen and paper.
-
..[snip]..
We are trying to be more responsive and less antisocial than the gEDA mailing list. If you are interested please join us.
..[snip]..
Editing in situ exists if people don't want to use it that is fine. They can edit the footprints in their library directly. In situ edits only change the one instance and are meant for doing *very* minor *one* *off* changes. Footprints should be drafted to spec. and if deviations are made they should be well documented. That is a user issue not a problem for the layout tool. Users of PCB mainline asked for this feature and they got it, we were not going to remove it from PCB-RND. (I have only used it once.) Insitu editing only lets you change pad/hole sizes and silk screen line thickness. You can't go remaking things completely
There is no fab I have ever seen that prints silk over directly over copper. There is there for no reason to care if someone has drawn silk over copper in their footprints. They are not modifying my data. They don't have the ability to print silk over copper directly.
Yeah, sure....
Free_electron's advice is pure Gold, but you guy's don't want to listen....
No, free_electron's advice is not pure gold. It is 1) aimed at doing very complicated PCBs and/or extremely high volumes and 2) some of his suggestions are already handled by any (decent) PCB manufacturer. There is a big difference between creating a board for a low to medium volume product (say up to 10000 pieces) and creating a board which needs to be reproduced a million times where spending a day on a tedious detail pays off.
Also people who design PCBs have widely varying workflows where some want a glorified MS paint and others want their CAD software to be rigid about everything. You can't really cater to both extremes at the same time.
-
Advice is a mixture of high end and simple. Automatic sliver removel , silkscreen clipping is something that even a hobbyist needs.
There is too much time lost in applying spit and polish - post layout.
Besides that i abolutely hate the way of thinking that "it's for hobby , mspaint will do" that is just bullshit. Hobbyists are always supposed to mess around with sub-par equipment. As a hobbyist that irritates me to no end.
-
I'm not talking about hobbyists but designs for low to medium volume production and prototypes. Every PCB manufacturer which has produced my PCB designs is perfectly capable of clipping solder mask, silk screen and other stuff to their manufacturing capabilities. Why should I bother with that? I'll probably get it wrong anyway and when my design ends up in a different factory I'd have to start allover again to cater for their specifications. Bottom line: leave PCB manufacturing specific post layout stuff to the PCB manufacturer. They get paid for it and are setup to apply their process parameters to a layout with one or two mouse clicks.
The same goes for footprints. I've dealt with lots of different assemblers over the past decades and each and every one of them has a different process and some of my designs are even made by various assemblers. Still a footprint which works fine for company A can be a total nightmare for company B so sometimes a footprint really needs some tweaking but it is rare. In some cases the assemblers apply their own rules to the PCB design when it comes to paste mask openings and other things to optimise the layout for their production process. The bottom line here is (again) to leave manufacturing specific things to the people doing the manufacturing because you generally can't foresee what the exact requirements are. However it helps to figure out what kind of footprints are the most error prone and avoid those (for example the ones with multiple pads underneath) for low to medium volume products. Unfortunately the sales droids will tell you an assembler can solder any package :scared:
You also misread my MS paint remark. Some people hate PCB packages which are too restrictive and many PCBs are so simple you don't need rules for each net or groups, etc so why waste the time to set it all up? Remember that in many small companies the designer of the circuit is also the one designing the PCB or is at least looking over the shoulder of the PCB designer. A couple of years ago I had an interesting discussion with someone who developes small RF-ish circuits. He really wanted a lot of freedom to draw the RF structures without some design rule or whatever kicking in at every corner. His boards where way too simple to use a complex package and be time efficient. To get back on topic: I can understand why some people will want the ability to adjust a footprint in a design without changing the library. It is a workflow which works most efficient for them.
-
This idea of aviding 'difficult footprtins' for low volume is total bullshit.
If i want to use any kind of really cool component i will use it . Even in a one off build.
Why do hobbyists eed to be restricted to bc547 transistors and so style packages ?
This is hampering innovation and the hobbyist.
I a not opposed to editing a footprit in-situ. By all means go ahead. I do understand that people want these things. I use em too. But i also want to be able to run DRC when i am building a footpritn. And have table based structures and have all the other stuff i mentioned.
Again : i do not want to take away any existing functionality. Just add tools and capabilities. Everything i have suggested does not mean breaking existing things or eliminating existing way of work.
There seems to be this notion that there should be only 'one-way' to do a certain thing.
Just give me MORE ways to do a certain thing !
-
This idea of aviding 'difficult footprtins' for low volume is total bullshit.
If i want to use any kind of really cool component i will use it . Even in a one off build.
But be prepared to pay through the nose for the PCB and have a double digit failure rates in production! I've seen it happen a few times already. At one time I had a SoC based project where the QFN version of the power management chip was hard to get. The fine pitch BGA version however was available in large quantities but that needed (IIRC) 60um traces with 40um clearance. The customer asked me to adapt the PCB layout for the fine pitch BGA chip but they soon found out that having the PCB made wasn't economic for the volumes they wanted. In some cases you just have to be realistic about the manufacturability and accept you can't use every component out there.
-
you guy's don't want to listen
:palm:
I'd just like to remind pcb_rnd and the project it was forked from are *both* software, which you download for free, designed by voluntaries and benevolent people. There's nothing as easy as "suggesting features"... until one has to code them. Please allow Rome to be built in more than one week if you keep that in mind.
-
Hiya. Been using geda/pcb for many years - both hobby and professional. Just discovered this so will be sure to give it a whirl on my next project. unfortunately found this just after sending a couple of designs off for fab.
-
Some observations as an almost complete neophyte to any EDA tool:
On my machine from a fresh install/cold start it comes up with the whole app occupying about a 16th of the screen and with the PCB area about an inch square - it's not immediately obvious what to do next.
u and R for undo & Redo, surely, world+dog (just about) uses ctrl-Z for undo and ctrl-Y for redo. There's nothing inherently better about either that pair or u/R but why swim against the tide?
Similarly z/Z for zoom rather than +/- (or ctrl + & ctrl -)
Also, as with the original I note that invoking rubber band moves with "all direction lines" not ticked is broken - it just moves the lines regardless leaving non orthogonal lines after the move. I spent some time hacking the original PCB to fix this - I'll see if I can dig out he code.
-
I like the general direction of the parametric footprints.
One thing i have been looking for in any PCB tool is the ability to drive the entire design parametrically. I.e. the coordinate of a part is the coordinate of some other part plus some variable.
-
I have just tried version 1.2.2 and I like it very much as it looks already. The only thing I've noticed on the GUI side is the lack of tooltips when hovering toolbar buttons — which come from the side toolbox in the "original" pcb application. Is there a problem on my side or is it expected?
-
Some observations as an almost complete neophyte to any EDA tool:
On my machine from a fresh install/cold start it comes up with the whole app occupying about a 16th of the screen and with the PCB area about an inch square - it's not immediately obvious what to do next.
u and R for undo & Redo, surely, world+dog (just about) uses ctrl-Z for undo and ctrl-Y for redo. There's nothing inherently better about either that pair or u/R but why swim against the tide?
Similarly z/Z for zoom rather than +/- (or ctrl + & ctrl -)
Also, as with the original I note that invoking rubber band moves with "all direction lines" not ticked is broken - it just moves the lines regardless leaving non orthogonal lines after the move. I spent some time hacking the original PCB to fix this - I'll see if I can dig out he code.
The key bindings are configurable in the menu file. What you get by default are the ~2 decade old key key bindings, but you are free to change any menu or key binding in the menu file.
Some users want their window manager to take care of the default size and would hate if the app wanted to remember some size, others want the app to remember window sizes and placement. We have support to both, and again this just the default. It is configurable in the preferences.
Window size is like keyboard layout if we change defaults, we may favor new users, but we piss off old users, so there's no good solution here, or at least no better solution than having it configurable, which we already have.
Sorry I did not reply faster. The code for rubber band mode is evolving now. There is a new additional rubber band mode that preserves trace angle and another mode that is targeting microwave layout. More on that in another post on our latest release.
-
I like the general direction of the parametric footprints.
One thing i have been looking for in any PCB tool is the ability to drive the entire design parametrically. I.e. the coordinate of a part is the coordinate of some other part plus some variable.
I have been curious about that too and we are looking at some aspects of it. For it to really work though we would need more expressive metadata from the schematic capture software than just a netlist. I advocated for that on gEDA's side a long time ago. I don't think we will ever get to a totally parametrically generated layout but it would make partially autorouting layouts more attractive.
-
I have just tried version 1.2.2 and I like it very much as it looks already. The only thing I've noticed on the GUI side is the lack of tooltips when hovering toolbar buttons — which come from the side toolbox in the "original" pcb application. Is there a problem on my side or is it expected?
This wasn't a priority for us compared to say updating the manual but you clearly tried the software so our lead developer dropped what he was doing and added some tooltips. It wasn't just you we did not have them. Thanks for the suggestion, people will want the tooltips at least until we get the manual sorted out!
Sadly your feature did not make our latest release but it will be in the next one. Currently if you grab the SVN head it should work.
-
Some observations as an almost complete neophyte to any EDA tool:
On my machine from a fresh install/cold start it comes up with the whole app occupying about a 16th of the screen and with the PCB area about an inch square - it's not immediately obvious what to do next.
u and R for undo & Redo, surely, world+dog (just about) uses ctrl-Z for undo and ctrl-Y for redo. There's nothing inherently better about either that pair or u/R but why swim against the tide?
Similarly z/Z for zoom rather than +/- (or ctrl + & ctrl -)
Also, as with the original I note that invoking rubber band moves with "all direction lines" not ticked is broken - it just moves the lines regardless leaving non orthogonal lines after the move. I spent some time hacking the original PCB to fix this - I'll see if I can dig out he code.
The key bindings are configurable in the menu file. What you get by default are the ~2 decade old key key bindings, but you are free to change any menu or key binding in the menu file.
Some users want their window manager to take care of the default size and would hate if the app wanted to remember some size, others want the app to remember window sizes and placement. We have support to both, and again this just the default. It is configurable in the preferences.
Window size is like keyboard layout if we change defaults, we may favor new users, but we piss off old users, so there's no good solution here, or at least no better solution than having it configurable, which we already have.
Sorry I did not reply faster. The code for rubber band mode is evolving now. There is a new additional rubber band mode that preserves trace angle and another mode that is targeting microwave layout. More on that in another post on our latest release.
I appreciate that it can be hell supporting multiple environments and existing users can get very tetchy when you change the UI on them but sensible defaults for new users are not a bad thing. Apparently nothing I do makes it want to start up at a sensible size and zoom.
User configurations of basic controls is a pain - you end up with no one being able to use your set up and you not being able to use anyone else's (BTDT, got the t-shirt).
Yes, I saw that some work had been done on rubber band mode (and also that the code has changed too much for me to trivially port the work I did to the old program for this). I didn't see why it only worked on line segments which are connected to two others (is that still the case?).
-
Some observations as an almost complete neophyte to any EDA tool:
On my machine from a fresh install/cold start it comes up with the whole app occupying about a 16th of the screen and with the PCB area about an inch square - it's not immediately obvious what to do next.
u and R for undo & Redo, surely, world+dog (just about) uses ctrl-Z for undo and ctrl-Y for redo. There's nothing inherently better about either that pair or u/R but why swim against the tide?
Similarly z/Z for zoom rather than +/- (or ctrl + & ctrl -)
Also, as with the original I note that invoking rubber band moves with "all direction lines" not ticked is broken - it just moves the lines regardless leaving non orthogonal lines after the move. I spent some time hacking the original PCB to fix this - I'll see if I can dig out he code.
The key bindings are configurable in the menu file. What you get by default are the ~2 decade old key key bindings, but you are free to change any menu or key binding in the menu file.
Some users want their window manager to take care of the default size and would hate if the app wanted to remember some size, others want the app to remember window sizes and placement. We have support to both, and again this just the default. It is configurable in the preferences.
Window size is like keyboard layout if we change defaults, we may favor new users, but we piss off old users, so there's no good solution here, or at least no better solution than having it configurable, which we already have.
Sorry I did not reply faster. The code for rubber band mode is evolving now. There is a new additional rubber band mode that preserves trace angle and another mode that is targeting microwave layout. More on that in another post on our latest release.
I appreciate that it can be hell supporting multiple environments and existing users can get very tetchy when you change the UI on them but sensible defaults for new users are not a bad thing. Apparently nothing I do makes it want to start up at a sensible size and zoom.
User configurations of basic controls is a pain - you end up with no one being able to use your set up and you not being able to use anyone else's (BTDT, got the t-shirt).
Yes, I saw that some work had been done on rubber band mode (and also that the code has changed too much for me to trivially port the work I did to the old program for this). I didn't see why it only worked on line segments which are connected to two others (is that still the case?).
You should look at these.
https://archive.org/details/middle-rubber
This is the microwave thing i was talking about.
https://archive.org/details/route-radius
-
You should look at these.
https://archive.org/details/middle-rubber
This is the microwave thing i was talking about.
https://archive.org/details/route-radius
I played with the rubber band changes, haven't see the radius stuff (but had planned on adding something similar myself, just never got to it).
When I looked at it, the line segment you were moving had to be between two others - I can't see the reason for that (when I implemented it I did not have this restriction, you could move the last or first segment and it adjusted the intersection point as necessary).
-
You should look at these.
https://archive.org/details/middle-rubber
This is the microwave thing i was talking about.
https://archive.org/details/route-radius
I played with the rubber band changes, haven't see the radius stuff (but had planned on adding something similar myself, just never got to it).
When I looked at it, the line segment you were moving had to be between two others - I can't see the reason for that (when I implemented it I did not have this restriction, you could move the last or first segment and it adjusted the intersection point as necessary).
The demo video doesn't show it but that works as well. It was the middle use case that was harder to code and so people wanted to show it off more.
-
I started a fresh thread about the new release.
-
I started a fresh thread about the new release.
In some respects that might have been a bad idea. The way that the forum software works there is no universal way to 'subscribe' to or 'follow' a thread without commenting; this results in a lot of 'me too' comments in threads as the only universally effective way of following that thread. If you haven't really changed the subject (and in this case I don't think you have) then creating a new thread invites all this overhead. Nothing you can do about it now, but it's something to think about for next time.
-
Cerebus you have a point but I don't like the way the threads on kicad stretch off into infinity. It makes them impossible to follow over time. Ether way here is an echo of the new threads only post...
A few days ago we released 1.2.4 which adds some new features. The most notable are...
* Eagle Binary Format - pcb-rnd can now read eagle files in the older binary format. We have a few weeks of testing time in on each release but if you find anything wrong with this please report it to us. We are working on exporting this format as well.
* Protel Autotrax/Easytrax Format - pcb-rnd can now import and export this format.
* Subcircuits - You can now draw a bunch of objects and group them as a subcircuit. This is one of a series of additions in our effort to target microwave/rf users. The next step is making subcircuits have their own distinct terminals and etc in netlist. (I would love it if people would test this but not use it in production until we have more done.)
* xy_exporter - now supports templates (we have a few users interested in using commercial pnp services)
Various bugs were also fixed of course.
To be honest I am more excited about our next 2 or 3 releases than this one not just because of subcircuits but other things (yet to be announced) as well.
-
Update:
I've moved this post to better place where pcb-rnd-1.2.6 is discussed, so probaly better place discuss this thing there:
https://www.eevblog.com/forum/geda/pcb-rnd-1-2-6/msg1336004/#msg1336004 (https://www.eevblog.com/forum/geda/pcb-rnd-1-2-6/msg1336004/#msg1336004)
-
From gEDA's mailing list. Think of this as a coming soon post.
Hi all,
a long standing user request is to have thermals on SMD pads, mentioned e.g. in these 13 and 9 years old threads:
http://archives.seul.org/geda/user/Aug-2004/msg00118.html (http://archives.seul.org/geda/user/Aug-2004/msg00118.html)
http://archives.seul.org/geda/user/Jul-2008/msg00411.html (http://archives.seul.org/geda/user/Jul-2008/msg00411.html)
In pcb-rnd we make things happen. This week's minute video demonstrates how to do this with pcb-rnd, using padstacks and a subcircuit:
https://archive.org/details/pcb-rnd-pad-thermal (https://archive.org/details/pcb-rnd-pad-thermal)
It starts with 3 pad stacks and 2 silk lines converted into a subcircuit, terminal names ("pin numbers") assigned to the SMD pads. These steps are similar to how we used to build elements.
Then from 00:30 the thermal tool is used to toggle thermals on each padstack.
The generic polygon shaped padstack is in the video to demonstrate that we are free from special casing and hacks: the rectangular pad is really a rectangular polygon, not a square cap line, and everything (including the thermal tool) works on every object type.
Regards,
Igor2
-
I used GEDA PCB for a lot of years before switching to Kicad because of the faster pace of development and I still have many designs archived that I need to open with PCB-RND now and then.
What is the plan for schematic capture for pcb-rnd? without that in place the whole system is going to fall many years of development time behind Kicad.
-
saike at the moment we support gschem, kicad's eeschema, ltspice, tinycad and mentor (Mentor Graphics Design Capture). We intend to support more and we are aware to grow more we need newer infrastructure than gEDA... a plan is in the works.
-
This isn't a coming soon. This is a HERE NOW. Also from the email list...
Hi,
Over the last year I started working on a library to directly export our geometry from pcb-rnd into OpenEMS. In the course of doing that Koen (one of the contributors to OpenEMS) decided to join our project and he added hyperlinx format support.
The following video shows my recreation of one of his demos of OpenEMS simulating a hair pin (distributed element) filter using pcb-rnd instead of eagle which is what he was using.
https://www.youtube.com/watch?v=f95dbLKmhLQ&t=18s (https://www.youtube.com/watch?v=f95dbLKmhLQ&t=18s)
So yea, we already have one way to simulate RF on boards and we are working on another.
Have fun,
Evan Foss
-
@saike - It's official pcb-rnd is splitting off from gEDA. gEDA is in our rear view mirror.
-
Good, I haven't checked in on PCB-RND for a while. I hope a few more developers come on board now.
-
Yes more people are coming on board. Some from the various factions of gEDA, others from KiCAD, and yet more from parts previously unknown.
-
Is it possible in PCB to remove soldermask from specific traces for copper plating to be reflowed to increase current capability?
Like this:
https://i.ytimg.com/vi/Gy1K3ayPfOk/maxresdefault.jpg
-
Fusion916 Yes that is possible in fact it was one of the reasons I joined the project.
In pcb-rnd we have very good layer system at this point. It's one of the largest advancements we made over the mainline of pcb. It took a lot of work but at this point you can both add and subtract from the solder mask layer. There are several ways to do it.
1. The simple way: Turn visibilty on for the solder mask layers and use the polygon, line, arc, or text tools to draw and the features they create will be subtracted from the solder mask.
2. The subcircuit way: This is for people who want to have things like footprints that use pads as heatsinks (where you want exposed copper but solder paste is optional) or for people who are doing microwave design like hairpin filters.
http://repo.hu/cgi-bin/pool.cgi?cmd=show&node=subc1 (http://repo.hu/cgi-bin/pool.cgi?cmd=show&node=subc1)
On a related note we now have a more functional thermal tool. http://repo.hu/cgi-bin/pool.cgi?cmd=show&node=thermals (http://repo.hu/cgi-bin/pool.cgi?cmd=show&node=thermals)
In the mainline (2014 release of pcb) it was done by making elements that fit over the traces but this was painful, time consuming and very unpleasant to edit.
-
From Igor2 (the lead developer of PCB-RND)
The short answer is: geda/pcb can not do it, pcb-rnd can do it.
The long answer is: the solder mask of pcb-rnd is a layer you can draw on, so you can make arbitrary shaped openings on it. So it is possible to make various shaped openings over traces.
For example I've seen real life examples of traces thickened only in a single narrow line in the middle of the trace or other examples on multiple parallel thin lines on the trace.
Random examples (not drawn with pcb-rnd, but could be reproduced with pcb-rnd):
https://www.eevblog.com/forum/blog/eevblog-317-pcb-tinning-myth-busting/ (https://www.eevblog.com/forum/blog/eevblog-317-pcb-tinning-myth-busting/)
https://www.eevblog.com/forum/projects/pcb-soldermask-question/?action=dlattach;attach=84686;image (https://www.eevblog.com/forum/projects/pcb-soldermask-question/?action=dlattach;attach=84686;image)
https://www.eevblog.com/forum/projects/show-me-your-interesting-pcb-layout-solutions/?action=dlattach;attach=168817 (https://www.eevblog.com/forum/projects/show-me-your-interesting-pcb-layout-solutions/?action=dlattach;attach=168817)
https://i.stack.imgur.com/lZgOc.jpg (https://i.stack.imgur.com/lZgOc.jpg)
(this last one is the grid thing; I guess they are using this to avoid uneven solder distribution, like a huge ball in the middle of a largish polygon)
Regards,
Igor2