Some samples from upcoming version of Eagle BRD widget, I added lots of features,

Some samples from upcoming version of Eagle BRD widget, I added lots of features, I feel like I need to write a user guide to explain all of them, here are the main ones:

  • Tabs (Board holders) … works with G1, G2 and G3.
  • Support layer 46 - Milling.
  • Vias & Pads are rendered accurately based or Resting parameters.
  • GCode Tab rearranged in multiple tabs.
  • Milling board dimensions with multiple tools based on wire width.

You can check the new features on http://www.chilipeppr.com/ameen
I still have few things to do before merging this update with main project.

Wow! This looks amazing. Oh my god this is getting gorgeous. You up for doing a quickie video? Also, those circuit boards you’re using are really rad.

Thank you, incredible work. Looking forward to getting back to milling PCB with your improved code.

Three of the boards in the screenshots are not real designs, I just made them to test my code, the forth one is a sample I downloaded from http://cirqoid.com, this board gave me the idea of using layer 46 and open dimension paths.
I’m designing a board to use as a show case for all new updates/features.

Send me the brd file when you like it so I can add it as a sample brd in the file load menu because I think it’s worth having a board like that for folks to load and play with to see how cool the widget is now.

Sure, I’ll send you the brd file once I finish it.

Awesome, great work. Can’t wait to try it out.

Hi @ameen.nihad

just trying out the import widget and noticed that the renderer is making some odd choices.

See below for an example - identical pitch headers and the renderer is not isolating some headers whilst managing others.

another anomaly @ameen.nihad

use case: make a board with a single 1 pad header and the import it.
If i do this the widget is only allowing me one layer, despite the pad evidently being on both top and bottom layers.

@Justin_Adie It looks like the missed trace is connected to ground and you have a ground plain, this is why the trace is ignored, isolating this trace will disconnect it from ground … if that not the case try disabling the option (Avoid Tracing Board Dimensions) under Gcode -> Traces tab.

The widget populate layers drop down list from signal wires, your board of single pad has no signals therefore list of layers should be empty, I recently updated the code to include Top layer when there are no signal wires.

On the first board? There is a ground plane but those pins are not connected to it.
Turning off the tracing board dimensions doesnt make a difference. I will post the brd file if you’d like. Deflating the milling path brings the isolation back.

The point is that the pads are the same top and bottom. So if the rendered can find an isolation route on one pad it should be able to find it on every pad.

Thanks on the second point. It is an unlikely scenario but pads are technically on both layers! If you only have single sided boards it is not an issue. But there is an obvious risk of shorts if you use double sided even for through hole applications.

I have had another issue where the renderer is forcing two passes for every isolation trace (doubling the milling time). This may be from ground planes (polygons). Is there a way to suppress this?

Please post the board file and I will check it.
The two passes issue is indeed due to polygons, this is a known issues from the early version of the widget, I might tackel it in the future, for now I don’t have easy fix.

thanks. here is the board link https://dl.dropboxusercontent.com/u/194358/dueShieldPowerMonitorv0.4.brd

it was supposed to be a 10 min job to create a throwaway shield to do some solar panel recharging measurements. but ended up breaking eight drill bits and taking two evenings … i’ve gone back to a breadboard!

i have some holiday coming so will take a look and see whether there are any easy wins for the polygons. perhaps keeping a register of milled areas and deduping before writing the gcode?

This requires some debugging, I see that all pad are in one package, there might be something wrong with the package itself, I can’t verify that as I don’t have the library.
I tested the board on xpix workspace, the result is the same … so it’s not my fault :slight_smile:
A workaround is to reduce the inflation of milling path to the default 0.35 mm or lower, what is the diameter of you bit? you should set this number to half the bit diameter.

Sure. Workaround is easy. The thing I’m finding difficult to understand is why identical pads are being isolated differently. There is something awry in the algorithm I guess.

I can post the lib if you want. It’s just a due board with a whole load of pins and pads removed.

@ameen.nihad ​ re the polygons is a different approach to give the user an option not to isolate ground pads and pins and not to render polygons? It is late here and I’m tired so I may have missed an obvious logic flaw and have not had time to visualise a render without a polygon and check for differences. Of course this only works for gnd polygons but I guess that is the most likely.

@Justin_Adie I recreated the pads issue using similar shield that you are using, apparently the widget considers any unconnected pads, pins as if they are on the same signal, that’s why some of the pads get merged. If you hover over any of those pads you will see in the popup windows that signal name is "undefined’ and all those pads will be highlighted.
Please report this as an issue on github, I’ll look for solutions.

reported against the main branch of the eagle brd import widget (your forked repo does not have issues enabled).

@Justin_Adie NC Pads and Layers issues are both fixed.

@jlauer I think I broke the Solder Mask feature with the latest updates to board dimensions, I don’t know yet how Solder Mask is related to ClipperDimensions array, I changed this array by removing duplicate vertices, but I believe it’s still a valid clipper path … any ideas to help me fix this?