[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]

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]

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]

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.

[samco]

In emc - you can set the % override limit to whatever you want. (it is an INI setting.) It will still only override to whatever your maximum settings are. (it will never go over your max axis and traj ini settings)

[DrStein99]

When I did the tests (and I will repeat again; which were very detailed studies over the course of months), I definately included setting the maximum velocity and acceleration to way below the systems maximum. The motors stall and error when I play with the fro above 100%.

I am certain that EMC2 isnt perfect and also has flaws and drawbacks; simply just because it exists. And I wont know if those problems outweigh the problems with Mach until I test and start using it. But I am trying to gather info.

So if I can set the FRO in EMC to a maximum, and by going to that value the motors WONT randomly move all over the place - UNLESS the speed/feed pushing hardware limits, then that right there answers one of the mysteries.

---
So about the encoder and joystick; I understand hooking up encoders, pushbuttons and switches to the parallel port, of course. How about configuring joystick interfaces?

-Erich

[Big John T]

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 can relate to your frustration even if didn't build 3 machines. Testing can drive you nuts especially if the software is faulty.

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.

My thinking differs here. You (the operator) should never be able to run the steppers/servos/machine faster than possible. Reaching the programmed machine limits should not result in a failure. Again just my humble opinion. Being an OEM and building machinery for a living if I turned out a machine that the operator could break just by pressing a button or twisting a dial I'd be out of work in a heartbeat.

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.

This indicates a problem with the program and should not happen in any software that controls machines IMHO.

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

I was thinking of making parts not sculptures thank you for increasing my horizons on this.

John

[Big John T]

When I did the tests (and I will repeat again; which were very detailed studies over the course of months), I definately included setting the maximum velocity and acceleration to way below the systems maximum. The motors stall and error when I play with the fro above 100%.

I am certain that EMC2 isnt perfect and also has flaws and drawbacks; simply just because it exists. And I wont know if those problems outweigh the problems with Mach until I test and start using it. But I am trying to gather info.

So if I can set the FRO in EMC to a maximum, and by going to that value the motors WONT randomly move all over the place - UNLESS the speed/feed pushing hardware limits, then that right there answers one of the mysteries.

---
So about the encoder and joystick; I understand hooking up encoders, pushbuttons and switches to the parallel port, of course. How about configuring joystick interfaces?

-Erich

In a nut shell EMC2 will not go past your limits in your INI file no matter what you do...

The Joypad is easy and there are several ways to get that done. The way I did is documented here:

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

John

[Big John T]

samco how did you do that?

I guess I don't know everything about what I don't know yet...

John

[samco]

easy as pie MAX_FEED_OVERRIDE = 1.2

1.2=120% so 4.0=400%

http://www.linuxcnc.org/docs/2.2/htm...LAY%5D-Section

samco how did you do that?

I guess I don't know everything about what I don't know yet...

John

[Big John T]

I know I know RTFM! LOL

Thanks
John

[neilw20]

I was using Mach3 controlling a SX3 with a 600MHz HP computer fitted with 1/2 G Ram, running XP SP2. I experienced occasional pauses at any feed rate, and tracked it down to the low level driver emptying the queue because the CPU was off in the weeds doing something else, and was not keeping the queue charged. If the queue gets emptied, all axis movement stops, and if the axis movement was fast enough the abrupt stop can cause loss of steps.
That said, just the act of using the mouse to change the feedrate with the +/- keys can break the bank. Clicking on a new place on the green bar seems to cause the least amount of problems.
I have since upgraded to a 1.4GHZ computer form a later junk pile, using 1/2G RAM and Win2000 (which does not go and do stupid unstoppable XP weed munching) and can do anything with the FRO now.
One thing that still gives grief, and this is a software stuff up, not the queue being emptied is if you hit the to pause, the current motion may be in the queue, the machine stops as requested, but when you hit cycle start, it MIGHT move too fast to the end of the move that was executing when paused. Great way to kill tiny cutters. I only ever stop it while cutting air, or sprinkle liberal M1's in the code so that it can be paused. I use very tiny cutters quite often.
Some don't do's with
Never pause during a peck drilling cycle
Never pause during a circle.
If you have to pause very close to the end of a move.
Another thing that helps with FRO load, is disabling graphics display, and any other CPU intensive operation, like a camera view or sound.
Another thing that will screw up the queue feeding is CAM generated sequences of vectors all in the same direction like:
G1 X2
X2.2
X2.4
X2.6
... etc (Thats really dumb code generation)
Like as though somebody used their old dot matrix algorithms.
Should be:
G1 X2
X2.6
...
What CPU/RAM/OS combination are you using.
Beware of overheads caused by badly driven video cards.
If your mouse movement is jerky that's a sign of problems.
Maybe you need to run the Mach3 speed diagnostics.