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 <br...@documenteddesigns.com> > 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: > > 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); > Manually edit each component on the board and keep a record of every change > in a “change list”; > Manually edit the schematic in accordance with the “change list”; > Regenerate the netlist; > Update PCB from schematics; > 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 > Sent: November 22, 2019 12:03 PM > To: Alexander Shuklin > Cc: KiCad Developers > 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 <stambau...@gmail.com> 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 <stambau...@gmail.com> > >>> 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 <stambau...@gmail.com> > >>>>> 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 <stambau...@gmail.com> > >>>>>>> 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 <j...@craftyjon.com> 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 > >>>>>>> <br...@documenteddesigns.com> 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@lists.launchpad.net > >>>> Unsubscribe : https://launchpad.net/~kicad-developers > >>>> More help : https://help.launchpad.net/ListHelp > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
