sch-rnd-aux knowledge pool

 

DNP and omit

dnp_omit by Tibor 'Igor2' Palinkas on 2023-07-02	Tags: howto, dnp, do, not, populate, omit, no-export, no, export
node source

 

Abstract: sch-rnd has support for DNP (Do Not Populate) and omit (do not export) attributes. This pool node is a guide through the different options of using them.

 

Difference between dnp and omit

Both options are used to manifest different variants (build options) of the same design by controlling how some components (and networks) are exported or built. In PCB workflow context dnp (Do Not Populate) means the footprint is present on the board but the part is not soldered on. Omit means the given object is not exported at all, so the component (or network) does not reach the netlist thus it is not present on the board. These can be regarded as two different levels of removal.

While omit is generic and most workflows shall respect it, dnp behaves differently for different workflows. For example the spice workflow (using export_spice) respects omit but ignores dnp, as there are no two different levels of removing the component. Each export plugin specifies how exaclty it behaves with dnp and omit, in the user manual.

Static dnp or omit

The easiest way to use these attribues is the manual/hardwired attribute set: create a symbol attribute called dnp (or omit ) with any non-empty value. During compilation, the target plugin (e.g. target_pcb, target_spice) will copy this attribute to display/dnp in the abstrat model. When display/dnp is present in the abstract model, the rendering code will indicate it at every concrete object that contributed to the given abstract object (with DNP or a red cross drawn over the component or wirenet). This marking appears in graphical export too.

It is also possible to print the value of these attributes in a dyntext object, e.g. using %a.display/dnp% and %a.display/omit%.

A slightly more advanced usage is to mark a component dnp only for the pcb workflow, oromit a component (or network) only from the pcb or spice workflow. For this set one of the following attributes instead of plain dnp or omit:

• pcb/dnp
• pcb/omit
• spice/omit

This works because at the end it's display/dnp and display/omit that matter, and target plugins (target_pcb, target_spice) will look at workflow prefixed attributes first, then the no-prefix variant. So if pcb/omit is set and target_spice calculates the value of display/omit, it will ignore pcb/omit, looking for spice/omit and plain omit only.

Conditional dnp or omit

It is possible to use project stances (build options) to control dnp and omit by inserting anything in the dnp or omit attribute. A typical example is setting up a conditional forge in an array attribute called forge-if/dnp in a component:

(stance.model == "cheap") || (stance.model == "medium")
scalar,dnp
sub,^,yes,dnp

The "/dnp" in forge-if/dnp is an arbitrary string. The first item of the array is a conditional expression that controls if the forge script (which is the rest of the items) would run. The forge script first ensures there's a scalar dnp attribute then it prepends "yes" to its value. When the project stance model is set to "cheap" or "medium", the forge script runs during compilation and injects "yes" in the dnp attribute of the component.

This will then trickle down through the target_pcb plugin that will copy it to display/dnp which will be picked up by the the rendering code. When target_pcb is used with the default config, the configured white list will set the export name to "dnp" on display/dnp and then export_tedax will export it as a "comptag" with key "dnp" and value "yes" for the given component; this is how the attribute reaches pcb-rnd at ther end.

Every step of the process can be observed in the abstract model dialog, on the right side, after clicking the component:

• the history of the dnp attribute will show the forge plugin has edited it using forge-if/dnp
• the history of the display/dnp attribute will show the target_pcb plugin has created it
• the "exported as" field for display/dnp is "dnp"

Notable corner cases

Operates on the abstract model

Although their input (as any input) is from the concrete model, these mechanisms are operating on the abstract model. A notable example of this is setting omit on a wirenet: the graphical indication, little red crosses, are drawn on the wirenet, but only because the whole abstract net has the omit attribute.

Thus this feature alone can not disconnect a gnd connection from a "pin":

• a symbol's terminal is connected to a gnd symbol using a wirenet, typically a single, straight wire line
• the omit attribute is set on this small wirenet
• the compiler figures the name of this wirenet is gnd, because it is connected to a gnd symbol that has an attribute based connection from its terminal to gnd
• the omit attribute is propagated to the gnd (abstract) net
• the whole gnd network is omitted from the output
• any wirenet on any sheet in the project that contributes to gnd will get the omit marks while rendering

Conclusion: the omit net feature is for omitting a whole network from the output, not for disconnecting a single terminal. There are other means for terminal disconnect.