Ok forgive me if this is too basic or if I’m not answering the question. All the CNC machines are a three step process. CAD, CAM and then the actual code load and cut. CAD, of course, is where you design a part. CAM is the program that takes that part and allows you to enter all the parameters I gave in the last message regarding chip load, speed, feed and depth of cut. Within the CAM program, there will be a place that you select a post processor that will actually generate the G-code file. CAM programs come with a number of post processors and occasionally, someone will post a compatible post processor on line in a CAM specific forum. Sometimes it is specific for different machines and processes. For example, I use this same method for generating code for a plasma cutter and the biggest difference is that I have to select plasma “tools” (mostly speed and height differences) and a post processor in CAM to generate G-code for the plasma cutter. The WIKI page doesn’t mention CAD and CAM because the parts I wrote were only concerned with the mill and computer. I have experience using CAD and CAM but there are people with much greater knowledge and so I stayed out of that. Hope that helps.
Yeah, that explains it. I hadn’t gotten the tools set up or a toolpath that I liked yet, so I hadn’t actually tried to go to the next step and generate gcode. So I hadn’t run into that. Hopefully, tonight, I’ll get a 2d version of my model done so I can try that with pycam and get better toolpaths, then start looking for a post processor.
PyCam isn’t sophisticated enough to have a ‘post processor’. It is designed to produce code form EMC (now known as LinuxCNC) so its g-code can be fed directly to the EMCO with LinuxCNC. You only need to select (or obtain) a post processor for more sophisticated CAM packages that support multiple dialects of g-code.
From the PyCAM site: “PyCAM is a toolpath generator for 3-axis CNC machining. It loads 3D models in STL format or 2D contour models from DXF or SVG files. The resulting GCode can be used with EMC2 or any other machine controller.”
Ok, so with pycam, I’m good. For future reference, what file format or whatever would a post processor normally take as input? The toolpaths have to be generated by the cam software, right, otherwise there’s nothing for a cam to do? So do the toolpaths get saved in some format that isn’t gcode to be imported into the postprocessor to create gcode, or are all post-processors built-in (not command-line or something) such that they don’t take a “toolpath file” but instead only work as the parent app generates the toolpaths? I would guess that most post-processors are plugins or something, but when I was working with linux, several years ago, even most of the “plugins” were really command-line driven apps. The parent app would generate a temporary file and hand that to the plugin app, or sometimes pass the data on the input stream. This is compared to the apps I’ve done in windows where the plugins get their data directly from the app down some COM call or other object-oriented procedure call.
My experience with CAM software is currently limited to the space’s VCarve and FeatureCAM. In both cases there is no intermediate file. You select the post processor from a drop down menu before you convert your tool paths to g-code
[quote=“programmertim, post:15, topic:4247, full:true”]
The toolpaths have to be generated by the cam software, right, otherwise there’s nothing for a cam to do?[/quote]
Yes, this is the primary purpose of the CAM software.
I have seen a few post processors that take g-code as input and output a slightly different g-code as output. Essentially translating dialects.
Plugins (or simply built in library) seems to be the way it works on the two Windows software mentioned. At least from the user perspective. Linux doesn’t really have a similarly robust CAM package (as far as I know) so there isn’t really a comparison.
If such a package existed for linux, I would expect it to run a a command line pipe that took g-code input and provided a modified g-code output.
I am having continuing success with the Emco. I am almost ready to put together something that counts as training. I’d like to wait until I receive a 1/2" collet but I believe I can start putting together some kind of information. I’d like someone to advise me what they think would be appropriate. I have thrown a drill vice on the mill just to do my tests and it works …OK. So I would like to talk to someone that is part of the “powers that be” and find out if we can get an actual milling vice and I suspect some decent bits would be nice as well. I THINK the Emco has a problem with horsepower from the motor. I thought I once heard that a VFC, like the one we are using, doesn’t deliver enough power to achieve full HP. Still, Id like to get people working on the Emco and at some future date look into upgrading the motor. Still, I’m pretty happy with the results I’ve gotten. So, anyone have any thoughts?
Much excitement. Many thoughts.
Probably nothing helpful, except to call @bgangwere 's attention to this, since I believe the emco is part of the machine shop purview. If I’m wrong, hopefully Bryan will correct me. It strikes me the committee chair for the “owning committee” would be best equipped to be helfpul in guidance and direction.
Blender cam is a pretty nice tool as well and it has a LinuxCNC post processor.
Soooo… has the “retrofit” that was shown funded under the “to do” list already done on this mill?
Just wondering if that’s waaaaaay out of date.
I suspect it is.
https://dallasmakerspace.org/wiki/Emco_Mill_Retrofit
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.