CvPcb footprint loading error


#1

Hey guys,

Today, I got an error when trying to associate components with footprints,

Errors were encountered loading footprints:
PARSE_ERROR: Expecting ‘circle, rectangle, oval, or trapezoid’ in input/source ‘https://github.com/KiCad/Connectors.pretty’ line 34 offset 14 from C:/Jenkins/workspace/windows-kicad-msys2-stable/src/kicad/common/dsnlexer.cpp : Expecting() : line 369

I installed KiCad about 2 days ago, and I used CvPcb before and never had any problems.


PCBNew Giving Parse Error
#2

Ah, the Curse of the Nightly Build plus the Curse of the Online Library team up to strike again!

Someone has pushed a module that uses roundrect pad type, this is not yet supported in 4.0.x (the offending module is SMA_SMD_Jack_Straight.kicad_mod).

Raise an issue on the github perhaps.


#3

I encountered this also, though from a different context, and have raised this issue against the repo:


#4

Is there a git commit test set up so that this type of error can be caught at commit time…

or possibly each kicad_mod file includes a ‘required feature’ spec that indicates which tells the librarian which features - e.g. roundrect - this component requires, and so can avoid loading…?


#5

There is a set of rules KLC plus some python scripts that are run by Travis (or user). I don’t think they have a compatibility check, but they could.

I think a flaw in the current footprint data is that there is no versioning of any sort, unlike the pcb and schematic files which at least have a version number.


#6

It seems this has not happened before. (That’s why nobody added a rule to the klc about that. This is also the same reason why no automatic check for that exists yet.)

Because of this problems i made the suggestion to add a rule about that to the next klc.
A automatic check for that should be easy to implement.

If we don’t find a good solution, there will be a real problem during the transition time from kicad 4.x to kicad 5.x.


#7

@SchrodingersGat just committed a fix:


#8

It would be very helpful if KiCad could gracefully “reject” a footprint that it doesn’t know how to use, rather than bringing the entire library down with it.

I am going to implement a compatibility check to the scripts. I’m just waiting for a comprehensive list of “incompatible” features from the devs so I can do it all in one hit.


#9

The fix has been merged. The library should now work again.