Part names with minuscules in eeschema cause filtering issues in CvPcb

[carloscuev]

Application: CvPcb
Version: 4106 (initially noticed since many revs before)
Platform: Windows 7 64-bit
Options: USE_PCBNEW_NANOMETRES=ON, KICAD_GOST=ON

Description: When placing parts with names that contain minuscules in Eeschema, all the minuscules become mayuscules, for example: "P1x12" gets placed as "P1X12", this could be not a problem if just the "Value" field was modified, but the problem is that the part identifier in the "components" section of the netlist gets written also in mayuscules, in the "libparts" section it gets written correctly with minuscules. Which causes that CvPCB cant find a libpart inside the netlist for the component, ando not filtering footprints.

Steps to reproduce:
1. Create a part in eeschema with name P1x12 and add some footprint filters that would get filtered results using any available module files.
2. Create a schematic using that part and generate netlist.
3. Open netlist in text editor and see that the part identifiers for the "components" and "libparts" section get written different.
4. Open CvPcb and try to assign footprint to that component, notice how component footprints don't get filtered.
5. Open text editor again and get the two part identifiers with the same name, whether mayuscules or minuscules.
6. Try step 5 again and now notice that CvPcb filters correctly the footprints.

[carloscuev (carloscuev)]

Here's a screenshot:
http://img221.imageshack.us/img221/9140/kicadbugmayusminus.png
in green squares: Correct identifier with minuscule letter
in red squares: Incorrect identifier with all mayuscules

[Wayne Stambaugh (stambaughw)]

On 4/25/2013 7:05 AM, carloscuev wrote:
> Here's a screenshot:
> http://img221.imageshack.us/img221/9140/kicadbugmayusminus.png
> in green squares: Correct identifier with minuscule letter
> in red squares: Incorrect identifier with all mayuscules
>
The solution is simple. The result of the solution is not. Two
potential problems exist. Eeschema is converting the component
footprint name to upper case but not the name read from the component
library. That's why there is a mismatch in the netlist file. The
filtering in CvPcb is performing a case sensitive compare which causes
problem you are seeing. A case insensitive compare would solve your
immediate problem in CvPcb but would only push the problem further down
the stack to Pcbnew. I believe this netlist will fail when you attempt
to read it into Pcbnew. The real issue is should we be case insensitive
or not. My preference is case sensitive but that has it's own set of
drawbacks. I may just patch the comparison in CvPcb and Pcbnew but it
would be a temporary solution. Getting everyone to buy into a case
sensitive KiCad and making all of the necessary changes is going to be a
long term fix.

[jean-pierre charras (jp-charras)]

I agree this is a long term fix.
If we take in account the footprint library table changes work in progress, my preference is also case sensitive, and do not fix this very minor issue, with is very easily solved by users.

[carloscuev (carloscuev)]

Isn't it easy just to disable eeschema to upper case all the letters when placing new component? I thought it was.

I've just checked that this happens only in advanced netlist format, the legacy works well because the footprint filters are identified for a specific part reference, not part name as the advanced format does.

Also just checked that Eechema as far as I've used Kicad (since rev 3044) has been converting part names to all mayus.

Btw, I also prefer case sensitive, but will be using legacy format for now because I have lots of part names with minuscule letters and really like the footprint filtering option.

[Dick Hollenbeck (dickelbeck)]

On 04/25/2013 01:06 PM, jean-pierre charras wrote:
> I agree this is a long term fix.
> If we take in account the footprint library table changes work in progress, my preference is also case sensitive, and do not fix this very minor issue, with is very easily solved by users.
>

Wayne,

How are we impacted by the fact that Windows is not case sensitive on filenames, but linux
is, and the effect of this on files residing in a *.pretty dir?

Windows would disallow two files of same spelling with different case correct? Linux not.

Or is there a modern Windows file system option now that they've had 20 years to see how
real operating systems work?

[Wayne Stambaugh (stambaughw)]

On 4/25/2013 2:10 PM, carloscuev wrote:
> Isn't it easy just to disable eeschema to upper case all the letters
> when placing new component? I thought it was.
>
> I've just checked that this happens only in advanced netlist format, the
> legacy works well because the footprint filters are identified for a
> specific part reference, not part name as the advanced format does.
>
> Also just checked that Eechema as far as I've used Kicad (since rev
> 3044) has been converting part names to all mayus.
>
> Btw, I also prefer case sensitive, but will be using legacy format for
> now because I have lots of part names with minuscule letters and really
> like the footprint filtering option.
>

I'll update the status as won't fix and users should continue to use the
old netlist file format until the footprint library table code is
implemented. I will convert all of KiCad to be case sensitive as part
of the implementation. This will also remove the conditional case
sensitivity build option. I hope everyone understands that this *will*
likely break any existing schematics where the case of the footprint
library name has lower case letters. It also means that filtering and
searching *will* be case sensitive so in this case of this bug report
P1X12 is not the same as P1x12.

[Wayne Stambaugh (stambaughw)]

On 4/25/2013 2:29 PM, Dick Hollenbeck wrote:
> On 04/25/2013 01:06 PM, jean-pierre charras wrote:
>> I agree this is a long term fix.
>> If we take in account the footprint library table changes work in progress, my preference is also case sensitive, and do not fix this very minor issue, with is very easily solved by users.
>>
>
> Wayne,
>
> How are we impacted by the fact that Windows is not case sensitive on filenames, but linux
> is, and the effect of this on files residing in a *.pretty dir?
>
> Windows would disallow two files of same spelling with different case
> correct? Linux not.
>
> Or is there a modern Windows file system option now that they've had 20 years to see how
> real operating systems work?
>
It depends. If the user's file system is NTFS, there is a way to make
it case sensitive but it's disabled by default. I doubt many users
enable it. I could use wxFileName::IsCaseSensitive() (assuming that it
works properly) to test for case sensitivity and take the appropriate
action in PCB_IO::FootprintSave(). Otherwise, creating a pretty
footprint on Windows with the same file name spelling irregardless of
case will overwrite the existing footprint without warning. I doubt the
user will be expecting this.

[carloscuev (carloscuev)]

Understood, with legacy format I'm totally ok for the moment, nice to know this issue will be non existent with the footprint library table feature, can't wait to try it! Thanks to all of you for your work, I'll keep helping doing the only thing I can, that is reporting bugs.

Regards.

[Wayne Stambaugh (stambaughw)]

I changed my mind. I'll make the status confirmed, the priority low, and assign the bug to myself since I will be effectively fixing it during the footprint library table implementation.

[Wayne Stambaugh (stambaughw)]

On 4/25/2013 3:20 PM, carloscuev wrote:
> Understood, with legacy format I'm totally ok for the moment, nice to
> know this issue will be non existent with the footprint library table
> feature, can't wait to try it! Thanks to all of you for your work, I'll
> keep helping doing the only thing I can, that is reporting bugs.
>
> Regards.
>
Thank you for your bug report. They are important and this is a good
bug report. One tip to make reporting bugs easier is select "Copy
Version Information" from the "Help" menu on any KiCad application and
paste the contents into your bug report. This gives developers a lot of
useful information and saves you time of having to look it up yourself.
 Here is what the release build on Windows looks like:

Application: KiCad
Version: (2013-04-25 BZR 4110)-testing
Build: wxWidgets 2.9.4 (wchar_t,compiler with C++ ABI 1002,GCC 4.7.2,wx
containers,compatible with 2.8)
Platform: Windows 7 (build 7601, Service Pack 1), 64-bit edition, 64
bit, Little endian, wxMSW
Boost version: 1.53.0
Options: USE_PCBNEW_NANOMETRES=ON
         KICAD_GOST=OFF
         USE_WX_GRAPHICS_CONTEXT=OFF
         USE_WX_OVERLAY=OFF
         KICAD_SCRIPTING=OFF
         KICAD_SCRIPTING_MODULES=OFF
         KICAD_SCRIPTING_WXPYTHON=OFF

[xzcvczx (xzcvczx)]

@Wayne has this been resolved since the move to fp-lib-table?

[Wayne Stambaugh (stambaughw)]

I think so but I cannot remember if I tested it. If someone has time to
test it, I would appreciate it.

On 5/23/2016 6:26 PM, Simon Wells wrote:
> @Wayne has this been resolved since the move to fp-lib-table?
>

[Jeff Young (jeyjey)]

Tested with "Si4532DY". Netlist written correctly:

    (comp (ref Q7)
      (value Si4532DY)
      (footprint Housings_SOIC:SOIC-8_3.9x4.9mm_Pitch1.27mm)
      (datasheet https://www.fairchildsemi.com/datasheets/SI/SI4532DY.pdf)
      (libsource (lib transistors) (part Si4532DY))
      (sheetpath (names /) (tstamps /))
      (tstamp 5ACA80FA)))

and footprints filtered correctly in CvPcb.