Edit:

Current Behaviour

In this sketch created with Fritzing 0.9.3b there 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

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

whose breadboard looks like this

capture

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

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

note that neither wire was replaced by a rats nest line, indicating there is no connection in breadboard! Which is shown here

capture3

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

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

if I now make the two connections in schematic

capture6

then the rats nest lines appear in breadboard as expected (although the wires that aren't connected remain!)

capture7

deleting the two wires in breadboard leaves only the rats nest lines and clicking on the rats nest lines produces a correct connection:

capture8

capture9

and if I delete the wires again in schematic they are correctly replaced by rats nest lines.

capture10

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

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

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

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

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

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

and in breadboard view the rats nest lines are gone

capture17

however the connections are still broken as the pads the wire appears to connect to do not light up yellow in either case

capture18

capture19

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

then delete the two wires that are incorrect like this

capture20

then save this sketch as "delay unit new4-breadboard-wires-deleted.fzz"

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 **

                          </connects>
                      </connector>

--- 895,900 ---- *************** *** 1077,1088 ****
--- 1071,1076 ---- *************** *** 1265,1276 ****
--- 1253,1258 ---- *************** *** 1443,1454 ****
--- 1425,1430 ---- *************** *** 1627,1638 ****
--- 1603,1608 ---- *************** *** 1805,1816 ****
--- 1775,1780 ---- *************** *** 8446,8492 ****
Wire24155
--- 8410,8415 ----

* 8496,8542 **
Wire24206
--- 8419,8424 ----

* 8555,8559 ** --- 8437,8456 ----

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

and check that the connections are correct (which they are!)

capture22

capture23

then save the now correct sketch to delay unit new4-breadboard-correct.fzz

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.

Are we sure the initial corruption happened on 0.9.9? Or is this just the version you used to analyze the problem?

"Are we sure the initial corruption happened on 0.9.9? Or is this just the version you used to analyze the problem?"

You are right, 0.9.9 is the version I am trouble shooting on. The other cases I have seen have been on 0.9.3b. I'll ask the person that made this which version he is using. As well I realize from the diff probably what is happening is a delete of the two wires (although doing that on 0.9.9 does not cause the issue) isn't completing for some reason and leaves some of the definitions in the .fz file leading to the problem.

edit: Indeed the problem occurred (and has occurred in the past) on 0.9.3b. I updated the report to indicate that and that it hasn't yet been seen on 0.9.9.

I expect what we really need to cure this problem is to be able to write the undo stack in to the .fzz file (which may make the .fzz file large though!) Given the undo information in the .fzz and the ability to reload it from the .fzz file and be able to back off the changes made in the file, we should be able to back out the changes until the corruption disappears. At that point if we redo the last change and the corruption reappears we have reproduced the problem. and can trace it If the corruption doesn't reoccur on the redo that would indicate that we are looking for a race condition which will be harder to reproduce. I don't know how easy it will be to change the redo stack in to xml to write to the .fzz file however. It likely needs to be enabled by default as there is no telling when this error will occur (there have only been 4 or 5 reports of this over the last 5 or so years.) I chose to report this particular case because it appears to be easier than the others I have seen. Here there looks to be only one error (the short from 24V to ground) in the other cases I have seen there were multiple similar errors making reproducing it even harder.

It seems that the database corruption is still present in 0.9.9, according to this: https://forum.fritzing.org/t/power-header-ratsnesting-positive-to-negative/14728/2

And it looks that it has happen again in 0.9.9: https://forum.fritzing.org/t/pcb-tracks-dont-match-schematic/15559/42

And yet again in a slightly different form (the error isn't in the routing database this time but in the placement of wires in schematic.) details are here in the forum:

https://forum.fritzing.org/t/raspio-triangle-request/15887/56

of note is that Fritzing seems to have realized there is a problem. The incorrect capacitor is outlined in a blue box (which I don't ever remember seeing before)

2c2c2af51fe7458ce294c52d2d061bb1d883237b_2_443x500

However as in all the other cases I have been unable to recreate the sequence of events that leads to this outcome. I think the best bet of doing that is to write the undo stack items (which may not be practical due to size!) to the .fz file so that after the fact we can step back via the undo stack until the problem goes away and see if it reoccurs when we redo the actions (if the fault is a race condition even this may not reproduce it!) An alternative may be to dump a copy of the undo stack to the .fz file if the condition that causes the blue box to be applied occurs (that will cut the volume of data needing to be saved by a huge amount I expect.)

Some more issues, in this case after the database corruption, but perhaps worth looking at as they look to be bugs. The full story is in this forum post:

https://forum.fritzing.org/t/how-do-i-find-parts-in-fritzing/4355/

Here is the original sketch I started from (which has routing database corruption as we will see, unclear how it occurred though!)

Winder-Retrofit01-Breadboard.fzz.zip

remove the trailing .zip to recover the .fzz file.

I started by deleting all traces in all views, then unlocking and moving the breadboard down (so the components on it don't have connections!) and moved the LED on the arduino up so it is also not connected.

capture

however that still leaves rats nest lines connected in schematic and pcb (circled in green here)

capture1

capture2

to (hopefully!) fix that select the ratsnest line in pcb and right click and select delete rats nest line. That should clear the routing connection from the database which is what we want. First however switch back to breadboard and verify that the diode is locked (which it is) and thus should not move.

capture3

however when I delete the rats nest line in pcb

capture5

capture6

the rats nest line indeed gets deleted

capture7

capture8

the diode in breadboard is moved (which appears to be a bug because the part is locked!) Deleting the wire on the IC causes the IC in breadboard (which is also locked) to move and adds wires to all the connections other than the one the rats nest line was removed from.

capture9

capture10

and deleting the rats nest line on the resistor both moves the resistor and makes a connection to the breadboard. Because of the database corruption this may not be worth looking at too closely as it may be caused by the corruption (as the routing database won't be as the code expects it to be) but it may also indicate bugs (locked parts shouldn't be moving in other views!) that could and should be fixed.

There may be finally light at the end of this tunnel! Bill has managed to corrupt two different sketches. He is the only person that I know of that has managed to do more than one, so it looks like something in his workflow is tripping this bug. If we can make a code change that will write out the undo/redo database to a file and give that version to Bill we may be able to finally find and fix this bug. I think the undo/redo database should have the full set of commands that cause the bug and thus replaying them should recreate the bug (I hope!) and allow us to fix it. Now I don't have any idea how complex writing the undo/redo log to a file is going to be and I'm probably not good enough at code to do it anyway @KjellMorgenstern would you be willing to look at how easy this would be to implement? It looks to me like the complete sequence of Fritzing commands that was used to get the sketch to where it currently is (and thus can be backed off from) is in the undo/redo log and if we can get that to a file fairly easily it may help solve this bug. Bill's first instance is logged above, his second (with a totally new sketch) is documented (so far) here

https://forum.fritzing.org/t/confused-about-new-part-fab/18632/

I'm poking at the .fz file from the sketch to see if I can figure anything out (I haven't been able to in the past and expect this time to be no different though.)

About saving the undo history, we have thought about that, especially also for debugging purposes. Two problems: First, the undo history of Fritzing relies on temporary (internal) representation, so it would not map to the project anymore once it is opened again. Second, the bug might be in to Undo/Redo itself.

~~Can you check if this is related to #3740 ?~~

Maybe it is possible to get a screenshot of the undo history window?

About saving the undo history, we have thought about that, especially also for debugging purposes. Two problems: First, the undo history of Fritzing relies on temporary (internal) representation, so it would really map to the project anymore once it is opened again.

That unfortunately is enough to probably make it not worth doing. I hadn't thought of the second possibility ...

Can you check if this is related to https://github.com/fritzing/fritzing-app/issues/3740 ?

Yes there are a bunch of bendable leg parts in this so I'll have a poke at them and see if something appears. I may make Bill non bendable leg replacements for all the bendable leg stuff and see if that helps as well. Anything that narrows down the areas to look will be useful and Bill being able to reproduce it should (I hope) help. The symptoms this time are somewhat different than any I have seen before. Some of the traces in pcb won't change layers (it is a two sided board) but others will. I'm currently trying to reproduce Bill's sketch from scratch so I can route a clean copy for him. I don't remember bendable leg parts in any of the previous cases I have seen though so this may not be directly related to bendable leg parts.

Note that #3740 is one of the fixes to be released soon. Indeed, when reading about the issue here in detail, it doesn't look related. To narrow it down, maybe we can get a minimal version of the problem: Remove all the parts from the sketch that seem unrelated (not moving, no ratsnest lines etc) . The repeat the "delete all traces in all views" again, and see if phantom ratsnest lines are still there? If yes, possibly remove more parts, so the file gets as simple as possible

Remove all the parts from the sketch that seem unrelated (not moving, no ratsnest lines etc) .

Excellent suggestion! Doing that tells me it is the breadboard. Here I unlocked and moved the breadboard to break (I thought) all the connections to the components. Turns out that isn't enough! While there are no wires or apparent connections in breadboard (other than the routing complete rather than no connections to route which I missed!), there appear to still be connections to the breadboard which are causing the rats nest lines in schematic and pcb.

capture

capture1

deleting the breadboard clears them and appears to reset the routing database.

capture2

capture3

capture4

That means I should be able to delete the breadboard in the original sketch and be left with the layout as is ready to route correctly. This doesn't entirely fix the problem, but at least leaves the layout intact in all three views so correcting the problem is easier.

Maybe it is possible to get a screenshot of the undo history window?

Another good thought! Unfortunately it relies on the user recognizing database corruption before saving the sketch, but it is certainly worth a try. I didn't know we had an undo history but I see we do and it would be helpful if the user recognizes database corruption has occurred soon enough to get a copy. Perhaps in this particular case getting Bill to save the history for every sketch just before saving the sketch will work. That way when we recognize database corruption we may be able to figure out what happened to create it (which is the part I haven't been able to figure out!) Presumably a code change to be able to save the history window display window to a file or better yet append the current history to a file associated with the sketch file name (such as sketch-file.fzz.debug) could be done fairly easily as some code is generating the screen output and that would give at least some clues for debugging. I'd like to see it on by default, but it does add a load to the user's disk space which may be undesirable.

capture

Do you still have the broken DM860A part?

My idea: When you create a sketch with the broken part, then save it, the part is not correctly stored in the sketch. But the connections to that part are stored.

Can it be reproduced this way, from a clean sketch?

Even if not, I'd still like to write a check for the kind of error you discovered in the part.

If I didn't save a copy I can easily recreate it as I have the fzp file and can just delete the pcb layerId. Since the latest sketch uses the corrected part, I don't think that is the cause of the database corruption though. I think Bill is making changes in multiple views and in the past that has been what causes the corruption.

@vanepp If the project was not recreated from scratch with the fixed parts, the orphaned connections still might be in there, even if now the corrected part is used. I have created an issue in fritzing-parts.

Regarding the undo history. I don't think this will help, just to be complete with the information: Fritzing writes an "undostack.txt" in debug mode. This is currently not active in releases, and can not be activated. I don't think that is production ready. For some unknown reason, the undostack is reset when loading a bin, overwriting the file for each bin. Although there is no obvious direct relationship to bins. It is fairly detailed:

Add 220Ω Resistor
    0 SelectItemCommand Breadboard View cross-view type:0 Selection
    1 CleanUpWiresCommand Breadboard View cross-view direction 2
    2 CleanUpRatsnestsCommand Breadboard View cross-view
    3 AddItemCommand Breadboard View cross-view moduleid:ResistorModuleID id:57920 modelindex:-1 flags:0 loc:331.684,-292.541 pt1:-1,-1 pt2:-1,-1
    4 SetDropOffsetCommand Breadboard View cross-view id:57920 19.3127,4.3695
    5 CheckStickyCommand Breadboard View cross-viewid:0
    6 SelectItemCommand Breadboard View cross-view type:0
    7 ShowLabelFirstTimeCommand Breadboard View cross-view id:57920 1 1
Add 220Ω Resistor
    8 SelectItemCommand Breadboard View cross-view type:0 Selection
    9 CleanUpWiresCommand Breadboard View cross-view direction 2
    10 CleanUpRatsnestsCommand Breadboard View cross-view
    11 AddItemCommand Breadboard View cross-view moduleid:ResistorModuleID id:57950 modelindex:-1 flags:0 loc:385.684,-211.541 pt1:-1,-1 pt2:-1,-1
    12 SetDropOffsetCommand Breadboard View cross-view id:57950 19.3127,4.3695
    13 CheckStickyCommand Breadboard View cross-viewid:0
    14 SelectItemCommand Breadboard View cross-view type:0
    15 ShowLabelFirstTimeCommand Breadboard View cross-view id:57950 1 1
Add Inductor
    16 SelectItemCommand Breadboard View cross-view type:0 Selection
    17 CleanUpWiresCommand Breadboard View cross-view direction 2
    18 CleanUpRatsnestsCommand Breadboard View cross-view
    19 AddItemCommand Breadboard View cross-view moduleid:56bed03878064b8286b71d5240035138InductorModuleID id:57980 modelindex:-1 flags:0 loc:377.014,-226.18 pt1:-1,-1 pt2:-1,-1
    20 SetDropOffsetCommand Breadboard View cross-view id:57980 19.2744,7.93
    21 CheckStickyCommand Breadboard View cross-viewid:0
    22 SelectItemCommand Breadboard View cross-view type:0
    23 ShowLabelFirstTimeCommand Breadboard View cross-view id:57980 1 1
24 SelectItemCommand Breadboard View cross-view type:0 Select 0 items
26 SelectItemCommand Breadboard View cross-view type:0 Select 0 items
28 SelectItemCommand Breadboard View cross-view type:2 Select All
29 SelectItemCommand Breadboard View cross-view type:0 Select 0 items
31 SelectItemCommand Breadboard View cross-view type:0 Select 220Ω Resistor
Add 220Ω Resistor
    32 SelectItemCommand Breadboard View cross-view type:0 Selection
    33 CleanUpWiresCommand Breadboard View cross-view direction 2
    34 CleanUpRatsnestsCommand Breadboard View cross-view
    35 AddItemCommand Breadboard View cross-view moduleid:ResistorModuleID id:58010 modelindex:-1 flags:0 loc:340.684,-229.541 pt1:-1,-1 pt2:-1,-1
    36 SetDropOffsetCommand Breadboard View cross-view id:58010 19.3127,4.3695
    37 CheckStickyCommand Breadboard View cross-viewid:0
    38 SelectItemCommand Breadboard View cross-view type:0
    39 ShowLabelFirstTimeCommand Breadboard View cross-view id:58010 1 1
Paste
    42 SelectItemCommand Breadboard View single-view type:3 Selection
    43 CleanUpWiresCommand Breadboard View cross-view direction 0
    44 CleanUpRatsnestsCommand Breadboard View cross-view
    45 AddItemCommand Breadboard View single-view moduleid:ResistorModuleID id:58040 modelindex:5804 flags:0 loc:384.074,-259.631 pt1:0,0 pt2:0,0
    46 CheckStickyCommand Breadboard View single-viewid:0
    47 ChangeLegCommand Breadboard View single-view fromid:58040 fromc:connector1 copy old:(0,0)(1.3095,0) new:(0,0)(1.3095,0)
    48 ChangeLegCommand Breadboard View single-view fromid:58040 fromc:connector0 copy old:(0,0)(-1.3095,0) new:(0,0)(-1.3095,0)
    49 CleanUpRatsnestsCommand Breadboard View cross-view
    50 CleanUpWiresCommand Breadboard View cross-view direction 1
    51 CheckPartLabelLayerVisibilityCommand Breadboard View single-view id:58040
    52 SelectItemCommand Schematic View single-view type:3 Selection
    53 CleanUpWiresCommand Schematic View cross-view direction 0
    54 CleanUpRatsnestsCommand Schematic View cross-view
    55 AddItemCommand Schematic View single-view moduleid:ResistorModuleID id:58040 modelindex:5804 flags:0 loc:397.652,1.3698 pt1:0,0 pt2:0,0
    56 RestoreLabelCommand Schematic View single-view id:58040
    57 CheckStickyCommand Schematic View single-viewid:0

Regarding the undo history. I don't think this will help, just to be complete with the information: Fritzing writes an "undostack.txt" in debug mode. This is currently not active in releases, and can not be activated. I don't think that is production ready. For some unknown reason, the undostack is reset when loading a bin, overwriting the file for each bin. Although there is no obvious direct relationship to bins. It is fairly detailed:

If we could make it work somehow that would be invaluable! It looks like exactly the type of information we need to find this problem. Resetting it on a bin load does seem odd!

If the project was not recreated from scratch with the fixed parts, the orphaned connections still might be in there, even if now the corrected part is used.

That is usually detectable by reading the .fz file for the sketch (manually at present although it should be automatable with some work in a python script which should allow recovery. I think that if you remove all traces (including deleting any breadboards in breadboard as even when moved they appear to keep connections!) Fritzing will clear it for itself. Turns out the latest one wasn't a case of database corruption at all. He used SMD pads as through hole while routing a single sided board in a double sided sketch. I was discovering on some traces that I couldn't switch layers and was assuming that indicated database corruption, but I don't think any is actually present. I ended up recreating his sketch from scratch but I used single pin headers in place of the pads in pcb and thus didn't hit the same problem. Looking at what was different between the two sketches is how I discovered what the problem was.

You are right there is no obvious connection to the bins. I was suspicious of this (from a

./fritzing-app $ grep -R "m_undoStack" *

src/partsbinpalette/binmanager/binmanager.cpp: m_undoStack->push(new QUndoCommand("Parts bin: part removed")); src/partsbinpalette/binmanager/binmanager.h: WaitPushUndoStack *m_undoStack;

but it appear to be pushing a command on to the stack not clearing it. That said I can't figure out where it even opens or closes the undostack.txt file (I did find where it is created (or at least where the file name is set though, I'm not sure what the m_file.remove(); is about I would expect that to remove the file we just created although it may well do something else entirely.

WaitPushUndoStack::WaitPushUndoStack(QObject * parent) : QUndoStack(parent) { m_temporary = NULL;

ifndef QT_NO_DEBUG

QString path = FolderUtils::getTopLevelUserDataStorePath();
path += "/undostack.txt";

    m_file.setFileName(path);
    m_file.remove();

endif

}

but nothing appears to call WaitPushUndoStack::WaitPushUndoStack. I suppose the next step is to break out the development environment here and see if I can compile a debug version and use gdb to tell me what is calling the WaitPushUndoStack::WaitPushUndoStack. I suspect we will find that something is calling this again in error which I expect will cause the truncation of the output file as it reopens the file? I see there are a lot of timers and signal type IPC calls involved so it is very possible the part I'm missing is in an IPC call somewhere. I'll see how I do poking at this ...

edit:

Well that died a quick death.

$ grep -R "QT_NO_DEBUG" * phoenix.pro: #DEFINES += QT_NO_DEBUG # uncomment this for xcode

...

shows no defines anywhere. The above line appears to only apply to the Mac (and I am trying on Ubuntu) so I don't even know what to change to enable debug mode!

Finally some good news! While testing a part I was fixing for someone I think I have managed to recreate the database corruption (although whether I can recreate it is open to question!) I moved a header with wires connected to it in breadboard and the screen jumped, the header re positioned and a wire jumped connections. Something in that sequence appears to have caused routing database corruption because the .fzz file is now acting like a corrupted one. I'll poke at it more to see if I can dependably recreate the problem and if it really is the corruption issue (it looks like it, unexpected rats nest lines present.)

We found a surprisingly easy way to reproduce this: Put something on the breadboard, and move it with the arrow keys by more than one step, fast (less than a second). I did some bug archeology, but this seems to exist since ever.

Fritzing 0.8.0 from 2013

https://github.com/fritzing/fritzing-app/assets/6494025/7601feca-1ee4-491d-9ea4-9705151b4c72

Working on a fix.

In the other video it is quite difficult to see, so here the current release: Fritzing 0.9.10

https://github.com/fritzing/fritzing-app/assets/6494025/da96a84a-c55e-4c5d-99f8-e3266186bbec

Corruption can also be triggered when scroll operation is paused by moving the mouse out of the view:

https://github.com/fritzing/fritzing-app/assets/6494025/094723e4-018e-472f-a858-cd9e5438e619

This is good news! Yes the problem has been here ever since I arrived (June of 2016) and I wouldn't be surprised if it was older. It happens relatively rarely (although checking the forums I have found at least 7 cases over about 7 years.) I'm working on a python script that analyses fz files (connections only at present) since it seems to me since the error can be propagated in a .fz file it should be detectable there, but so far all I'm seeing is missing connections (such as copper1 being missing) but it isn't complete yet either and I have fz files with corruption. It should be possible to at least return the .fz file to a consistent state (although there may be either missing or extra wires in the result) which would be a help to people hit by this I expect. I as noted managed to create this once, but since then have been working on the script and haven't tried again very much.

We have a detector, and fixed several of the bugs that caused this. To consider this ticket done:

at least make the detector available as debugging tool (Fritzing 1.0.2),
or make it available similar to the DRC checker
maybe run it when loading old Fritzing projects?

I think there are still problems (or I don't understand something, unfortunately either is possible!) My script (as of 1.0.1) no longer reports empty connections (and I closed that ticket) but I think things are fairly broken (and have been since at least 0.9.3b.) If I create a sketch like this

testcase1_0_1-1wire-bb-only.fzz.zip

(here is the sketch, remove the trailing .zip to recover it!)

capture

all is well there is a single wire instance and my script is happy. The no connections on pcb is normal as pcb has no connections. The connections section (created by the -c flag) is for debugging, it dumps the entire connection database with the source line in the fz file where the entry was found. Normally that is suppressed as uninteresting.

$ fzcheck.py -c testcase1_0_1-1wire-bb-only.fz

Process testcase1_0_1-1wire-bb-only.fz

5783 TwoLayerRectanglePCBModuleID (srcln 13) no connections

*** connections

5787 generic_female_pin_header_2_100mil (srcln 24) 5787-connector0-breadboard 5792-connector1-breadboardWire (srcln 33,36) 5787-connector0-schematic 5792-connector1-schematicTrace (srcln 52,55) 5787-connector0-copper0 5792-connector1-copper1trace (srcln 68,71)

5792 WireModuleID (srcln 130) 5792-connector1-breadboardWire 5787-connector0-breadboard (srcln 137,140) 5792-connector1-schematicTrace 5787-connector0-schematic (srcln 155,158) 5792-connector1-copper1trace 5787-connector0-copper0 (srcln 173,176) 5792-connector0-breadboardWire 5790-connector0-breadboard (srcln 143,146) 5792-connector0-schematicTrace 5790-connector0-schematic (srcln 161,164) 5792-connector0-copper1trace 5790-connector0-copper0 (srcln 179,182) 5792-connector1-breadboardWire 5787-connector0-breadboard (srcln 137,140) 5792-connector0-breadboardWire 5790-connector0-breadboard (srcln 143,146) 5792-connector1-schematicTrace 5787-connector0-schematic (srcln 155,158) 5792-connector0-schematicTrace 5790-connector0-schematic (srcln 161,164) 5792-connector1-copper1trace 5787-connector0-copper0 (srcln 173,176) 5792-connector0-copper1trace 5790-connector0-copper0 (srcln 179,182)

5790 generic_female_pin_header_2_100mil (srcln 78) 5790-connector0-breadboard 5792-connector0-breadboardWire (srcln 87,90) 5790-connector0-schematic 5792-connector0-schematicTrace (srcln 104,107) 5790-connector0-copper0 5792-connector0-copper1trace (srcln 120,123)

there are 2 2 pin header connectors and one wire connecting them and all the connections match up (for each forward connection there is a matching reverse connection as there should be.) If I add a second wire to the sketch like this, things break

testcase1_0_1-2wire-all-layers-connected.fzz.zip

(here is the sketch, remove the trailing .zip to recover it!)

capture1

while there are only two wires in the sketch (and I would expect there to be 2 wires in the fz file) there are in fact 6 wire entries (all with all 3 layers present) and some of the wires are missing some of the return paths (usually pcb). Unless I don't understand the fz file (which is entirely possible!) I would expect there to only be 2 WireModuleIDs one for each wire. It looks to me that many more are being generated and some of them are incomplete. That doesn't appear to do anything to functionality, but it increases the size of the .fz file seemingly without reason and I expect it may cause confusion in the code depending on which WireModuleID gets selected for a change. Does anyone know why there isn't just one WireModuleID? Is there something I don't understand about the fz file format that needs multiple WireModuleIDs for some reason (I can't think of one)?

$ fzcheck.py -c testcase1_0_1-2wire-all-layers-connected.fz

Process testcase1_0_1-2wire-all-layers-connected.fz

5783 TwoLayerRectanglePCBModuleID (srcln 13) no connections missing 5787-connector0-copper1 5820-connector1-copper1trace missing 5790-connector0-copper1 5820-connector0-copper1trace missing 5787-connector1-copper1 5824-connector1-copper1trace missing 5790-connector1-copper1 5824-connector0-copper1trace missing 5787-connector1-copper1 5830-connector1-copper1trace missing 5790-connector1-copper1 5830-connector0-copper1trace

*** connections

5787 generic_female_pin_header_2_100mil (srcln 24) 5787-connector1-breadboard 5813-connector1-breadboardWire (srcln 33,36) 5787-connector1-breadboard 5824-connector1-breadboardWire (srcln 33,37) 5787-connector1-breadboard 5830-connector1-breadboardWire (srcln 33,38) 5787-connector0-breadboard 5792-connector1-breadboardWire (srcln 41,44) 5787-connector0-breadboard 5820-connector1-breadboardWire (srcln 41,45) 5787-connector0-breadboard 5828-connector1-breadboardWire (srcln 41,46) 5787-connector1-schematic 5813-connector1-schematicTrace (srcln 62,65) 5787-connector1-schematic 5824-connector1-schematicTrace (srcln 62,66) 5787-connector1-schematic 5830-connector1-schematicTrace (srcln 62,67) 5787-connector0-schematic 5792-connector1-schematicTrace (srcln 70,73) 5787-connector0-schematic 5820-connector1-schematicTrace (srcln 70,74) 5787-connector0-schematic 5828-connector1-schematicTrace (srcln 70,75) 5787-connector1-copper0 5813-connector1-copper1trace (srcln 88,91) 5787-connector0-copper0 5792-connector1-copper1trace (srcln 94,97) 5787-connector0-copper0 5828-connector1-copper0trace (srcln 94,98)

5813 WireModuleID (srcln 243) 5813-connector1-breadboardWire 5787-connector1-breadboard (srcln 250,253) 5813-connector1-schematicTrace 5787-connector1-schematic (srcln 268,271) 5813-connector1-copper1trace 5787-connector1-copper0 (srcln 286,289) 5813-connector0-breadboardWire 5790-connector1-breadboard (srcln 256,259) 5813-connector0-schematicTrace 5790-connector1-schematic (srcln 274,277) 5813-connector0-copper1trace 5790-connector1-copper0 (srcln 292,295) 5813-connector1-breadboardWire 5787-connector1-breadboard (srcln 250,253) 5813-connector0-breadboardWire 5790-connector1-breadboard (srcln 256,259) 5813-connector1-schematicTrace 5787-connector1-schematic (srcln 268,271) 5813-connector0-schematicTrace 5790-connector1-schematic (srcln 274,277) 5813-connector1-copper1trace 5787-connector1-copper0 (srcln 286,289) 5813-connector0-copper1trace 5790-connector1-copper0 (srcln 292,295)

5824 WireModuleID (srcln 361) 5824-connector1-breadboardWire 5787-connector1-breadboard (srcln 386,389) 5824-connector1-schematicTrace 5787-connector1-schematic (srcln 368,371) 5824-connector0-breadboardWire 5790-connector1-breadboard (srcln 392,395) 5824-connector0-schematicTrace 5790-connector1-schematic (srcln 374,377) 5824-connector1-schematicTrace 5787-connector1-schematic (srcln 368,371) 5824-connector0-schematicTrace 5790-connector1-schematic (srcln 374,377) 5824-connector1-breadboardWire 5787-connector1-breadboard (srcln 386,389) 5824-connector0-breadboardWire 5790-connector1-breadboard (srcln 392,395) 5824-connector1-copper1trace 5787-connector1-copper1 (srcln 404,407) 5824-connector0-copper1trace 5790-connector1-copper1 (srcln 410,413)

5830 WireModuleID (srcln 479) 5830-connector1-breadboardWire 5787-connector1-breadboard (srcln 504,507) 5830-connector1-schematicTrace 5787-connector1-schematic (srcln 522,525) 5830-connector0-breadboardWire 5790-connector1-breadboard (srcln 510,513) 5830-connector0-schematicTrace 5790-connector1-schematic (srcln 528,531) 5830-connector1-copper1trace 5787-connector1-copper1 (srcln 486,489) 5830-connector0-copper1trace 5790-connector1-copper1 (srcln 492,495) 5830-connector1-breadboardWire 5787-connector1-breadboard (srcln 504,507) 5830-connector0-breadboardWire 5790-connector1-breadboard (srcln 510,513) 5830-connector1-schematicTrace 5787-connector1-schematic (srcln 522,525) 5830-connector0-schematicTrace 5790-connector1-schematic (srcln 528,531)

5792 WireModuleID (srcln 184) 5792-connector1-breadboardWire 5787-connector0-breadboard (srcln 191,194) 5792-connector1-schematicTrace 5787-connector0-schematic (srcln 209,212) 5792-connector1-copper1trace 5787-connector0-copper0 (srcln 227,230) 5792-connector0-breadboardWire 5790-connector0-breadboard (srcln 197,200) 5792-connector0-schematicTrace 5790-connector0-schematic (srcln 215,218) 5792-connector0-copper1trace 5790-connector0-copper0 (srcln 233,236) 5792-connector1-breadboardWire 5787-connector0-breadboard (srcln 191,194) 5792-connector0-breadboardWire 5790-connector0-breadboard (srcln 197,200) 5792-connector1-schematicTrace 5787-connector0-schematic (srcln 209,212) 5792-connector0-schematicTrace 5790-connector0-schematic (srcln 215,218) 5792-connector1-copper1trace 5787-connector0-copper0 (srcln 227,230) 5792-connector0-copper1trace 5790-connector0-copper0 (srcln 233,236)

5820 WireModuleID (srcln 302) 5820-connector1-breadboardWire 5787-connector0-breadboard (srcln 327,330) 5820-connector1-schematicTrace 5787-connector0-schematic (srcln 309,312) 5820-connector0-breadboardWire 5790-connector0-breadboard (srcln 333,336) 5820-connector0-schematicTrace 5790-connector0-schematic (srcln 315,318) 5820-connector1-schematicTrace 5787-connector0-schematic (srcln 309,312) 5820-connector0-schematicTrace 5790-connector0-schematic (srcln 315,318) 5820-connector1-breadboardWire 5787-connector0-breadboard (srcln 327,330) 5820-connector0-breadboardWire 5790-connector0-breadboard (srcln 333,336) 5820-connector1-copper1trace 5787-connector0-copper1 (srcln 345,348) 5820-connector0-copper1trace 5790-connector0-copper1 (srcln 351,354)

5828 WireModuleID (srcln 420) 5828-connector1-breadboardWire 5787-connector0-breadboard (srcln 445,448) 5828-connector1-schematicTrace 5787-connector0-schematic (srcln 463,466) 5828-connector1-copper0trace 5787-connector0-copper0 (srcln 427,430) 5828-connector0-breadboardWire 5790-connector0-breadboard (srcln 451,454) 5828-connector0-schematicTrace 5790-connector0-schematic (srcln 469,472) 5828-connector0-copper0trace 5790-connector0-copper0 (srcln 433,436) 5828-connector1-copper0trace 5787-connector0-copper0 (srcln 427,430) 5828-connector0-copper0trace 5790-connector0-copper0 (srcln 433,436) 5828-connector1-breadboardWire 5787-connector0-breadboard (srcln 445,448) 5828-connector0-breadboardWire 5790-connector0-breadboard (srcln 451,454) 5828-connector1-schematicTrace 5787-connector0-schematic (srcln 463,466) 5828-connector0-schematicTrace 5790-connector0-schematic (srcln 469,472)

5790 generic_female_pin_header_2_100mil (srcln 105) 5790-connector1-breadboard 5813-connector0-breadboardWire (srcln 114,117) 5790-connector1-breadboard 5824-connector0-breadboardWire (srcln 114,118) 5790-connector1-breadboard 5830-connector0-breadboardWire (srcln 114,119) 5790-connector0-breadboard 5792-connector0-breadboardWire (srcln 122,125) 5790-connector0-breadboard 5820-connector0-breadboardWire (srcln 122,126) 5790-connector0-breadboard 5828-connector0-breadboardWire (srcln 122,127) 5790-connector1-schematic 5813-connector0-schematicTrace (srcln 141,144) 5790-connector1-schematic 5824-connector0-schematicTrace (srcln 141,145) 5790-connector1-schematic 5830-connector0-schematicTrace (srcln 141,146) 5790-connector0-schematic 5792-connector0-schematicTrace (srcln 149,152) 5790-connector0-schematic 5820-connector0-schematicTrace (srcln 149,153) 5790-connector0-schematic 5828-connector0-schematicTrace (srcln 149,154) 5790-connector1-copper0 5813-connector0-copper1trace (srcln 167,170) 5790-connector0-copper0 5792-connector0-copper1trace (srcln 173,176) 5790-connector0-copper0 5828-connector0-copper0trace (srcln 173,177)

In addition creating a new identical copy of the sketch then processing it changes the number of missing connections which indicates to me there is a problem if Fritzing. If I missed a reason for the extra WireModuleIDs the fz file produced should be identical and it is not. The intent of flagging the missing connections is to provide the option of adding the missing connections back in to the .fz file so the file will be at least consistent (if possibly not correct if database corruption has occurred!) but I haven't gotten that far yet as I can't get it to correctly process the fz file.

I'm making progress! It struck me over night that I can (and have) create what I think is correct .fzz file by deleting all the extra instances and their associated connections, and indeed that seems to work. I have missed a flag in one of the deleted instances probably because schematic and pcb in the corrected .fzz are rats nest lines rather than wires but I should be able to work that out. Best of all loading the corrected .fzz file in to Fritzing 1.0.1 then saving it (without making any changes) writes a correct .fzz file (no added wires.) Changing the rats nest lines to wires in schematic and pcb then saving that as a .fzz file adds extra wires and causes corruption. As a result this should be an easy test case for what is going wrong. Here are the two sketches (remove the trailing .zip there to keep github happy!) to recover the .fzz files.

This one is the corrected file (saved from Fritzing)

testcase1_0_1-2wire-all-layers-connected-fixed-saved-no-changes.fzz.zip

which looks like this when run through fzcheck.py

$ fzcheck.py -c testcase1_0_1-2wire-all-layers-connected-fixed-saved-no-changes.fz

Process testcase1_0_1-2wire-all-layers-connected-fixed-saved-no-changes.fz

5783 TwoLayerRectanglePCBModuleID (srcln 13) no connections

*** connections

5787 generic_female_pin_header_2_100mil (srcln 24) 5787-connector1-breadboard 5813-connector1-breadboardWire (srcln 33,36) 5787-connector0-breadboard 5792-connector1-breadboardWire (srcln 39,42) 5787-connector1-copper0 5813-connector1-copper1trace (srcln 55,58) 5787-connector0-copper0 5792-connector1-copper1trace (srcln 61,64) 5787-connector1-schematic 5813-connector1-schematicTrace (srcln 80,83) 5787-connector0-schematic 5792-connector1-schematicTrace (srcln 86,89)

5813 WireModuleID (srcln 225) 5813-connector1-breadboardWire 5787-connector1-breadboard (srcln 232,235) 5813-connector1-copper1trace 5787-connector1-copper0 (srcln 250,253) 5813-connector1-schematicTrace 5787-connector1-schematic (srcln 268,271) 5813-connector0-breadboardWire 5790-connector1-breadboard (srcln 238,241) 5813-connector0-copper1trace 5790-connector1-copper0 (srcln 256,259) 5813-connector0-schematicTrace 5790-connector1-schematic (srcln 274,277) 5813-connector1-breadboardWire 5787-connector1-breadboard (srcln 232,235) 5813-connector0-breadboardWire 5790-connector1-breadboard (srcln 238,241) 5813-connector1-copper1trace 5787-connector1-copper0 (srcln 250,253) 5813-connector0-copper1trace 5790-connector1-copper0 (srcln 256,259) 5813-connector1-schematicTrace 5787-connector1-schematic (srcln 268,271) 5813-connector0-schematicTrace 5790-connector1-schematic (srcln 274,277)

5792 WireModuleID (srcln 166) 5792-connector1-breadboardWire 5787-connector0-breadboard (srcln 173,176) 5792-connector1-copper1trace 5787-connector0-copper0 (srcln 191,194) 5792-connector1-schematicTrace 5787-connector0-schematic (srcln 209,212) 5792-connector0-breadboardWire 5790-connector0-breadboard (srcln 179,182) 5792-connector0-copper1trace 5790-connector0-copper0 (srcln 197,200) 5792-connector0-schematicTrace 5790-connector0-schematic (srcln 215,218) 5792-connector1-breadboardWire 5787-connector0-breadboard (srcln 173,176) 5792-connector0-breadboardWire 5790-connector0-breadboard (srcln 179,182) 5792-connector1-copper1trace 5787-connector0-copper0 (srcln 191,194) 5792-connector0-copper1trace 5790-connector0-copper0 (srcln 197,200) 5792-connector1-schematicTrace 5787-connector0-schematic (srcln 209,212) 5792-connector0-schematicTrace 5790-connector0-schematic (srcln 215,218)

5790 generic_female_pin_header_2_100mil (srcln 96) 5790-connector1-breadboard 5813-connector0-breadboardWire (srcln 105,108) 5790-connector0-breadboard 5792-connector0-breadboardWire (srcln 111,114) 5790-connector1-copper0 5813-connector0-copper1trace (srcln 127,130) 5790-connector0-copper0 5792-connector0-copper1trace (srcln 133,136) 5790-connector1-schematic 5813-connector0-schematicTrace (srcln 150,153) 5790-connector0-schematic 5792-connector0-schematicTrace (srcln 156,159)

and looks like this in Fritzing

capture

capture1

capture2

This is the same sketch but in Fritzing convert the rats nest lines in schematic and pcb to wires:

testcase1_0_1-2wire-all-layers-connected-fixed-saved-ratsnest-to-wires.fzz.zip

Running this through fzcheck.py displays the corruption:

$ fzcheck.py -c testcase1_0_1-2wire-all-layers-connected-fixed-saved-ratsnest-to-wires.fz

Process testcase1_0_1-2wire-all-layers-connected-fixed-saved-ratsnest-to-wires.fz

5783 TwoLayerRectanglePCBModuleID (srcln 13) no connections missing 5787-connector0-copper1 5822-connector1-copper1trace missing 5790-connector0-copper1 5822-connector0-copper1trace missing 5787-connector1-copper1 5826-connector1-copper1trace missing 5790-connector1-copper1 5826-connector0-copper1trace

*** connections

5787 generic_female_pin_header_2_100mil (srcln 24) 5787-connector1-breadboard 5813-connector1-breadboardWire (srcln 33,36) 5787-connector1-breadboard 5826-connector1-breadboardWire (srcln 33,37) 5787-connector1-breadboard 5834-connector1-breadboardWire (srcln 33,38) 5787-connector0-breadboard 5792-connector1-breadboardWire (srcln 41,44) 5787-connector0-breadboard 5822-connector1-breadboardWire (srcln 41,45) 5787-connector0-breadboard 5830-connector1-breadboardWire (srcln 41,46) 5787-connector1-copper0 5813-connector1-copper1trace (srcln 59,62) 5787-connector1-copper0 5834-connector1-copper0trace (srcln 59,63) 5787-connector0-copper0 5792-connector1-copper1trace (srcln 66,69) 5787-connector0-copper0 5830-connector1-copper0trace (srcln 66,70) 5787-connector1-schematic 5813-connector1-schematicTrace (srcln 86,89) 5787-connector1-schematic 5826-connector1-schematicTrace (srcln 86,90) 5787-connector1-schematic 5834-connector1-schematicTrace (srcln 86,91) 5787-connector0-schematic 5792-connector1-schematicTrace (srcln 94,97) 5787-connector0-schematic 5822-connector1-schematicTrace (srcln 94,98) 5787-connector0-schematic 5830-connector1-schematicTrace (srcln 94,99)

5813 WireModuleID (srcln 245) 5813-connector1-breadboardWire 5787-connector1-breadboard (srcln 252,255) 5813-connector1-copper1trace 5787-connector1-copper0 (srcln 270,273) 5813-connector1-schematicTrace 5787-connector1-schematic (srcln 288,291) 5813-connector0-breadboardWire 5790-connector1-breadboard (srcln 258,261) 5813-connector0-copper1trace 5790-connector1-copper0 (srcln 276,279) 5813-connector0-schematicTrace 5790-connector1-schematic (srcln 294,297) 5813-connector1-breadboardWire 5787-connector1-breadboard (srcln 252,255) 5813-connector0-breadboardWire 5790-connector1-breadboard (srcln 258,261) 5813-connector1-copper1trace 5787-connector1-copper0 (srcln 270,273) 5813-connector0-copper1trace 5790-connector1-copper0 (srcln 276,279) 5813-connector1-schematicTrace 5787-connector1-schematic (srcln 288,291) 5813-connector0-schematicTrace 5790-connector1-schematic (srcln 294,297)

5826 WireModuleID (srcln 363) 5826-connector1-breadboardWire 5787-connector1-breadboard (srcln 388,391) 5826-connector1-schematicTrace 5787-connector1-schematic (srcln 370,373) 5826-connector0-breadboardWire 5790-connector1-breadboard (srcln 394,397) 5826-connector0-schematicTrace 5790-connector1-schematic (srcln 376,379) 5826-connector1-schematicTrace 5787-connector1-schematic (srcln 370,373) 5826-connector0-schematicTrace 5790-connector1-schematic (srcln 376,379) 5826-connector1-breadboardWire 5787-connector1-breadboard (srcln 388,391) 5826-connector0-breadboardWire 5790-connector1-breadboard (srcln 394,397) 5826-connector1-copper1trace 5787-connector1-copper1 (srcln 406,409) 5826-connector0-copper1trace 5790-connector1-copper1 (srcln 412,415)

5834 WireModuleID (srcln 481) 5834-connector1-breadboardWire 5787-connector1-breadboard (srcln 506,509) 5834-connector1-copper0trace 5787-connector1-copper0 (srcln 488,491) 5834-connector1-schematicTrace 5787-connector1-schematic (srcln 524,527) 5834-connector0-breadboardWire 5790-connector1-breadboard (srcln 512,515) 5834-connector0-copper0trace 5790-connector1-copper0 (srcln 494,497) 5834-connector0-schematicTrace 5790-connector1-schematic (srcln 530,533) 5834-connector1-copper0trace 5787-connector1-copper0 (srcln 488,491) 5834-connector0-copper0trace 5790-connector1-copper0 (srcln 494,497) 5834-connector1-breadboardWire 5787-connector1-breadboard (srcln 506,509) 5834-connector0-breadboardWire 5790-connector1-breadboard (srcln 512,515) 5834-connector1-schematicTrace 5787-connector1-schematic (srcln 524,527) 5834-connector0-schematicTrace 5790-connector1-schematic (srcln 530,533)

5792 WireModuleID (srcln 186) 5792-connector1-breadboardWire 5787-connector0-breadboard (srcln 193,196) 5792-connector1-copper1trace 5787-connector0-copper0 (srcln 211,214) 5792-connector1-schematicTrace 5787-connector0-schematic (srcln 229,232) 5792-connector0-breadboardWire 5790-connector0-breadboard (srcln 199,202) 5792-connector0-copper1trace 5790-connector0-copper0 (srcln 217,220) 5792-connector0-schematicTrace 5790-connector0-schematic (srcln 235,238) 5792-connector1-breadboardWire 5787-connector0-breadboard (srcln 193,196) 5792-connector0-breadboardWire 5790-connector0-breadboard (srcln 199,202) 5792-connector1-copper1trace 5787-connector0-copper0 (srcln 211,214) 5792-connector0-copper1trace 5790-connector0-copper0 (srcln 217,220) 5792-connector1-schematicTrace 5787-connector0-schematic (srcln 229,232) 5792-connector0-schematicTrace 5790-connector0-schematic (srcln 235,238)

5822 WireModuleID (srcln 304) 5822-connector1-breadboardWire 5787-connector0-breadboard (srcln 329,332) 5822-connector1-schematicTrace 5787-connector0-schematic (srcln 311,314) 5822-connector0-breadboardWire 5790-connector0-breadboard (srcln 335,338) 5822-connector0-schematicTrace 5790-connector0-schematic (srcln 317,320) 5822-connector1-schematicTrace 5787-connector0-schematic (srcln 311,314) 5822-connector0-schematicTrace 5790-connector0-schematic (srcln 317,320) 5822-connector1-breadboardWire 5787-connector0-breadboard (srcln 329,332) 5822-connector0-breadboardWire 5790-connector0-breadboard (srcln 335,338) 5822-connector1-copper1trace 5787-connector0-copper1 (srcln 347,350) 5822-connector0-copper1trace 5790-connector0-copper1 (srcln 353,356)

5830 WireModuleID (srcln 422) 5830-connector1-breadboardWire 5787-connector0-breadboard (srcln 447,450) 5830-connector1-copper0trace 5787-connector0-copper0 (srcln 429,432) 5830-connector1-schematicTrace 5787-connector0-schematic (srcln 465,468) 5830-connector0-breadboardWire 5790-connector0-breadboard (srcln 453,456) 5830-connector0-copper0trace 5790-connector0-copper0 (srcln 435,438) 5830-connector0-schematicTrace 5790-connector0-schematic (srcln 471,474) 5830-connector1-copper0trace 5787-connector0-copper0 (srcln 429,432) 5830-connector0-copper0trace 5790-connector0-copper0 (srcln 435,438) 5830-connector1-breadboardWire 5787-connector0-breadboard (srcln 447,450) 5830-connector0-breadboardWire 5790-connector0-breadboard (srcln 453,456) 5830-connector1-schematicTrace 5787-connector0-schematic (srcln 465,468) 5830-connector0-schematicTrace 5790-connector0-schematic (srcln 471,474)

5790 generic_female_pin_header_2_100mil (srcln 106) 5790-connector1-breadboard 5813-connector0-breadboardWire (srcln 115,118) 5790-connector1-breadboard 5826-connector0-breadboardWire (srcln 115,119) 5790-connector1-breadboard 5834-connector0-breadboardWire (srcln 115,120) 5790-connector0-breadboard 5792-connector0-breadboardWire (srcln 123,126) 5790-connector0-breadboard 5822-connector0-breadboardWire (srcln 123,127) 5790-connector0-breadboard 5830-connector0-breadboardWire (srcln 123,128) 5790-connector1-copper0 5813-connector0-copper1trace (srcln 141,144) 5790-connector1-copper0 5834-connector0-copper0trace (srcln 141,145) 5790-connector0-copper0 5792-connector0-copper1trace (srcln 148,151) 5790-connector0-copper0 5830-connector0-copper0trace (srcln 148,152) 5790-connector1-schematic 5813-connector0-schematicTrace (srcln 166,169) 5790-connector1-schematic 5826-connector0-schematicTrace (srcln 166,170) 5790-connector1-schematic 5834-connector0-schematicTrace (srcln 166,171) 5790-connector0-schematic 5792-connector0-schematicTrace (srcln 174,177) 5790-connector0-schematic 5822-connector0-schematicTrace (srcln 174,178) 5790-connector0-schematic 5830-connector0-schematicTrace (srcln 174,179)

Here we have the initial two wires (apparently in the same format) but Fritizing has added 4 wires some of which are incomplete (as indicated in the missing section at the top of the display.) Starting from the first .fzz file and clicking on the wires in schematic or pcb should allow you to trace what is going on that is causing the extra wires. In Fritzing it looks pretty much normal other than the .fzz file has extra wires.

capture3

capture4

capture5

It should be possible in fzcheck.py with enough thought to detect and correct this by finding the duplicate wires and removing them. I will work on that. Hope this helps!

edit

Well that was a good theory, unfortunately it is wrong! There is a separate wire for each view (which makes sense as routing is different for each view) so you can ignore all of the above because its wrong. So back to the drawing boards ...

The detector is published with the 1.0.2 code.

There are still some issues. For example, when importing this old project (created with a >13 years old Fritzing version) https://fritzing.org/projects/555-impulsegenerator-symmetrical-pulses , then the Submarine part in the PCB behaves strange.

The detector is active in debug mode. Automatic fixes can be attempted in Schematic View -> Routing -> Tidy Wires

fritzing / fritzing-app

Detect routing database corruption #3904

Current Behaviour

Expected

Expected Behaviour

ifndef QT_NO_DEBUG

endif