pcb-rnd feature poll

Currently shown: list all (anonymous visitor)
Search:
show all | top 5 stats

Features

  score name description & my vote
94
stats
[pushshove]
push & shove
The user defines a new forbidden zone (explicitly or implicitly by grabbing and moving existing objects). Automatically move out objects from the forbidden zone by changing and moving them, effectively make room for new objects.

Compatibilty: not affected

start voting

93
stats
[bus]
draw "bus"
GUI feature that lets the user to draw 2 or more parallel traces at predefined spacing. Useful for differential lines.

What makes this relatively easy is the fact that as long as the traces of the "bus" need to be strictly spaced, there can not be any obstacle (vias, other traces) get in between the tracks while drawing. This means the whole process can be considered as drawing a very thick trace: as thick as the width of the "bus". The wide trace is just replaced with parallel traces the moment the user finalizes the line segment (or arc).

Compatibilty: not affected by a pure GUI feature

start voting

57
stats
[clearpolyly]
clear poly flag per layer
Make the Clear Polygon flag a per layer flag for each object. If a trace or via or pin needs to touch one poly and have a clearence to the other, this feature makes that possible as long as the two polygons are on different logical layer. They can be on the same physical layer, tho: a ground trace should touch solder side ground polys but should have a clearence to solder side Vcc polys.

Compatibilty: mainline pcb wouldn't understand this feature and would convert clear polygon flags which would result in either "touch-all" or "clear-all" for the object on the given physical layer.

start voting

46
stats
[splitline]
split line segments by inserting new points
action and GUI/key binding to split an existing segment of a trace into two by inserting a new endpoint at an arbitrary position.

Compatibilty: not affected

start voting

46
stats
[bbvia]
blind and burried vias
each via would have an optional field that'd describe which layers it connects

Compatibilty: mainline pcb wouldn't understand this feature and would convert all vias tru-hole

start voting

42
stats
[tracelen]
better trace length calculations
trace length calculation that:
  • considers overlapping traces
  • consdiers tee junctions
  • displays length on the drawing
  • displays in real-time so manual trace length optimisation is possible

Compatibilty: not affected

start voting

27
stats
[horver]
autorouter: horizontal/vertical (biased)
Some users prefer the classic horizontal/vertical routing: use one layer for horizontal traces and another for vertical traces. More generally, layers should have a direction bias and the autorouter should lay out tracks according to that bias; each direction change is a via. Currently pcb-rnd lacks such a router. There are three potential ways to do this:
  • there's legacy code that converts between pcb and MUCS and runs MUCS' autorouter; this could be converted into a plugin, keeping MUCS external
  • the same plugin, but MUCS code compiled in
  • write a router from scratch

Compatibilty: not affected

start voting

26
stats
[textinv]
inverse text
Be able to write text in inverse, as a cutout on a rectangle. This is useful on silk layer, especially with small fonts and/or toner transfer.

Compatibilty: mainline pcb wouldn't understand this feature and would convert the text to normal

start voting

25
stats
[progdrc]
Programmable DRC
The original/current DRC (Design Rule Checker) applies a set of rules hardwired in the C code. A programmable DRC would instead provide C code to do basic steps of checking (e.g. "is there at least 4 mil spacing between these two objects"?). The actual rules could then be specified using a simple scripting language.

As the number of generic C utilitiy functions would grow, a programmable DRC would enable the following practical features:

  • different/dynamic minimal copper spacing depending on random factors, like distance to a specific component (e.g. increase requred clearance next to the transformer), per network (e.g. 10 mil to gnd, but at least 15 mil to anything else)
  • checking for keep-away (copper-wise: HV/LV insulation; silk-wise: component spacing)
  • checking star topology grounding
  • "keep this net shorter than 15 mm"
  • check if matched length pairs or buses are really matched within whatever margin (e.g. +-5%)
  • ... or even the number of vias on them are matched
  • check if traces of a differential pairs are really kept close together
  • ensure minimum trace width (high current nets)
  • ensure bypass caps are close enough to the corresponding device
  • microstrip and friends: make sure traces for this net have gnd below them on the next layer (including: no gaps)
  • other layer-related checks like "don't ever route this net on an outer layer"
  • enforce component orientation or layer, e.g. "all these buttons should face south" (the actual wording depends on the initial orientation of the footprint or maybe on a vector defined as a sequence of pin numbers)
  • ensure two components are near or far from each other (e.g. don't place the sensitive opamp too near to the HV section), place this component close to the outline layer

All these not via custom C code hand crafted for each specific use case, but because of script fewliners that combine simple checks in the right way. In turn, the DRC script can be generated by the netlist tool, from network or component attributes, using DRC-script templates. This lets the user extend the DRC to cover new cases without having to change or recompile pcb-rnd code.

Compatibilty: mainline pcb wouldn't understand the drc scripts; mainline pcb would ignore or even remove drc scripts from save files. The design could still include old-style drc parameters so the simplest checks could be performed by mainline pcb.

start voting

20
stats
[io_fp_eagle]
eagle footprint load/save
Native support for eagle footprints (load and save).

NOTE: needs more user contribution than just testing (but this doesn't necessarily mean coding)

Compatibilty: not affected (once the footprint is loaded, it gets embedded in the pcb design, mainline pcb won't notice the difference)

start voting

17
stats
[gcode]
test and fix gcode export
Some users have reported bugs about the gcode exporter. With a few testers having real gcode machines available, it would be fun to fix the exporter.

Compatibilty: not affected

start voting

16
stats
[ppgrid]
per project grid settings
Optional grid size array that:
  • is a list of user defined grid sizes and origins
  • is set and stored per project
  • offers actions to changing grid up/down selecting the next/previous item on the array; so if the design wants 5, 10 and 25 mil grids, there'as a hotkey to switch "down" in 25->10->5.

Compatibilty: mainline pcb wouldn't understand this feature; a .pcb file saved with custom grid list embedded would make load error in mainline pcb (but the offending block is easy to remove with a text editor).

start voting

11
stats
[ports]
port to "exotic" systems
Port pcb-rnd to desktop/server systems other than GNU/Linux and windows, e.g. UNIX, BSD, MacOSX. If there are testers, I am willing to port to your favorite system.

Compatibilty: not affected

start voting

11
stats
[bindist]
autobuilt binaries
Autobuild binary packages for your favorite distribution (.deb, .rpm, windows installer, etc.)

Compatibilty: not affected

start voting

10
stats
[io_fp_kicad]
kicad footprint load/save
Native support for kicad footprints (load and save).

NOTE: needs more user contribution than just testing (but this doesn't necessarily mean coding)

Compatibilty: not affected (once the footprint is loaded, it gets embedded in the pcb design, mainline pcb won't notice the difference)

start voting

4
stats
[webui]
cloud pcb-rnd: web HID, run on a server
Provide a web HID; pcb-rnd core would run on repo.hu and the UI in the user's browser. Most probably this would be realized with:
  • html5 canvas on client side
  • javascript on the client side that handles zoom, pan, crosshair and layer selection
  • a HID that acts as a minimalistic web server generating the code/data required for html5 drawing the layers
  • menus and layer selection in plain html around the canvas

Compatibilty: not affected

start voting

4
stats
[handheld]
Port to handheld devices (smartphone, tablet)
Produce a version that runs on android and acts at least as a viewer, but preferably as a full featured editor. Most probably requires a new HID optimized for android.

Compatibilty: not affected

start voting

3
stats
[fileform]
file format plugin
  • (DONE: create a plugin-API for load/save, called io)
  • (DONE: move the current .pcb parser and save code to a plugin (called io_pcb))
  • add lihata variant (called io_lihata)
  • depending on the immediate need of the testers signed up, add io_json and/or io_xml and/or other formats

NOTE: file formats do not solve the problems of internal representation of pcb data; thus it won't automatically bring blind/burried vias, better stackup handling, text-in-footprints, etc.

Compatibilty: not affected; the original pcb file format is kept, only the code is moved to a plugin; new file formats are obviously not loaded by mainline pcb.

start voting

2
stats
[qucs]
QUCS import
QUCS->pcb-rnd forward annotation path. Either using the import schematics plugin, or by providing an alternative to gsch2pcb.

Compatibilty: not affected

start voting

1
stats
[textln]
manual text line width
be able to manually change width of text lines, regardless of the font size

Compatibilty: mainline pcb wouldn't understand this feature and would convert the text to the default line width

start voting

0
stats
[windows]
windows port
Port pcb-rnd to windows using the gtk HID.

Compatibilty: not affected

start voting

0
stats
[ttf]
native support for true type font
Write with true type font, on silk, on copper. To handle all corner cases, this needs some infrastructure:
  • possibility for more than one font set to be embedded in the .pcb - this enables the user to use the original font or multiple ttf fonts
  • old-style fonts are static, ttf fonts are dynamic (see below)
  • writing new text would use a global "current font" setting; this selects which one of the multiple font sets should be used
  • an action to allocate a new set and bind it to a ttf
  • sparse embedding: embed only the symbols that are actually in use (don't grow the .pcb file to megabytes with 15 Unicode snowmen glyphs)
  • if the font is dynamic new glyphs are allocated as needed, e.g. the first time the user writes letter 'Q', it needs to appear in the sparse embedded version of the font; this means the ttf glyph for 'Q' is vector-rendered to letter 'Q' of the embedded font assigned to the ttf
  • the current font rendering code doesn't change except dealing with multiple fonts
  • font info would be stored as an attribute to the text object, so mainline pcb would preserve it (but would kill the embedded font set!)
  • to minimize such compatibility issues with mainline, ttf glyph would be rendered into the same font size as the default font, so replacing any ttf text with the default font would cause only small differences in copper

Having all glyphs in use embedded in the design means the design can be saved and loaded on another system without risking any "copper change" due to:

  • missing ttf file
  • different version of the ttf file
  • different ttf file with the same name
  • some clever ttf lib mechanism finding a substitution ttf for a missing ttf
  • different ttf lib version, host architecture, etc. causing slight differences in ttf rendering

The risky part starts when one edits text and starts using glyphs not embedded; in this case the ttf is used again to import the new glyphs. This can be overcome by an action that lets the user embed the basic alphabet or whatever glyphs, even if they are not currently in use.

Compatibility: mainline pcb wouldn't understand multiple fonts and would render everything with the default font. While font type attributes would be preserved with text objects, mainline pcb would probably remove the embedded glyphs of dynamic fonts - forcing pcb-rnd to re-embed them on the next load (reducing "copper-stability" vs. ttf file versions).

start voting


 
SUBMIT VOTE