emc VS mach - has anyone used both?

[DrStein99]

I have built 3 cnc routers in the course of 4 years (on a small scale) and am now preparing for my next one which is retrofitting a CNC series 1 rigid ram Bridgeport. I started with Turbo cnc and quickly moved to Mach 3, which does the job, but not completely satisfied. I've gained some linux experience in the years and starting to like the system over windows, and microsoft products.

Has anyone else used Mach-3 and switched to using EMC ? Can you tell me about likes dislikes?

Also a quick question - how difficult is it to configure special function joystick devices, and possibly use a Contour-shuttle pro for an MPG encoder / positioner?

- Erich Stein

[andy55]

EMC can control closed-loop servos, so I would use mach only on stepper machines where the cutting loads are small (pcb-router, plotter etc.)

Configuring a jog-pendant or joystick should not be that hard, there are a couple of examples on the web and on the wiki.

[Big John T]

Originally Posted by DrStein99 I have built 3 cnc routers in the course of 4 years (on a small scale) and am now preparing for my next one which is retrofitting a CNC series 1 rigid ram Bridgeport. I started with Turbo cnc and quickly moved to Mach 3, which does the job, but not completely satisfied. I've gained some linux experience in the years and starting to like the system over windows, and microsoft products. Has anyone else used Mach-3 and switched to using EMC ? Can you tell me about likes dislikes? Also a quick question - how difficult is it to configure special function joystick devices, and possibly use a Contour-shuttle pro for an MPG encoder / positioner? - Erich Stein

If I can do it anyone can this is my write up on hooking up a MPG pendant.

http://wiki.linuxcnc.org/cgi-bin/emc..._A_MPG_Pendant

What are you not satisfied with on Mach3? I use EMC2 btw...

John

[DrStein99]

Big John;

I am not satisfied with Mach-3. Though only a few outstanding bugs, one of them I found completely unacceptable -- where change the FEED/SPEED during g-code execution causes steppers to malfunction. A closed-loop system (to me) is also very important - and has taken a big back seat in the Mach-3 world. Also, the developers appear to be taking on some other software projects, which delay fixes and advances to Mach-3.

Windows is a good user interface, of course. I am not a fan for use with robotics, or other crucial timing sensitive applications. I prefer to use a linux system for this type of application and would rather take a chance and try something new. My experience so far building linux systems (used professionally a different environment and purpose) has shown me its more stable, consistent and configurable for engine server related platforms.

-Erich Stein

[Big John T]

Thanks Erich for sharing that with me.

Was the feed changes during short arcs and or lines?

Thanks
John

[DrStein99]

Big John;

I cant say for sure specifically WHEN or WHERE the steppers would begin to malfunction. It started off as a wierd thing - and took months for me to trace down and pinpoint. If I ran a program and then just increased the FEED speed (simply by pressing "+" to increase speed beyond like 5%); then the steppers would just start randomly going MAD.
I thought at first for sure there was something wrong in my setup. Until after MONTHS passed and under every circumstance the problem will repeat and persist - on the router, and also in the test-bench.

I brought it up in the support forums and was told an array of different excuses. The only resolution was either to NOT use the feed-speed increase button above 125%, or to set the feed IN THE G-CODE TO 200% above what your target rate was, and set the default feed to 10% and increase up to 100% - but DO NOT exceed 125%.

This type of function is so basically necessary for g-code control.

[H.O]

Hi,
I'm sorry, I've never used EMC but I thought I'd try to shed some light on this feedrate override thing...

The reason that it is not advisable to go beyond 125% feedrate override in Mach3 is that it is not only the velocity that gets overridden but unfortunately also the acceleration. So if your setup is on the borderline acceleration-wise you may stall the motors when you override upwards.

Feedrate override is a necessary function for sure and IMO it works. I'm not sure (I've only seen a few in real life) but if you look at comercial CNC-controls, do you often see ones where FRO above ~120% is possible?

So, by posting your code with 2X your desired feedrate you can set the FRO to 50% and get the correct feedrate as well as having the possibility to override upwards.

Again, I'm just trying to explain what I think you were "hitting" and why. I beleive that originally the FRO in Mach3 was "locked" at 120% or something like that but people with more "capable" systems wanted "more" so it was increased.

There's not really a problem overriding above 125% if your motors can take it. The fact that the acceleration is overridden too is drawback for sure but that's how it is....

Hope that helps a bit.

/Henrik.

[Big John T]

IMHO there is no reason to go past 120% with feed override. If your system is capable of more then it is not configured properly. If you programmed the G code wrong then you should fix that not twiddle with a slider past 120%...

I can understand how having acceleration tied to feed override and allowing either one to go past the machine limits is a big problem.

EMC2 does not allow that to happen. You set the machine limits in the INI file. The feed override or Fnnn will never go past the limits.

John

[DrStein99]

I pursued the FRO problem with great detail, and guarantee its not a matter of hardware. Months of my time were spent logging results in an analytic manner, with swapping equipment to the tune of at least 3 completely separate test environments.

I understand how the process of the data in a g-code program works with timing the output into a step/direction signal out the parallel port. I also understand the max top speed and acceleration will vary on hardware.

If I run g-code near the top feedrate on a Mach-3 system, and then push the FRO close-to or beyond that limit; makes perfect sense to see that problems will happen. I would expect a failure on EVERY system when pushed near limits.

If I run the same g-code at 1/3 the top feedrate on the SAME system, and push the FRO above 130% -- the motors still error and fail! Even though at 130% FRO the maximum speed and velocity of this system is still at 1/2 of its tested maximum speed and velocity.

For many people; all they want are simple mill operations which each portion is executed less then 30 minutes so it doesn't affect them very much. My artistic sculptures require HOURS of machine uptime - so changing the FRO is as common to me as a throttle peddle to a truck driver. Stopping the machine to reprogram g-code isnt something I feel comfortable with, when feed-increase should just do its job and work.

-Erich

[ger21]

Originally Posted by DrStein99 If I run the same g-code at 1/3 the top feedrate on the SAME system, and push the FRO above 130% -- the motors still error and fail! Even though at 130% FRO the maximum speed and velocity of this system is still at 1/2 of its tested maximum speed and velocity.

Did you set the velocity and accel in motor tuning to 1/3 their normal values? That's what you needed to do for your test.

Also, about 2 months ago some changes were made to the FRO I believe. Have you tried the latest versions?

And btw, the FRO on our $150K machine only goes to 110%.

[cyclestart]

Originally Posted by H.O Hi, Feedrate override is a necessary function for sure and IMO it works. I'm not sure (I've only seen a few in real life) but if you look at comercial CNC-controls, do you often see ones where FRO above ~120% is possible?

I've been away from commercial machines for a while. If memory serves correctly 200% override was common. In addition some controls (conversational types) had the ability to learn (change the program) as adjustments were made. Very handy for proving out a program. There's a reason a tailor built control costs big $$$.

In Axis there's a slider control that goes to 120%. Think that's the limit with all interfaces (not positive). The keyboard shortcuts only reduce feedrate. If there's another way of exceeding 120%, other than the gcode based solution, I'm unaware of it.

Oh yeah, and hands off, DrStein is ours now j/k

ger
What machine? Seems a strange limitation for $150k

[Andre' B]

Every machine in our shop has a feed override to 200% and spindle override to 150% but one older machine which is 120% on the spindle.
They all also have a separate override for rapid moves.
And in the parameters they have different max speed and acc settings for feed rate and rapid moves. The max speeds for rapids are faster then the max for feed rate moves but the accelerations are lower.