New Ground fill bug

Hello all.

I was preparing a PCB for manufacturing and I noticed that the new ground fill is not generating a proper file. More specifically, I saw that the part’s trace pads are connected to the copper fill when they shouldn’t be connected.

I tried the old ground fill and I didn’t get this problem. The part I’m using is the JDY-23 which you can find here: JDY-23 / JDY-23A BLE module. I never had an issue using ground fill in the past using older versions of Fritzing with this part.

You can see what the new ground fill generated and how the part’s pad are connecting to the copper fill:

and what the old ground fill generated where the pads are not connecting:


You would be best to open an issue here on github (after checking the open issues to see if of them covers your issue)

you would also need to supply the sketch that demonstrates the issue as well, images are not much use. There are a number of open issues (many scheduled to be fixed in 1.0.3) with copper fill.


Hi Peter.

I run some more tests the weekend comparing the export results between my desktop and the laptop, both using the same version of Fritzing and linux. I copied the fritzing file from the desktop to the laptop. I noticed that the exports from the laptop where actually correct even when using both the old and the new ground fill options. Still, I couldn’t make it work on the desktop pc. As a last resort, I removed the part from the desktop, re-import it and then tried the export again. This time it worked, I didn’t get any connections between the copper and the pads. I tested a few times using the old and new copper fill options and didn’t get the issue back.

Not exactly sure what happened here, since I created the circuit on the desktop machine, copied over to the laptop for more testing and then managed to work correctly when I removed the part and re-import it.

Apparently, at the moment doesn’t seem to be an issue, so I will go ahead and close the thread.


edit: I can’t close it :slight_smile:

Threads in the forum can’t be closed (issues on github can!) so that isn’t a problem. The .fzz file copies the part from the local machine to the .fzz file, so it appears something (what is unknown!) on the local machine was corrupting the part but the export was working correctly. That is a very odd problem and it would have been interesting (if not necessarily easy) to capture the .fzp and svg files in the Fritzing user directories to examine before the part was reloaded (in case you see this again) as comparing those files to the .fzpz versions may shed light on what was happening and how it could be fixed.