Parts not grounding. - Githubissues

DetonationEMS commented 3 years ago

Current Behaviour

This is actually one of the biggest issues I have been working around with previous issues of fritzing but the newest version is far worse. If some parts are to close to traces, another part or nothing at all it will not be grounded. I have to shuffle parts/traces around of get what feels like nothing more than luck to get parts to ground. Ill Include snapshots. Both the exact same file. When the file is ground filled with Version 0.9.4 (CD-498-0-a1ffcea 2019-12-01) 64 [Qt 5.12.3] it will work as I had it set for production. The second snap is Version 0.9.6 (bCD-175-0-8a1e0682 2021-02-21) 64 [Qt 5.12.10] the exact same file, when the ground fill is applied you can see many ground traces are left out. Several parts are left ungrounded. Again to reiterate, this is an issue with all versions of Fritzing over many years . This newest version seems to have this issue the worst. I wish I spoke up about this sooner because the issue is very frustrating because so much time is spent making sure parts are actually grounded before the I send the files for production.

Operating System: <Windows 10>

Steps to reproduce: Outlined above

Expected Behaviour

Enough room to place traces but this space cannot be used to ground a part. 0 9 4 0 9 6

failiz commented 3 years ago

It would help if you can upload the file or a minimum example.

KjellMorgenstern commented 3 years ago

Easy to reproduce:

3794_not_grounding.fzz.zip

The kathode is set as ground fill seed. Also works with just three diodes, not related to label or ground fill seed. It looks that this depends on the distance of the connectors to their neighbours.

DetonationEMS commented 3 years ago

Sorry, I think I have notifications off on github. It can be reproduced as shown above with any grounded parts or pad. I want to reiterate this is an issue with all versions of Fritzing i have been using for many years.. I have had to play with locations of parts for all of my projects.. Ill include one of the files I am working on now.. Just ground fill with the new version vs the 0.9.4 v1.3.2.7.fzz.zip...

Even this file was modified after a prototype was made because of a no grounding issue on 0.9.4. Ill also include a snapshot of what happened to me on 0.9.4 because I missed one of my parts not being grounded. There is no reason for c4 to have not been grounded. AHHHHHHH

DetonationEMS commented 3 years ago

I know very little about coding so I will leave these pictures here. These are examples of the grounding issues I have been having since using fritzing. This is on 0.9.4. You can see there are no ground connections were there is plenty of room to have them.

gr1 gr2 gr3

KjellMorgenstern commented 3 years ago

We fixed some of the issues in 0.9.6 compared to 0.9.4, so examples from 0.9.4 are not as useful.

So far, this issue shows that neighbouring GND connections are not connected to the ground fill in 0.9.6. That fix should not be to difficult. But are there other occurrences?

DetonationEMS commented 3 years ago

We fixed some of the issues in 0.9.6 compared to 0.9.4, so examples from 0.9.4 are not as useful.

So far, this issue shows that neighbouring GND connections are not connected to the ground fill in 0.9.6. That fix should not be to difficult. But are there other occurrences?

I'll have to ground fill some files after 0.9.6 is fixed knowing what issues I have with 0.9.4 and previous versions and see if what is being fixed now resolves the issue.

It's tough because to me seems this bug is just be a far worse version of the issue that I've been having ever since I've been using fritzing. I remember reading Josh from speeduino made some comments about this very same this some years ago on the fritzing forum. He has since switched to kicad. I learned so much on fritzing and love it for what it can do. So, I'm quite dedicated to trying to make this work for me.

I guess keeping posted when the issue is fixed and I'll try and reground what I know has caused issues in the past and we'll see what happens.

-Aaron

failiz commented 3 years ago

Could be #3745 related to this?

KjellMorgenstern commented 3 years ago

I don't then the issue is related. The other issue is about connections being to small for very large connector pads, but they are not missing.

DetonationEMS commented 3 years ago

I'm curious if there will be an update to this issue in the near future of if it will be a while. I am working on shrinking some of my projects but even in 0.9.4 this grounding issue severely hinders me from doing it. Thanks!! -Aaron

KjellMorgenstern commented 3 years ago

I recommend to use 0.9.6, i think it behaves more predictable. Previous versions could sometimes get very close to unrelated traces, causing shorts. (directly, or later during manufacturing) This was fixed in 0.9.6, but a different issue still remains. When donuts are direct neighbors, so that no part of the ground plane is in between, they will not connect to each other or to the ground plane.

In that case, you need to manually connect them to the ground plane. Depending on your circuit and workstyle, you could also use the autorouter, after creating the ground plane.

DetonationEMS commented 3 years ago

I am working with a product that has been designed, prototyped and finalized in 0.9.4. I can't get most of chips in my previous work to ground at all on 0.9.6. So in 0.9.4 I was able to wiggle my was through the grounding issues but 0.9.6 renders the board completely unusable. I may be wording the issues I have been having wrong. I found someone else, I think Josh Stewart who had the same complaint and had to abandon fritzing because of it. Ill highlight and point out what i mean in a follow up post.

DetonationEMS commented 3 years ago

Everything with an arrow is not grounded. There is no reason for a ground connection to be missing here. Even the Voltage regulator (the dpack chip), nothing would let it have a ground that is why I had to use the vias and traces to even give it ground. So I cannot dispute any other changes in the 0.9.6. I was unable to even ground my existing project so I was unable to use 0.9.6 at all. But these ground issues were in 0.9.4 and prior versions. I point this out because I wonder if the issues in 0.9.6 is an exacerbation of the same issue. If it's not, then it's another bug that needs to be addressed.

jonathanhogg commented 3 years ago

I've just run into this today upgrading from 0.9.4 to 0.9.8 – I've got pins that are completely absent a ground.

It seems to be super-easy to reproduce: I just dropped a standard 5-pin header into a new schematic, connected the 1st, 3rd and 5th pins to ground:

Put the header in the middle of a small PCB and did a ground fill top and bottom. Only the 1st and 5th pins are grounding and only on one side, the 3rd pin is completely disconnected from the ground plane:

And here's that simple test file:

Test.fzz.zip

I upgraded to 0.9.8 to solve some other tracing issues, so this is a real headache for me now as it's breaking my previously working PCB design. I'm going to have to drop in manual copper fills to create the proper ground connections in my design.

DetonationEMS commented 3 years ago

I was having so many issue and 2 years of headache with tracing, lack of parts and grounding I gave up. I really hope fritzing becomes a move usable product one day. After a learning curve I'm doing twice the work in half the time on KiCad. Sorry.

SpComb commented 2 years ago

Noticed the same problem after upgrading 0.9.4 -> 0.9.9 and re-generating the bottom ground fill on a simple PCB: the voltage regulator core part is left with its center ground pin disconnected from the ground fill:

Screenshot from 2021-11-01 00-28-13

I don't think this happened with 0.9.4, but it did with the same project in 0.9.9.

DetonationEMS commented 2 years ago

I was only able to complete my project in 0.9.4. Further updates would result in this same issue. I just tried 0.9.9 yesterday and it was worse than 0.9.6. No versions were able to correctly connect all grounds and after my project became more complicated I was forced to migrate to different software. I really hope Fritzing can fix this massive issue. It caused hundred of hours of adjusting parts to try and get proper or at least partly proper grounding. When i opened this issue I got the impression I was alone. Issue I am having is not just what you have recreated but the lack of proper ground on parts even in the core parts list. If a massive trace can fit through the space between the next part then why cant the part be connected to ground?? (refer to this https://github.com/fritzing/fritzing-app/issues/3794#issuecomment-815338845 )

KjellMorgenstern commented 2 years ago

The issue is caused by a fix for an even worse issue: Before, there were cases of pads being connected to ground fill which should not (resulting in a short). Since the connectors are highlighted in red, they should be by easy to spot, and adding a trace manually should also be possible? It is inconvenient, but how can it result in hours of work? Maybe i am missing something? Nevertheless, we will improve this of course.

DetonationEMS commented 2 years ago

I tried to included pictures. I had several projects with well over 100 parts on a board. Fritzing being what I learned on and capable of SMD parts I stuck with it. I'll try to explain in best detail. After I placed the parts and organized them on the board, run the check and then ground fill. This is were all goes wrong. The ground fill will leave allot of without sufficient ground or any ground at all. After a while of playing around I found that the distance between the nearby parts and traces make a major difference. It had zero correlation with the keep out zones or any other setting. That distance was almost random in nature. So many many many times I would have to reorganize an entire section of the board or in some cases the whole board board just to find a jigsaw way to get ground to some parts. Yes, you can add traces into the mix GND to GND but that doesn't solve the issue. I am getting the feeling it's my fault for thinking I could do this much complex work within fritzing. I realized this after I saw a very old post on the forums from Josh Stewart complaining about the same thing. I'd have to look but the post was very old, several years. So the issue was never addressed. Unfortunately we both came to the same conclusion that our work may just be beyond fritzing. I accept that, I am creating ECU's for cars. I have long moved on from fritzing and migrated to KiCad. I am only throwing my thoughts in because for a starter PCB designer or hobbyist Fritzing could be the most perfect tool as it's simple and effective. I used Fritzing for a few years before I had to switch. So I can assure you that the issues is real, maybe less real to simple designs but for more complex and SMD designs it almost unusable.

KjellMorgenstern commented 2 years ago

Of course it is a real issue, I totally agree with that.

So you rearranged the parts until the auto-ground fill would cover all connections. This is quite complex, and i understand that it will easily take many hours on a bigger circuit.

But did you consider manually setting the routes to GND for the affected connections? Or was this not a valid workaround for some reason?

The same can usually be done if you want to connect to the Ground fill with a wider connection for higher currents.

DetonationEMS commented 2 years ago

I did consider traces as grounds. As shown in my picture above it was the only way I was able to ground the regular. I think a few very important things would make the issue easier to deal with. A rats nest connection check. It's in every other PCB software I've ever used. This would as least tell the user a GND (or any other connection for that matter) has not been made, or have been made incorrectly. Additionally, for SMD at least, a selection to not have thermal relief ground connections would almost completely eliminate the issue I was having since I was working with mostly SMD parts. These options would not only add to the experience but be solid and viable workarounds until the GND issue is resolved.

SpComb commented 2 years ago

But did you consider manually setting the routes to GND for the affected connections? Or was this not a valid workaround for some reason?

I think 0.9.9 also has some issue affecting selection of partially overlapping objects in the PCB editor that makes this very difficult - I worked around this ground fill issue by copy-pasting a ground fill segment from a different via/pad and manually aligning it with the affected via. However, attempting to select the ground fill segment from "under" any component outline was VERY fiddly, and once the ground fill segment was in place and de-selected, it was more or less impossible to move.

Would manually routing traces between vias so that they overlap with the ground fill be a better workaround? Is that also preferred for working around the issue with the ratsnest routing /connection checks not understanding ground fills?

jonathanhogg commented 2 years ago

I gave up on expecting the ground fill to work as expected and manually traced all of my grounds before doing the fill. It was worth doing in the end anyway to make the board easier to solder – the default 4-sided ground connections in Fritzing don't provide much in the way of thermal isolation.

However, where I do want connections on multiple sides, it can be a royal pain doing this manually as Fritzing doesn't like you trying to draw multiple traces between the same connections, and this is sometimes necessary if there's not another spare ground connection nearby to trace to. I had to fool it by drawing the new trace on the other side and then swapping it back.

Since ground fills are absolutely recommended practice for PCBs and they are so clearly broken in the recent versions of Fritzing on standard parts (pin headers, regulators, etc.), I am somewhat surprised that this bug isn't gaining greater attention.

I mean, it's labelled as "priority-high" but has attracted neither an assignee nor a target release. If it's a technically challenging fix, perhaps a technical explanation here might attract some development help.

SpComb commented 2 years ago

Since the connectors are highlighted in red, they should be by easy to spot

Based on my experience using the (working) ground fill in 0.9.4, all of my ground connections had always been highlighted in red - perhaps I assumed that was just the color coding used for highlighting ground connections 😛

So it seems to me that the recommended practice is to first route ground connections as traces, and then use an additional overlapping copper/ground fill. That's not at all obvious to someone using Fritzing or EDA tools for the first time.

Is there an issue for tracking the lack of ratsnest connection check support for ground fills, that together with a fix for this issue would make the manual routing of ground traces unnecessary?

KjellMorgenstern commented 2 years ago

Since the connectors are highlighted in red, they should be by easy to spot

Based on my experience using the (working) ground fill in 0.9.4, all of my ground connections had always been highlighted in red - perhaps I assumed that was just the color coding used for highlighting ground connections stuck_out_tongue

So it seems to me that the recommended practice is to first route ground connections as traces, and then use an additional overlapping copper/ground fill. That's not at all obvious to someone using Fritzing or EDA tools for the first time.

Is there an issue for tracking the lack of ratsnest connection check support for ground fills, that together with a fix for this issue would make the manual routing of ground traces unnecessary?

Indeed, ground fill seeds are not added to the ratsnest. so my suggestion about that does not help. The recommended practice is (for versions up to 0.9.9, lets see if we can improve it in the next release) to include ground connections when routing.

There is no issue yet for adding ground fill seeds and the ground fill itself to the ratsnest. But then, the whole feature would just be there to support the workaround for an issue that should be fixed anyways, and might come with its own problems. I think it is better to invest the time into make ground fills work reliably.

KjellMorgenstern commented 2 years ago

@jonathanhogg Target release is "next". I had to shift this multiple times, since a partially working fix was not yet safe enough, and I didn't want to delay the release further.

DetonationEMS commented 2 years ago

Sounds like you have a better idea on what I was trying to explain. I am sorry my explanation wasn't very good. I think a big part of my issue was making an extremely complex PCB and it's not what fritzing is yet meant for. I am often adding hundreds of components onto a small area. My smaller more simple modules are a pleasure to design in fritzing. So as I said before I think i've moved beyond it's capabilities. But I want to stress I am not here to call it a bad program because with some more fixes Fritzing can be amazing for beginners and hobbyists. I wish you the best of luck and I'll keep an eye on future releases. - Aaron

KjellMorgenstern commented 2 years ago

@DetonationEMS Would you be able to share such a complex circuit? It doesn't need to be a working circuit, and I could also keep it local to my dev environment. But it would be interesting to test Fritzing against some more demanding real world cases.

vanepp commented 2 years ago

I think this forum thread is another instance of this same bug.

https://forum.fritzing.org/t/looking-for-modifyed-isolated-carrier-borad/16523/8

there appears to be a bug added between 0.9.4 and 0.9.6 in the mix too.

DetonationEMS commented 2 years ago

Ya that's what I said in my initial write up. It was always there but it's far far worse from 0.9.6. I cannot believe it's been an issue that's spanning years. I found a post from Noisymine from more than 4 year ago talking about the same issue.

KjellMorgenstern commented 2 years ago

I don't think this got worse from 0.9.4 to 0.9.6. Of course this needs an explanation. Those affected by the bug please bear with me :-) Let me explain, and demonstrate how the workaround should work.

Why it was an improvement.

Before, similar issues would cause unwanted connections, which could easily go unnoticed, shortening your circuit, and required manually cutting the connection after PCB production. Now, we have more situations in which the ground plane calculation fails, but at least there is a workaround, by manually routing the connections.

How to work around this

Fritzing notifies about unrouted connections, the hint should always be visible in the bottom bar. The GND connections should always be routed in the schematics or breadboard view. If you don't want to add such traces in the schematic, you can use GND labels. Don't let connections open if you want them to be connected. Fritzing can not help with such unconnected pins, but even more important, this is also hard to understand for anyone reading the schematic. Note #(todo: I think there is an issue that unconnected gnd fill seeds should automatically be treated as 'connected', but I could not find the issue number right now)

One (simplified) example. We have two parts that have a GND connector:

Due to the bug #3794 (the issue we are talking about), the parts GND is not connected to the ground fill:

After pressing the "autoroute" button, the parts GND connectors are routed. The autorouter selected to connect them on the bottom layer of the board:

Now, maybe you don't want to use the autorouter, or you want to connect it on top and bottom layer. To create a connection manually, button down on one connector, and manually route it to the other. For this demonstrations, I route the connection at a 45-degree angle (by holding shift while moving the mouse), and choose a thinner 8mil route:

Please let me know (right here in the issue) if some of these workaround steps are not applicable for a specific situation. @jonathanhogg The example you uploaded is straightforward to show the bug, but it doesn't show why the workaround is impractical. Do you have an example for this? I am asking because a possible fix could still cause the same problem for your use case then.

One problem with the workaround is that the GND plane only has one single connector, which could be hard to find a route to:

Why does it take so long to fix?

If there was a single reason, we would probably already have fixed it, so this is a bit lengthy:

Main reason still is that Fritzing was not improved for many years until we restarted development. Now this was already three years ago, so this excuse won't hold for much longer ;-) There simply had many other, also high priority issues, accumulated.
There is not one single point in the code that causes this. There are several reasons, each could result in a connection not being made. Each needs to be handled on its own, and for each we would have to ensure that there are no unwanted side effects. Unfortunately, those side effects are not rare, and we already had to revert fixes.
There are other issues with the ground fill: #3745, #3209, #2304, #3932, #1915, #3185, #2638. The last one, #3185 is not really about the ground fill, but ground fill suffers from the same 'leaving vector space' issue.

What are we doing to fix it?

After some 'simple' patches had to be reverted, I think the issue needs a bigger approach to tackle.

Work on a generic approach, that allows to parameterize individual ground seeds (e.g. do you want thin or thick connections):

Mini feature spec: Right now, the ground fill works in pixel graphics, which I think is a flawed approach. Implementing a vector solution could be as 'easy' as just automating the above described workarounds. We would create traces that stop as soon as they reach the copper plane. Traces in Fritzing can already be parameterized, so users can choose how thick traces should be. Plus, traces are in vector space.

Add tests, so we can ensure the ground plane works in all applicable situations: This is already solved. But if you have some nice example Fritzing projects (.fzz) , you can attach them here. I will then add them to our tests. Basically, we select the ground fill from the menu and compare the result to a reference image, for each build of Fritzing.

What else

Until then entirely disable to ground plane (only allow copper planes) feature to avoid users running into this open knife?
After this is solved, some lessons learned from implementing this could be taken to improve the autorouter.

jonathanhogg commented 2 years ago

@jonathanhogg The example you uploaded is straightforward to show the bug, but it doesn't show why the workaround is impractical. Do you have an example for this? I am asking because a possible fix could still cause the same problem for your use case then.

As noted in my last message on this thread, I've been manually routing all of my ground plane connections since discovering this bug – so the workaround is fine for me. Indeed, when I want more control over the thickness of the connection (generally for thermal isolation) it's more useful to manually route.

The only issue is where I want a more solid ground plane connection than is afforded by a single route and there's not another handy nearby ground connection to draw a second route to. There's no way to draw a connection to the ground plane itself.

NickInTimeFilms commented 1 year ago

Hey all, wanted to follow up with this bug because it is still present in the latest 1.0.0 release and I feel it should be of core concern.

Yes this can be fixed manually, but the point is this is a bug. It's not a useful feature when it isn't reliable, and leads to a nasty surprise when your designs aren't working because a via was missed.

My current workflow is to design everything in the latest release, then save and open in v0.9.3b to properly generate the ground plane connections.

Here's a comparison of V1.0.0 vs V0.9.3b ground plane generation, where 3 vias are missing tabs completely.

1 0 0 ground fills

0 9 3 ground fills

On a different note, I think a successful ground plane connection should remove the rats nest line and count as connected. That way even if the software can't connected a via, you will be notified that there are still unmet connections.

DetonationEMS commented 1 year ago

It doesn't look like a commit has been made in a year so I'm not sure if fritzing has been abandoned. Although I've moved to a different open source alternative, KiCad, I had hopes for fritzing for smaller projects or beginner hobbyists. Looking at the complexity of what you're doing in those photos I sadly would strongly suggest trying KiCad. It has a bit it a leaning curve as most of this type of does. Once it starts to click in your head it's night and day.

Sorry fritzing devs. I really really tried.

KjellMorgenstern commented 1 year ago

It is marked for Milestone "next". That means it is in the list off issues we try to resolve for Fritzing 1.0.1. That version is planned to follow shortly after the current 1.0.0 version, which is already available, but not yet fully rolled out. This week the increased activity after the 1.0.0 release slows down work on the Application code by quite a bit.

KjellMorgenstern commented 1 year ago

@DetonationEMS Commit history can be misleading. For example, I have pushed 7c4fcca right now. Github lists it as 19th June 2022. The commit was authored on Thu Dec 2 18:21:06 2021 +0100 however. (It didn't make it into any release before because of side effects and lacking tests) but is now include in 1.0.0 For Fritzing, it could be accurate could be to look at the issues, and sort them by recent activity.

DetonationEMS commented 1 year ago

@DetonationEMS Commit history can be misleading. For example, I have pushed 7c4fcca right now. Github lists it as 19th June 2022. The commit was authored on Thu Dec 2 18:21:06 2021 +0100 however. (It didn't make it into any release before because of side effects and lacking tests) but is now include in 1.0.0 For Fritzing, it could be accurate could be to look at the issues, and sort them by recent activity.

This is all fantastic news!!! Thanks for clearing that up. I've personally moved beyond fritzing as I said. It was my starting point and rocketed me into what I do today. I think it has the ability to be an incredible starting point for others also so I continue to follow it. I think with more polish fritzing can "bridge the gap" for lack of better words between playing with breadboards and real design. Thanks for the clarification.

KjellMorgenstern commented 8 months ago

Retested various examples from this issue with Fritzing 1.0.2. I think it looks good.