kicad-developers team mailing list archive

["Brian Piccioni" <brian@xxxxxxxxxxxxxxxxxxxxx>]

Wayne

I reread the V6 roadmap and understand what you meant regarding netlist import.

That would make the process much easier: essentially just update the ref des on the PCB and do a netlist back to eeSchema. That's most of the problem solved once pin and gate swapping is supported.



-----Original Message-----
From: Wayne Stambaugh <stambaughw@xxxxxxxxx> 
Sent: May 10, 2018 6:59 PM
To: Brian Piccioni <brian@xxxxxxxxxxxxxxxxxxxxx>; KiCad Developers <kicad-developers@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Kicad-developers] Proposed Geographic PCB Re-Annotation for Kicad 6

Brian,

Make sure you do a reply all or reply list so that this gets posted on the mailing list.  That way any discussion and any useful information is archived on the mailing list for future reference.

On 05/10/2018 02:39 PM, Brian Piccioni wrote:
> Wayne
> 
> I do not know the details of the time stamp, etc.. but I think I have a workaround for the back annotation problem, at least with respect to geographic re-annotation.

Using the timestamp is a must.  You cannot guarantee the reference will be unchanged in the schematic when you attempt to back annotate.  The timestamp does not change unless a new symbols is added to the schematic.

> 
> The way my code is structured it makes a "change list" which it then uses to parse the various files (PCB, SCH, NET) and update them.

If you are not using kicad's file parsers and formatters to do this, you are creating an extra set of potentially buggy code.  If you are using your own code to do this, I would consider this an unacceptable approach for inclusion into the KiCad source.  The KiCad parser's and formatters are pretty well tested.  The netlist file does not need to be changed although you could do it that way.  In the future, I would like to do away with external netlist files completely except for export to other EDA tool netlist formats.

> 
> As I understand Kicad (and I'm new at this) it is possible to "pipe" commands from PCBNew to eeSchema. At least when I click on a part in PCBNew, the display on eeSchema is updated.

Yes but the current functionality is limited.  There is currently no way to pass a netlist from the board editor to the schematic editor.  The current code only supports sending a netlist from the schematic editor to the board editor.  Take a look at the kiway files in the include and common folders.  The message passing functions live there.

> 
> I believe I can make use of the Search/Replace functionality of both eeSchema and PCBNew to do the updates. That code already exists, and it should be possible to access the more primitive functions programmatically (sorry if I am not expressing this correctly).

You would be better served changing the references in the board footprint objects (MODULE class), creating a netlist from the board object, and passing the netlist to the schematic editor.

> 
> Therefor I can use search to assemble the list of PCB components (i.e. search wildcard until it wraps), create the change list, and use search/replace (using the change list as a source) on both PCB and SCH. Netlist can then be updated through an automated call.
> 
> Of course, all files should be backed up first.
> 
> This approach would guarantee integrity because it would be the same as if done by hand and have the benefit of being intact when file formats are changed.

Using the internal objects and the file parsers and formatters would guarantee that your board changes and back annotations would not break any files no matter what version was in play.

Cheers,

Wayne

> 
> In principle, it could also be used as a general approach to back annotation.
> 
> Of course, you folks are the experts.
> 
> 
> Brian
> 
> -----Original Message-----
> From: Kicad-developers 
> <kicad-developers-bounces+brian=documenteddesigns.com@lists.launchpad.
> net> On Behalf Of Wayne Stambaugh
> Sent: May 10, 2018 2:25 PM
> To: Jeff Young <jeff@xxxxxxxxx>
> Cc: kicad-developers@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Kicad-developers] Proposed Geographic PCB Re-Annotation 
> for Kicad 6
> 
> On 5/10/2018 2:21 PM, Jeff Young wrote:
>> Ahhh… that makes much more sense now.
>>
>> So we have back-annotation for Cvpcb which matches on reference and 
>> updates the footprint field.
>>
>> This would be similar only matching on timestamp and updating the 
>> reference field?
> 
> Yes but it will be far more complicated to implement due to potential changes in the schematic which could cause the board and schematic to be out of sync.
> 
>>
>>
>>
>>> On 10 May 2018, at 19:10, Wayne Stambaugh <stambaughw@xxxxxxxxx 
>>> <mailto:stambaughw@xxxxxxxxx>> wrote:
>>>
>>> Hey Jeff,
>>>
>>> I believe Brian has proposed annotating by the physical position on 
>>> the board layout and back annotating the schematic accordingly.  The 
>>> problem I see is that we do not have back annotation support implemented yet.
>>> I'm guessing his implementation directly modifies the schematic file 
>>> which I would be opposed to unless it uses the schematic file plugin 
>>> for loading and saving the schematic to ensure file integrity.  The 
>>> ideal solution would be to wait until the back annotation feature is 
>>> implemented and push the updated references back to the schematic 
>>> from the board editor.  It's not a trivial change.
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> On 5/10/2018 1:54 PM, Jeff Young wrote:
>>>> Hi Brian,
>>>>
>>>> Re-annotation is usually done in Kicad from Eeschema rather than Pcbnew.
>>>>
>>>> The current annotation dialog supports two ordering mechanisms: "by 
>>>> x position" and "by y position".  If I understand what you’ve done 
>>>> correctly it could be added as a third option “rules based sorting”
>>>> (or something).
>>>>
>>>> We’d then have to add a dialog for editing the rules.  How 
>>>> complicated are they?
>>>>
>>>> Cheers,
>>>> Jeff.
>>>>
>>>>
>>>>> On 2 May 2018, at 22:43, Brian Piccioni 
>>>>> <brian@xxxxxxxxxxxxxxxxxxxxx <mailto:brian@xxxxxxxxxxxxxxxxxxxxx>
>>>>> <mailto:brian@xxxxxxxxxxxxxxxxxxxxx>> wrote:
>>>>>
>>>>> Sorry if this is a duplicate: I originally sent if from my 
>>>>> non-registered email address.
>>>>>
>>>>> * *
>>>>>
>>>>> *Proposed Geographic PCB Re-Annotation for Kicad 6*
>>>>>
>>>>> I wrote a standalone program called RenumKiCadPCB which does a 
>>>>> rules-based geographical renumbering of PCB components and 
>>>>> back-annotates the schematic hierarchy and netlist.
>>>>>
>>>>> As it stands, this is an external program written in c.
>>>>>
>>>>> Having looked at the Kicad codebase I believe it can be 
>>>>> incorporated into Kicad as a standard function. Because this is 
>>>>> common in commercial electronic CAD I believe it would be 
>>>>> appreciated by the user base. Manual geographic re-annotation is 
>>>>> time consuming and source of potential error.
>>>>>
>>>>> Currently the freestanding code works like this (summary):
>>>>>
>>>>> 1. *Drops into a primitive text based menu system for set up;* 2. 
>>>>> Parses the schematic hierarchy to determine storage requirements
>>>>>    and file paths;
>>>>> 3. Parses the PCB file to locate all components and their 
>>>>> locations; 4. *Creates a sorted “change list” based upon the rules 
>>>>> for sort
>>>>>    direction and the results of step 2;* 5. Makes backups of the 
>>>>> schematics, PCB, and netlist; 6. Updates all schematic symbol 
>>>>> reference designations in accordance
>>>>>    with the “Change List”;
>>>>> 7. Updates the PCB reference designations and nets in accordance 
>>>>> with
>>>>>    the “Change List”;
>>>>> 8. Updates the Netlist reference designations and nets in 
>>>>> accordance
>>>>>    with the “Change List”;
>>>>> 9. Writes out the updated files.
>>>>>
>>>>> There are various “traps”, etc., if errors are detected.
>>>>>
>>>>> Besides the issues of being a standalone program, the need to 
>>>>> parse the various file formats (SCH, Kicad_PCB, netlist) means 
>>>>> that if simply ported into Kicad the code would have to be 
>>>>> constantly updated in order to accommodate even small changes to the file formats.
>>>>>
>>>>> Having spent some time looking at the Kicad code base, I am pretty 
>>>>> sure all but step 1 (the menu) and step 4 (creation of a 
>>>>> rules-based change list) can be replaced by calls to existing 
>>>>> Kicad functions, in particular those used for search and replace, 
>>>>> editing text, etc.. I assume it is possible to spawn eeSchema from 
>>>>> PCBNew in order to do the search and replace on the schematic 
>>>>> hierarchy and to regenerate the netlist.
>>>>>
>>>>> The Netlist Importer menu in PCB new would make a good prototype 
>>>>> for the new menu.
>>>>>
>>>>> Use of existing Kicad functions would probably result in the code 
>>>>> running slower than it currently runs ( << 1 second for a large
>>>>> board) but that should not be a problem since this is the sort of 
>>>>> thing which is rarely run more than a couple of times during the 
>>>>> life of the project.
>>>>>
>>>>> Nevertheless, use of existing functions ensure the geographical 
>>>>> reannotation would be robust against any future changes to file 
>>>>> formats, etc., since reference designations and coordinates are 
>>>>> inherent characteristics in an ee CAD system.
>>>>>
>>>>>  
>>>>>
>>>>> *_Risks_*
>>>>>
>>>>> I have to note that my participation has some risk:
>>>>>
>>>>> 1. I am old (60) and have never written code as part of a large,
>>>>>    collaborative project: most of my programming experience is
>>>>>    limited to embedded designs;
>>>>> 2. I have only a passing familiarity with c++; 3. I am not used to 
>>>>> the sort of documentation associated with Kicad; 4. These imply a 
>>>>> steep learning curve for an old guy; 5. As such, it will probably 
>>>>> take me much longer than a skilled
>>>>>    programmer to do this.
>>>>>
>>>>>  
>>>>>
>>>>> Therefore, it would be helpful if there was a mentor I could turn 
>>>>> to for some guidance, if the developers accept that this is a good idea.
>>>>>
>>>>> I would appreciate any feedback. If you think this would not be a 
>>>>> good thing to pursue, please let me know.
>>>>>
>>>>>  
>>>>>
>>>>> Regards
>>>>>
>>>>>  
>>>>>
>>>>> Brian Piccioni
>>>>>
>>>>> Documented Designs
>>>>>
>>>>>  
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>