You can do that by defining your own project variables, say “schVersion” and “pcbVersion”. Then use those in the worksheet editor rather than “REVISION”. (Or you can even daisy-chain, by setting REVISION to “${schVersion}”.)
1 Like
It seems to work on Linux, after all. But not on Windows. I see this on 2 different machines, Win 7 and 10. The buttons or the grid don’t work. I added a variable to the .pro file and it’s shown in the grid but I can’t edit it.
The latest nightly build - either from Board Setup or Schematic Setup.
Application: Eeschema
Version: (5.99.0-1237-g9b4b85bb7), release build
Libraries:
wxWidgets 3.0.4
libcurl/7.66.0 OpenSSL/1.1.1d (Schannel) zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.1.1) nghttp2/1.39.2
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
Build date: Apr 6 2020 21:00:39
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.71.0
OpenCASCADE Community Edition: 6.9.1
Curl: 7.66.0
Compiler: GCC 9.2.0 with C++ ABI 1013
Build settings:
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_PYTHON3=OFF
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_USE_OCC=OFF
KICAD_SPICE=ONAliases for some of the variables could be nice.
Constantly typing $REFERENCE instead of $REF for example.
FP_LIB
FP_NAME
etc
Cross-references are also now in: ${R12:REFERENCE}, ${C101:VALUE}, etc.
Note that the typed reference (“R12” and “C101” in the above examples) are only shorthand; Kicad actually saves the UUID of the items so that if the schematic is re-annotated the cross-references will still point to the right items.
1 Like
${R12:REF} and ${C101:VAL} would be even more short hand :3
2 Likes
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.