AR Fields in $Comp

[LabZDjee]

Hello everyone:

I’m new to this forum. I hope I post at the right place with the right way and form of requiring other’s help.

I have a question about how reference designators work in schematic .sch files.

Reason why is: I found a back-annotation utility trip and fail on AR Path fields in $Comp definitions. And I found no sensible way to fully understand the reason why you can find things like this in hierarchical schematics:

$Comp
L Relay:FINDER-40.52 K?
U 1 1 604D271A
P 3590 5400
AR Path="/6042907E/604D271A" Ref="K?"  Part="1" 
AR Path="/604D271A" Ref="K1"  Part="1" 
F 0 "K1" H 3560 5830 50  0000 L CNN

It is undocumented in Kicad_file_formats.pdf legacy document where no AR field is mentioned anywhere.

I’m in the process of writing a back annotation helper utility and I would like to support this syntax which remains unclear to me.

Could anyone explain what is the idea (probably factorize something)? And how it works… Like: is reference designator in L field mostly ignored and F 0 field is the only source of truth? Any information or hint would help…

Thanks, take care.
GG.

[Rene_Poschl]

The AR stuff is to support multi instantiation of hierarchical sheets. It contains the path to the instance (identified via the timestamps) and defines what the reference designator of this instance will be.

[LabZDjee]

@Rene_Poschl

multi instantiation of hierarchical sheets

Thank you Rene for the reply. Anyway I don’t really get what ‘multi instantiation of hierarchical sheets’ means. What does AR stand for, by the way?

I’m in the middle of writing a back-annotation utility and my only concern is to clearly identify reference designators in $Comp records and still AR fields challenge my understanding as clearly I don’t see their what their utility is.

So I did many tests and the only way I could trigger AR fields is copy-paste components from one sheet to another sheet (whatever the hierarchy, top down or bottom up). The destination of the copy-paste will carry this strange AN fields:

$Comp
L Device:R R?
U 1 1 608D319B
P 4260 2150
AR Path="/608C6FE5/608D319B" Ref="R?"  Part="1" 
AR Path="/608D319B" Ref="R9"  Part="1" 
F 0 "R9" H 4330 2196 50  0000 L CNN

In this example we can see 608C6FE5 is the timestamp of the sub-sheet this copy comes from.

As my only concern it to find reference designator, here R9, I would have to only ignore the L field and take the AR field matching the F 0 field.

So far so good, maybe I can change my utility to recognize this and apply consequently. However I don’t feel fully comfortable with the reason with such strange mechanism occurs.

So I would appreciate advice from anyone who knows the rationale for this and confirm my way of identifying reference designators in $Comp records is correct.

Thank you.

PS: I noticed even removing the source of a copy-paste makes the AR fields remain in the sheet where component is copied to.
This makes usefulness of those fields even more questionable.
Is there any means to wipe them out?

[paulvdh]

In KiCad, a hierarchical sheet can be drawn once, and then included multiple times in the project. An example for this would be an USB hub. You can make a hierarchical sheet for an USB output connector and it’s surrounding protection circuitry, and then each output of the USB hub will get that circuitry around it’s connector.

For more info about Hierarchical sheets:

Hierarchical or flat schematic design, what is best for me? (How to deal with multi page schematics?)

Disclaimer: An unofficial colour scheme has been used to make the screenshots of this lecture. You can find it in https://github.com/pointhi/kicad-color-schemes (blue-tone scheme) Introduction The official documentation for this topic: http://docs.kicad-pcb.org/5.1.2/en/eeschema/eeschema.html#hierarchical-schematics KiCad in general is more geared towards the use of hierarchical design. Small flat designs are easily possible as well but making complex systems as a flat design is not as easy. W…

Related to this there is also a “Replicate Layout” script.
With this script you do the layout of one instance of a Hierarchical sheet on the PCB, and you also place a single reference Footprint for all the other sheets on the PCB, and then run the script, and it takes the layout (Tracks and Footprints) of the Hierarchical sheet you designed on the PCB and it replicates that layout for all the other instances of the Hierarchical sheet. This script can also be run multiple times when making revisions of a project.

I don’t know what that “AR” thing is, but I guess it has something to with managing the RefDes to make this multi inclusion of a Hierarchical sheet possible.

[LabZDjee]

OK, thank you very much, Paul.
This opens up a whole new vista on schematic sheets. I was wrong in calling multi-page sheets hierarchical sheets. With your reply I understood multi-page sheets can be flat or hierarchical and so far I only used the former kind.
Hierarchical sheets are a completely different approach that I already met long time ago with Cadstar EDA.
I’ll have a close look how they work with KiCad and come back with any interesting findings I could come across concerning my work on collecting reference designators.

[LabZDjee]

After several tests tinkering with hierarchical sheets, yes, AR fields are definitively associated with it. As with the following snippet:

$Comp
L Device:C C1
U 1 1 608EA8C7
P 4960 3570
AR Path="/608E5EEB/608EA8C7" Ref=“C1” Part=“1”
AR Path="/608E89EF/608EA8C7" Ref=“C2” Part=“1”
AR Path="/608EB8AA/608EA8C7" Ref=“C2” Part=“1”
F 0 “C1” H 5075 3616 50 0000 L CNN

Here capacitor C is given two reference designators C1 and C2. It is so because the sub-sheet it is defined in is instantiated two times.

[Actually sheet with timestamp 608E89EF above designates a deleted instance and KiCad didn’t care to remove it. Removing it manually posed no problem. Perhaps the same untidiness explains what I saw with copy-paste results at the beginning of this thread where weird pending annotations such as L Device:R R? can be seen.]

So, to sum-up my concern, a way to programmingly replace reference designators in .sch sheets recursively is to simply look for old ones in L, AR, and F 0 fields and proceed with necessary remplacements with new ones. Simple as that.

Edit: Simple as that? Not quite. As it is important to gather the list of valid reference designators, here are the rules for validating reference designators, I discovered after many tests:

• When AR fields exist, only the ones which Paths point to the sheet they are defined in, are valid. All other are ignored by KiCad and seems to be by-product or copy-paste,
• When AR fields exist L and F 0 fields should be ignored.

Hope it could help anyone interested in such proceedings and again thanks for ideas and suggestions you brought.

This way I could complete my utility which I hope works as expected to replace reference designators in Eeschema for KiCad 5.