I’ve done this since… I can’t remember:
Still dealing with this years later:
Would it be possible to code “passives” as “PWR_FLAGS”? Maybe pin 1??
Maybe this is already taken care of in V7; but I don’t yet have V7.
But you would likely end up with multiple PWR_FLAGs on a net and that’s an error too.
Properly understood and assigned, PWR_FLAGs are easy-peasy.
2 Likes
So Mentor has this “nice” feature where L and C can be treated from an ECR perspective as a “short” and thus a nodal connection. This is “good” as it permit ECR characteristics, like net classes and pwr connectivity to transparently propogate and thus solves problems like this
5 Likes
To answer the original question, no PWR_FLAGs are still used in v7 as they were used in V6. However there’s a preference that can disable that type of ERC error, if you don’t want to be bothered by them. I don’t think that preference is new in V7, but it’s there in any case.
That is a feature I would also like in KiCad.
Quite a lot of people are “complaining” about cluttering their schematic with power flag symbols, and as far as I know this still has not been solved yet.
The issue below is related, but it solves it in a different way, by defining “signals”.
I’m not sure how this “signal” thing would work without labeling all the involved nets.
1 Like
L (and fuse, and PTC) I understand. But why C?
3 Likes
For AC signals perhaps?
1 Like
What if I told you I dont like this concept and it causes more problems that it solves (for my use-cases…). This is why “nice” is in quotes
So why C? Because my local librarians enabled the feature for C because Mentor provided an option to permit any 2pin device to propogate from 1-2 … Sounds great for fuses… Some like it for inductors (I don’t I’ll get to that) and it makes sparing sense for C and D
But that’s what happens when a feature is made available and a particular use-case forces it for all (also hidden behind three UIs and not visible on the cct)
Why don’t I like it for inductors? Because it only makes sense for DC and when you are planning out segregation for a 3stage EMI filter operating at 800V and your netclasses keep changing because and inductor “propogates” because someone wants their life easier for power being provided… You start seeing red because for Audio Sus there can easily be 400V across an inductor and thus you need to ensure there are different netclass rules for one side compared to the other to ensure a dense but safe design
1 Like
So you don’t like nice features if they are in between quotation marks. I could try to remember that, but it is very difficult to deduce such things from text. In real conversations there is eye contact and voice intonation that help detecting sarcastic remarks.
Only on the third attempt I got you probably meant skin color. At first I thought it was some way of showing ERC in some other program… (Yes, my bad, I have some issues with interpretations).
But still. You can’t (or at least should not) blame a feature in a program for people abusing it. If you look at the C++ programming language, then I guess that half of it may be “legacy” and for compatibility with historic code, and should not be used (in that way) for “modern programming”. There are lots of (mostly two pin) parts for which this “short two pins for ERC” works quite nice. From fuses to filtering parts such as ferrite beads and indeed inductors. But when you get to a 3 stage EMI filter, adding a PWR_FLAG after the filter is a more logical choice.
Equally consider a fuse… When it blows the full voltage will be seen across it and thus aspects of creepage and clearance should consider this but if netclass propogate you might end up putting 8th creepage “because it’s a short” when it really should be 5mm due to 1000V… Now you have a high energy failure …
My point is while there is valid use cases to simplify the constant need for placing PWR_FLAG everywhere, other use cases must be considered to make sure the solution doesn’t cause other problems
(Yes I HATE this feature, especially as it is enabled by default for my Xperitipn library…)
Signals will probably require labeled nets. It’s different from what you’re asking for, which would be some kind of symbol-level attribute.
Quotation marks are the typical way to indicate someone else said it 
I agree things are always abused and Xpedition belongs in special hell for their UI/UX … I am just trying to point out what seems like a great feature may result in some unexpected considerations (us high power lot are a special breed )
@paulvdh Side note on “seeing red”. Of course you could google for details, but briefly, the expression means “to become angry”. Most likely by analogy to the red cloth waved in front of a bull in bull fights to get the bull to charge.
Personally I don’t like to use the power flags to mark the potential points and meet ERCs either. However, it can be useful as a double check during schematics design. For people who don’t know KiCad it may seem strange and several times, when sharing schematics, I’ve heard them say: What the hell is this? 
I don’t know if this is feasible or an absurd idea, but I share it anyway.
What if kicad allows to add as a property (e.g. power_net) in the list of Net Classes?
In addition to selecting the colour, width, etc. of the net, it could also be marked with a label, as can be done in Altium. This would replace the current Power Flag.
1 Like
Should it be a property of the net, or of the component (connector pin, battery etc.) where the power comes from?
How is it done in other software?
People can always turn off this particular check and then you don’t have to learn about PWR_FLAG which isn’t actually that hard.
I think it’s like listening to an organ grinder monkey crank and complaining that it’s not playing Bach’s Toccata and Fugue, but just Skaters’ Waltz.
It’s usually a property of the component only if that component always provides power. So for a connector, it generally would not be set.
The directive labels shown in the Altium screenshot are a decent way (but only slightly smaller than a PWR_FLAG symbol)
I don’t have much experience yet with the new “Net Class Directive Labels” in KiCad V7, but I’m thinking of making a feature request to be able to hide them from the schematic with a single checkbox. Maybe a checkbox to hide the PWR_FLAG symbols would also be useful.
I didn’t know. How can I turn off this?
I like the ideas of @gschelotto and @hmk for making it a net property and optionally a net color/thickness. That is clean, simple, and removes the pwr-flg clutter. I had even tried making my own little power flag as a small arrow that sat right on the net, but even that looked cluttered to me. Or, as @paulvdh suggested, a way to hide the power flags for viewing and printing. I like the idea of colored/thicker lines to distinguish power nets for schematic review, and it would be handy to change color of nets for other reasons: perhaps you have 5V logic coming in and want to identify those distinct from 3.3V logic, or other use cases. Perhaps this is already available and I have not found it yet as I have not dug into net classes much. But I do dislike the power flags and don’t want them cluttering my schematic. FWIW.