Ground Fill with gap lines

Hello every one! i am workin with fritzing just a few days. I did advance good until now, but i am stucked with my ground fill. i did it and there are some line gaps in the ground fill. Someone knows how to have a clean placement or it is a bug?

Of course this picture is the final version for printing. In the Fritzing PCB it is barely visible, but still there.

Thank you!

Those are how Fritzing creates the ground fill. Frizing intersects lines with the other copper areas. I have never home etched a PCB from Fritzing but I can say they never show up in a professionally made boards I have made from Fritzing. I also believe they may not be there when you print them out on paper as I think they only show up because of how a monitor has a limited number of lines of resolution and it has to decide which pixels to display which SVG lines on and sometimes it shows them as having gaps but if you zoom in or out on the SVG those gaps move as they are not actually gaps.

I understand… but my concer is because the image was generated in PDF to print… and the gaps are there…
but i will give a try…
how do you print your bords? Do you use any othe program to this?

A PDF is also an SVG (Scalable vector graphic) and it could possibly still be a display issue unless you have printed it on plain paper already and it prints that way.

I haven’t etched a board in years now. I order my boards from Elecrow and get 5 100mm x 100mm professionally made boards for under $5 which is far less then it would cost to make a single PCB using toner transfer paper, etchant and copper clad board. Plus they are tested, have my choice of solder resist color, board thicknesses from 0.6 - 1.6mm and nice silkscreens all for that price.

There are many other places that have similar prices like Fusion PCB manufacturing (Seeedstudio) and Dirty PCBs but I prefer Elecrow myself. I’ve never had a bad board and if they find anything wrong with the solder resist or silkscreen during inspection they will remake them and send you all the PCBs. That means some times you will order 5 and get more just because the silkscreen is smudged or the color is off on some.

Many thanks for your attention, i will print and back to tell you the result. unfortunatly, i don´t have a easy contact company to do the boards…

You can use any of those companies. They all make boards for makers not just large corporations. They all accept PayPal and ship worldwide too. You just export your board as gerbers , zip them up and upload them to their site. They make the boards in about 1 week and send them off. If you are in a country that is part of the E-packet program you can select registered mail and email them and tell them you want E-packet shipping and get them in under two weeks for the cost of registered mail which for me in Canada takes up to 6 months so E-packet is a dream at under 2 weeks.

The ground fill gap lines should not cause a problem… we have been over this subject many times. They are caused by the way the algorithm that create the ground fill. The core people are working on a new algorithm for the ground fill… maybe the next upgrade they will have that fixed… :grinning:

Thank you for remarkable help here! As @sublimeartistry said, this lines disapear on printing! If anyone has this issue, print with confidence, no problem at all!!
Thank you @sublimeartistry and @steelgoose

This is a big problem for me when trying to etch with a pdf.

Would you please indicate if this will be fixed in the next release and approximately when that might happen?

Thanks, Roger

Please note the lines do not disappear when I export to pdf or svg, both usually need to be manually edited to ensure the ground plane is contiguous.

I believe the fixes being referred to are the gerber export fixes (some 6000 commits) that ended up being backed out of the development version because they caused gerber export problems when tested back around 2018. The folks that had done the work did not respond to emailed requests for assistance and are assumed to be no longer interested in proceeding (at the time Fritzing development had died.) The commits are still available in the github source repository and development is going again so there is some hope that work may again occur assuming there is interest, but I’m not aware of a timeline for a release, as someone new will need to learn what the code is doing and with 6000+ commits that is likely to take some time. The folks that identified the problems in 2018 are also no longer posting so the testing will need to occur again (although some of the issues are probably available in forum posts or on github) … You may be better off looking for a gerber to pdf translator as usually the gerber output is correct as that is the primary output format (although there are some bugs in there too.) I don’t know if there is such a tool, but there may be.

Peter

Peter, thank you very much for your prompt response, although it is disappointing. I didn’t know there was a gerber to pdf translator either but I will try looking for one and thanks for the suggestion. I have tried to use some other PCB design tools but much happier with Fritzing so I am hoping the fixes will be included in a future upgrade.

Peter, Are you sure the root of the problem is not with gerber file generation? I ask because tracespace view ‘https://tracespace.io/view/’ which apparently coverts gerber to svg and it produces the same irritating lines in the svg files from gerber files produced by Fritzing. In fact, I can see the lines on the Fritzing PCB view so it may be the problem originates in the ‘Ground Fill’ function.

Sorry fro the late reply, network access still down. No I’m not sure it isn’t in gerber generation, although the problem has never been reported in gerber generation as far as I know, only in pdf. That said ground fill does sometimes have issues even in gerber and there are some gerber fixes in the development version (some 5 fixes were committed around last november) but they were for board outline more than ground fill. It could be a fault in gerber generation which gerber accepts but breaks when the conversion to pdf is done. Hopefully we will get someone familiar with gerber and pdf to work on the code at some point.

Peter

Hi Peter,

Thank you for your reply but please note that the faint lines can be seen in Fritzing after ground fill but before any export. It is hard to see in the image below but the horizontal problem lines can be seen.

The lines are clearly seen when exported to SVG or PDF. Maybe the issue might be with the ground fill algorithm?

image.png

Regards,

Roger

Your .png doesn’t appear to have uploaded correctly as it isn’t showing as a link. It is entirely possible that this is a ground fill problem, if I recall the discussion when the changes were rolled back, a different method of doing ground fill was also part of the package.

Peter

Please note I am not a programmer and I have a hard time understanding the nuances of the Fritzing source code but in any case I thought I would look for the code used for ground plane generation. I found ‘groundplanegenerator.cpp’ and when I opened it up I immediately noticed a note at the beginning that maybe the problem:

// !!!
// !!! IMPORTANT NOTE: QRect::right() and QRect::bottom() are off by one–this is a known Qt problem
// !!!
// !!!▷▷⋅▷⋅▷⋅▷⋅ one workaround might be to switch to QRectF
// !!!

I have no idea if this is the problem that I am seeing but it might be worth looking into?

Regards,
Roger

Join the crowd :slight_smile: most of us are in the same boat, the source is difficult to understand, and it is usually unclear when a change may affect something else unexpected.

It is probably worth looking in to, but may or may not be the problem. Just the fact that the original developers thought there is an issue there is worth looking at. I have a long list of bugs to look at, and I am probably not the one for this area which needs someone that understands the gerber and svg generation code (which isn’t me :slight_smile: .) It is probably worth checking this issue is listed on the issues section on github (which is the official repository of bug reports:

Peter