After gsch2pcb, pcb fails to open the new pcb file

Another test, created a new pcb file and manually copied the elements loaded into the .new.pcb file by gsch2pcb, and again the pcb program fails to open the pcb. The elements are all standard elements from the geda tree.

Running it from the command line, here is the error message:

LoadPCB: Failed to load existing file "TDAQ_LT1226CurrentAmpBoard.pcb". Is it supported PCB file?

Note that before copying the element files into it, pcb opened the file without problems.

Found the source of the problem. There are three bugs that come together to produce this behavior

1) The footprint files "DIODE_LAY 300.fp", and other in different sizes, have a space in the file name.

2) The space in the file name breaks gsch2pcb, resulting in corrupted elements in the pcb file.

3) The pcb file, on encountering the corrupt elements, outputs no error message, except to say it cant load the file.

Thanks Mitch.

Point 1 is sort of iffy. In general, it would be nice to support spaces in filenames. Whether we like it or not, the computing world is moving in a direction where it is expected that you can do this.

Point 2 is the real problem here, that gsch2pcb doesn't produce the correct output as a result of there being a space in the footprint filename. The bug is in the gsch2pcb.scm gnetlist backend... written in scheme... Maybe I can get one of the gschem/gnetlist developers to fix this.

Point 3 is a bug in pcb, that pcb provides no explanation as to why it failed to load the file. Unfortunately, this may be a difficult bug to fix as our parser is not easy to work with. I'll have to dig into this at some point, but it's going to take a fair bit of time to work out.

Possible workarounds:
1. Forego putting the footprint into gschem, and then add the footprint manually in pcb using File > Load element data to paste-buffer and then renaming the element with the correct refdes.

2. Create a copy of the offending footprint files, rename them without spaces, label the parts with those footprint names in gschem, and then point gsch2pcb at your local footprint library with the renamed parts.

I am using the ALF footprints for the diode. Those are pretty good.

The DIODE_LAY footprints have another "gotcha", the drill holes are too small.

> 2) The space in the file name breaks gsch2pcb, resulting in corrupted elements in the pcb file.

Could you please provide me with an example broken output file, as well as a manually patched working output file, so I can fix this in gsch2pcb?

Sure, please see attached.  Chad asked me for this also.

It might be of interest that gsch2pcb from the fedora repository did not
fail in this way, even though it shows the same version number.

On 05/22/2018 05:04 PM, Roland Lutz wrote:
>> 2) The space in the file name breaks gsch2pcb, resulting in corrupted
> elements in the pcb file.
>
> Could you please provide me with an example broken output file, as well
> as a manually patched working output file, so I can fix this in
> gsch2pcb?
>

> Sure, please see attached.

Which is which?

> It might be of interest that gsch2pcb from the fedora repository did not fail in this way, even though it shows the same version number.

This is weird. Are the gnet-gsch2pcb.scm files identical?

Oops, wrong attachment.  Here is the correct attachment.  The pcb file
has the errant element, see line 44.

The scm files are different.  Please see second attachment.

On 05/22/2018 06:28 PM, Roland Lutz wrote:
>> Sure, please see attached.
> Which is which?
>
>> It might be of interest that gsch2pcb from the fedora repository did
> not fail in this way, even though it shows the same version number.
>
> This is weird. Are the gnet-gsch2pcb.scm files identical?
>

> Here is the correct attachment.

The files are identical, just differently named.

> The scm files are different. Please see second attachment.

I have run both versions of gnet-gsch2pcb.scm on your example schematic and got the same output:

    ...
    PKG_JUMPER1.fp(JUMPER1.fp,CONN1,unknown)
    PKG_JUMPER1.fp(JUMPER1.fp,CONN2,unknown)
    PKG_DIODE_LAY(DIODE_LAY-300.fp,D1,unknown,300.fp)
    ...

> gsch2pcb from the fedora repository did not fail in this way

Could you please provide me with the correct output from the Fedora gsch2pcb?

More specifically, should the output be

    PKG_DIODE_LAY 300(DIODE_LAY-300.fp,D1,unknown,300.fp)

or

    PKG_DIODE_LAY_300(DIODE_LAY-300.fp,D1,unknown,300.fp)

or

    PKG_DIODE_LAY-300(DIODE_LAY-300.fp,D1,unknown,300.fp)

or something else?

There is a pcb file, in the zip file, that has the errant output.

On May 23, 2018 7:01 AM, "Roland Lutz" <email address hidden> wrote:

> More specifically, should the output be
>
> PKG_DIODE_LAY 300(DIODE_LAY-300.fp,D1,unknown,300.fp)
>
> or
>
> PKG_DIODE_LAY_300(DIODE_LAY-300.fp,D1,unknown,300.fp)
>
> or
>
> PKG_DIODE_LAY-300(DIODE_LAY-300.fp,D1,unknown,300.fp)
>
> or something else?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1771726
>
> Title:
> After gsch2pcb, pcb fails to open the new pcb file
>
> Status in pcb:
> Confirmed
> Status in geda package in Ubuntu:
> New
>
> Bug description:
> New design, run gsch2pcb on the gschem file and produces a pcb file.
> pcb fails to open the file, or rather it closes immediately without
> displaying anything
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/pcb/+bug/1771726/+subscriptions
>

Hi Dr M,

Regarding #5: AFAICT this was reported in LP699286 (https://bugs.launchpad.net/pcb/+bug/699286) and released in pcb-4.0.0.

Can you tell us which version of pcb you are using ?

Kind regards,

Bert Timmerman.

Your link opens to a bug entitled "ALF footprint drill holes too tight"

That is almost completely not related to this bug.

If you follow the discussion change you will see that will found what is
causing the problem, and its being worked on as far as I know.

Its the footprint files that have a space in their name.  For a recent
build of the gsch2pcb, this results in a corrupted pcb file.

On 05/29/2018 03:14 PM, Bert Timmerman wrote:
> Hi Dr M,
>
> Regarding #5: AFAICT this was reported in LP699286
> (https://bugs.launchpad.net/pcb/+bug/699286) and released in pcb-4.0.0.
>
> Can you tell us which version of pcb you are using ?
>
> Kind regards,
>
> Bert Timmerman.
>

Hi guys-

I just wanted to check in on this and see if it's been resolved.

Dr. M-

I think Bert's above comment (post #13) was in reference to the "gotcha" you mentioned in your earlier message (post #5). So, it may not be quite as out-of-the-blue as it seems.

Can you please confirm the various versions of the tools that are creating the issues? I'm having trouble reproducing it myself, so, it may have already been fixed.

The other thought that occurred to me was that the library footprint could have become corrupted. I think that you were testing some of the other bugfixes I was working on, so, if your footprint file happened to be corrupt, it might have been fixed by installing my bugfix work.

Roland-

Regarding the output in #10 above, where is that? The problematic output, I believe, was in the .pcb files produced by gsch2pcb. When I run it myself (gsch2pcb -V reports 1.6), I get an element in the resulting pcb file defined this way:

Element(0x00 "DIODE_LAY-300.fp" "D1" "unknown" 0 0 0 100 0x00)
(
 Pin(0 150 50 30 "1" 0x101)
 Pin(300 150 50 30 "2" 0x01)
 ElementLine(0 150 100 150 10)
 ElementLine(200 150 300 150 10)
 ElementLine(100 150 200 100 10)
 ElementLine(200 100 200 200 10)
 ElementLine(200 200 100 150 10)
 ElementLine(100 100 100 200 10)
 Mark(0 150)
)

I believe Dr. M was getting the following corrupted output:

Element(0x00 "DIODE_LAY-300.fp" "D1" "unknown" 20 0 100 0x00)
(
 Pin(0 50 30 "1" 0x101)
 Pin(300.fp 50 30 "2" 0x01)

 ElementLine(0 10)
 ElementLine( 300.fp 10)

 ElementLine( 10)
 ElementLine( 10)
 ElementLine( 10)
 ElementLine( 10)
 Mark(0 )
)

I apologize for not being much help on this... I've been so buried in the pcb core that I haven't actually dug into footprint libraries, or the import process.

Thanks for your help tracking this down.
--Chad

Status changed to 'Confirmed' because the bug affects multiple users.