New Eagle BRD widget features released courtesy of Ray Kholodovsky .

New Eagle BRD widget features released courtesy of @raykholo . All layers of a board can render now. Still some work to do on flipping, but it’s looking good.
https://www.youtube.com/attribution_link?a=jiU2yGyfkYI&u=%2Fwatch%3Fv%3De8bzxPg-KVE%26feature%3Dshare

kudos! @raykholo

@Anthony_Webb we would love to get you more involved in the PnP work that Ray, Frank, and I are doing. If we can take the Eagle BRD import to the next step for generating pick and place as well we really have a nice toolchain for workflow.

@jlauer I’d love to help where I can. I’ve been exploring doing OpenCV magic in the browser. I’ve learned that much of the magic of PNP is made possible from really great vision processing.

@Anthony_Webb Funny you should mention this, John and I briefly discussed it this evening. My take on it is similar to that of Slic3r: that it has been developed and refined for years and trying to port a basic interpretation of it to run in the browser would be awesome, but it would be undoing all that work. It would also not be conducive to thin clients that may not have the horsepower available for this type of computation. I see it more as an API on a server somewhere that we make a call to, or the call could be to a Pi that is local to the machine. Either way, I’d love to see it all working in the browser, It’s just that those concerns come to mind and I’d love to be wrong about them. Making an OpenCV API is no easy task either.

You’ve got a good point @raykholo Probably better written as a REST call to a service that can perform various tasks using the camera plugged into its USB port. This would restrict the machine hosting the service to have enough horsepower to collect the image and process it, firenodejs has proven this can run fairly well on the latest versions of raspberrypi.

Could almost be the same principle as SPJS, so it’s easy to decouple and being run on a beefy machine. But for example to find orientation and position of parts lying in pockets for single parts, the power needed would be reasonably, as you know the rough position of the pockets and you could make a run for getting position and saving that, so even with less horsepower you’d only need more time.

Very nice job @raykholo ​​​​.
I was thinking about the possibility of adding a reference drill points in order to align a board when flipping out to the other side. This can be a checkbox followed by X and Y distance values input field from board edges allowing a user to use or not use this feature. Even if the board is not going to be flipped to the other side, which is @jlauer ​​​​ approach with single layer boards, reference drills can be used to place single layer copper clad into exactly the same position. Having this each layer can be processed on the X-Y positive only and you don’t need to bother with ‘moving’ bottom layer g-code to the X-negative Y-positive part of the coordinate system.

I agree @Anthony_Webb ​, rest calls to service for doing vision work is best and easiest as well. There is quite some lag though if the machine is not the same.

In drill feature, i generate this black circles for every hole. The g-code will generate of the center of this circles :slight_smile: That’s the point why you can’t generate correct drills at the flipped board. But IMHO you can mill and drill the top side and mill the Bottom side, then u get also a well board.