On 11/20/2013 12:48 PM, Wayne Stambaugh wrote: > On 11/19/2013 5:23 PM, Edwin van den Oetelaar wrote: >> Testing library view in CvPCb. >> Latest bzr. >> >> EuroBoard_Outline >> View Selected Footprint window active. >> I have the 3D viewer open. (error does not happen when 3D is closed) >> >> Select: >> EuroBoard_Outline:EuroBoard160mmX100mm or >> EuroBoard_Outline:EuroBoard160mmX100mm_holes >> >> happens also with >> PFF_PSF_PSS_Leadforms:PFF_Leadform_5pins >> >> >> Get error message : >> ----- >> IO_ERROR: Unable to find the next segment with an endpoint of (0 mm, >> -99.9998 mm). >> Edit Edge.Cuts perimeter graphics, making them contiguous polygons each. >> from /home/oetelaar/kicad_sources/kicad.bzr/pcbnew/specctra.cpp : >> ThrowIOError() : line 120 >> >> Unable to calculate the board outlines. >> Therefore use the board boundary box. > > I confirmed this. All of these footprints are defined with an unclosed > PCB edge cut area. That explains the 3D error about contiguous > polygons. There is also PCB_LINE_T assertion in debug builds because > technically footprints are not allowed to have PCB edge cut layers. At > some point, this will probably be fixed so that any PCB edge cuts will > be merged with the board edge cuts to create the final board outline. > As of right now, you are taking your chances by defining footprints with > PCB edge cuts. > > >> ----- >> >> More serious (I think, something with the embedded slash char) >> Select: SMD packages >> Select: SMDHD/VF >> >> Get error message: >> ----- >> IO_ERROR: lib table contains no logical lib 'VF' >> from /home/oetelaar/kicad_sources/kicad.bzr/common/fp_lib_table.cpp : >> FindRow() : line 592 > > Using path separators in module names was not an issue in the legacy > file format. With the pretty format, it will cause the file path to be > incorrect. I have it on my todo list to add filtering to prevent new > modules names from containing illegal file name and path characters. I > will have to add this test when converting other library formats to the > pretty format. My guess is this is what happened in this case. For > now, we will have the fix them by hand as we come across them. > Hopefully there wont be too many of them.
We ran into that in the EAGPLE_PLUGIN. The simplest solution was to simply lie about the name encountered when loading the footprint. This is done in function static bool fix_eagle_package_name( string* aName ) in the eagle plugin. But it now looks like the strategy could have general applicability, including in LEGACY_PLUGIN. The advertised names are converted before even using them, from FootprintLoad() or cacheLib(). This is the chosen path for EAGLE anyways. Note that it was not good enough to do a character to character swap. That lead to a duplicate footprint name. No foolin', murphy is always in charge. We were swapping '/' with say '-'. But then ran into a library with say both 'XYZ/' and 'XYZ-' in the same library! Back to the drawing board. What's now in place is a URL encoding like substitution. Nobody would ever name their footprint 'XYZ%2f' would they? Please say no, because finding a unique name is the goal. After one read / write cycle, a person can always use the module editor to rename anything with a % in it. Or in the case of pretty, just a file manager. Dick _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
