kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

What Jeff described is the simplest case.  Where things really get
interesting is when you start sharing schematic files between projects.
 When this happens, there will entries in a symbol definition for each
instance (sheet) of the schematic file in every project.  Here is an
sample symbol (component) section with comments of what happens in the
file itself:

$Comp
L Device:R R?
U 1 1 56C02CD5
P 4650 3250
# These four entries are from one project where this schematic file is
# referenced in four separate sheets.
AR Path="/56C02CC2/56C02CD5" Ref="R1"  Part="1"
AR Path="/56C0317D/56C02CD5" Ref="R2"  Part="1"
AR Path="/5B8E85A4/56C02CD5" Ref="R3"  Part="1"
AR Path="/5B8E866A/56C02CD5" Ref="R4"  Part="1"
# These four entries are from a different project where this schematic
# file is referenced in three separate sheets.
AR Path="/56C02CC5/56C02CD5" Ref="R1"  Part="1"
AR Path="/56C0317F/56C02CD5" Ref="R2"  Part="1"
AR Path="/5C8E85A4/56C02CD5" Ref="R3"  Part="1"
# There can be any number of these references so you cannot use the
# reference to look up changes for back annotation.  You must use the
# path but paths can deviate from the board if the schematic has been
# modified and changes have not been pushed to the board which further
# complicates things.
F 0 "R?" V 4730 3250 50  0000 C CNN
F 1 "R" V 4650 3250 50  0000 C CNN
F 2 "" V 4580 3250 30  0000 C CNN
F 3 "" H 4650 3250 30  0000 C CNN
	1    4650 3250
	1    0    0    -1
$EndComp

There are a whole bunch of issues that can crop up like timestamp
clashes between projects so there are known bugs even with what I
described above.  The new file format will add some type of hashing to
prevent this.

On 11/22/19 2:47 PM, Jeff Young wrote:
> Hi Brian,
> 
> If you double-click into the left channel you’ll see Q101.  If you
> double-click into the right, you’ll see Q201.  So it looks like there
> are two.  But if you edit either one it goes back to a single file so
> both will be changed.
> 
> (To be honest I’ve never used this feature, so I’m not 100% sure the
> above is correct.  But I’m pretty sure.)
> 
> My guess is there’s a tutorial somewhere; perhaps Wayne or JP could comment?
> 
> Cheers,
> Jeff.
> 
> 
>> On 22 Nov 2019, at 19:42, Brian <lotharyx@xxxxxxxxx
>> <mailto:lotharyx@xxxxxxxxx>> wrote:
>>
>> Hi Jeff,
>>
>> Thanks for helping me understand this.  So how would someone looking
>> at the schematic know that this one symbol represents both Q101 and
>> Q201?  For that matter, if there's some instructions or a tutorial
>> about creating a situation like this (one schematic drawing
>> representing multiple instances of the subcircuit on the pcb), I'd be
>> interested to learn it.  I have a couple projects in the pipeline
>> where I might find this feature useful; in the past, I've manually
>> copy/pasted sections of a schematic to repeat subcircuits.
>>
>> Thanks,
>> -Brian
>>
>> On 11/22/19 2:37 PM, Jeff Young wrote:
>>> Hi Brian,
>>>
>>> Imagine you’re doing an audio amplifier.  Your main schematic sheet
>>> has 4 subsheets: PSU, control logic, left channel and right channel.
>>>  Both left channel and right channel point to the same sub-page.  So
>>> there’s a single schematic symbol for each part in the left & right
>>> channel, which gets annotated as two different references (ie: Q101
>>> and Q201), and attached to two different footprints.
>>>
>>> Cheers,
>>> Jeff.
>>>
>>>> On 22 Nov 2019, at 19:29, Brian <lotharyx@xxxxxxxxx
>>>> <mailto:lotharyx@xxxxxxxxx>> wrote:
>>>>
>>>> From the peanut gallery:
>>>>
>>>> Can someone tell me an example use-case for a single schematic
>>>> symbol corresponding to multiple board entities within a single project?
>>>>
>>>> As perhaps a rather naïve PCB designer, it seems like mostly a bad
>>>> idea to me to have anything other than 1:1.
>>>>
>>>> Thanks,
>>>> -Brian Henning 
>>>>
>>>>> On Nov 22, 2019, at 1:44 PM, Brian Piccioni
>>>>> <brian@xxxxxxxxxxxxxxxxxxxxx <mailto:brian@xxxxxxxxxxxxxxxxxxxxx>>
>>>>> wrote:
>>>>>
>>>>> 
>>>>> Wayne 
>>>>>  
>>>>> I thought I would weigh in as I am collaborating with Alexander.
>>>>>  
>>>>> If a designer manually re-annotates a board and schematics he would
>>>>> follow a number of steps:
>>>>>  
>>>>>
>>>>>  1. Ensure the schematics, PCB, and netlist are coherent and
>>>>>     without error (I.e. nothing in the schematics or PCB which is
>>>>>     not in the other, netlist corresponds to schematic and PCB);
>>>>>  2. Manually edit each component on the board and keep a record of
>>>>>     every change in a “change list”;
>>>>>  3. Manually edit the schematic in accordance with the “change list”;
>>>>>  4. Regenerate the netlist;
>>>>>  5. Update PCB from schematics;
>>>>>  6. Verify that the schematics and PCB are still coherent.
>>>>>
>>>>>  
>>>>> Manually editing the schematic would consist of going from
>>>>> component to component, looking up the component ref des in the
>>>>> “change list”, changing the ref des to the new value, and moving to
>>>>> the next component. The final step would only be necessary due to
>>>>> the near certainty that manual re-annotation would have introduced
>>>>> errors.
>>>>>  
>>>>> This is, more or less, what I do in my standalone application.
>>>>> Unfortunately, I also run roughshod over timestamps, etc..
>>>>> Nonetheless, the application has been well received and appears to
>>>>> be used a fair bit.
>>>>>  
>>>>> If we were to write a demon (probably the wrong term) which
>>>>> essentially did the same steps, would that address your concerns?
>>>>>  
>>>>> Of course, we would use Kiway to accomplish the transfers but the
>>>>> approach would be pretty much identical to a manual re-annotation
>>>>> except far less likely to introduce errors.
>>>>>  
>>>>> If that would not work, can you please explain why? Perhaps if we
>>>>> understand why we can suggest solutions.
>>>>>  
>>>>> Brian
>>>>>  
>>>>> *From: *Wayne Stambaugh <mailto:stambaughw@xxxxxxxxx>
>>>>> *Sent: *November 22, 2019 12:03 PM
>>>>> *To: *Alexander Shuklin <mailto:jasuramme@xxxxxxxxx>
>>>>> *Cc: *KiCad Developers <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>>> *Subject: *Re: [Kicad-developers] Back annotate references from PCB
>>>>>  
>>>>> I would prefer that you did ask questions rather than spending a lot of
>>>>> development time on a solution that would not be accepted because it
>>>>> breaks things.  This is not a trivial problem although it may appear
>>>>> that way.  There are plenty of ways to implement back annotation that
>>>>> will break things in unexpected ways.  There are a very few ways to not
>>>>> break things.  This is why I'm telling you this.  If you don't care
>>>>> about the schematic and the board references being synchronized, then
>>>>> back-annotation isn't really necessary.  As soon as you attempt to
>>>>> back-annotated the schematic from the board, all of the issues that I
>>>>> have previously discussed come in to play and have to be addressed.
>>>>>  
>>>>> On 11/22/19 9:53 AM, Alexander Shuklin wrote:
>>>>> > Excuse me for so much questions. There's plenty of ways how it can be
>>>>> > done, and I'm quite new, maybe I don't see some simple way.
>>>>> > I can back up data from pcbnew which is not up to date to schematics,
>>>>> > after that I call update pcb dialog. Somebody will want to update pcb
>>>>> > by references and after that I will have pcbnew old data which is not
>>>>> > up to date either to schematics or layout anymore. I don't think
>>>>> there
>>>>> > will be straight forward solution how to solve it.
>>>>> > May I just open update pcb dialog and ask user to care about
>>>>> schematic
>>>>> > and layout being up to date?
>>>>> >
>>>>> > On Fri, 22 Nov 2019 at 17:16, Wayne Stambaugh
>>>>> <stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>> wrote:
>>>>> >> 
>>>>> >> There is no need to create your own dialog.  Just call the
>>>>> update board
>>>>> >> from schematic function before you back annotate.  You will have
>>>>> to make
>>>>> >> a temporary copy of your board reference changes because
>>>>> updating from
>>>>> >> the schematic will clobber any reference changes in the board.
>>>>> >> 
>>>>> >> On 11/22/19 9:13 AM, Alexander Shuklin wrote:
>>>>> >>> Hi Wayne,
>>>>> >>> 
>>>>> >>> I don't want to start PCB update from eeschema straight away,
>>>>> because
>>>>> >>> if you run back-annotation, you already changed some references in
>>>>> >>> layout and you gonna lose it. And probably you can get some
>>>>> footprints
>>>>> >>> which are not connected to any of components in schematics as
>>>>> there's
>>>>> >>> possibility in pcbnew to create them. What I almost done is
>>>>> reporting
>>>>> >>> about all errors in dialog (I currently use annotation dialog in
>>>>> >>> eeschema, but I can create my own if it necessary), and if
>>>>> there's any
>>>>> >>> errors, it will not allow you to back-annotate. It will ask you
>>>>> to fix
>>>>> >>> them first.
>>>>> >>> But if you want, I can run "update pcb from schematic" dialog.
>>>>> >>> 
>>>>> >>> On Fri, 22 Nov 2019 at 16:30, Wayne Stambaugh
>>>>> <stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>> wrote:
>>>>> >>>> 
>>>>> >>>> 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 <mailto: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 <mailto: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
>>>>> <mailto: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 <mailto: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..
>>>>> >>>>>>> 
>>>>> >>>> 
>>>>> >>>> _______________________________________________
>>>>> >>>> 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
>>>>> <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
>