pcb-rnd knowledge pool

 

Mass-change of object properties

mass_chg by Tibor 'Igor2' Palinkas on 2017-01-07

Tags: howto, edit, scripting, scripted

node source

 

 

Abstract: For mass-changing object properties, pcb-rnd offers different approaches, which are each described, pros and cons.

  Imported from the mailing list archives.

Unfortunately line based processing is unsafe for tree structured files like lihata files. It's the same problem as with any other structured files (like xml, or C source code).

1. using the GUI

These features are not very well tested in practice, but are available for a very long time already: use the advanced search to select all interesting object. You can easily craft a search expression that selects all top copper objects. You even get a GUI if you don't want to learn the query syntax (which is among the few things that are really well documented in pcb-rnd). Once you have your mega-selection, use the property editor (ctrl-e) to change the clearance of all selected object to fixed value.

2. using the CLI

The above features, both the query based selection and the property edition are accessible from the command line, without any GUI or dialog box involved. What you want to do can be done by executing two action calls. Can be done even from the batch HID, fully automatically. Which means you can easily write a shell script that runs pcb-rnd, loads your design, searches-and-selects, change properties, save and exit. Which means you get a shell script converter tool that is guaranteed to understand any past or future file format. It's just written in pcb-rnd action script, not in awk.

3. using built-in scripting

Use scripting from within pcb-rnd; gpmi is not in good shape at the moment, so this probably won't work out-of-the-box. When it used to work a year ago, it was like this: you could write, in one of 10 languages, awk included, a script that ran within pcb-rnd and accessed and manipulated data right in the memory. So it's like writing a plugin not in C but in your favorite language. You could have written a script that iterated on top copper objects and changed clearance.

One of my plans for 2018, especially after finishing the data model switchover, to get sciprting to work again. It's a stretegic field where pcb-rnd can easily beat any other PCB package (because even if they support scripting, they usually support only one language).

Background: unfortunately the user demand behind scripting turned out to be much lower than the user demand behind the data model rewrite and I/O plugins. Meanwhile I started to replace gpmi with fungw+puplug. The full history is that I originally had gpmi scripting as a plugin, on top of pcb first (circa 2010 or so) then on top of pcb-rnd. But I always felt like it was a waste that gpmi had a much better plugin arch than pcb (or later pcb-rnd) had. So I felt the good choice is not putting gpmi on top of pcb but put pcb on top of gpmi. I figured soon enough that it was hopeless to get mainline to accept this, so I went with the gpmi-on-top-of-pcb approach. Then after the pcb-rnd fork, I realized the way to swap the stack is to split gpmi in two separate libs: one that does the plugin system only, puplug, and another that does the call dispatching only, fungw. This way it was easier to replace the old plugin system in pcb-rnd, we already use puplug for a long time, but becuase of the low user demand, fungw is not up to speed yet.

4. external scripting: tree parsing

Use a language that really parses and understands the lihata document tree; at the moment we don't have too mnay bindings for lihata, but lihata is so small and trivial that it's rather easy to implement new bindings. The only one direct language binding is to php. But what we also have is fungw binding, which allows automatic binding to any language fungw supports. This is not a long list yet: a somewhat tested lua binding and untested libmawk and tcl bindings. I would happily accept contribution to fungw language bindings!

5. external scripting: lhtflat

Partial solution: lhtflat; lhtflat is an utility distributed with lihata. It properly parses a lihata document and renders it in a different, flat text file format that is suitable for line based processing. It was invented exactly for the case when you want to use awk (or other languages that don't yet have lihata bindings). The solution is partial, because we don't yet have a way to convert a flat file back to lihata - so you can use ti to read out values but not to make modifications.

5. external scripting: line based processing

Use a line based processing and depend on the formatting of the file (a bit risky - not recommended! ); Peter Stuge posted and excellent example.

It will work most of the times, but there would be some files on which it breaks. For example it is possible to write '{' or '}' in text strings in lihata, and such a script will not understand that and will think it's an opening or closing brace; it's also possible to assing the clearance value with '=' or without '=', or to protect the value with {}. You can also have a protected newline (backslash and newline) in between any two field. If you want to go this way, I recommend using the 'save as' function in pcb-rnd first, with a new file name, to get a relatively clean formatting.

Background: the decision for such a non-line-based format was hard (back in 2017) - I love to write awk scripts too, all our web services are based on CGI scripts running awk scripts deep inside. But I had to realize the limitations of the old file format could not be solved unless we switched to a format that has named fields and can represent arbitrary deep trees easily. I accepted this mostly because I knew I'd provide the options listed below.