I’ve never done any cam, and I’m trying to do something with the emco. I read the emco page that I need to load my gcode into linux cnc, so I’m working on generating the gcode at home. I started with a video on youtube about going from sketchup to gcode (here). I got up to the point of using aspire and found that it is 2000 dollars. Does anyone know of a free app to do that step? I’ve downloaded the evaluation version of featurecam for now, since I read on here that the space has it. So the other question I have is if anyone has a list of the specs I need to put in (such as available cutters and such) to generate gcode that will actually work? I read the emco page, but I think the only thing it gave me was the spindle speed.
As an FYI I don’t have a time frame yet but we will likely be purchasing aspire in the immediate future as soon as jump is rebuilt
1 Like
I suspect FeatureCAM can be configured for the Emco. Would it not be a good idea to train on one tool rather than having many fragmented CAM tools? This would provide a nice path to learn the “hard lessons” on the Emco before graduating to the HAAS.
In the past I’ve used PyCAM for small milling projects. It’s pretty straightforward to use and it’s free.
I was shying away from that one, simply because it didn’t have a decent installer. Just downloading the binaries didn’t let it run right for some reason, probably missing dependencies. But I’ve now found that FeatureCAM’s evaluation version doesn’t allow you to save, so I have to try something else. Maybe I’ll try to install the dependencies tonight.
Please keep us posted on your PyCam+Emco experience. Per zmetzing’s observation, I’d like to get some hands-on CNC experience with the Emco before moving on to the Haas.
AutoDesk’s Fusion 360 includes both 3D CAD as well as 3D CAM. Both student licenses as well as inexpensive monthly subscriptions ($40) are available.
1 Like
Ok as far as speeds and feeds, I’m working on that. All my testing has been on a 1/4" bit and I have had some pretty good success with it. Wood, wax, plastics and Aluminum all melt at low heat so the end mills for these should probably only be two flute end mills. If you are daring and cutting steel, you can use 4 flute.
Chip loads for Aluminum I would try are
1/8" .001"
3/16" .002"
1/4" .002"
3/8" .003
1/2" .004"
I’d use these on the on line calculator at http://www.custompartnet.com/calculator/milling-speed-and-feed
I take the chip load, tool diameter, TWO flute mill bit and the fact that the EMCO spindle is 2000 RPM max. I can plug those three in where they have places for those and it will give me a feed rate. For the 1/4" end mill, I plug in .25" for the Mill Diameter, 2 for the number of teeth (flutes) .002" for the Feed per tooth and skip to the spindle speed to fill in 2000. The line will back fill the cutting speed SFM but we don’t really need it. Anyway, I get a feed rate of 8" per minute and I have had good success with that.
HOWEVER… (you knew it wasn’t going to be that easy, right?) we are still missing plunge rate and depth of cut per pass. For no reason in particular, I am using a plunge of 1/10 the feed rate so the 1/4" bit gets a plunge of .8" per minute plunge rate is not real critical (as long as it is slow) and if your CAM software can do it, I’d ramp the cutter into the piece. The depth of cut I am using is 1/4 the diameter of the end mill so for the 1/4" (.25") I am using a depth of 1/16" (.0625") per pass. You can use up to 1/2 the endmill diameter. ALL of this depends on a number of factors. The rigidity of the mill, the spindle speed and horsepower, the material, coolant and the condition of the end mill. So the calculations you use might be giving you the ideal numbers. The one thing you can find a lot of is disclaimers about all this. Plus, these numbers are for roughing out the part. I haven’t tried a finishing pass yet. For slotting, you may want to slow down by half to start with and maybe speed up depending on how the mill sounds.
I am using SheetCam. I have a license and I like it but the space has a FeatureCAM license and I would use that if you can find the right post processor. Sheetcam license is 110 BSP so whatever that is in US dollars is a really good steak somewhere and I’d keep the money and use FeatureCAM.
I just use the Mach3 post processor and that works perfectly. I think you would use a generic fanuc post processor in FeatureCAM.
Thanks, that should help a lot.
Do I need a post processor? The instructions I found on the wiki were talking about loading the gcode into LinuxCNC on the machine hooked to the emco. I thought that would do the post processing.
@urbite, I’ve got PyCam working (just running, I haven’t actually tried it on the emco yet) by running the “standalone” binaries. It looks like it will produce code that is probably useable, but going from STL output from sketchup, it treats it all as a 3d surface and generates the tool paths in a square grid. I’m concerned that even a finish path will be rough around curved edges and such. To get a finish equivalent to what a spiral pocketing operation would give, you’d have to set the step-over to the smallest increment the CNC machine can handle, if I’m understanding the processes right. I found a video talking about doing things like pocketing with pycam, but it looks like that is based around a 2d polygon drawing. If so, it seems that what I am doing is technically 2.5d (all surfaces are either horizontal or vertical, no slopes) so I should be drawing it in more of a 2d app instead of 3d cad. I haven’t used any other cam software, so I don’t know if this is a common thing or not. @lukeiamyourfather, were you doing 3d or 2.5/2d stuff with pycam?
Tim,
I believe the ‘post processor’ that steve is referring to is the ‘dialect’ of the g-code interpreter. Different machines/CNC programs (Mach 3, LinuxCNC, Grbl, HAAS, FANUC) have slightly different versions of the g-code language that they work with. The EMCO is designed to work with the LINUXCNC version; however, steve was saying that he found it processed g-code created for MACH 3 to work.
Not sure what versions of g-code our FeatureCAM will output. Being a commercial package MACH3 is possibly more likely than LinuxCNC.
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?
1 Like
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.
1 Like
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