Change in behavior with the Eagle Widget.

Change in behavior with the Eagle Widget. I milled out two boards yesterday and discovered the two issues.

  1. Holes were not milled out to proper diameter. I like to mill with a .6 bit and let CP mill out to a larger hole where necessary. Today this did not happen. It appears that any change to to the eagle widget requires a clicking on the “Render” then clicking on “Send Gcode” while the send Gcode gave me the layer milling it did not give me the hole milling. I’m pretty sure this is a new behavior (see images).

  2. As part of this job I am milling 6 and 8 pin headers. It appears that the bit did not complete the circle and left a very small sliver of copper on the board (see image). I don’t know if this is related to the above problem. If needed I can try milling another board but I need to pick up some copper first.

Has anyone else seen this? If clicking “Render” prior to clicking the “Send Gcode” is a hard requirement after any changes. I suggest that clicking “Sending Gcode” automatically invoke a “Render” first. I don 't see this as a huge issue we just need to confirm clicking “Render” is a must going forward.

Thoughts?

@Michael_Omiccioli Yes, you need to click “Render” after changing any settings and before sending Gcode to workspace, I’m planning to make some adjustments to indicate that current Gcode is not valid and user need to click “Render”. I don’t prefer to add functionality of Render to Gcode button because with complex boards the Rendering takes long time.

Regarding second issue, I guess those pads are not connected to any wires, in this case pads are treated as if they are connected to same signal and that causes adjacent pads to connect if inflation if high enough, try rendering same board with same setting on http://www.chilipeppr.com/ameen and let me know if you have the same issue.

It’s always a good practice to examine the gcode before performing the job to make sure you get desired results.
http://www.chilipeppr.com/

Ameen, having a visible indicator will work well, it removes ambiguity as the state of the Gcode.

I will give it a try and let you know how shortly. Thanks for the great work.

Ok ran a new mill and the “Render” solution correct all of the issues I had. Even the sliver issue, I did use the version of CP that you suggested worked like a charm. I did run into one other issue but this may be my issue on settings within Eagle. The pads are bigger on a mill I ran about a month ago versus the one I ran today. But that might be because I had not set the netconfig settings properly.

Notice the pads on the left are smaller than the right. My setting in eagle was blank even though I had the traces at 16mils I think pads were milled with less.

Ameen,

Your new version looks great , the tabs worked well too. Can I suggest just have one send Gcode and one render button at the top. Get rid of the other redundant ones in the submenus to save space. All the new features are great but the widget is getting busy so reducing unnecessary object would be good.

I have other suggestions if your interested.

Sure, I’m open for any suggestions.
@jlauer ​ do you agree on removing the extra ‘Send Gcode to Workspace’ buttons?

Pad size should be more accurate than before, previously it was 2x hole size, but now the widget uses Restring parameters to calculate pad diameter, and pads should match the size you see in Eagle, if you spot any difference please post the details with sample board on github.

Yeah, I think removing redundant buttons could help clean up, but for folks new to the widget, will it be self explanatory?

The help boxes when hovering over the buttons is very useful. And hi-lighting the button in some way to indicate that new Gcode needs to be sent to the workspace will help. When Ameen is ready I can make a video that shows the basic process of using the Eagle Widget with all the new features to mill a circuit. Especially since the video’s I made before are out dated with the mirroring ability.

One of the techniques I used in later widgets to figure out if a Gcode regeneration was needed was to simply add a class to the DOM element like “needs-regen” and then you just do one Jquery call on $(’.needs-regen’).on(‘change’) and then just mark some flag as dirty. In earlier versions I had more code on each element and that got heavy. What I always thought would be cool is to regenerate the rendering and Gcode in a sub-thread using the new Javascript threads, and if any new dirty happened, cancel the thread and restart it from scratch, but that’s so hard to do and to debug it’s barely worth it.

I agree it will become complicated and will be more work than it’s worth. Getting an indicator and clicking a single button is not a big deal. Not sure about others but I do hit Render more than once anyway as I tweak settings. Certinly don’t want processing going on when I’m not done making changes. As long as the user knows a Render is required that should be fine.

I made some changes to UI, and the feature of Registration Holes is almost completed, I just need to add data validations, please read the description under registration tab.

http://www.chilipeppr.com/ameen