I’ve been fighting with an issue all day now.
The VALUE field in Escheema now carries over to PcbNew; and seems to set precedence.
I am confused. This was always the case. (This after all is the purpose of the value field in pcb_new.)
1 Like
Look closer at the Footprint name in library: field.
My custom Atomic Footprint was supposed to have 10µF where the value field is now.
I guess I have been doing it all upside down till now, and never knew any different.
What would that have to do with the footprint name?
1 Like
By the way i just tested it in 4.0.6 there is no way the value field set in the library is not overwritten on netlist import. Is it possible that you simply had a custom text field and did hide the value field?
Edit:
I am not sure you use the term atomic correctly. An atomic part is when you have one specialized symbol for one specialized footprint (both the symbol and footprint are only intended to be used with each other. The symbol has of course the footprint pre set in the library. Normally you would then also prefill all other fields in the symbol.)
You however seem to use the generic capacitor symbol from the official library. (That would explain why the value field was pre filled with “C”)
So it might be that in the past you had a symbol for 10uF cap connected to the footprint of the 10uF cap. If you also had the value field of this specialized symbol pre filled with the same value you used in the footprint you would have never noticed that the value of the footprint is overwritten on netlist import.
Edit 2:
Is it possible that in the past you followed the “fully specified symbol” workflow. Meaning you had one symbol per capacitor “value” that connected to its correct generic footprint? (That would make more sense. Mybe you just got confused between the roles of symbol and footprint in that particular workflow.)
1 Like
I think this could be the heart of the issue that I am having.
It was not very clear, at the beginning of me using V3 how to work with everything.
I hid the value field with the “~” symbol for parts without an actual value.
I’m not following here ?
Did this use to work, but now does not ?
I can paste 10µF into a PCB field fine, save/export netlist and then import with
(value "15µF")
and the value changes as expected. Reports
Changing footprint "C3:/56577AD5" value from "10µF" to "15µF".
It’s always been like that. It’s been noted before that you can’t set a default value in the footprint, the text is just a placeholder that gets overwritten.
You might want to change the title. It also confirms my THEORY about people who put RANDOM words in caps… Rather than leaping to conclusions, why not ask first?
2 Likes
No, it has not.
I used this quirk to create a seperate drawing with only the Fab Layer.
C5 was fully qualified for what I wanted on all the layers; including the NON-Fab layers. I was able to select the layers of interest and create and print a document that illustrated the properties of the parts on the board.
I suppose I should probably move all of the Fab layers in my library into one of the other layers; that is going to be quite a bit of a time sink.
Bottom line, I WAS using KiCad to create secondary documents by printing those layers. I’m now going to have to wait to see what happens with release of V5 before I spend to much time on my own personal libraries.
It has nothing to do with what layer the value field is on. It is always handled the same way.
Can you explain which steps work, or used to work.
If there is a value in the SCH, that would be expected to export in the NET.
However I can see uses where someone might want to load some default LIB value, and in order to do that, omits value line from the NET. Other CAD pgms work like this. ie info not in net, comes from lib.
In that somewhat special case, I would expect NET import into PCB to load the LIB part, with LibVal
Strangely, in an (older) Version: (5.0.0-rc2-dev-44-gde6b32d23) I get this behaviour
I can create a custom LibValue field in LIB, and manual add-part, brings that in fine.
NET import, with no value line at all, (edited NET file) brings in an empty value part.
After that is imported, I can still manually add from lib, and LibVal shows on NEW manual footprint.
However, neither update from lib nor change footprint will get the LibVal updated on any existing part ?
To me that is a blind spot.
Smarter LIB/NET combined operation would be :
- If Value is in NET, apply that. (this works)
- If no value line at all is in net, use LibVal (this is missing)
- If value line is “”, use empty value (really line 1 rule)
- Update from Library, should have Keep/update value choices
- Change part, should also have keep/update value choices
Currently, you appear to have a situation where a LIB change, cannot be applied to an existing design.
When I download a new nightly, I’ll recheck this. << Addit: Identical on latest build.
1 Like
I can not quite remember all the details of the different versions I have used!
My biggest issue, from what I recall, is that if I wanted to make a VERY SMALL change to the footprint dimensions, then ALL of the silkscreen and Fab layer information was dorked up in location and rotation upon reading the new NetList.
Silly me thought it might be a good idea to seperate and include the two concepts. I’d have an Atomic Symbol that had an Atomic Footprint. It worked in KiCad for a while.
As a reminder, this issue has NOTHING to do with board fabrication, but is related to how I attempted to use KiCad to create an IPB with location and value not changing even if the Land Pattern of the Footprint was changed.
At the moment, it looks like I may retain the same concept, but move the Atomic Footprint data off of the Fab_Layer in KiCad.
My further thinking was that even if a part had the same Land Pattern, it might physically have a different height and benefit from other tweaks in design.
I’m not an expert in any way, but I already have 2 separate 1206 FootPrints for resistors and capacitors.
I figured that that even though the Land Pattern dimensions might be the same, the Solder Paste and Solder Mask might not be the same.
My very first attempt at Atomic FootPrints is apparently a failure.
As i explained above, you use the atomic idea wrong.
A proper atomic pair has a symbol specific to your footprint. The symbol holds all the data (reference, value, mpn, …) whereas the footprint is made in the normal way.
- Using REF** for the reference placeholder and probably the footprint name as the value placeholder. Both of these are arbitrary as they are overwritten anyways. If you want to place additional copies on different layers you need to add text fields with %R for references and %V for the value
So if you then update from schematic you get the correct data from the atomic symbol into the placeholder fields of your footprint.
Mainly because the 3d model is different (resistor has a black body, capacitor a brown body)
But also because users will expect a resistor footprint for resistors and a capacitor footprint for capacitors.
In the case of resistor vs capacitor they are equal (both fall under the same IPC rules) In the official lib both footprints are generated by the same script.
1 Like
The default libraries always did this as the end metalisation is very different, before you even start thinking about the different 3d models
1 Like
What do you mean with “end metalisation”? The 1206 footprints in the resistor, capacitor, diode, … libs are identical with respect to the footprint data. (only the description, tag and 3d path are different. You can easily check that using a text diff tool.)
I am talking about the part, not the footprint
I am still not really clear why that would need different footprints. (which after all is what the discussion is about)
There was a time when V4 hand soldering footprints did vary