-
Notifications
You must be signed in to change notification settings - Fork 842
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Duplicating a net label in schematic view causes phantom ratsnest connections to appear. Cannot be deleted either. #3340
Comments
Of course, this might be the expected behaviour in that net labels behave slightly differently from other components when duplicated in this way. I often duplicate resistors, capacitors etc with no problems, and change names and/or values and I thought that net labels would be similar. However,if I had given it some thought, duplicating a net label should indeed 'connect' both labels. (Although they should disconnect if the name or label text is edited.) The only problem is that you don't see this connection on the schematic diagram, only on the other two views. Cheers, |
Indeed, that might be a feature. However, when renaming, I think either: The connection should be removed. Or both labels should be renamed ? |
I would go for removing the connection as the best option when a duplicated net label is renamed. Cheers. |
I'd say this really is a bug, not an enhancement request. |
I would say that the connection should be removed once the duplicated net label is renamed. The issue #1326 is related to this: how to handle schematic only components. |
I do this sort of thing for a hobby and I have limited "hobby time" that I steal from my "family time". Therefore the first thing I do when I discover a new application is look for power-user tricks that help me become more productive. The duplicate (ctrl-d) function is an incredible time saver because - in this case - you can create a port, flip it, change the label, and then duplicate it for all the pins down the left side of a microcontroller. Much faster than dragging out a new one from the tool box and flipping it. However, I recently ran into this bug - and it truly is a bug - no one expects a renamed port to remain invisibly connected to the source port. The fact that it makes complete sense to the developer means nothing to a user. They expect the software to operate in a sane manner. I can confirm that the problem still exists in 0.9.4b. I'm a software developer myself and wouldn't mind helping out. If I cloned the repo and worked on a fix for this, would anyone be interested in a PR? |
A pull request would be welcome. If two labels are equal, they are connected. So, the ratsnest line in PCB and breadboard view is correct. Before starting to code a new behavior, it must be clear how that behavior should change.
|
@KjellMorgenstern - thank you for the clear picture of the problem space. These are all great ideas, However, I’m not sure you understand the actual bug. It’s easily reproduced with the following steps. Please try it out:
At this point I think you’ll agree that there should be a ratsnest line between the two pins in the pcb view.
There are now logically two distinct nets in the sketch but if you switch to the pcb view, you’ll note that there is only one net from Fritzing’s perspective, as all of the pins with ports are now tied together with ratsnest lines. The only way to fix this is to delete the duplicated net-label and recreate it manually, instead of using the duplicate feature. The fix for this bug is to ensure that duplicated net-labels, when renamed, drop their ties to the source label’s net. It’s as simple as that, I believe. John |
@jcalcote Thanks for clearing this up. I agree this is a bug. The problem even persist if you exchange step 7 and 8. If you The new behavior (the fix): Not part of a fix: |
@KjellMorgenstern - I downloaded the source and built Fritzing. I read the developer section of the wiki. I've spent several hours today in QTCreator using gdb to walk through various code paths. The problem is I just don't have enough background in the data model to determine how an original net label and a duplicate are incorrectly connected after a duplication command. I'm requesting someone with a bit more experience please look into this issue, if such a person can spare the time. |
I just wanted to re-enforce two items: I think you've already landed squarely in calling it a bug, but wanted to put my 2 cents in as an old designer. FWIW, this bug nailed me for a couple hours' worth of re-work today and in just trying to figure out what the heck was going on when my breadboard and pcb were looking totally screwy. |
I think I got a fix for this bug. @jcalcote (and others), if you are able to build Fritzing, it would be very nice if you can test this fix. |
Description
When I add a net label to the schematic view, give it a name etc, then duplicate it, edit the name and move it elsewhere, there are no rogue connections between the two labels in schematic view (as seen if I click and hold the "connector" in one of them) but on the breadboard and PCB views, there are now new ratsnest lines between the two points where the labels are, clicking on one end of the resistor "lights up" the other end.
Project showing problem
I have attached a simple project showing the problem described above with a single resistor and two net labels. It is called
NetLabelPossibleBug.fzz.zip
- you will simply need to drop off the.zip
extension, GitHub doesn't cope with*.fzz
files, so I had to give it an additional extension that GitHub liked!NetLabelPossibleBug.fzz.zip
Fritzing Version
0.3.9 Beta.
Steps to reproduce
This is the simplest way to reproduce, I discovered the problem when I duplicated a 5 pin female header connected to D0,D1, D2, D3,D4 on an ATMEGA328 and with net labels on each of the 5 pins, to a 6 pin for the A0 through A5 pins. On the breadboard and PCB views, I had ratsnest lines connecting D0 to A0, D1 to A1 ... D4 to A4.
I suspect that the problem is caused when the duplication takes place, the internal "I am connected to this point" data of the source net label is not cleared out when duplicated as the second one??? (Just guessing!)
Kind regards,
Norman.
The text was updated successfully, but these errors were encountered: