Why should i use EMC over Mach3

[dresda]

The only think I want to make sure is that it's not going to take off and ram it's self into the end of the table, that's the only reason I want a closed loop system.

[PCW_MESA]

Why doesn't running a closed loop controller with Mach or EMC make for a closed loop system? What specifically are you missing that you would have with "true" closed loop system?

I've heard this argument before, but I'm not a believer.

The last time we went through it here on the 'Zone, there were no really compelling answers for what the "true" closed loop could do that an "open loop" Mach running a servo drive couldn't accomplish. I think the most compelling thing was you wouldn't have to home the machine after an E-Stop, which wasn't much of an advantage.

Cheers,

BW

A true real time closed loop system like EMC differs from systems that close the loop locally to the drive in several ways:

Perhaps most important is that all servo information is available to the controller (EMC for example)

This means for example EMC knows the actual following error of a servo system, and does not have to rely on a just a fixed error margin like most step/dir drives provide. It can be smart about such things because its has all the needed information, unlike a "blind" step/dir type system.

It also means that is easy to add new real time features to EMC since all control is in one (temporal) place in the PC rather that scattered between systems. Also, if the feature is added to EMC it automatically works with _all_ supported hardware not just external hardware that happens to support the feature.

An example of this issue is Machs inability to use high resolution encoders for spindle synchronized moves without hardware that does electronic gearing.

I realize these are subtle differences but are examples where EMCs system architecture leads to real advantages. You may be able to do most of the same things with Mach, but very likely not as well...

[austin.mn]

One difference that no one has chimed in on yet is the Look Ahead. EMC2 calculates it when you load the GCode and Mach does the calculation as its running. The only time that I have ran into an issue with this is when I needed to cut an engraving file that was 10mb. EMC couldn't even load it, however with mach it just popped up and was ready to go. I haven't had any issues with files that are around 1.5mb, which is still a large file... but that is the only time that I have really had any issues with EMC.

Both systems will do the job for most machines and I am constantly amazed by the creativity by users in both camps.

[chester88]

Actually EMC does look ahead as it runs NOT while it loads.
AXIS (the GUI or screen) goes through the whole gcode and can take some time to do this.
In fact a think there is a setting to speed up the display at the expense of less accurate display ( not less accurate machining )

This could have been what you were suffering from.

[chester88]

I've heard this argument before, but I'm not a believer.

The last time we went through it here on the 'Zone, there were no really compelling answers for what the "true" closed loop could do that an "open loop" Mach running a servo drive couldn't accomplish. I think the most compelling thing was you wouldn't have to home the machine after an E-Stop, which wasn't much of an advantage.

Cheers,

BW

For instance with EMC I can set the following error to anything I want. I can tune the PID. (or write a new PID routine) I could use any resolution encoder. A fellow has written a component included in EMC that will convert different HALL effects schemes from one manufacturer to another (actually a whole lot more then that) allowing one to mix and match motors and brushless servo amps or allow one to directly control the coils of the motor.

Ridged tapping with nothing more then an encoder and a way to control the spindle motor.
Threading using a single pulse or the full encoder resolution.

You don't need really fancy hardware cards for any of this, nor any particular card.

As i said before if none of this is important to you and your open loop motors are sized right it probably will never matter to you.

[cyclestart]

AXIS (the GUI or screen) goes through the whole gcode and can take some time to do this.
In fact a think there is a setting to speed up the display at the expense of less accurate display ( not less accurate machining )

If the delay is caused by displaying the path tabbing to DRO display will allow huge files to load ? The older interfaces still function afaik (?)

I've never tried to load a 10MB file but have occasionally run into a different glitch. If the first few lines of a file are 'stepped through' the file stops dead after executing a few more lines in 'run' mode. It happens rarely and only on certain files but on those files the glitch is repeatable. i haven't run those files recently and the problem may have been caught in a bug fix.

As far as testing both Mach and emc (post #34), wouldn't it be difficult to find hardware that tests both to their best advantage ? It could get expensive.

Merry Christmas to all and avoid the eggnog before noon *
* (if it's blended the same way at your home as it is here)

[Al_The_Man]

Why doesn't running a closed loop controller with Mach or EMC make for a closed loop system? What specifically are you missing that you would have with "true" closed loop system?
BW

What closed loop means to me when using true closed loop controllers is the fact that the processor making the motion trajectory decisions receives direct feed back from devices being commanded.

This means that when using motion control devices that use this method such as Galil motion and others, as well as practically all commercial systems, features such as Variable Ratio Gearing, Electronic Cam, true gearing between axis and spindle when threading or tapping and for slaving two or more axis off a master.

Double feedback loop when using linear scales to split the PID between scale and motor encoder to prevent the often seen oscillation that occurs when backlash exists and scales are used.

Some applications done with Galil are Rotating Metal Shear (Moving Sheet), Dual X axis gantry synchronizing, synchronized Threading, lathe Spindle used as C axis with live tooling, (cyclindrical Interpolation).
I just have comfort in the fact the controller knows where each axis really is.
Al.

[BobWarfield]

So, in addition to E-Stop without Home we have:

Ability to change the amount of follow error before a fault. Of course that's possible for many of the servo controllers one could use with Mach. Not clear how useful it is to change it once it is set appropriately for the machine's purpose and performance.

Al, making the motion trajectory decisions with encoder feedback sounds great, but what does it really mean? What does it amount to in terms of real tangible benefits? Particularly when we have trajectory planners of the sophistication (or lack thereof) of Mach3 or EMC? These are not Fanuc HSM grade controllers.

Mach3 does talk to Galil, you might want to look at what it can take advantage of there. It also threads on lathes which is electronic gearing.
C-Axis can be run on Mach3. Have seen that done. There's one fellow in particular fond of building 4th axes that can act as either a 4th axis or as a lathe headstock and do mill-turn work very nicely. It also looks to me like dual gantry drive sync is not a problem--have read more than one project that did it and Mach3 has an option for it. Granted, it won't be aligned as well as if you have some fancy code to sync from encoder input, but it won't be far off either with servo drives talking to Mach. If it was, it'd fault. I wonder if it's off enough to matter vs the rigidity errors of such a beast.

Rigid tapping. Yay, good one. But there sure are a lot of CNC machines out there that don't rigid tap and seem to get by fine, particularly machines running EMC or Mach3. There are fascinating arguments about degrees of rigid tapping too (do you sync the table to spindle or spindle to table, do you use a tension compression holder anyway, etc.) Still, I will give it #2 favorite 'cause why not, it's cool!

Glass scale feedback. This would be my favorite of the claimed advantages. There's a lot of good to be gained here. There are ways to skin this cat too and get most of the value in Mach, though not all the value for sure. For some interesting insights into how to increase accuracy on machines without glass scales, it is fascinating to learn more about Renishaw's RAMTIC methodology:

RAMTIC: Fast Super-Precision Manufacturing on Cheap Machines « CNCCookbook

Mach also does leadscrew mapping, which is an excellent thing to do with glass scales, BTW.

Good counter examples for EMC. Thanks guys.

Cheers,

BW

[Maglin]

I think this has been talked about enough and we don't need to be telling everyone why what they use is better. EMC2 is daunting at first but very nice and easy to use although not as easy to use as Mach at first. Figure about 20-30 hours of reading to start to understand it.

Personally I have emc2 and using Mesa PCI card have more I/o than I know what to do with. One nice thing about emc is that if you are running Mach currently w/o a smoothsteper you can get it running very quickly on emc to check it out.

Sent from my Incredible 2 HD using Tapatalk

[chester88]

If the delay is caused by displaying the path tabbing to DRO display will allow huge files to load ? The older interfaces still function afaik (?)

I've never tried to load a 10MB file but have occasionally run into a different glitch. If the first few lines of a file are 'stepped through' the file stops dead after executing a few more lines in 'run' mode. It happens rarely and only on certain files but on those files the glitch is repeatable. i haven't run those files recently and the problem may have been caught in a bug fix.

Tabbing the display will have no effect. The run through happens anyways.

Have you reported this as a bug? A bug report with a sample program would probably get you a solution- sounds like a special case problem.

[chester88]

I think this has been talked about enough and we don't need to be telling everyone why what they use is better.

Oh I don't think we were fighting yet
Bob asked a valid question we were giving examples and opinion.

Mach has advantages
EMC has advantages

I vote for EMC of course as I work on it - but it certainly isn't perfect.
it would be interesting if EMC was marketed similar to Mach how it would do.

Clearly it would need an easier to modify screen - that seems very popular in Mach.

[TomKerekes]

For instance with EMC I can set the following error to anything I want. I can tune the PID. (or write a new PID routine) I could use any resolution encoder. A fellow has written a component included in EMC that will convert different HALL effects schemes from one manufacturer to another (actually a whole lot more then that) allowing one to mix and match motors and brushless servo amps or allow one to directly control the coils of the motor.

Ridged tapping with nothing more then an encoder and a way to control the spindle motor.

Threading using a single pulse or the full encoder resolution.

Just had to point out that all this is possible with our external KFLOP controller running under Mach3.

I think the main distinction between approaches is whether the real-time control should be inside the PC or in an external controller. At Dynomotion we believe the highest performance and reliability can be achieved with the real-time control external from the PC. I wish EMC was more friendly toward external controllers.

Regards and Happy Holidays

[chester88]

Just had to point out that all this is possible with our external KFLOP controller running under Mach3.

I think the main distinction between approaches is whether the real-time control should be inside the PC or in an external controller. At Dynomotion we believe the highest performance and reliability can be achieved with the real-time control external from the PC. I wish EMC was more friendly toward external controllers.

Oh I didn't mean it couldn't be done with Mach at all, but it must be done with hardware that you are basically locked to.
I'm not knocking your or anyone else's product. I find your product very interesting.

With the motion control locked in a blackbox - yes of course you CAN have better performance and reliability. You lose choice.
With EMC you CAN have excellent performance, reliability and choice.

It seems to me with the motion controller in a blackbox then the software really just becomes a way to load the gcode to that black box. The software ceases to be a CNC controller and becomes a fancy screen.
Of course as a user that really doesn't matter. If it does what you want then all is good.

Tom, roughly how does Mach send commands to the KFLOP?

EMC is always going to be a motion controller so will never be friendly to moving the motion controller to a blackbox. (not that it hasn't been done - someone was using a Mesa 7i43 thru USB - no details how)
Now putting EMC IN the black box been worked on and does work with the philosophy but has not got far AFAIK.

[Maglin]

One thing to mention about EMC2 is that it was designed to be as capable as a lot of the commercial controls with the least amount of expense.

Break Down:
EMC2 : Free
Servo Drives : 3x 30amp +/- drives around $100 total
BOB : From $10-$800 but usually around $80-$180

You can't touch a commercial control for that kind of money. Mach3 is an excellent end user control but requires step/dir control only. So servo drives will cost you 3-5x as much. With the added costs of people wanting smooth stepper and the PMDX stuff the BOB's get quit a bit higher as well. I did a conversion on a Denford CNC (Sherline) that only required an outlay of $20 for a 25 pin BOB. That is pretty cheap considering.

Personally if I already had something under Mach3 control and was happy with it I wouldn't change it over. You already have the outlay of expense for the hardware closed loop drives and your BOB wired and working.

If you are shopping still for electronics then I would take a hard look at EMC2. The added savings in cost for the hardware can be used to get your spindle encoder for rigid tapping. The Mesa 5i20 PCI interface board with more I/O than most people know what to do with along with very nice daughter cards for all different kinds of possible drive set-ups with +/-10v being the most favored. You might even have enough in savings to get a 4th axis as well.

This is all going with a Servo System. For a Stepper system I think it's a coin flip as most the hardware will be the same. If you don't know Linux and want to learn it go EMC2. If not go Mach3 and either way the end result is an accurate machine. Also Mach3 isn't so finicky on computer hardware as EMC2 uses a realtime kernel that doesn't like multi cores, multi threeded hardware or Nvidia for that matter.

And as for running closed loop on a stepper set-up I think it's just wasted time. Their are people that have done it but it's a mess to get implemented correctly. The best thing is running scales on your axis's to be able to give feedback on actual movement and not perceived movement as you get with an encoder.

So their are my thoughts now that I had a computer handy. Hope everyone had a Merry Christmas.

[Mjolinor]

Just had to point out that all this is possible with our external KFLOP controller running under Mach3.

I think the main distinction between approaches is whether the real-time control should be inside the PC or in an external controller. At Dynomotion we believe the highest performance and reliability can be achieved with the real-time control external from the PC. I wish EMC was more friendly toward external controllers.

Regards and Happy Holidays

I think this is showing a non familiarity of what Linux is. You are calling it "the PC" but you should be thinking of the Linux part as "the black box" and that black box has methods to be in there with a monitor and keyboard/ mouse if you want it that way. The monitor / keyboard / mouse do not have to be on your "EMC" machine, it should be fairly trivial to compile EMC to run on an embedded Linux micro such as Openwrt and then it even looks like your black box.

It's a subtle difference but I think one that is absolutely crucial to understanding what EMC is.

That's a bad explanation.
I am trying to say that I view EMC as a fancy front end for a sophisticated series of systems and controls that can be configured to suit anything you may want to do with any type of hardware.

Baking my noodle trying to write this down, someone more capable than I will pick it up.

[chester88]

Embedding linux is not the problem, embedding realtime linux (specifically RTAI) on a black box that will support EMC has been the problem.

EMC was designed to separate the realtime motion control part from the user part (screen / user controls)

You can run EMC from a separate computer even one that is running windows.
You can actually run multiple screens for one CNC
That separate computer can have no realtime control over the machine.

I believe it was the floating point math that EMC requires that limits the embedded hardware but I'm stretching my memory ....

[cyclestart]

Just had to point out that all this is possible with our external KFLOP controller running under Mach3.

It's also possible under KMotion with no need for Mach3 ? It looks like you offer a complete solution if the user doesn't need all of Mach3's bells and whistles.

I wish EMC was more friendly toward external controllers.

The emc2 project of linuxcnc.org or emc in a broader sense ? Both ? Your website mentions deriving KMotion from emc.
btw: Interesting products and (from all reports read so far) impressive in it's capabilities.

chester88
I'll dig up one of the offending files (mentioned in my last post) and attach it to another thread in this forum. It may be something in the gcode and not a bug at all.

[TomKerekes]

Hi all,

From my viewpoint Linux is great because it offers multitasking, virtual memory, disk access, Ethernet, keyboard, touch screens, Internet, USB, great development tools, email, CAD, multiprocessing, graphics, etc etc. But the one thing it is not designed for is real-time control. The same can be said about MS Windows. As well as PC motherboards. So to try to use it as a real-time controller will always be like swimming up-stream. I don't think moving/splitting EMC2+Linux into a separate microprocessor box helps. In fact it makes things more difficult and non-standard. I'm sure many feel differently and those shouldn't read any further :}

What I would love to see happen with EMC2 is to have only the real-time portion split off or isolated so it can be performed in a simple external controller (like ours - heh heh). This would mean you could run any common Linux, not have to have certain motherboards, real time extensions, limited drivers, etc. EMC2 would just be an application.

This wouldn't necessarily limit choice any more than using any other piece of I/O hardware and there isn't a significant increase in cost. There are some packaging advantages as well. Not all of EMC2 except the "screens" would need or even want to be moved to the external controller. Only hard-real time things like servo feedback and pulse generation for example. The complex pieces like the GUI, the Interpreter, the trajectory planner, Kinematics, Error recovery, Machine configuration, etc would remain in the PC.

This is basically the model Mach3 uses with their SDK and Plugin approach that allows your choice of any hardware to be used with it. Mach3 still does the screens, GCode Interpreter, Wizards, Trajectory Planning, etc... and only the low level motion is passed to an external controller to be buffered and executed. And of course the external controller handles threading, rigid tapping, slaving, etc.

But my understanding from looking in from the sidelines is that within EMC2 the real-time stuff is hopelessly intertwined with the non-real time stuff so it wouldn't be worth the effort to untangle it. As someone once told me: "It would no longer be EMC". Is this the general consensus?

Happy New Year

[PCW_MESA]

Hi all,

From my viewpoint Linux is great because it offers multitasking, virtual memory, disk access, Ethernet, keyboard, touch screens, Internet, USB, great development tools, email, CAD, multiprocessing, graphics, etc etc. But the one thing it is not designed for is real-time control. The same can be said about MS Windows. As well as PC motherboards. So to try to use it as a real-time controller will always be like swimming up-stream. I don't think moving/splitting EMC2+Linux into a separate microprocessor box helps. In fact it makes things more difficult and non-standard. I'm sure many feel differently and those shouldn't read any further :}

What I would love to see happen with EMC2 is to have only the real-time portion split off or isolated so it can be performed in a simple external controller (like ours - heh heh). This would mean you could run any common Linux, not have to have certain motherboards, real time extensions, limited drivers, etc. EMC2 would just be an application.

This wouldn't necessarily limit choice any more than using any other piece of I/O hardware and there isn't a significant increase in cost. There are some packaging advantages as well. Not all of EMC2 except the "screens" would need or even want to be moved to the external controller. Only hard-real time things like servo feedback and pulse generation for example. The complex pieces like the GUI, the Interpreter, the trajectory planner, Kinematics, Error recovery, Machine configuration, etc would remain in the PC.

This is basically the model Mach3 uses with their SDK and Plugin approach that allows your choice of any hardware to be used with it. Mach3 still does the screens, GCode Interpreter, Wizards, Trajectory Planning, etc... and only the low level motion is passed to an external controller to be buffered and executed. And of course the external controller handles threading, rigid tapping, slaving, etc.

But my understanding from looking in from the sidelines is that within EMC2 the real-time stuff is hopelessly intertwined with the non-real time stuff so it wouldn't be worth the effort to untangle it. As someone once told me: "It would no longer be EMC". Is this the general consensus?

Happy New Year

A lot of people use EMC precisely because it does not adopt the buffered system architecture use by Mach and others but uses a simpler and cleaner approach. It could be argued that the buffered model used by Mach is really just a bandaid necessitated by the lack of a a true RTOS for the controller.

You can look at EMC as having the real time motion control "black box" integrated in the same PC that runs the userland tasks. This has the advantage of a simpler and more robust overall control architecture, and more CPU horsepower than can be provided by any but very exotic external boxes.

Also by moving the real time portion to a proprietary box you have to randomly subset EMC capabilities based on what the external hardware provides. As it is now EMC can do rigid tapping and threading on the simplest parallel port hardware, and if a new realtime motion feature is added to EMC it becomes available to _all_ EMC users.

So its not much a question of whether its worth "untangling" the realtime
portions of EMC from the non realtime portion as why would you want to go backwards to buffered system with a non RTOS drip feeding a proprietary external box with considerably less horsepower than available in even a very modest modern PC.

[BobWarfield]

A lot of people use EMC precisely because it does not adopt the buffered system architecture use by Mach and others but uses a simpler and cleaner approach. It could be argued that the buffered model used by Mach is really just a bandaid necessitated by the lack of a a true RTOS for the controller.

You can look at EMC as having the real time motion control "black box" integrated in the same PC that runs the userland tasks. This has the advantage of a simpler and more robust overall control architecture, and more CPU horsepower than can be provided by any but very exotic external boxes.

Also by moving the real time portion to a proprietary box you have to randomly subset EMC capabilities based on what the external hardware provides. As it is now EMC can do rigid tapping and threading on the simplest parallel port hardware, and if a new realtime motion feature is added to EMC it becomes available to _all_ EMC users.

So its not much a question of whether its worth "untangling" the realtime
portions of EMC from the non realtime portion as why would you want to go backwards to buffered system with a non RTOS drip feeding a proprietary external box with considerably less horsepower than available in even a very modest modern PC.

I hear this kind of argument for EMC, but find insufficient hard evidence or deep discussion to be compelled. It seems like a lot of handwaving: because this code is written this way and that code is written this other way, therefore this code is better. The argument is that this conceptually more elegant architecture gives EMC advantages. Let's go back over the claimed advantages again, along with any hard evidence or counter-argument:

- Simpler architecture. Well not really, because the guts are all hanging out in one place instead of delegating some of it to a black box. That makes the architecture more complex in fact relative to what's needed to just drive the black box.

- More robust. Why is this more robust? If anything, handling all this intricacy in code that is so intertwined it can't be separated out sounds less robust.

- Buffered model is a bandaid approach. Yet, it is an approach adopted by commercial controllers like the Siemens A2100:

Motion Control Boards Take Mach3 From Hobby Class to Industrial Grade, Part 1 « CNCCookbook

Is a layered approach to software design a bandaid, or is it really how things should be and are largely done?

- It has more CPU horsepower than any but the most exotic black boxes. Again, is this really true? EMC has a hard time with multiple cores. Mach3 is being set up to take advantage of multiple cores as we speak, for example by moving the backplot and display code to another core.

EMC's real time kernel delivers a lower kernel frequency than Mach3 on a parallel port, let alone the 4MHz that Mach3 can run with a device like a Smoothstepper. The lower kernel frequency of real time EMC goes to the issue mentioned that the PC motherboard isn't even well set up for this kind of app. If EMC does have more CPU horsepower available, it isn't clear it actually manages to employ it effectively.

Engineers love to use what they like, and they love having source code access. The Linux world reviles Windows, yet the Linux world, while it rules the server, has a tough time on the desktop save for those die hard souls that love it. They each have their place, but I sure do like to see hard evidence for what that place is.

For me, only a few things seem to fit that hard evidence criteria:

- A hardware motion control device outboard is not a bandaid, it's a means of delivering better performance that's been proven on many a commercial grade control. It can help either Mach3 or EMC to achieve higher goals.

- EMC is far more configurable than Mach3, if only because you get the source code. If I had to retrofit a really idiosyncratic machine, I'd likely have an easier time doing it with EMC. But, we have to consider that most machines are not so idiosyncratic.

- Mach3 is easier to set up out of the box for a straightforward machine, especially for those that do not know Linux. There also seems to be a much larger community of users and ecosystem providers for Mach3, though the EMC community is certainly spirited. In other words, I can get more off the shelf accessories for Mach3, and more online help from users.

- As far as the whole closed loop/open loop thing goes, we have uncovered a few EMC advantages:

1. Rigid tapping is possible. BTW, I plan to write an article on this soon as there are many variations and degrees of rigid tapping, and while it sounds cool, there is a lot involved before it delivers parts faster and more cheaply.

2. Glass scale feedback. I still say this is a BIG deal for EMC if you are trying to make a machine super accurate. It kills a lot of birds with one stone--thermal expansion of various machine parts and leadscrew errors being just two. I wish guys like KFLOP would look at what it might take to build this in below the level of Mach3, as it doesn't look like Mach3 is internally set up to deal with it. If Mach3 was sending idealized commands and the KFLOP or other device "accurized" those commands with glass scale feedback, it would be pretty awesome.

3. A bunch of other minor stuff in the category of "No need to home after E-Stop" or "Can change the fault limit on following error." Not sure this stuff adds much to real productivity, though it is interesting.

- There is the recurring cost argument: since EMC does so much in software, I have to buy less hardware, and therefore I get this awesome performance a lot cheaper. I'm still skeptical on this. It doesn't ever count the cost of your time, just the laundry list of hardware for solution "A" vs solution "B". Is the end result really that good, or are we kidding ourselves? There is definitely some performance level where doing it in software is not as good.

Usually when we try to shave too many pennies, we wind up kidding ourselves. It would be great to see some objective testing where the only thing that is being changed is the electronics and software.

- Some sort of discussion should be had around the pace of change of these two platforms. Which one is getting more TLC and new features for a given amount of time? Neither one looks like it is evolving particularly quickly in any event, so maybe this one is a wash.

- Just to be even-handed, let me throw a slap against Mach3--its ring buffer plug-in architecture works, but forces the outboard hardware it accesses to be awfully low level. Would that it was at a high enough level it could accept "pidgin g-code", but it seems to be nowhere close. Making it higher level so the outboard device could start to do some more of the trajectory planning job ought to result in even higher performance, but it seems that Mach's architecture is so layered on the ring buffer model that would be hard to make happen.

It kind of winds up being the Chevy vs Ford conversation of our old hot rodding days, doesn't it? Some of those arguments sure did get heated, LOL!



Like the Chevy vs Ford argument, you can probably make either one perform to amazing levels with some work and effort. Decide what kind of work and effort you're more comfortable with and experienced with, and that will help you choose which one would be better for you.

Cheers,

BW