Here’s a video about a use case which I believe is quite common.
screencast_textvariable-2020-05-29_00.33.32
EDIT: Oops, I forgot to change the revnum variable afterwards. Let’s say it’s your homework. 
5 Likes
@JeffYoung, I expect that hierarchical sheet fields can be used inside the sheet content. But it doesn’t seem to work. Is this a bug or is my expectation wrong or do I try to use it in a wrong way?
2 Likes
@eelik, I can see how that would be useful. Why don’t you go ahead and log an enhancement request?
1 Like
BTW, when editing fields & text in their own dialog (ie: not through the grid editor in their parent), autocomplete is now available.
May be also introducing ${ENV:HOME} ${ENV:MY_LIB}
ATM there no special syntax for scope or namespace. The system is pretty simple. I wonder if it would be good to support variables like ENV:HOME mentioned above, or GLOBAL:var1, SHEET:var1, SYMBOL:var1, :var1 (for the nearest level) etc. Now it’s not possible to use the same name in different levels and use them in the same place. The nearest level overrides the others. For example
- Project level: myvarname = x
- Symbol level: myvarname = y
- Symbol text: ${myvarname} => y
In many cases it would also make things clear in the first sight, now I can’t necessarily know where ‘myvarname’ is defined. It’s possible to use the same name in global and hierarchical sheet level, but I can’t say where the variable is supposed to come from if I see it used in a text inside a sheet without opening and looking at the variable definitions.
We may need to do something like that, but I think we need to get it out there first, and then see what improvements we can make in the 6.1 or 6.2 time-frame.
(Note that you can now reference parent sheet variables, but they’re not scoped so if they have the same names as local variables you get the local one.)
1 Like
How do I use these? I can’t for example use a value of another symbol in a symbol’s value field:
I would think this is going to far for my own use case. I actually think, I would avoid using this way. Instead I rather control the component value and stuff from .CSV file using Excel or some short. This would the most typical way of hardware design for me, and allow me have variances of BOMS for the same PCB board.
This currently could be accomplished with script bom2sch.py that I been mention.
The most use cases for the value substitution for me to abstracted out the absolute path in each person machine when they clone the project that include project libs without have to figure out what to set, or change libs. Reference to 3D model files, to Datasheet, etc… Same for a location of global libs, and global datasheet, global 3d model files, event global ngspice model files.
Your usage is correct. I’m just not processing them in refdes or value fields. RefDes makes sense, but I can’t remember why not for values…
I take that back. I’m only processing them in schematic text, not symbol fields. I can’t see a reason to preclude them, so I’ll add it…
1 Like
OK, thanks.
Refdes is a bit special case. There may be some valid cases for using variables in them, but because they are mostly automated and don’t have arbitrary text, using variables in them would probably cause many corner cases when reannotating and keeping schematic<->pcb in sync. Luckily text processing is (I hope) robust enough so that it doesn’t cause crashes, but I don’t wonder if users will find unexpected results.
1 Like
Would it be possible to add “external” values? For example I would like to add git commit and branch… Now I do it in my build automation by bunch of replacements like _ _ gitcommit _ _ => actual git commit id but having it directly in KiCad would be great…
+1 for git hashes. I assume there will be a https://libgit2.org/ dependency sometimes for integrated VCS support anyways.
User defined fields of the symbol can now be referenced in the footprint because the user fields are propagated from eeschema to pcbnew when updating the board.
The texts including variables are still used as-is, unresolved, when propagating and can’t necessarily be resolved in pcbnew, so using e.g. hierarchical sheet user fields isn’t possible. You would only get the unresolved variable name in pcbnew. For this see https://gitlab.com/kicad/code/kicad/-/issues/5005.
Now the hierarchical sheets can be fully parameterized and the result is seen in the schematic and in the layout. Look into the attached project.
hierarchical_sheet_with_parameters.zip (7.4 KB)
2 Likes
This is amazing!
Jeff disabled text replacement in reference designators. The reasons should be clear: they are mostly made automatically, should be simple, short and predictable, are exported to many files which would create problems with variables, backannotation would be problematic, could cause other unforeseeable problems, it’s difficult to find useful use cases for text variable in them, other EDA’s probably don’t have such a feature…
I guess nobody used that possibility which was available for a while.
If someone still finds unresolved text variables slipping to exported files where they should be resolved, see https://gitlab.com/kicad/code/kicad/-/issues/5285 and https://gitlab.com/kicad/code/kicad/-/issues/5287.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.