Ground plane not rendered in current beta
Issue #347
resolved
I attached a gerber source file with a large ground plane, which renders fine in v8.5, but it fails to recognize and render the large plane in the current beta. To reproduce, open the file in version 8.5 and the current beta and see the difference. 8.5 renders it correctly, current beta does not recognize the large ground plane. I tried both, OSX and Windows 10 and get the same issue.
Comments (13)
-
-
reporter
Yes, it is only rendered as an outline. But, I tried to render the large file in gerbv and KiCad and it does fine, so I do not think the file itself is corrupted.
Actually, I cannot provide a smaller file exhibiting this issue, as those other files render fine in both, 8.5 and current beta.
-
reporter
The file was generated by SprintLayout with Auto-Groundplane switched on. https://www.electronic-software-shop.com/elektronik-software/sprint-layout-60.html?language=de
-
This file is made a bit weirdly. Basically they draw a large copper polygon in a positive way and then they draw the spaces between the traces with clear (negative) polygons this way creating the delimitation's between copper features (traces, pads etc).
Which software generate it?
-
Ok. I’ll look on what are they trying to do, I have a license bought some time ago for Sprint Layout 6.0.
-
What is really weird is that loading your file in Sprint Layout 6.0 it loaded incorrectly, drawing the board as a polygon over the actual traces. If I delete this overlapping polygon then traces are shown but without the ground polygon. If even the software that created it can’t import it back …
-
reporter
- attached bitbucket.lay6
If this helps, here is the original SprintLayout File from which the gerber was derived. I also tried to import the gerber to Spritlayout and get the same weird behavior. So, I agree, these files that SprintLayout emits are kind of weird.
But … Flatcam was able to manage this in 8.5, so I wonder if we could figure out what was changed in Flatcam beta that it cannot manage this any more. This would make Flatcam import more robust to weird files.
It would be a great advance, at least for those using SprintLayout out there (and cannot afford more professional CAD software…)
Thanks.
-
- changed status to resolved
- fixed issue
#347- a Gerber generated by Sprint Layout with copper pour ON will not have rendered the copper pour
→ <<cset 0b5073457827>>
-
OK, fixed.
-
BTW, deleting R20 in the bitbucket.lay6 solved the issue with the generated Gerber rendered in FlatCAM beta even before I applied the fix. And to arrive to this …. took a long series of deletions and trials ….
In any case, something was fishy with the PCB file.
-
reporter
Okay, thank you very much. This is very much appreciated. Will try this asap.
-
reporter
Unfortunately, the problem persisted, at least for me. By stepwise deletion and demarcation of certain regions of the layout I was able to delimit the area causing the problem down to U2 in the layout. Here, I noticed that there were two footprints stacked on top of each other, erroneously. I deleted one of them and boom, rendering is fine. The same holds for (similar) U5, but here it did not cause any trouble. Why? I don’t know.
Besides, ?I noticed that python/flatcam throws an error, when rendering is not correct in this case, and does not throw that error, when rendering is correct. Maybe, this could be used to catch faulty rendering due to fishy gerbers.
[DEBUG][Dummy-5] plot --> FlatCAMObj.plot() Data error can only concatenate tuple (not "int") to tuple
Thanks a lot, Robert
-
Hi Robert,
That error is thrown somewhere in the internals of VisPy module which is the Python module used for rendering graphics in FlatCAM OpenGL graphic engine. Unfortunately it’s kind of a black box. Not to say that it can’t be modified/patched but not something I can do. I’m already way over my head with how things are currently (you don’t want to know how much time I put in what you already see as FlatCAM beta) and I’m trying to dial this down but trying to understand the OpenGL things (the things done in “background”) will increase the complexity too much.
But regardless, it is only a consequence of the real problem which is the validity of the geometry.
Good night,
Marius - Log in to comment
Actually it’s rendered only as an outline. Can you please provide a smaller Gerber file that exhibit the same behavior? It will help me debug where is the issue. The attached one has 20440 lines which makes it very hard to use for debugging purposes. Thanks!
LE: Which EDA software generate this kind of Gerber?