While I’m retired and thus can spend time as pleases me, a lot of this effort is actually chasing the corruption bug (which has been frustrating me for more than 5 years now!) I’m hoping your sketch may shed some light on that. Now I have a copy that routes clean I can compare the corrupted file to a clean one and see it that tells me anything new about the corruption. In this case it may, because the corruption in this case is much worse than any I have seen before. Even if it doesn’t illuminate the original issue it may point to another bug or bugs that we can fix. I’m interested in how and why it managed to change the base operation of Fritzing (changing the color of the traces in pcb.) and if there is anything we can do to prevent that.
The connections that overlaps aren’t supposed to be connected to each other. Even though they overlap in pcb, Fritzing is remembering they are two different nets (thus the DRC error.) The two nets are separate, but the way they are connected they will short together and make the board not work. My layout (assuming I didn’t make a mistake of some kind) is correct and is routed without the two nets being connected to each other.
Sorry, I tend to not remember the odder features aren’t obvious to everyone (a danger of using Fritzing for a long time!), DRC stands for Design rules check (Routing->Design rules check)
This checks that all traces on the board are far enough away from the edge of the board and from all other traces and parts on the board and (assuming the silkscreen layer in parts are accurate) the parts will physically fit correctly on the board (I notice some of the terminal blocks are pretty close to each other for instance!) so the board should be producible by a board house. The settings line under it can modify the settings for it and autorouter, but by default they are set to professional, which is what is in use here. Clicking an an item in the list highlights the trace in error, then you need to look for the (sometimes painfully small!) red marker that marks the traces that are too close (the trace is the outer red circle and the marker the small red dots in the inner circle in this image.) It is sometimes safe (and necessary!) to ignore warnings but it is good practice to always check for them and make sure they are safe to ignore.
assuming I didn’t screw something up (although I don’t think I did as DRC was complaining) this image of my new routing indicates the problem. In your sketch these two traces overlap and would (because in the end up copper is copper) short together and cause the board to not work because two nets that are supposed to be separate short together.
edit:
I just came across (or at least just recognized) another oddity:
The connection circled in red here seems strange. 12V is going to the terminal block on the red wire, but the black and white striped wire to the optocoupler connects to a 10k pull up resistor to 12V. I would expect the black and white wire to be ground or at least pull to ground to activate the optocoupler but then I would expect the 12V connection to the terminal block to connect to ground instead to supply whatever is on the end of the terminal block with the necessary ground. It is probably worth looking at this connection to make sure it is correct (I can’t tell since I don’t know what is in the end of T5 or T13 so it may be fine as is!)
edit1:
I just figured out the cause of our problems. It isn’t database corruption at all, but rather your choice of pads. The pad you used is only on one side of the board either top layer or in this case bottom layer, but they are SMD type pads and thus despite looking like they have a hole in Fritzing in the gerber output they do not. Because they are only on the bottom layer the trace can not be moved to top layer (because there isn’t a through hole connection because the pad is single layer.) It looks like there is another bug somewhere which caused the color change I saw on the original sketch (I so far haven’t been able to reproduce that one!) The reason my new sketch works is because the headers I used as the pads are through hole and will both let me change layers and drills a hole in the gerber output. Here is a screen shot of the pcb view with some of your pads from Fritzing. While the green dot (which appears to represent the connection point, not a hole!) looks like a hole should be produced it is in fact not. The fact the pad is only showing on the bottom layer (as it is brown not golden like the through hole pads) should have alerted me to what was wrong, but it didn’t until just now.
although it appears to have a hole in pcb view the gerber output has no hole because there isn’t a circle in the pad (and it isn’t through hole) to create one. This is the gerber output (displayed by gerbv) for the copper0 and drill layers in the gerber files.
Note a through hole pad (circled in green here) has a hole. The ground and 2 j1 pads (and the A0 pad on the left edge) do not have holes and I expect they won’t get drilled when you mill the board because the holes aren’t in the gerber drill file. The solution is to use the through hole headers as off board connect points as I did in my sketch. That should do what you want. This is another Fritzing quirk, gerber processing takes place after the render for pcb view and will sometimes (as in this case) show holes in pcb view where in fact the hole isn’t in the gerber file (which is why you should always check the gerber output with a gerber viewer before ordering boards!) At this point I don’t think your original sketch had database corruption (I can’t find any evidence of it) just this quirk of how Fritzing works which took some time for me to figure out.
Peter