Pretty sure that from when the Emco was a pile of parts, before Steve got it up and running.
Just to keep anyone in the loop that caresâŚ
PyCam seems to be built for either 3d work, or single-layer 2d work. My part has 3 levels (through holes and two steps). I canât find any way to tell pycam, when working with 2d items that different polygons are at different levels. dxf import seems to have a similar problem, in that it seems to follow the contour lines around, but isnât using them for height. Maybe it is a problem with sketchupâs dxf export, though. I havenât tried recreating it in a different cad program.
Using the 3d work only seems to be doing x-y zigzags over the entire part. The problem with this is if I am using something like a .5" endmill and have a .555" hole in the middle, there isnât much chance of the toolpath lining up perfectly to drill that central hole. Maybe there is a direction setting someplace that I could tell it to use a spiral, but I canât imagine that getting all of my holes right either.
Sketchucam doesnât do 3d either, although it does have an âoutput 3d gcodeâ checkbox, which I havenât figured out what it does. The interface only seems to let you select 2d polygons to do the cuts, though. It does, however, have a method to join multiple gcode files. So the tutorials I have seen draw multiple 2d layers for each of the series of cuts, and then join those. If I could figure out how to tweak out the height and depth in pycam, I could probably do the same thing, but would have to find an external joiner and such. At least sketchucam is a single workspace. However, it wonât work. My first cut is a shallow round pocket. The toolpath appears that it will do this by making one pass around the outside edge, and then x-y zigzags for the rest. But when I generate the gcode and it loads into a gcode plotter, it is simply a square cut out with x-y zigzags. No circular first pass and the zigzag doesnât even have different length paths to indicate that it might do a circle. Seems like a bug.
Iâll try blendercam tonight, but since it is billed as âartistic camâ, I imagine it will have the same limitations as pycam, in that it will do x-y passes over a 3d object. If that is the case, Iâll go back to pycam and try cutting down each step myself, tweaking the height/depth settings, and find a joiner.
I probably could have learned gcode and programmed this manually by now, and may try that that soon.
Something like featurecam seems to be the way to go, where I can point out each individual âfeatureâ and generate toolpaths for it. I havenât done anything with the spaceâs network. Is the jump server and featurecam available externally with a VPN connection, or do you have to be at the space and on the internal network to use it.
I did just check autodesk fusion again, though. I need to find their full license agreement; the education page says students and teachers, but the footnote implies just research and development for non-commercial stuff also qualifies. I may be able to use it without having to lie about being a student or getting one of my kids to sign up. Software and cloud-based services provided without charge to Education Community members may be used solely for purposes directly related to learning, teaching, training, research or development and shall not be used for commercial, professional or any other for-profit purposes I would fall into the âresearch or developmentâ group, but I donât know what their definition of âEducation Community memberâ is.
Can you export your three different levels as three different dxf? files and have pycam generate g-code for each separately?
You donât always need, or really want, a single gcode file to do all of the machining on a part. You can break them into separate operations and treat each differently; ie. different tools, origins, heights, etcâŚ
Featurecam will require the set-up and storage of tool cribs (or something like that) for the device your generating g-code for. I am not sure if the software is set-up to allow you to save such changes under your ACL account or if they simply disappear when you log out.
Jast, Most of that stuff has already been done or set up. There had been a grand plan to have a CNC cart and several devices that used a âuniversal plugâ so that the controller could be wheeled around. The Emco was pat of that project. That project effectively died and I foolishly noticed all these parts and realized we could Frankenstein the Emco and get it working. I had intended to make it work and then wash my hands of it⌠but, as it turns out, that was never going to happen. Anyway, I got busy so I never looked at it much. I only recently learned that it has a backlash issue and, more out of curiosity, decided to look into it. I have realized it is a much better device than a lot of newer Chinese build mills. I would like to see a more powerful and faster motor someday, but other than that I wouldnât mess with it. Bottom line is that I used the parts we already had so I donât know if they were purchased from the funded under the âto doâ list of if they were funded (more likely) from the CNC cart project. OK Iâm rambling. Iâm still experimenting with feeds and speeds so we can have reliable set like we do for the Haas, and after that I invite anyone who sees a way to improve it to jump in and go for it.
Thank you Steve. I wanted to update the To-Do list, as I know almost nothing on itâs in scope any more. That one appeared obviously out of date, but I wanted to ask instead of just removing it.
It is no longer on the âto doâ as far as that list is concerned.
I appreciate your attention to this guy. Several folks have, I think, come to similar conclusions as you, that itâs actually a pretty quality piece but suffers from inattention and lack of knowledge. Maybe with your help, itâll get a new lease on life and churn out some good stuffâŚ
I started doing this last night, and it looks like it will work. I used the SVG file instead of the dxf, though. Itâs easier to take the individual 2d polygons than to try to split the 3d object. I use the table as z0 so that it is the same for each piece. In pyCam, you scale your svg file to whatever total depth you want, so my first pocket was scaled to .234. Then, to make the gcode come out as it being cut from the top of a 3/4" part, I shifted that .507z. This made it appear in pycam that my workpiece was floating, but it settled the height/depth-of-cut stuff. I got that pocket, the large center hole, and one small hole done (and then redone, because I found I have to offset the paths for the cutter diameter manually) before pycam locked up.
For the small hole, pycam didnât like offsetting a .13 (pycam rounds) endmill .06 while doing a pocket. I finally got it working, and I think it was because I turned off pocketing so it would simply follow the circle and do a single circuit. It should have calculated that on its own, but didnât want to, apparently.
Anyway, I saved off the gcode for the first 2 parts, but will have to redo the small hole once I reboot. I havenât found any way to load the gcode back into pycam so that I can see the new parts in relation to the parts I have already done, so Iâll probably have to find that 3rd party plotter, but that shouldnât be a problem. If anyone knows of a good one, let me know, especially if it will do simulation and detect gouges. I doubt I find that for free.
So, overall, it looks like pycam will work, at least for this side. Thereâs no interference with the pockets on this side, but the flipside will have âtowersâ that have to be avoided. I think itâs just a âtoggle directionâ click and let it pocket the outside of the towers, but I donât know yet. Hopefully, Iâll get up to the space this weekend to try at least the first side in wood.
I posted part of this over in the resurrected Status of EMCO CNC mill thread, but Iâll post it here with more info as wellâŚ
I went up and played with the emco last night, and everything worked great. I couldnât find a collet for the 1/8" endmill, though. And the endmill I found was down in the purple drawers, so Iâm not sure whether that is the one you use, @steve_a, or whether the one you normally use is still in its collet somewhere. Does you know where that is? Also, do you know why the 1/4" endmill has a âpolyprinterâ label on it?
The inkscape-pycam workflow worked fine, and the gcode was basically great. I think thereâs a measurement issue, but I donât know whether that was my fault or pycamâs. Iâd have to dig back into the model and gcode to check. I also didnât have much overlap (possibly none). It may be that it is set right for aluminum, but not enough for wood, or it may be that it really is set at 0 and itâs a pycam setting I forgot to modify.
I tried blendercam, but only enough to load it and remember how much I disliked blenderâs interface. (Maybe itâs great, but it takes getting used to for sure.)
I did play with MDI to test some gcode that I was wondering about. All of the gcode I have managed to get output (I never got featurecam to output anything) doesnât do a true circle. It may be that with all of the conversions, pycam and others donât know whether you actually drew a circle, or whether you intentionally drew a 10,000 sided polygon. Although, you would think with inkskape generating svg vectors and pycam using those that it could say for sure itâs a circle. Anyway, for a circle of any size, the gcode I got was several pages long. There is, however, a gcode (g2 and g3) to tell the controller to draw a circle or an arc. When I found it online, I was wondering if it was a newer command that may not be supported, but my MDI testing shows that it is. This was the only thing keeping me from just programming my own gcode generator; I didnât want to have to deal with calculating arbitrarily sized sides of a polygon, especially since that length should be the unknown minimum step size of the machine.
So instead of using inkscape/pycam, Iâm probably going to write a few routines in c# and generate my gcode that way, using the arc commands to pocket out my circles. If anyoneâs interested in that, let me know and Iâll send you a copy when I verify that the gcode output is actually useable.
OK, OOPS⌠I think the other 1/8"collet is actually some other size. There had been a drill bit in it and I didnât really look at it since Iâm not to drilling yet. My bad. Not sure why the polyprinter label is on that 1/4" endmill. That particular endmill is in pretty sorry shape. Not sure why but I do know that I didnât do it! As far as the collets go, Bryan is going to order a full set so we should have more options. The set I recommended has a 1/8" so it will come at some point. I have to admit, I have been bringing my own end mills to do testing. I have kept them with me so that I can know what they have been through and if something happens I can at least know whether or not the condition of the endmill was a factor.
I cut some parts yesterday and after reviewing my CAD and g-code determined that there is still an accuracy issue. about 30 mils worth on the X axis. I did more on line searching and had an idea about it. I just got back from pulling the X axis lead screw and so the mill is currently down for repairs. I needed a metric tap to clear out the threading on two of the parts. I just finished doing just that and the difference is significant. I plan to do the same for the Y axis and I should have it back up by tomorrow afternoon. Not sure if that is part of your accuracy problem but I wouldnât do a lot of changes just yet.
I have been using G2 for arcs and it has been working. I am using sheetcam and a Mach2 postprocessor if you have a Mach 2 option that might solve that issue. I have suggested to Bryan that a FeatureCAM profile for the Emco might be useful and since the space has a license and it is available for use with the Haas, then anyone can use it. However, that means re setting the Linux EMC2 program for imperial. Hope you are not wedded to metric but it would actually make a lot of sense.
Oh, I will leave endmills in the plastic container. These are solid carbide, sharp and should make life easier. There will e 1/8", 1/4" and 1/2".
I did find a 5/32" collet that was in a slightly different style holder in the bottom purple drawer. I was hoping it was 1/8", but it wasnât. I do think there is a 1/16" collet and 1/16" ballnose endmill. I donât think it is long enough to drill the holes I need, but I could use it to start the holes and then drill by hand later (I have to tap afterward hand anyway).
I was using imperial yesterday in the gcode, but I did notice that the interface still shows metric. I briefly glanced around for a setting, but didnât find one, so I just ignored it. As to accuracy, I havenât checked today (especially since I still havenât bought an analog caliper and my digital battery is dead), but it looks like the circle is round, and the problem is probably in my generation somewhere. Itâs possible that it is slightly elongated, but not enough to account for what I was seeing, I donât think.
In EMC under âViewâ there is an option to show in Inches.