# Power header ratsnesting positive to negative

**URL:** <https://forum.fritzing.org/t/power-header-ratsnesting-positive-to-negative/14728>\
**Category:** beginners\
**Created:** [December 21, 2021, 3:42pm UTC](https://forum.fritzing.org/t/power-header-ratsnesting-positive-to-negative/14728 "2021-12-21T15:42:31Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![catwowe99](https://forum.fritzing.org/letter_avatar_proxy/v4/letter/c/13edae/32.png) [@catwowe99](https://forum.fritzing.org/u/catwowe99)\
**Post date:** [December 21, 2021, 3:42pm UTC](https://forum.fritzing.org/t/power-header-ratsnesting-positive-to-negative/14728/1 "2021-12-21T15:42:31Z")

</div>

Hey guys,

I’ve probably done something stupidly wrong here, but after quite a lot of time of debugging and unable to understand exactly what the issue was, I thought I’d ask for some proper help.

I’m trying to design a PCB, which is powered by a generic two pin header. The issue is that in the PCB view the ratsnest takes negative to positive, or vice versa, then out to the rest of the board, which breaks routing.

I’ve checked connections in breadboard view, everything looks to be okay as when I click the individual positive or negative pins, all of the correct connections light up.

We can see this in the screenshot below for J8 - I expect two seperate ratsnests out from the header, but they merge into one across the pins.

Any help would be much appreciated - many thanks

 ![Screenshot 2021-12-21 at 15.37.26](https://forum.fritzing.org/uploads/default/original/2X/7/78df2f0a99eeb847479f606910eeebae05e268eb.png)

[pcb\_button\_forum.fzz](https://forum.fritzing.org/uploads/short-url/qAyjpjFSTQdPEzudgdZkB11L9xk.fzz) (54.7 KB)

---

<div class="post-metadata">

**Author:** ![vanepp](https://forum.fritzing.org/user_avatar/forum.fritzing.org/vanepp/32/4426_2.png) [@vanepp](https://forum.fritzing.org/u/vanepp)\
**Post date:** [December 21, 2021, 4:44pm UTC](https://forum.fritzing.org/t/power-header-ratsnesting-positive-to-negative/14728/2 "2021-12-21T16:44:20Z")

</div>

It looks like you have caused routing database corruption. Typically that happens because you made incorrect changes in another view that caused shorts and the shorts remain when the bad connection is removed. We have never been able to reproduce this problem to fix it, and the usual answer is to start the drawing again from scratch and complete one view completely (such as the current case with breadboard which looks correct.) Then do the other two views by clicking on the rats nest lines and routing them (as they show where Fritzing thinks the connection should go.) That avoids making wiring errors that may lead to database corruption. If you click on a pin all connections to that pin will light yellow. In breadboard all seems fine, there is no power to ground short:

 ![capture](https://forum.fritzing.org/uploads/default/original/2X/c/cf0634b54c9a8885729568189250288834f60655.jpeg)

here only the power wires light yellow, ground does not indicating no short. In pcb the opposite is true (which indicates routing database corruption because the views should be the same!)

 ![capture1](https://forum.fritzing.org/uploads/default/original/2X/4/4a2de1405a142db9059a0931b2fcb35c801e98af.jpeg)

there are a lot of unexpected shorts. Doing Routing-\>select all wires in breadboard and then hitting delete does not cure the problem (but there are still wires connected because of the resistors.) Usually if you remove all the connections the routing database will reset leaving you with the components ready to wire, but that doesn’t happen in this case. Several other oddnesses (none of them necessarily wrong!) the leds appear to really be a pin header (presumably because we don’t appear to have a re/green LED part which surprises me!) which shouldn’t be an issue. In pcb the chips are shown as on top of the board as is usual:

 ![capture2](https://forum.fritzing.org/uploads/default/original/2X/2/2e3ed17e0068c7dbb5b4338b4810a23898379040.jpeg)

but the resistors are both SMD and on the bottom of the board (by default they are on the top!) Again this isn’t necessarily incorrect and not the cause of this problem, but it is unusual although there may be a reason for it.

 ![capture3](https://forum.fritzing.org/uploads/default/original/2X/7/78c062f51564756ca26bc2f14ac02566b8120aa3.jpeg)

I’m afraid your best bet is to start the sketch again from scratch, and wire breadboard to match the current layout and see if that corrects pcb (which it should!)

Peter

---

<div class="post-metadata">

**Author:** ![fai](https://forum.fritzing.org/letter_avatar_proxy/v4/letter/f/87869e/32.png) [@fai](https://forum.fritzing.org/u/fai)\
**Post date:** [December 21, 2021, 10:10pm UTC](https://forum.fritzing.org/t/power-header-ratsnesting-positive-to-negative/14728/3 "2021-12-21T22:10:50Z")

</div>

What is your Fritzing version?  
We have made a lot of bug fixing in recent versions and it would be nice to check if we still have this bug around.

---

<div class="post-metadata">

**Author:** ![catwowe99](https://forum.fritzing.org/letter_avatar_proxy/v4/letter/c/13edae/32.png) [@catwowe99](https://forum.fritzing.org/u/catwowe99)\
**Post date:** [December 21, 2021, 10:23pm UTC](https://forum.fritzing.org/t/power-header-ratsnesting-positive-to-negative/14728/4 "2021-12-21T22:23:55Z")

</div>

Peter, thanks so much for the awesome reply - I’m going to rebuild now.

It would be great if in the future Fritzing could self report when a database corruption has occurred or is likely to avoid users having to debug.

thank you all again!

@fai version Version 0.9.9  
(bCD-348-0-f0af53a9 2021-09-22) Cocoa [Qt 5.15.2]

---

<div class="post-metadata">

**Author:** ![fai](https://forum.fritzing.org/letter_avatar_proxy/v4/letter/f/87869e/32.png) [@fai](https://forum.fritzing.org/u/fai)\
**Post date:** [December 21, 2021, 10:43pm UTC](https://forum.fritzing.org/t/power-header-ratsnesting-positive-to-negative/14728/5 "2021-12-21T22:43:30Z")

</div>

Thanks, we still have to fix it then.  
Could you remember anything that could help us to reproduce it? Any action that you performed just before detecting the shortcitcuit?

---

<div class="post-metadata">

**Author:** ![vanepp](https://forum.fritzing.org/user_avatar/forum.fritzing.org/vanepp/32/4426_2.png) [@vanepp](https://forum.fritzing.org/u/vanepp)\
**Post date:** [December 21, 2021, 11:32pm UTC](https://forum.fritzing.org/t/power-header-ratsnesting-positive-to-negative/14728/6 "2021-12-21T23:32:45Z")

</div>

> [@catwowe99](#):
>
> It would be great if in the future Fritzing could self report when a database corruption has occurred or is likely to avoid users having to debug.

Unfortunately Fritzing doesn’t see anything wrong. I have been seeing these (around 5 cases over the last 5 years) after they occur, but even when I repeat what I think the user did, I can’t get the fault to occur. If we can figure out how to reproduce it then we can probably fix it, but without that there isn’t much we can do since we don’t know what causes the problem. Yours is the first case we have seen on version 0.9.9 (the rest have been earlier versions) so it is useful to know that it hasn’t been fixed yet.

Peter

---

<div class="post-metadata">

**Author:** ![catwowe99](https://forum.fritzing.org/letter_avatar_proxy/v4/letter/c/13edae/32.png) [@catwowe99](https://forum.fritzing.org/u/catwowe99)\
**Post date:** [December 22, 2021, 10:06am UTC](https://forum.fritzing.org/t/power-header-ratsnesting-positive-to-negative/14728/7 "2021-12-22T10:06:23Z")

</div>

I don’t know about a specific action that caused the short circuit, but I know that working with large perf boards often caused performance issues which sometimes lead to crashing - often the files to recover were unusable. Furthermore, I worked with this particularly file across Linux, Windows and Mac devices, not sure if that would also be a contributing factor.

Finally, this was one of my first Fritzing projects and I did a lot of experimentation with design iterations, possibly it was something during this phase?

I know this isn’t much help but I will keep an eye out if I can reproduce again.

Thank you all again for your work here

---

<div class="post-metadata">

**Author:** ![vanepp](https://forum.fritzing.org/user_avatar/forum.fritzing.org/vanepp/32/4426_2.png) [@vanepp](https://forum.fritzing.org/u/vanepp)\
**Post date:** [December 22, 2021, 4:09pm UTC](https://forum.fritzing.org/t/power-header-ratsnesting-positive-to-negative/14728/8 "2021-12-22T16:09:03Z")

</div>

This is unfortunately fairly normal. There is usually a lot of things that have happened before the corruption is noticed. The last one I saw was more straightforward, in that there was (I think anyway!) a single mistake due to an odd part where power and ground got reversed in schematic while correct in breadboard. However even with that, I have not been able to create a sequence of changes that cause the corruption. There is some specific set of actions that causes the corruption (it looks like a delete did not complete for some reason leaving enough elements around to cause the corruption but I don’t know why), but it isn’t at all obvious what the sequence is. Until we can reliably reproduce the problem we can neither trace the issue to fix it, nor be sure any fix has actually fixed the problem. It may be that we need to add the facility to save the undo stack in Fritzing to a file so that once the corruption occurs it would be possible to step back through the undo stack to see how the issue occurred and hopefully reproduce it by reapplying the changes. I’m however not sure that is feasible, I expect it may be difficult to write the undo stack out to a file and that file may get very large, usually for no purpose because this happens very rarely.

Peter

---

<div class="post-metadata">

**Author:** ![catwowe99](https://forum.fritzing.org/letter_avatar_proxy/v4/letter/c/13edae/32.png) [@catwowe99](https://forum.fritzing.org/u/catwowe99)\
**Post date:** [December 27, 2021, 9:26pm UTC](https://forum.fritzing.org/t/power-header-ratsnesting-positive-to-negative/14728/9 "2021-12-27T21:26:31Z")

</div>

Okay I think I can reliably reproduce the issue now.

Changing it to bridge both side rails causes the short

 ![Screenshot 2021-12-27 at 21.24.14](https://forum.fritzing.org/uploads/default/original/2X/9/9eacd12392c4b1f24cdd3713def04bd66e018372.png)

Unfortunately I cannot upload all of the required media in one post, but now, if we only allow the two pin power to go to one side of the rails (in an L shape as opposed to an inverse T ship) this resolves the issue.

Let me know if you need more info or have further findings 🙂

---

<div class="post-metadata">

**Author:** ![fai](https://forum.fritzing.org/letter_avatar_proxy/v4/letter/f/87869e/32.png) [@fai](https://forum.fritzing.org/u/fai)\
**Post date:** [December 28, 2021, 12:34am UTC](https://forum.fritzing.org/t/power-header-ratsnesting-positive-to-negative/14728/10 "2021-12-28T00:34:23Z")

</div>

Excellent news. Great that you found a way to reproduce the issue. However, I am a bit confused. Could you tell us how to reproduce it in our computers?  
The best way would be some instructions on a minimal example such as STEP1: Add a protoboard of 9x10, Step2: Add a resistor, STEP3: etc.  
If you can not find a minimal example , you are also welcome to upload the currect file and give us some steps as before.  
Thanks for finding a way to reproduce it!

---

<div class="post-metadata">

**Author:** ![vanepp](https://forum.fritzing.org/user_avatar/forum.fritzing.org/vanepp/32/4426_2.png) [@vanepp](https://forum.fritzing.org/u/vanepp)\
**Post date:** [December 28, 2021, 3:32am UTC](https://forum.fritzing.org/t/power-header-ratsnesting-positive-to-negative/14728/11 "2021-12-28T03:32:46Z")

</div>

Where did you start from? If I use your original .fzz file above I can make this happen too, but I think it is a result of the database corruption (because pcb still shows nets to be routed, indicating the routing database has not been cleared.) I took your original .fzz file, and deleted all traces in all views (which still leaves ratsnest lines in schematic and pcb!) and then moved the components in breadboard until there were no connections in any of the 3 views. That should clear the routing database and now I am going to rewire your circuit and see what happens (I expect it will work correctly! but we will see.)

Peter

---

<div class="post-metadata">

**Author:** ![catwowe99](https://forum.fritzing.org/letter_avatar_proxy/v4/letter/c/13edae/32.png) [@catwowe99](https://forum.fritzing.org/u/catwowe99)\
**Post date:** [January 17, 2022, 2:07pm UTC](https://forum.fritzing.org/t/power-header-ratsnesting-positive-to-negative/14728/12 "2022-01-17T14:07:44Z")

</div>

Hey to confirm this was a brand new fzz. regarding how to reproduce, can someone allow my ability to post more than one image per post and i can give a detailed set of instructions 🙂

thanks!

---

<div class="post-metadata">

**Author:** ![vanepp](https://forum.fritzing.org/user_avatar/forum.fritzing.org/vanepp/32/4426_2.png) [@vanepp](https://forum.fritzing.org/u/vanepp)\
**Post date:** [January 17, 2022, 4:14pm UTC](https://forum.fritzing.org/t/power-header-ratsnesting-positive-to-negative/14728/13 "2022-01-17T16:14:40Z")

</div>

That is excellent news! I can’t increase your post limit (I think it increases with either time or number of posts) although the admin may be able to. How about just describing what you did one step at a time in text and I will try and reproduce it (what Fritzing version you are using may be important too, I am currently on 0.9.9 but have older copies if you are using something older. I would suggest you post the .fzz file without the power wires then state in text which wires you added in which sequence to cause the fault. With that I can start from your sketch and see if it recreates for me (which will be awesome if it will!) as well as make sure the routing database corruption hasn’t already occurred in the base .fzz file. Alternately you can use multiple posts (which while a pain, should work!) with one image in each post.

Peter

---

<div class="post-metadata">

**Author:** ![fai](https://forum.fritzing.org/letter_avatar_proxy/v4/letter/f/87869e/32.png) [@fai](https://forum.fritzing.org/u/fai)\
**Post date:** [April 5, 2022, 7:29pm UTC](https://forum.fritzing.org/t/power-header-ratsnesting-positive-to-negative/14728/14 "2022-04-05T19:29:57Z")

</div>

@catwowe99 , If you can explain us how to reproduce the error, we can fix it!  
You are welcome to send us a mail or write a link to a Google Docs or similar, if that is better for you. Additionally, you could also write an issue in github:

> **[Issues · fritzing/fritzing-app](https://github.com/fritzing/fritzing-app/issues)**
>
> Fritzing desktop application. Contribute to fritzing/fritzing-app development by creating an account on GitHub.

Or write in this one:

> <https://github.com/fritzing/fritzing-app/issues/3904>
>
> \*\*Edit\*\*:
> \## Current Behaviour
> 
> In this sketch created with Fritzing 0.9.3b t…here is a ratsnest line between 24V and ground, which is not backed by any routed connection or bus in any of the views.
> 
> \[delay unit new4.fzz.zip\](https://github.com/fritzing/fritzing-app/files/7524713/delay.unit.new4.fzz.zip)
> 
> There are other similar problems (see text below)
> \## Expected
> Note: Some root causes for this issue have been fixed, and we don't have yet reports for this problem for 0.9.7 or later.
> It would be helpful if Fritzing could detect such orphaned ratsnest lines.
> Once detected, report them and offer to delete them.
> 
> \*\*Was\*\*:
> 
> In this sketch (remove the trailing .zip to recover the .fzz file) 
> 
> \[delay unit new4.fzz.zip\](https://github.com/fritzing/fritzing-app/files/7524713/delay.unit.new4.fzz.zip)
> 
> whose breadboard looks like this
> 
> !\[capture\](https://user-images.githubusercontent.com/16514277/141405544-d92199a3-6f2d-4044-893d-09867532c2b5.jpg)
> 
> shows 3 problems, 1) a missing wire in breadboard, 2) a short between 24V and ground (caused by an incorrect connection in schematic) and 3) two apparently valid connections in breadboard which also have rats nest lines (and are in fact not connected!) This is the schematic as it starts:
> 
> !\[capture1\](https://user-images.githubusercontent.com/16514277/141405651-cc259798-cf4a-4b37-b7e7-adc4284f6aef.jpg)
> 
> the two connections circled in red are the cause of the rats nest lines in breadboard (which is the indication of routing database corruption!) So remove the two wires in schematic like this:
> 
> !\[capture2\](https://user-images.githubusercontent.com/16514277/141405756-a167b432-f678-427a-84f0-7cd23396625d.jpg)
> 
> note that neither wire was replaced by a rats nest line, indicating there is no connection in breadboard! Which is shown here
> 
> !\[capture3\](https://user-images.githubusercontent.com/16514277/141405914-9f0ca25c-db14-46c3-b7bc-5f31a00b9b29.jpg)
> 
> this appears to show a valid connection on both the wires circled in red in the above image. However clicking on a trace indicates that the connection is in fact not valid as neither the wire nor the trace it connects to light yellow to indicate connection. 
> 
> !\[capture4\](https://user-images.githubusercontent.com/16514277/141405997-d5e71993-4f74-432a-a719-3b4dab9394c7.jpg)
> 
> the same thing occurs on the other connection, it appears valid but is not as it does not light yellow along the entire path when clicked on. 
> 
> !\[capture5\](https://user-images.githubusercontent.com/16514277/141406089-a8d4147e-4676-48ba-83c2-350732d5c638.jpg)
> 
> if I now make the two connections in schematic
> 
> !\[capture6\](https://user-images.githubusercontent.com/16514277/141406159-79ea8547-d7e7-456b-af23-5b64e7faf105.jpg)
> 
> then the rats nest lines appear in breadboard as expected (although the wires that aren't connected remain!) 
> 
> !\[capture7\](https://user-images.githubusercontent.com/16514277/141406240-431b3425-55f8-4e38-8d47-6b260d360fce.jpg)
> 
> deleting the two wires in breadboard leaves only the rats nest lines and clicking on the rats nest lines produces a correct connection:
> 
> !\[capture8\](https://user-images.githubusercontent.com/16514277/141406301-f9299777-b94f-4829-90fa-6bae3c0d36c2.jpg)
> 
> !\[capture9\](https://user-images.githubusercontent.com/16514277/141406814-f53a04a8-3e76-4483-bd9b-5d03203ec735.jpg)
> 
> and if I delete the wires again in schematic they are correctly replaced by rats nest lines. 
> 
> !\[capture10\](https://user-images.githubusercontent.com/16514277/141406975-c5bb6ad0-cbc1-4cdc-b8cb-55d357ecae10.jpg)
> 
> I think (from past experience with this bug) that this issue was caused by breadboard being completed and then a wrong connection made, in this case by the connection circled in red here, in schematic which reflected in to breadboard and corrupted the routing database.
> 
> !\[capture11\](https://user-images.githubusercontent.com/16514277/141407153-db816c75-015c-435b-a06a-ec607b0167eb.jpg)
> 
> which as we see from the rats nest lines should be to the bottom connector on U5 (the user assumed this part was a standard 7805 with input power on the top left pin and ground on the bottom pin which is incorrect for the actual part used.)
> 
> !\[capture12\](https://user-images.githubusercontent.com/16514277/141407268-098e629c-d333-4f93-a048-f22cc944b861.jpg)
> 
> as shown by the rats nest lines for the actual connection which indicates ground is the top left and power input is the bottom pin as shown here.
> 
> !\[capture13\](https://user-images.githubusercontent.com/16514277/141407318-9a766fcb-e0a6-4bc8-955a-64442f0555e8.jpg)
> 
> Unfortunately for finding this bug, there is step missing. Just connecting the wires in the incorrect order with 24V connecting to the connector circled in blue in the above drawing and the pin on the 7805 circled in green produces the short from 24V to ground but does not reproduce the invalid rats nest lines on the connections to the base and collector of Q9. I haven't so far been able to find any sequence of connections that will cause the original error, there is some step that I am missing (and the person who did this doesn't remember what he did to cause it!) Until we can find the sequence that produces this error (and I have seen 4 or 5 instances of this same problem in the past, none of them reproducible!) I expect we will have a hard time fixing it. I however just found another issue that may relate. The ground net has two wires in it, which result in loops in ground. I don't know if this will break anything but it may.
> 
> !\[capture14\](https://user-images.githubusercontent.com/16514277/141407509-ed92718a-7021-4993-97f6-78d86592d027.jpg)
> 
> here I dragged all the ground connections apart and then changed the wire colors for the two wires making up ground to red and green. As we see there are three loops in ground where a pin has 2 connections in parallel to ground. If I select a ground node, all the other ground nodes in both wires light up yellow, but I wonder if the multiple wires and loops in ground are causing a problem somewhere and causing the seeming unrelated base and collector connections on Q9 to become broken (although as noted I can't so far recreate that!) 
> 
> !\[capture15\](https://user-images.githubusercontent.com/16514277/141407769-a818f435-ffc9-435e-a189-538e592ba1ff.jpg)
> 
> The error appears to be in breadboard view. If I delete the two connections in schematic, the rats nest lines disappear in breadboard (because they are caused by the connetion in schematic not being present in breadboard view)
> 
> !\[capture16\](https://user-images.githubusercontent.com/16514277/141408190-aaa62055-9b06-4a60-bffb-598893f1eddd.jpg)
> 
> and in breadboard view the rats nest lines are gone
> 
> !\[capture17\](https://user-images.githubusercontent.com/16514277/141408252-7194e06c-2738-4be6-ae59-4c15816602ef.jpg)
> 
> however the connections are still broken as the pads the wire appears to connect to do not light up yellow in either case
> 
> !\[capture18\](https://user-images.githubusercontent.com/16514277/141408294-d8787503-2515-4c50-92b7-14271fa25f67.jpg)
> 
> !\[capture19\](https://user-images.githubusercontent.com/16514277/141408308-03b12c56-89bb-40cc-ac27-cfaf752716f1.jpg)
> 
> So at this point save the sketch as delay unit new4-base.fzz (again remove the trailing .zip to get the.fzz file)
> 
> \[delay unit new4-base.fzz.zip\](https://github.com/fritzing/fritzing-app/files/7524812/delay.unit.new4-base.fzz.zip)
> 
> then delete the two wires that are incorrect like this
> 
> !\[capture20\](https://user-images.githubusercontent.com/16514277/141408518-fe001509-ceb8-4a38-8c9d-6d46b034a382.jpg)
> 
> then save this sketch as "delay unit new4-breadboard-wires-deleted.fzz"
> 
> \[delay unit new4-breadboard-wires-deleted.fzz.zip\](https://github.com/fritzing/fritzing-app/files/7524819/delay.unit.new4-breadboard-wires-deleted.fzz.zip)
> 
> then unzip both .fzz files to recover the .fz files and run dif against them
> 
> $ diff -c 'delay unit new4-base/delay unit new4-base.fz' 'delay unit new4-breadboard-wires-deleted/delay unit new4-breadboard-wires-deleted.fz'
> \*\*\* "delay unit new4-base/delay unit new4-base.fz" Thu Nov 11 18:54:20 2021
> \--- "delay unit new4-breadboard-wires-deleted/delay unit new4-breadboard-wires-deleted.fz" Thu Nov 11 18:58:18 2021
> \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
> \*\*\* 895,906 \*\*\*\*
> \<connect connectorId="connector0" modelIndex="85634041" layer="breadboardWire"/\>
> \</connects\>
> \</connector\>
> \- \<connector connectorId="connector21004" layer="breadboardbreadboard"\>
> \- \<geometry x="0" y="0"/\>
> \- \<connects\>
> \- \<connect connectorId="connector1" modelIndex="85643703" layer="breadboardWire"/\>
> \- \</connects\>
> \- \</connector\>
> \<connector connectorId="connector22003" layer="breadboardbreadboard"\>
> \<geometry x="0" y="0"/\>
> \<connects\>
> \--- 895,900 ----
> \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
> \*\*\* 1077,1088 \*\*\*\*
> \<connect connectorId="connector2" modelIndex="85624591" layer="breadboard"/\>
> \</connects\>
> \</connector\>
> \- \<connector connectorId="connector18004" layer="breadboardbreadboard"\>
> \- \<geometry x="0" y="0"/\>
> \- \<connects\>
> \- \<connect connectorId="connector0" modelIndex="85643594" layer="breadboardWire"/\>
> \- \</connects\>
> \- \</connector\>
> \<connector connectorId="connector2002" layer="breadboardbreadboard"\>
> \<geometry x="0" y="0"/\>
> \<connects\>
> \--- 1071,1076 ----
> \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
> \*\*\* 1265,1276 \*\*\*\*
> \<connect connectorId="connector0" modelIndex="85634041" layer="copper1trace"/\>
> \</connects\>
> \</connector\>
> \- \<connector connectorId="connector21004" layer="breadboardbreadboard"\>
> \- \<geometry x="0" y="0"/\>
> \- \<connects\>
> \- \<connect connectorId="connector1" modelIndex="85643703" layer="copper1trace"/\>
> \- \</connects\>
> \- \</connector\>
> \<connector connectorId="connector22003" layer="breadboardbreadboard"\>
> \<geometry x="0" y="0"/\>
> \<connects\>
> \--- 1253,1258 ----
> \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
> \*\*\* 1443,1454 \*\*\*\*
> \<connect connectorId="connector2" modelIndex="85624591" layer="copper0"/\>
> \</connects\>
> \</connector\>
> \- \<connector connectorId="connector18004" layer="breadboardbreadboard"\>
> \- \<geometry x="0" y="0"/\>
> \- \<connects\>
> \- \<connect connectorId="connector0" modelIndex="85643594" layer="copper1trace"/\>
> \- \</connects\>
> \- \</connector\>
> \<connector connectorId="connector2002" layer="breadboardbreadboard"\>
> \<geometry x="0" y="0"/\>
> \<connects\>
> \--- 1425,1430 ----
> \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
> \*\*\* 1627,1638 \*\*\*\*
> \<connect connectorId="connector0" modelIndex="85634041" layer="schematicTrace"/\>
> \</connects\>
> \</connector\>
> \- \<connector connectorId="connector21004" layer="breadboardbreadboard"\>
> \- \<geometry x="0" y="0"/\>
> \- \<connects\>
> \- \<connect connectorId="connector1" modelIndex="85643703" layer="schematicTrace"/\>
> \- \</connects\>
> \- \</connector\>
> \<connector connectorId="connector22003" layer="breadboardbreadboard"\>
> \<geometry x="0" y="0"/\>
> \<connects\>
> \--- 1603,1608 ----
> \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
> \*\*\* 1805,1816 \*\*\*\*
> \<connect connectorId="connector2" modelIndex="85624591" layer="schematic"/\>
> \</connects\>
> \</connector\>
> \- \<connector connectorId="connector18004" layer="breadboardbreadboard"\>
> \- \<geometry x="0" y="0"/\>
> \- \<connects\>
> \- \<connect connectorId="connector0" modelIndex="85643594" layer="schematicTrace"/\>
> \- \</connects\>
> \- \</connector\>
> \<connector connectorId="connector2002" layer="breadboardbreadboard"\>
> \<geometry x="0" y="0"/\>
> \<connects\>
> \--- 1775,1780 ----
> \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
> \*\*\* 8446,8492 \*\*\*\*
> \<instance moduleIdRef="WireModuleID" modelIndex="85645514" path=":/resources/parts/core/wire.fzp"\>
> \<views/\>
> \</instance\>
> \- \<instance moduleIdRef="WireModuleID" modelIndex="85643594" path=":/resources/parts/core/wire.fzp"\>
> \- \<title\>Wire24155\</title\>
> \- \<views\>
> \- \<breadboardView layer="breadboardWire"\>
> \- \<geometry z="3.50005" x="234" y="-99" x1="0" y1="0" x2="27.0393" y2="9.04975" wireFlags="64"/\>
> \- \<wireExtras mils="22.2222" color="#418dd9" opacity="1" banded="0"/\>
> \- \<connectors\>
> \- \<connector connectorId="connector0" layer="breadboardWire"\>
> \- \<geometry x="0" y="0"/\>
> \- \<connects\>
> \- \<connect connectorId="connector18004" modelIndex="85613958" layer="breadboardbreadboard"/\>
> \- \</connects\>
> \- \</connector\>
> \- \</connectors\>
> \- \</breadboardView\>
> \- \<pcbView layer="copper1trace"\>
> \- \<geometry z="9.50006" x="225" y="-99.0001" x1="0" y1="0" x2="36.0395" y2="9.04986" wireFlags="64"/\>
> \- \<wireExtras mils="11.1111" color="#f2c600" opacity="1" banded="0"/\>
> \- \<connectors\>
> \- \<connector connectorId="connector0" layer="copper1trace"\>
> \- \<geometry x="0" y="0"/\>
> \- \<connects\>
> \- \<connect connectorId="connector18004" modelIndex="85613958" layer="breadboardbreadboard"/\>
> \- \</connects\>
> \- \</connector\>
> \- \</connectors\>
> \- \</pcbView\>
> \- \<schematicView layer="schematicTrace"\>
> \- \<geometry z="5.50003" x="225" y="-99.0001" x1="0" y1="0" x2="36.0395" y2="9.04986" wireFlags="64"/\>
> \- \<wireExtras mils="9.7222" color="#404040" opacity="1" banded="0"/\>
> \- \<connectors\>
> \- \<connector connectorId="connector0" layer="schematicTrace"\>
> \- \<geometry x="0" y="0"/\>
> \- \<connects\>
> \- \<connect connectorId="connector18004" modelIndex="85613958" layer="breadboardbreadboard"/\>
> \- \</connects\>
> \- \</connector\>
> \- \</connectors\>
> \- \</schematicView\>
> \- \</views\>
> \- \</instance\>
> \<instance moduleIdRef="WireModuleID" modelIndex="85645517" path=":/resources/parts/core/wire.fzp"\>
> \<views/\>
> \</instance\>
> \--- 8410,8415 ----
> \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
> \*\*\* 8496,8542 \*\*\*\*
> \<instance moduleIdRef="WireModuleID" modelIndex="85645521" path=":/resources/parts/core/wire.fzp"\>
> \<views/\>
> \</instance\>
> \- \<instance moduleIdRef="WireModuleID" modelIndex="85643703" path=":/resources/parts/core/wire.fzp"\>
> \- \<title\>Wire24206\</title\>
> \- \<views\>
> \- \<breadboardView layer="breadboardWire"\>
> \- \<geometry z="3.50006" x="225.059" y="-89.9503" x1="0" y1="0" x2="35.941" y2="-9.0497" wireFlags="64"/\>
> \- \<wireExtras mils="22.2222" color="#418dd9" opacity="1" banded="0"/\>
> \- \<connectors\>
> \- \<connector connectorId="connector1" layer="breadboardWire"\>
> \- \<geometry x="0" y="0"/\>
> \- \<connects\>
> \- \<connect connectorId="connector21004" modelIndex="85613958" layer="breadboardbreadboard"/\>
> \- \</connects\>
> \- \</connector\>
> \- \</connectors\>
> \- \</breadboardView\>
> \- \<pcbView layer="copper1trace"\>
> \- \<geometry z="9.50005" x="215.881" y="-89.9503" x1="0" y1="0" x2="54.1194" y2="-9.04975" wireFlags="64"/\>
> \- \<wireExtras mils="11.1111" color="#f2c600" opacity="1" banded="0"/\>
> \- \<connectors\>
> \- \<connector connectorId="connector1" layer="copper1trace"\>
> \- \<geometry x="0" y="0"/\>
> \- \<connects\>
> \- \<connect connectorId="connector21004" modelIndex="85613958" layer="breadboardbreadboard"/\>
> \- \</connects\>
> \- \</connector\>
> \- \</connectors\>
> \- \</pcbView\>
> \- \<schematicView layer="schematicTrace"\>
> \- \<geometry z="5.50004" x="215.881" y="-89.9503" x1="0" y1="0" x2="54.1194" y2="-9.04975" wireFlags="64"/\>
> \- \<wireExtras mils="9.7222" color="#404040" opacity="1" banded="0"/\>
> \- \<connectors\>
> \- \<connector connectorId="connector1" layer="schematicTrace"\>
> \- \<geometry x="0" y="0"/\>
> \- \<connects\>
> \- \<connect connectorId="connector21004" modelIndex="85613958" layer="breadboardbreadboard"/\>
> \- \</connects\>
> \- \</connector\>
> \- \</connectors\>
> \- \</schematicView\>
> \- \</views\>
> \- \</instance\>
> \<instance moduleIdRef="WireModuleID" modelIndex="85645526" path=":/resources/parts/core/wire.fzp"\>
> \<views/\>
> \</instance\>
> \--- 8419,8424 ----
> \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
> \*\*\* 8555,8559 \*\*\*\*
> \--- 8437,8456 ----
> \<instance moduleIdRef="WireModuleID" modelIndex="85645578" path=":/resources/parts/core/wire.fzp"\>
> \<views/\>
> \</instance\>
> + \<instance moduleIdRef="WireModuleID" modelIndex="85645580" path=":/resources/parts/core/wire.fzp"\>
> + \<views/\>
> + \</instance\>
> + \<instance moduleIdRef="WireModuleID" modelIndex="85645582" path=":/resources/parts/core/wire.fzp"\>
> + \<views/\>
> + \</instance\>
> + \<instance moduleIdRef="WireModuleID" modelIndex="85645584" path=":/resources/parts/core/wire.fzp"\>
> + \<views/\>
> + \</instance\>
> + \<instance moduleIdRef="WireModuleID" modelIndex="85645586" path=":/resources/parts/core/wire.fzp"\>
> + \<views/\>
> + \</instance\>
> + \<instance moduleIdRef="WireModuleID" modelIndex="85645588" path=":/resources/parts/core/wire.fzp"\>
> + \<views/\>
> + \</instance\>
> \</instances\>
> \</module\>
> 
> As expected the diff shows mostly deletes. At the end 6 wires appear to have been added for some reason but I don't know why. However with that done, now on the "delay unit new4-breadboard-wires-deleted.fzz" sketch add the two wires in breadboard like this:
> 
> !\[capture21\](https://user-images.githubusercontent.com/16514277/141408764-db0977a2-4e3e-43fd-a493-1e6f7dee2c8c.jpg)
> 
> and check that the connections are correct (which they are!)
> 
> !\[capture22\](https://user-images.githubusercontent.com/16514277/141408800-0294579f-b853-459f-80e8-74ea2a53c631.jpg)
> 
> !\[capture23\](https://user-images.githubusercontent.com/16514277/141408811-4a8585c6-8bf4-4869-92cb-722258da6f3d.jpg)
> 
> then save the now correct sketch to delay unit new4-breadboard-correct.fzz
> 
> \[delay unit new4-breadboard-wires-deleted.fzz.zip\](https://github.com/fritzing/fritzing-app/files/7524830/delay.unit.new4-breadboard-wires-deleted.fzz.zip)
> 
> now unzip the .fzz file and diff the repective fz files to see what changes have occurred which may (or may not!) shed light on what went wrong in the original sketch. 
> 
> diff -c 'delay unit new4-breadboard-wires-deleted/delay unit new4-breadboard-wires-deleted.fz' 'delay unit new4-breadboard-correct/delay unit new4-breadboard-correct.fz
> 
> This makes a huge number of changes ( 215 lines for the first diff against 10,566 for the last diff which I won't list here), but it indicates that something substantial went wrong in the original creation of the .fzz file and we are possibly no further ahead on solving this issue because unless someone else can figure out a way to reproduce it, I don't see how we can fix it. At least now there is a record that there is a problem though. 
> 
> \*\*Build:\*\*
> 
> Version 0.9.3 (b5c895d327c44a3114e5fcc9d8260daf0cbb528
> 
> not yet seen on 
> 
> Version 0.9.9 
> (bCD-348-0-f0af53a9 2021-09-22) 64 \[Qt 5.15.2\]
> 
> \*\*Operating System:\*\*
> Windows 10
> 
> \*\*Steps to reproduce:\*\*
> 
> At present I don't know how to reproduce this error. All I have is the sketch after the error has occurred and so far repeating what I think was done to the sketch does not reproduce the problem (this has been the case in the 4 or 5 cases of this I have seen over the last 5 years though!) 
> 
> \## Expected Behaviour
> 
> The routing database doesn't get corrupted.