Bottom Copper layer is displayed on top of Top Copper Layer

[Georges760]

With a 2 sides PCB, the eagle's bPlace layer is well drawn on the bottom of the 3D PCB, but the Bottom Layer (copper) is drawn on the Top Layer.

[follower]

Thanks for your report. Are you able to provide screenshots and/or an example file demonstrating the issue?

Do the included examples (e.g https://github.com/Omniblox/Eagle-Loader/blob/master/examples/complex.html) display correctly for you?

[Georges760]

Hi,

on the complex example page, when selecting the "Thing", you can see in the middle of the bottom layer a silkscreen mark saying "I2C PU" and a rectangle around the component, there is also the copper route going to this component, but not the 3 soldering pad. And if you look the other side (Top Layer), you can find these 3 solder pads on a wrong layer.

Thanks,

Georges

[follower]

Thank you very much for your further explanation with one of the built-in examples, it was very helpful and I see exactly what you mean now. :) The issue is also visible with the FTDI/VCC jumper footprint.

For our future reference, here is a view of the bottom side of the Thing board with the affected areas highlighted:

And the misplaced footprints highlighted on the top side:

For comparison here are photographic images of the actual board from the SparkFun site (https://www.sparkfun.com/products/13231):

Thanks again for your helpful report, we'll track progress of a fix here. We'd welcome any other feedback you might have from using the library and appreciate you taking the time to file this bug report.

[Georges760]

Let me return you the thanks, for this very impressive project, I love it a lot.

Actually I wanted to try to fix it myself and push it to you, but I am not good enough in JS...

[follower]

I'm a new addition to the development team but I'll pass on your appreciation. :)

I'd be interested to know what you're currently using the library for if that's something you can mention publicly.

Appreciate your desire to help with a fix. :)

[follower]

Further investigation of the issue suggests an underlying cause but a test fix has also highlighted other instances of the problem and another issue.

The elements noted in the original bug report are solder jumpers (with a prefix SJ), specifically SJ2 is "I2C Pull Up" and SJ4 is "VCC / FTDI power selection". It seems SJ1 may also be affected.

The SJ elements are of the form:

<element name="SJ4" library="SparkFun-Passives" package="PAD-JUMPER-2-NO_YES_SILK" value="" x="35.56" y="3.81" rot="MR0"/>

I noted the SJ elements don't specify a layer and the particular elements with the issue all had the M prefix on the rotation (rot) attribute:

<element name="SJ1" library="SparkFun-Passives" package="PAD-JUMPER-2-NC_BY_TRACE_YES_SILK" value="" x="35.56" y="6.35" rot="MR180"/>
<element name="SJ2" library="SparkFun-Passives" package="PAD-JUMPER-3-3OF3_NC_BY_TRACE_YES_SILK_FULL_BOX" value="" x="26.035" y="11.303" rot="MR180"/>
<element name="SJ4" library="SparkFun-Passives" package="PAD-JUMPER-2-NO_YES_SILK" value="" x="35.56" y="3.81" rot="MR0"/>

The SJ3 element doesn't seem to actually be a solder jumper--or possible is a dual solder/through-hole jumper:

<element name="SJ3" library="SparkFun-Passives" package="PTH-JUMPER-NC_BOTTOM_NO_SILK" value="" x="35.56" y="6.35" rot="R180"/>

From previous research I was aware that the M prefix is used to "mirror" a component for placement on the bottom of the board.

Further investigation revealed that it appears that mirroring is handled by the method EagleBrdRenderer.Layer.assessElementCandidate():

                ...
                // Flip layers on mirrored elements
                // NOTE: This might not catch everything.
                // I've only seen it used for silkscreen elements.
                if ( el.elementParent && ( new EagleBrdRenderer.AngleData(
                                el.elementParent.getAttribute( "rot" ) ) ).mirror ) {
                        oldLayer = layer;
                        swapLayers( layer );
                }
                ...

So, it turns out mirroring is not just used for silkscreen elements--a possibility mentioned in the existing comment.

As a first attempt to fix the issue, for a basic two-sided board it seems this patch to swapLayers() results in the pads being placed correctly on the bottom of the board when the element is mirrored:

                swapLayers = function( layerOriginal ) {
                        switch( layerOriginal ) {
+                               case 1:
+                                       el.setAttribute( "layer", "16" );
+                                       layer = 16;
+                                       break;
+                               case 16:
+                                       el.setAttribute( "layer", "1" );
+                                       layer = 1;
+                                       break;
                                case 21:
                                        el.setAttribute( "layer", "22" );
                                        layer = 22;

(The switch/case block does not currently have a default: block which could be added to trap unhandled layer swaps but due to the way it is called (multiple times per element per layer) it would be very noisy to log such cases.)

With this quick fix patch in place the result is (with original issue areas highlighted):

So, it seems like the pads are now on the correct side of the board, however when comparing the result to a photograph of the board, it seems the I2C PU jumper has extra silkscreen around the pads.

In addition, this fix also makes apparent that the issue was affecting other elements too (highlighted here):

Unfortunately, in the case of the RST and Test Point what should be circles are actually rendered as squares, which appears to be a new issue. (I seem to recall seeing something similar with rendering of fiducials on the SparkFun Red Stick.) The JST battery connector holes seem to render correctly however. (The SJ3 footprint is kinda messy and not easy to see in the product photo, but at a minimum the top side appears correct with the patch.)

Here is a view of the top side of the board with the changes highlighted (The 2nd and 4th from the top ellipses show where the pads aren't mistakenly rendered ):

So, it seems this patch is a partial fix but further investigation is required to come up with a more complete solution. (I also wonder if using a mapping rather than switch/case block might be a helpful refactor.)

Wanted to at least record the result of my current investigation and then leave further work until discussions about prioritisation of it.

[Georges760]

for sure, follower, you know how to fill an issue ticket ! very impressive, never seen that is my developer live ;)

[Georges760]

I just tried your patch, and it fixed my original issue (on my own PCB) ;)

For reference, I am an electronic engineer in freelance, and I coded a website for my customer deliveries, with an automatic export from Eagle, so in one click I export all infos from Eagle and my customer can log in to my website to find their board gerber, schematic, BOM, etc... I planed to add a 3d module by converting the eagle sch/brd infos into a x3d model, then I found your amazing project, so I integrated it in 2h of time !!! Now my customers can also have a 3d preview of the board. If you or your colleague are interested to know more about it, I will be pleased to show you.

[dave5]

I'd love to see your project (i started Omniblox) ... reach out to me at dave (at) omniblox (dot) io

[follower]

Thanks for testing out the patch @Georges760 and reporting that it worked for you.

What were the component(s) that were affected originally? Were all component footprints placed on the bottom layer placed incorrectly?

Thanks for telling us more about your use of the library and enthusiasm for it. :)

[follower]

Further investigation suggests that the "extra silkscreen around the pads" is related to mis-rendering of tStop and bStop in EagleBrdRenderer.prototype.renderSolderMaskLayer() (See // Erase mask holes comment section.)

Created #33 to address this.

[follower]

Main issue fixed in master by #34. Other issues now live in separate tickets as mentioned above.