gnetlist ignores symbols without pins

Bug #1288906 reported by Bdale Garbee
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gEDA
In Progress
Medium
Patrick Bernaud

Bug Description

I would like to have symbols in a schematic for purely mechanical parts that have no associated footprint or netlist connections, but would be included in the bill of materials. I realize this is "abusing" the netlist in a way, but for projects where there are only one or two such parts (like a snap-together plastic case for the board), being able to capture part attributes visibly in the schematic without having to do something outside the normal process can be very useful. In the process of investigating alternatives for accomlishing this, I've run into what DJ and I both think is a bug in gnetlist.

If you include a symbol in a schematic that has no pins, gnetlist is silent about the existence of the symbol. It is not included in the bill of materials, and is not included in DRC output.

If you include a symbol in a schematic with exactly one pin, and that pin is unconnected, the symbol is included in the bill of materials and the DRC complains about the unconnected pin. If you connect that pin to some net or to an explicit no connect symbol, the part remains in the bill of materials and the DRC goes quiet as expected.

If you include a symbol in a schematic with exactly one pin, where the type of that pin is 'nc', gnetlist is silent about the existence of the symbol. It is not included in the bill of materials, and is not included in the DRC output.

It seems like a bug that gnetlist goes silent on a part that has no pins, or has only pins with type 'nc'. I would have expected all symbols to show up in the bill of materials. I'm not sure what I expected to see in DRC output, but I didn't expect to see nothing at all when a symbol existed with no pins or with only pins of type 'nc'.

Tags: gnetlist
tags: added: gnetlist
Revision history for this message
Bdale Garbee (bdale) wrote :

While trying to come up with a minimal test case, I realized that I was wrong. The problem wasn't presence or absence of a pin on the symbol, the problem was that if there's no refdes assigned the symbol is silently ignored. It seems that it would be useful to throw a warning if a symbol is found with no refdes, but I'm not inclined to push that rope.

I also discovered in the process that the scheme for gnetlist -g drc breaks if there are no nets in the schematic. I found this by adding 3 symbols to a schematic page and trying to run drc on the page without connecting anything up. This is probably worth fixing, but isn't really related to my original complaint.

Revision history for this message
Patrick Bernaud (patrickb) wrote :

gnetlist does have a test for component missing a refdes and should print a warning. However under certain conditions the test is skipped and the message is not displayed. The patch attached should fix this particular problem.

I will look at the other issue.

Changed in geda:
assignee: nobody → Patrick Bernaud (patrickb)
status: New → In Progress
Revision history for this message
Peter TB Brett (peter-b) wrote :

Hi Patrick, I've committed your patch.

Peter TB Brett (peter-b)
Changed in geda:
importance: Undecided → Medium
Revision history for this message
gpleda.org commit robot (gpleda-launchpad-robot) wrote :

A commit was made which affects this bug
git master commit 16535799b3970540a4bf215c61791ec2bd70313d
http://git.geda-project.org/geda-gaf/commit/?id=16535799b3970540a4bf215c61791ec2bd70313d

commit 16535799b3970540a4bf215c61791ec2bd70313d
Author: Patrick Bernaud <email address hidden>
Commit: Peter TB Brett <email address hidden>

    From 49ff7d9d496d0ea8d5dd0756ff4a377fd742255b Mon Sep 17 00:00:00 2001
    Subject: [PATCH] gnetlist: Fix warning for components without refdes.

    When traversing objects searching for components, a variable was not
    reinitialized properly. After the discovery of a graphical object,
    the warning was disabled for any subsequent component missing a
    refdes.

    Affects-bug: lp-1288906

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.