kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

Hi Alexander,

You must ensure that all of the reference paths are up to date with the
schematic before you attempt to back annotate from the board.  Schematic
changes can result in the footprint paths in the board being out of sync
so you have to perform and update board from schematic (this code
already exists) before you attempt to run the back annotation process
from the board editor to ensure all of the paths are up to date.  This
will ensure when you back annotate that there is a one to one
correlation between board footprint sheet paths and schematic symbol
sheet paths.

Cheers,

Wayne

On 11/22/19 1:18 AM, Alexander Shuklin wrote:
> Hi Wayne,
> thanks for answer.
> Hopefully I will show you commit soon, so team could look, check and
> suggest something about that. I'm aware about differences between
> PCBnew and eeschema and just now I'm writing algorithm that will check
> it.
> Do you mean that some schematic file(.sch) can be used in more than
> one projects? So, I don't plan to change the unique IDs and those
> components will still be linked to each other, but if references will
> be changed it will make a mess in another project.
> I have 3 ideas how I can deal with that:
> 1) create a dialog, which will say something like "please make sure,
> that your schematic files are not shared between different projects"
> 2) I can go by recently opened projects, parse schematics in each of
> them and look if any schematic uses sheet, which already in use in
> current project. I'm now sure, but I would presume, that it will be
> quite slow.
> 3) To hold information in what project this particular schematics was
> used. So that's should be saved in .sch file then. But I don't think
> that information will be very valuable.
> 
> 
> On Thu, 21 Nov 2019 at 00:07, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>>
>> On 11/7/19 5:06 AM, Alexander Shuklin wrote:
>>> Hi,
>>> is it alright to answer anybody in one letter?
>>> First of all, don't take amiss if I keep silence for a day, as I have
>>> 2 little children and at the best case I have couple of hours a day on
>>> my own.
>>>
>>> On Wed, 6 Nov 2019 at 16:27, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>>>> Complex schematic hierarchies (using the same schematic more than once in a design) always trips up new developers.
>>> Can you please explain a bit more? I know that you can use
>>> hierarchical sheets, so there will be more than one sch files in the
>>> schematic. And there's also "multi-symbols" which have few eeschema
>>> symbols but one footprint. I'm not quite understand what means "using
>>> the same schematic more than once in a design", as every symbol has
>>> unique ID. Is it something else I'm not aware of?
>>
>> Yes, every symbol has a unique path ID but that doesn't mean that the
>> board and the schematic will always be in sync so this is where issues
>> come into play.  There also can be unique IDs from other projects
>> because schematics can be shared between projects so you have to be
>> careful not to break all of these cases.
>>
>>>> You'll want to take a close look at KIWAY::ExpressMail() and KIWAY_PLAYER::KiwayMailIn()
>>> Ok, I'll look at that. I think I've seen that in footprints back annotation.
>>>> This is unfortunate.  Being able to work directly with on of the lead developers would have made this task a lot easier to understand.  You are always free to reach out for help on this mailing list.
>>> Thanks for that. Actually now i think to join FOSDEM, but I need visa
>>> and I'm not sure yet.
>>>> Asking first prevents you from working on something that someone else may already be working on and writing code that would be immediately rejected
>>> Actually I already made that mistake, when made board statistics
>>> dialog. It was accepted, but I felt myself really stupid.
>>>> Good luck and thank you for your interest in contributing to KiCad.
>>> Thanks! I will try hard to match coding and git polices.
>>>
>>> On Wed, 6 Nov 2019 at 17:24, Jon Evans <jon@xxxxxxxxxxxxx> wrote:
>>>> Eeschema now keeps its internal net state up to date continuously, but I didn't work on any continuous syncing to PcbNew.  The way it works in Eeschema, the graphical schematic is still the driving source of truth; the netlist does not drive the schematic.
>>> Am I right in general idea: Eeschema creates netlist which updates
>>> continuously. And PCB updates through eeschema by "uppdate PCB from
>>> schematic" tool. It isn't planned to do that automatically and
>>> continuously, is it?
>>>
>>> On Wed, 6 Nov 2019 at 17:56, Brian Piccioni <brian@xxxxxxxxxxxxxxxxxxxxx> wrote:
>>>> My utility is up on GitHub as a standalone app. I learned enough c++ and wxWidgets so porting it to Kicad should be useful.
>>> I've seen your app, and bug report. And actually I try to jump in
>>> because I use geometrical renumber of components as well)))
>>>> Replacing my homebrew parsing of PCB, Schematic, and netlist files to calls to internal Kicad functions/methods in the respective apps;
>>>> Once this is done I’ll use Kiway to communicate the changes between eeSchema and PCBNew.
>>> Have you already start to create communication between eeschema and
>>> pcbnew? If not, don't you mind if I'll start with that first? From my
>>> point of view, that's a worst part in this question today. For example
>>> you can renumber modules in pcbnew even by python scripts, but you
>>> have no any tool to change schematic after that. And by the way it's
>>> not only about renumber of all components. Somebody would like to
>>> change some references in pcbnew by hand at push that data back to
>>> schematics.
>>>> In the final version, if I understand correctly, in V6 changes to the PCB will be back-annotated to the schematic in order to support pin and  gate swapping. So updating the PCB will immediately incorporate the changes to the schematic. I haven’t seen any discussions of how this will be done but clearly if the prototype as described above works it will be trivial to support the V6 common database.
>>> Hm... I haven't think about that... I'm not sure if pin swapping will
>>> interact with back-annotation tool. I wouldn't say that, but if
>>> somebody has comments and thoughts about that, it would be greatly
>>> appreciated.
>>>
>>> As far as I see now, It should be some tool a bit similar to "Update
>>> PCB from schematic", which will utilize KiWay functions to send data
>>> between PCBnew and eeschema..
>>>