← Back to team overview

kicad-developers team mailing list archive

Re: Eeschema annotate block / specific component types proposal


Hi James,
few months ago I implemented "update schematic from pcb" feature, and
I think it's a little bit similar to feature you want to make. I'm not
very often work with KiCad source, but if you don't have better person
to ask, feel free to ask me.
First of all - there's major change in schematics code, but I believe
api remains the same.
First advice - don't get lost between SCH_COMPONENT and SCH_REFERENCE.
Basically if you want to work with some schematic modules, you want to
use SCH_REFERENCE class. It holds data about where (in what sheets)
component was used and all data about it (majority is in the
corresponding SCH_COMPONENT class. You can get it with
SCH_REFERENCE.GetComp() ). Imagine that you have 3 hierarchical sheets
which share same resistor. With that particular resistor you will have
only 1 SCH_COMPONENT instance and 3 SCH_REFERENCES instances.
There's quite handy api to mange all these. I'll cite some piece of
code from "update sch from pcb" (eeschema/tools/backannotate.cpp)

SCH_SHEET_LIST sheets( g_RootSheet ); // You'll get all sheets in root schematic
sheets.GetComponents( m_refs, false ); // You'll get plain list of all
sheets.GetMultiUnitComponents( m_multiUnitsRefs ); // You'll get all
list of the multi-part units

Basically, you will need to parse these containers to manage all
errors you can get during block annotation.

With git I usually follow git master head and keep my patch in one
commit (if I don't have reason to do opposite) In that case it's very
easy to follow master updates. But I like git :)

sorry that I missed your mail, I believe for refreshing schematics you
can look in eeschema/dialogs/dialog_update_from_pcb.cpp : 126 line

Sorry if I say something trivial or I explain in some strange way, I
hope my mail save your time at least a little bit.

On Sat, 9 May 2020 at 00:13, Evan Shultz <evan.shultz@xxxxxxxxx> wrote:
> Since other ECAD tools are specifically mentioned and I use a new tool I'll add my 2 cents. I'm a Cadence Design Entry HDL user (oh God, it's so awful...) working with always hierarchical schematics often having >100 pages.
> DEHDL works on a principle where you add symbols and then they're 'packaged' (annotated) later. That part is like KiCad. Each symbol has a property where the ref des is the property value. The property can be set to locked or not (this is determined by having a leading dollar sign or not). If the user manually types in a ref des, it automatically locks and the ref des cannot be changed during annotation. The user can also manually lock a property after annotation.
> A cool feature is the 'ref des pattern' which is applied during 'packaging'. Packaging happens from the top down, and as the packager moves deeper and deeper into the schematic it pushes down into from the top. If I have a hier block with any random property, let's say BLOCK_SUFFIX, I can then use the value of that property in the 'ref des pattern'. For example, if I have 8 instances of the same block I can give them a BLOCK_SUFFIX property with a value A through H. Then the ref des pattern can be '<symbol prefix><incremented number starting at 1><BLOCK_SUFFIX>' where <symbol prefix> is 'R' for resistor, 'C' for capacitor, etc. and controlled by the library symbol. So I will get a R1A in the first block. And the corresponding part in the second block is R1B, continuing on through R1H. For parts at the top level of the schematic not in a block, or parts in a block without a BLOCK_SUFFIX property, the value is automatically set to an empty string. And any sub-blocks will also get the same BLOCK_SUFFIX from their parent block. I could also make a pattern like  '<symbol prefix><DESIGN_SECTION><incremented number starting at 1><BLOCK_SUFFIX>' where DESIGN_SECTION is a property on blocks broken up by function in the product so '1' for digital circuitry, '2' for analog, etc. This means the first resistor in the digital part would be R11, and the first resistor in the analog circuitry is R21A going through R21H. And if I put I/O connectors at the top level of the schematic, I get J1 and not J11. There are many, many uses and that is one thing I think fits nicely with the core idea proposed that I'd love to see in KiCad.
> One painful step is that any block which is to have multiple instances and be packaged like I've shown above must be packaged on it's own. Not in the scope of the entire design, but with the block itself as the top level of the schematic. Then later that block (and any child blocks) can be packaged with the entire schematic. There are a number of hoops to jump through and potential gotchas if the you want the BLOCK_SUFFIX behavior described above to work.
> If a user in DEHDL places too many gates to fit into one physical package and then have locked the ref des, there is an error during packaging and packaging stops. It knows if have the power pins of an opamp set to be U73, and I place another set of power pins also set to be U73, that cannot work. But if a user places a bunch of symbols the packager will try to condense them into as few physical packages as possible (there are several settings but that's the default behavior). I personally would like to be aware of what's going on during this step of annotation and not see KiCad create 43 physical parts on it's own simply because of how I decided to construct the schematic without having any options.
> Regarding multi-unit symbols spread around a schematic, in DEHDL one can place a symbol in a block but not have that symbol packaged with other symbols in another block, whether the blocks are peers or parent/child. For example, if I have one dual opamp gate in one block and another in another block, I will get two physical packages. DEHDL can't handle that situation. It's a little sad. The workaround would be to add ports and place the common part at a high level in a schematic. Imagine a dual instrumentation amp circuit with a block containing a pair of inst amp blocks. The single gain setting resistor would need ports if a single dual pot or dual digitally-controlled resistor IC or other single component is to control the gain of both inst amp circuits. Make sense?
> DEHDL can add parts to a BOM without them having a schematic representation, but it's a horrible process that I've tried several times and given up on. It feels like the kind of thing that an Intel or Motorola paid $1B to have implemented and it's tied to one user's specific way of working and their library structure. I can see value in the idea, but not the execution.
> Lastly, when pushing schematic changes to a board in Allegro the parts go into a queue and can be placed in many ways. They can be placed manually, one-by-one, but there is an autop-placement feature that gives many options. One is to place at a selected point by schematic page so I can plop down piles of footprints that represent each schematic sheet. And then I can do the layout once and replicate it for multiple corresponding piles. I really like having more control over placing footprints than Pcbnew gives, but alas. I'm not sure this was already part of the discussion above, so sorry if it's a tangent.
> I'd be happy to answer questions or provide screenshots if that helps to explain things. Let me know.
> Cheers!
> On Thu, May 7, 2020 at 3:54 PM James Jackson <james.a.f.jackson.2@xxxxxxxxx> wrote:
>> Thanks Jon - I don't have access to Altium so that's really helpful.
>> I was wondering about the possibility of locking components; I sometimes want to do this with, for example, key ICs - MCUs, DACs, etc. One could add this as a Symbol Property, which wouldn't need any changes to file formats. Whether it got a custom checkbox in the Symbol Properties dialog, or would just be there as another option that a user may add (which would make it a 'power user' feature as it wouldn't be obvious unless one knew to add it) would need to be considered - UI clutter vs. access to features for all.
>> With the multi-part consideration, where on the schematic does it dump the new components? It wouldn't be too difficult to implement an algorithm which finds a space in which all the sub-components required could fit, with some gross assumptions on layout. Or can Altium add a component to the BOM without it being on the schematic?
>> I'm also mindful that some algorithms can't solve everything (although this strikes me as a non-trivial problem, rather than an impossible problem...) - and bailing out and telling the user why is also always a option, in the spirit of 'do no harm'.
>> Yours,
>> James.
>> On Thu, May 7, 2020 at 9:59 PM Jon Evans <jon@xxxxxxxxxxxxx> wrote:
>>> Altium doesn't have "annotate selected"
>>> It does let you lock the annotation on components at will, so you can lock some, reset everything (which ignores locked) and then re-annotate.
>>> If you change the annotation of one part of a multi-part component, it will result in two components being forwarded to the PCB like Janvi proposes.
>>> And also likewise, the ERC will warn about this if configured appropriately.
>>> As to how it handles the complex hierarchy situations JP mentioned, I'm not certain to be honest, because Altium's hierarchy model is a bit different from KiCad's (in some ways simpler) and I haven't checked to see if the same situations are possible.
>>> -Jon
>>> On Thu, May 7, 2020 at 4:48 PM James Jackson <james.a.f.jackson.2@xxxxxxxxx> wrote:
>>>> That's an interesting take on it. I can foresee the catastrophic addition of loads of other components though, if there's an error in the schematic somewhere and a rogue missing / one-over unit gets cascaded down sheets.
>>>> What do other EDA tools do with annotation? Do they have this feature? Do they handle these conditions?
>>>> On Thu, May 7, 2020 at 8:18 PM janvi@xxxxxxxxx <janvi@xxxxxxxxx> wrote:
>>>>> > - What about multi-units components: for instance what about renaming 2 of 5 units when one unit is the unit handling the power pins?
>>>>> > this is the best way to break a design.
>>>>> This should add another component to the BOM and schematic DRC should
>>>>> report unused gates for both of the reference designators
>>>>> > Good luck with block annotation.
>>>>> _______________________________________________
>>>>> 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
>>>> _______________________________________________
>>>> 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
>> _______________________________________________
>> 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
> _______________________________________________
> 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

Follow ups