I am getting a lot of “More than one name given to this bus or net” when I use that strategy to rename the signal of a bus. Should I consider this a issue? (I know that this warning is interesting, but in this specific case is intentional).
I am not sure why you think it is a good idea to do this.
You can prevent the warning from showing up by using net-ties, but those are more ment for other things such as intentionally wanting to change track widhts. For example a high current motor controller, with thin voltage sense feedback lines.
In KiCad the buses are mostly cosmetic, and you can just jusee the “status0” local label to the place your “DIO11” connects to.
Drawing schematics in a neat, organised and logical way is often a puzzle, sometimes a struggle. Having multiple names for a single net is probably going to add more to the confusion than to the defusion.
Why not simply remove both the “DIO13” and “extra0” labels and use “relay0” as local label?
The purpose of this warning is to let people know (in case they aren’t aware) that while you can put multiple different labels on a net, only one of them will be forwarded to the PCB. So when it comes time to lay out the PCB, a user might get confused if they expected a different name (or somehow expected multiple names) on the PCB.
It will be possible to disable this warning in V6.
2 Likes
Yes, sure. Have the warning capability is the best. I will just disable in the project that I use this kind of resource.
But I am think, there is a better way to achieve this NET connection in my schematic (open the bus and connect to local NETs) and workaround this warning without disable it?
If this were my schematic, I would just use the nets relay0,relay1, etc instead of renaming them extra0… and DIO13 etc.
If the DIO* nets are the names of microcontroller pins or something like that, I sometimes will add graphical text labels nearby explaining how microcontrollers or FPGAs with multiplexed pins are assigned.
1 Like
Understood. Thanks.
At the and I use two times this hierarchical block, the “main” and the “extra”. So, in this case I will live with the warning.
The DIO*, exactly are the pins of the controller. But it is connected using a DSub, so I prefer to keep these name that will provide better cross-reference to to software develloper.
Euhm, no.
During software development “DIO13” does not have much meaning.
I’ve got the habit of defining all I/O pins in a single header file, and in your case the pin for the relays would also get the names “relay0” and “relay1” in the source code.
If then later you want to swap the pins of the relays, (for example for better PCB routing) then the software guy only has to change a few lines in the macro’s in the I/O definition file.
Using logical names in the firmware also helps a lot with tracking down how and where variables are used. A decent IDE can easily do a search over multiple source files and make an overview of such things.
It also helps if you want to re-use parts of a project in anoter project, or have to port the whole project to another uC.
Yes, agree (I use also this strategy for DSPs / uC).
Curiosity: This hardware in particular http://www.ni.com/pdf/manuals/374069f.pdf have its own definition and high level programming (blocks) language. So the cross-relation is interesting to create the translation.
Not if you go over sheet boundaries and most definetly not with the updates they got in nighlies (This was started on the “new things in nightly topic” so i would guess that it was meant to mean that it could be a problem with the new bus handling introduced in that topic.)
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.