Why should i use EMC over Mach3

[PCW_MESA]

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

The basic system architecture of EMC is simpler because buffering always incurs additional control complexity/compromise since _ALL_ state information is not available in one place at one time. I stand by my bandaid statement. If buffering were not required by a non RTOS control and perhaps non-real
time transport what benefit does it have? It is basically a work-around. That is in a Mach like setup, buffering is required for good performance, in EMC it is not...

Sure a layered approach is good for software design, but a buffered multiple locus of control architecture is not at all the same thing as software layering.

More robust because its built on a true RTOS not an OS with no maximum time limit on operations with a buffer for a bandaid...

As for EMC having trouble with multiple cores, that may have been true at one time but is no longer true at least up to 4 core machines. So yes EMC easily has more raw power for applications with complex real time motion needs than any but the most exotic external boxes.

EMCs maximum base thread frequency may be a little lower (though this may also be that it is just more conservative about latency) and may be a minor limitation for parallel port machines (40 KHz or so is obtainable with comodity MBs) Note the base thread rate is by no means a measure of computing power. EMC also has low cost hardware step generation options (up to 12.5 MHz up to 48 Axis)

EMC can easily run with sample rates of up to 10 KHz for servo machines This is much faster than is needed for a typical high performance servo CNC machine and is sufficient to support linear motors and other higher bandwidth
actuators.

As far as performance level goes, unless you are doing control in actual hardware, all systems we are talking about are doing control in software.
The tradeoff between an external box doing motion and EMC doing motion is likely somewhat greater jitter (in the 6-10 usec region) but better computing performance for EMC and lower jitter but also lower computing performance for an external box.

[BobWarfield]

Let's just cut to the chase, because a lot of this is a geek food fight anyway, and not that interesting or productive.

The real question is not theoretical elegance, it's what can we see and measure in terms of real world performance cutting chips? What are the real advantages if these systems are looked at as black boxes, because that's how they should be evaluated unless we plan to change the code ourselves.

Let's start with a black box view of this RTOS issue, get past the elegance claims, and onto how it affects the user.

More robust because its built on a true RTOS not an OS with no maximum time limit on operations with a buffer for a bandaid...

It is true there is no specified maximum time limit for Windows, however, there is a practical time limit, just as there is for EMC2 at the low end. If Windows ignores the interrupts for too long, it quits working. If we configure a system as many have where Windows can service the interrupts frequently enough and with minimal interruption, it works great. If EMC2 interrupts too often it freezes and has quit working.

Both therefore have to be timed to their sweet spots, so forget the internal elegance and ask whether it allows one to deliver a bigger sweet spot than the other or whether one is easier to configure to its sweet spot? I can't see much evidence to award a victory for one or the other at this stage. EMC has a lower potential kernel frequency but the claim is that it's more stable. Without doing a bunch of testing that involves reconfiguring the same hardware with two completely different OS's (labor intensive), we're not going to know. Let's assume they're broadly pretty darned similar and move on.

With that said, we should be aware of what's needed for the kinds of servo driven systems being bandied about.

EMCs maximum base thread frequency may be a little lower (though this may also be that it is just more conservative about latency) and may be a minor limitation for parallel port machines (40 KHz or so is obtainable with comodity MBs)
...
EMC can easily run with sample rates of up to 10 KHz for servo machines This is much faster than is needed for a typical high performance servo CNC machine and is sufficient to support linear motors and other higher bandwidth
actuators.

You've quoted two different frequencies there, which is interesting. Which one are you going to stand by?

The 10 KHz frequency does not seem adequate for a regular servo system, let alone to reach the full potential of a linear motor system.

If your sample rate 10 KHz, you can send how many pulses? From here:

EMC Documentation Wiki: PulseRates

looks like 10 Khz = 5000 pulses a second, regardless of axes. So, if we position to 0.0001" per pulse, we'd need 16,667 pulses a second to go 100 IPM. Looked at another way, my mill needs 28K pulses to move 1 inch, and 100 IPM is a bit over 1" per second. 10 KHz doesn't work there.

40 KHz will get me there, if I can find a machine that delivers that with EMC. But that's an issue too as we will see. For now, let's assume it's 40KHz and that it is therefore the same ballpark as Mach3 runs its parallel port.

Even at 40Khz, I still don't see this as in league with typical industrial controllers from Fanuc or Siemens. We can still improve on it with outboard hardware.

Still no clue on where an advantage for Mach3 or EMC2 may lie though. All that's left is the impact of latency variability. Is the real time OS less susceptible?

Even though EMC is theoretically "real time", it still seems to have many of the same issues and foibles people complain about with Mach3 in the form of what the EMC world calls latency issues. Just Google "EMC2 latency" and you'll start seeing the complaints:

Can't use an onboard graphics controller. Nvidia causes trouble. Disable onboard audio. Turn off power saving and any other BIOS option you can live without. Yada, yada. Doesn't that sound just like the issues the Mach3 guys struggle with?

In fact, some of the same motherboard issues that plague Mach3, like DMA disturbing the system timer interrupt will have to be present for EMC if you use the same motherboards and BIOS, which you do.

This came from the EMC2 Wiki:

EMC Documentation Wiki: TroubleShooting

So then is it real time all the time, or just real time when it is setup just exactly right and has the right hardware? Even Windows is "real time" at some level of granularity and when it is set up just exactly right. It will at least pass a real time Turing test (if you didn't know if it was Windows or the real time OS, but only saw the pulse train output, you couldn't tell the difference), which is essentially all that matters.

The thing is, who cares whether the innards are theoretically more elegant or what causes the issues: they're the same darned issues!

Back to the practical. If I can run Windows setup in such a way that the latency issues are managable relative to the required timing, I'm just as happy with it. If I can add an inexpensive and easy to drop in hardware component like a Smoothstepper or KFLOP to enable even better performance, I'm happier still.

If I'm trying to figure out my latency issues on EMC, and they prevent me running as fast as I need to run on the hardware I happen to own, I'm just as unhappy with it as I am on non-real-time Windows. Or, if we want to be glass half full, if I can get it all configured on the hardware I happen to own, I'm happy with EMC too. If I can get the hardware add-on to work with EMC, I will likely enhance its performance just like I did with Mach, and I'll be even happier.

Yay!

Back to the original assertion: elegant or not can be debated, but it isn't all that productive.

What the user is familiar with and therefore can tweak around the latency issues, what the proven performance is, the requirements on the ecosystem, and the challenges the user wants to undertake are what deliver the results.

I wouldn't want to be a Windows expert (let alone novice) who knows not about Linux trying to tweak that in. Nor would I want to be a Linux maven dealing with the vagaries of Windows. If I was an expert at neither, I would want the biggest best community of experts helping me 'cause I'm just a poor chip maker trying to make his chips.

And again, this is why the world has chocolate and vanilla. We like choices. EMC2 or Mach3, vive la choice!

Cheers,

BW

[chester88]

- 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.

Well there is that linux it's self is more robust the windows.
Realtime is more robust then non realtime.

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

- 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.

Ok does workaround sound better? I can't see how a commercial controller has any choice - if they want a windows front end (marketing value) they must use a separate smart control board. Windows is not realtime. Also I would imagine Siemens are capable of some pretty amazing performance, they are also locked into those features. You can run some pretty fancy and large machines with EMC not locked in to hardware or a huge price tag (like Siemens etc)

- 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.

EMC is far more configurable even without the source code. But it takes more knowledge or time.
What do you consider idiosyncratic?
What the source code does give you is choice. You can work on your own machine with every bit of information available.
If you are talking serious money making machines that can be a huge asset.

- 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.

This is probably true. I'm not sure, do the external cards require configuring too?
There are a couple of configuration programs to help new users out with EMC.
The larger user base of Mach is certainly true! Mach is marketed and uses windows
- that makes it automatically more popular. But using Linux for everyday stuff is not much of a barrier other then it's different and most people don't like change.

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.

You mention Glass scale feedback but it's really making changes based on any feedback. (the definition of closed loop). With EMC you have maximum choice. Recently one fellow connected a microcontroller with a temp probe to EMC using a serial port then used it to compensate for thermal growth of the spindle ( about .003 ). He could have just as easily used one of the other 'officially supported' hardware. This compensation feature is not a standard thing, he came up with the idea and added it. EMC does support a compensation lookup table for such things as screw compensation.

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 direct comparisons would be interesting.

- 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.

I know EMC is actively developed pretty much daily.
The development tends to be un directed formally. It generally moves in the direction of what interests the current developer.
Hence Fancy easily configurable graphics are not high on most developers wants so EMC is a little boring looking and difficult to change it's look.

- 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.
BW

This seems odd to me. Then Mach would cease to be a motion controller it would be a familiar screened interface to probably inconsistently supported features of motion control cards.

BTW Bob I read your site regularly. I very much enjoy it.

Chris

[clytle374]

I'm not sure where having trouble with multiple cores came from. I was running 2 cores about 2 years ago with the system running on the 1st core and the 2nd being dedicated to motion control.

Cory

[BobWarfield]

Well there is that linux it's self is more robust the windows.
Realtime is more robust then non realtime.

See my other post on this "realtime is more robust" issue. Show me how I can tell without looking inside the black box that it's more robust.

Ok does workaround sound better? I can't see how a commercial controller has any choice - if they want a windows front end (marketing value) they must use a separate smart control board. Windows is not realtime. Also I would imagine Siemens are capable of some pretty amazing performance, they are also locked into those features. You can run some pretty fancy and large machines with EMC not locked in to hardware or a huge price tag (like Siemens etc)

Actually, no, the workaround doesn't sound better. This is again, a very common architecture. What is not so common is EMC's architecture among industrial grade CNC controllers.

When you can say you can run some pretty fancy large machines, there are a few EMC anecdotes about running older VMC's. It's far from clear they get the results that for example a Cincinnati Arrow running the Siemens A2100 could.

EMC is far more configurable even without the source code. But it takes more knowledge or time.

How do you quantify that? For example, none of the screen work one seems on Mach with the "brains" and other sorts of add-ons seem possible without source in EMC.

What do you consider idiosyncratic?

Complicated mill-turn machines and the like. Machines with weird kinematics or axis relationships. Machines with weird requirements for ancillary devices.

Most VMC's are not idiosyncratic.

What the source code does give you is choice. You can work on your own machine with every bit of information available.
If you are talking serious money making machines that can be a huge asset.

No, if you're in the business of making serious money doing machine work, most everyone will tell you to steer clear of Mach3, EMC2, retrofits, and anything else that detracts from making the chips that are your parts. Depreciate the machine in 4 years and buy another one that makes the parts faster.

But using Linux for everyday stuff is not much of a barrier other then it's different and most people don't like change.

Easy to say if you've already crossed that rubicon, but just not true for most folks. Learning a new OS is a major barrier.

You mention Glass scale feedback but it's really making changes based on any feedback. (the definition of closed loop). With EMC you have maximum choice. Recently one fellow connected a microcontroller with a temp probe to EMC using a serial port then used it to compensate for thermal growth of the spindle ( about .003 ). He could have just as easily used one of the other 'officially supported' hardware. This compensation feature is not a standard thing, he came up with the idea and added it. EMC does support a compensation lookup table for such things as screw compensation.

Temp comp like you describe for the spindle case sounds doable in Mach3. Mach also has leadscrew comp. I've used it after calibrating mine with a tenths reading DRO.

I know EMC is actively developed pretty much daily.
The development tends to be un directed formally. It generally moves in the direction of what interests the current developer.
Hence Fancy easily configurable graphics are not high on most developers wants so EMC is a little boring looking and difficult to change it's look.

Similar sentiments for Mach3. But what are the major features introduced, and when were they introduced?

This seems odd to me. Then Mach would cease to be a motion controller it would be a familiar screened interface to probably inconsistently supported features of motion control cards.

Not odd at all. It's how a lot of the world works. Look at it this way. The extreme low level guts don't involve all that much interesting innovation. It's just a knot hole we have to get through to move the axes. A world of much more interesting innovation exists at higher levels.

Heck, the g-code dialects of both EMC and Mach3 are starkly limited compared to what Fanuc and many others offer. Just making that area richer would add a lot of value to these audiences. How about the full Fanuc Macro B language? How about the canned lathe cycles? How about more sophisticated trajectory planning? There's a ton of very subtle effects that Mach3 and EMC2 aren't even close to addressing while they're mired at these low levels.

This is how the PC world made so much progress. If the same company has to design and build all the hardware (CPU, graphics chip, mobo controllers, etc.) as builds the OS and the apps too, progress is glacial and lock-in is maximal.

Somebody will do it. There's too many college kids messing around with g-code, Arduinos, and such for it not to happen. Gecko is starting to talk about higher level interfaces to their drives.

As soon as you get that sort of pidgin g-code backed into the hardware--just g01, spindle control, and maybe control a few relays with M-codes, you make the task of building the higher levels dramatically less finicky. Then you'll see a lot more innovation in the software.

The best news is it will all be cheap too. Arduino costs way less than a Smoothstepper.

It's having to make all these angels dance on the head of a parallel port that slows us down, if you'll pardon my fractured metaphor.

Cheers,

BW

[chester88]

When Peter mentioned 40 kHz He was speaking of software stepping through the parallel port.
This is pulsing step and direction signals at 40 kHz. The trajectory and motion controller run at a different rate, usually 1 kHz

When Peter talked of 10 kHz he was talking of hardware assisted analog servo signals. eg +-10 volt servo amps with encoder feedback. This requires a hardware card for any real useful machine.

The 10 Khz is the trajectory/motion controller rate. there are no pulses sent out.
mesa card specs : encoders can be read in Rs422/485 mode up to 10 mHz

[samco]

Here is the change log...

EMC Documentation Wiki: Released

sam

[samco]

Some thoughts in general as there was so much thrown out.

The fastest 'thread' (proccess that run over and over at a known period) is what the step generation is run in usually. This can output pulses at around 40khz on good hardware. some have gotten faster - some have had to lower it. Machines that don't use step/dir (like analog servo dives with supported hardware) don't usually require a fast thread.

there is another thread that the motion is calculated in. This includes PID loops and such depending on the machine setup. The heavy calculating is done here. This thread normally runs at 1khz but could be run faster - say 10khz. 1khz is a pretty common interval.

You can add other threads also. Being that this is a realtime setup - those thread run consistently within the jitter time. (on decent hardware that could be 10-20us) So - if I want something to happen every 1ms - it will happen every 1ms. or if I want something to happen every 50us - it will happen every 50us. If it doesn't there is something interfering with the real-time os and needs to be fixed. (emc will tell you if it misses its timing.)

I have tested emc on a lot of hardware. Other than laptops which are not a good candidate for real-time as they have all the power saving stuff. I have had maybe 1 or 2 motherboards that I could not get to work with decent latency. The big issue is on board video that uses shared memory. (some on board video works just fine). Popping in a video card solves the problem. I have had a couple older motherboards that required the SMI fix - but still - it fixed it. Once you get good latency numbers (running the latency test for a few hours to be sure) the system will be rock solid.

I have a HMC that I am using emc for.
All the setup is done within emc and emc's ladder logic. It has a 60 tool tool chain with mechanical barcode rings on each tool (15 bit) tool changing arm. 3 axis with 40 amp servo drives and a locking rotary axis(B). 2 pallet changers 16 gear spindle driven by a vfd. 2 hydraulic motors and a good 30 hydraulic solenoids. I am controlling 96 digital i/o + 4 axis and spindle. 7 encoders are being read. (4 axis, 2 on the spindle, 1 mpg).. This all could have been done without a stitch of code. (I wrote the spindle gear shift/spindle lock logic in emc's C like language call 'COMP' mainly because I could wrap my head around it programmically vs ladder logic/HAL.) Tool fetch,change and pallet swap is all done in ladder/HAL. I have less than $600 in interface hardware (all mesa). This is expandable also. (I can add more i/o easily) (I do have the printer port io I could use also)

I am the one doing the spindle temp comp. As the spindle heats up - that data gets sent though a arduino into emc. (cheap analog input into emc) I offset the z axis so as the spindle grows - z moves away from the spindle. This was also done all within emc's hal. (someone had created a cool interface driver between emc's hal and the arduino).

[chester88]

Linux Robust - Take windows connect it to the web 24/7 and remove the anti-virus software. add and upgrade a lot of software. - In general Linux will fair much better.

Realtime robust - On a properly setup realtime system you can load the system so heavily that the GUI will not respond and the realtime machine control will continue to run on time. there is no need to strip down the OS to ensure the machine will track accurately.

Workaround - Well that is a matter of opinion I guess.
If your going to compare a Siemens control with EMC control and say the Siemens has higher performance I am probably not going to argue. But your are locked in to that choice and I'm sure you pay for it. I'm sure we could take that same motion control card they use and tailor EMC around it and get the same performance but then we would be locked to that same motion control card. I guess it depends on if choice and freedom is important to you.

I think a large five axis milling machine is pretty fancy considering the cost of the hardware to run it.
And yes I do not personally know how it compares to a OEM control as far as results go. the fact the guy trusts EMC to run it and the other large machines he has converted says a lot in it's self. I am not certain why he choose EMC vrs Mach as the price difference is no consequence for these machines. But I would bet it's cause he can repair and configure his machines in house. The 5 axis machine did require a components written in C language in this case. He wrote it with the help of the EMC developers.

configurability - Aside from the main screen EMC is very configurable. As I said before EMC is not easy to completely change the look or function of the main screen, but If you need to add GUI bits and pieces like buttons, readouts, or numerical inputs one can use hand written XML file (for pyvcp) or a graphically built XML file (gladeVCP). These can be added to the standard screen in a couple of prearranged spots.
For configuring I/O EMC uses HAL a text based description of connections from EMC to components to the hardware board or parallel port. There are many small components that can be connected that do specific tasks. They can be connected to other components to form complex functions without knowing any 'real' programming language. It is analogous to electrical connections.
Then there is 'comp' which helps integrators write their own components if required. One could consider this programming though - it is closely related and converted to the C language.
There is ladder logic component that is 'programmed' with a GUI.
So this allow you to connect such things as USB HID devices, MPG encoders, extra I/O cards, dual encoder feedback, different kinematic components, GUI controls etc.
It takes time to understand the concepts of HAL and think through the logic of what you want to do.

idiosyncratic - True I think most machines that users are likely to put a lowcost control on are fairly straight forward - maybe the tool changer being the most common exception.

As for the business of making serious money i guess i needed to qualify that. If you are talking about Chevrolet manufacturing yes buy a new machine!
If you are talking about a company the size that would consider a refit of the control well then what I said can be true. or not it depends on the company and the people running it.

All very interesting points Bob. I have enjoyed your discussion.

I have come to the conclusion that for me the main reason I preferred EMC is freedom of choice.
Obviously I like to tinker with the programming side of motion control.


Chris M

[BobWarfield]

I'm sure we could take that same motion control card they use and tailor EMC around it and get the same performance but then we would be locked to that same motion control card.

Chris, probably not. There is a lot we're not even talking about in this thread that a commercial control has that lies between the low level motion control (e.g. this "pulse" level) and the g-code interpreter. Call it the trajectory planner, but there is more than just trajectory planning and it is very sophisticated on these controls, much more so than with either Mach3 or EMC2.

BTW, thanks for the link to the EMC2 change log. The equivalent Mach3 change log is here:

http://www.machsupport.com/downloads/Changelist90.txt

Out of curiousity, I did an analysis. I went back to beginning of 2009 for both products, and listed all the improvements. I did not list bug fixes--both products seem to have tons of that sort of work going on--nor did I list things like documentation changes. I was focused on genuine new functionality, but I did count performance improvements as "features".

For Mach3, 28 releases were done (!), and a total of 29 new features were introduced. For 3 years, that seems pretty light. Granted, Brian has a whole ton of stuff tied up in Mach 4, which we haven't seen yet, so I am assuming that is part of the reason not much more was done for Mach3. The 28 releases largely focused on bug fixing.

EMC2, by contrast, did half as many releases--14. However, those 14 releases delivered 280 feature improvements--almost 10x what we saw for Mach3. Lots of these were very cool things like additions to the g-code language of various kinds and not just minor tweaks.

At least until we see Mach4, the pace of innovation seems much stronger in the Open Source world.

Cheers,

BW

[kudos]

i think with EMC you also have to think what has been done feature wise that is not even in the main EMC release profiles that people have programed them selfs?

like one thing i did on a machine was slave my 4th axis to the spindle encoder feedback to cut gears with, took zero extra hardware only 10mins of my time writting some HAL code and away we went..
id not like to think what would cost me on my Fanuc machine todo that...

im sure there are much more that people have done and are possible that is not listed any where.. so counting features is abit odd way to go.. with Mach or EMC..

[andypugh]

You've quoted two different frequencies there, which is interesting. Which one are you going to stand by?
...
looks like 10 Khz = 5000 pulses a second, regardless of axes.

EMC2 can output one pulse every base period if using the parport driver (a subset of pins can be chosen to be reset every time the base thread runs)
A 15uS base thread will give you 60kHz step pulses.

The 10kHz rate that Pete mentioned was the "servo thread" rate, the rate at which the motion control (floating point maths) calculations are done. The output from this thread are the axis velocities and step rates, which are passed on to the fast thread. Normally the servo-thread runs at 1kHz, and if you consider how far the typical machine moves in 1mS then 1kHz is normally perfectly OK. Higher servo thread rates start to become relevant when running brushless motor commutation in software, or running very fast machines (or both, if running a linear-motor machine)

Whilst it is true that not all motherboards will work at all well with EMC2, the good news is that some very cheap ones work excellently. The Intel Atom boards (D510MO and D525MO) work out of the box with the onboard graphics and cost about $80 for board including CPU. Add a stick of RAM, a PicoPSU to run it off the machine 12V supply and a 4GB or larger SSD and you have a system that will easily support a 15uS base period for <$180. Mount that in the box with the drivers etc and you can almost forget that it is actually a PC.
These systems will run with about 8us latency, so 15uS is also fairly conservative for the boards in question, at that rate you can use the board normally for web/music at the same time.

Going back to a point elsewhere, about the realtime and userspace elements of EMC2 being hoplessly entwined, I don't think that is necessarily true. It is perfectly possible to run only the realtime part of EMC2 from the command line. In fact I do that all the time during testing, loading just the realtime code, starting the threads and loading realtime hardware drivers for testing purposes. I wouldn't mention that in any discussion about "user friendlyiness" though.

[TomKerekes]

Going back to a point elsewhere, about the realtime and userspace elements of EMC2 being hoplessly entwined, I don't think that is necessarily true. It is perfectly possible to run only the realtime part of EMC2 from the command line. In fact I do that all the time during testing, loading just the realtime code, starting the threads and loading realtime hardware drivers for testing purposes. I wouldn't mention that in any discussion about "user friendlyiness" though.

I guess I was thinking the boundary between User Code to Real-time code was further down the data path where it was already planned motion. It would then be easier to direct to our controller and not require real-time on the PC.

In our system the Trajectory Planner needs to look seconds ahead as it might take that long for a system to stop. With tiny sements that could be hundreds or even thousands of segments. For us its a complex process that requires multiple passes through the segments to optimize the trajectory so it doesn't lend itself well to deterministically run in real-time. Ours runs in User Space.

But my understanding is EMC2 is different. It somehow runs in real-time using a ~1KHz cycle?

Can anyone tell me the form of the data that crosses the User Space to real-time boundary?

Thanks

[clytle374]

Can anyone tell me the form of the data that crosses the User Space to real-time boundary?

Thanks

That is the great part, you can git the source and see yourself.

Cory

[andypugh]

Can anyone tell me the form of the data that crosses the User Space to real-time boundary?

There is some information here, but it may be a little outdated in places:
EMC internals

As an experiment I just loaded up realtime / kinematics and motion (the realtime part) without the rest of Emc2 and I think that creates interfaces that could be used by any other motion motion control package.

If you want to experiment, it is fairly easy to download the EMC2 liveCD, boot your PC from that (you can leave the hard drive untouched) , then open a terminal and type

halrun
loadrt trivkins
loadrt motmof

Then (for example) "show pins" will list all the HAL pins that are available to the shared memory. That is only part of the interface, though. I am not entirely sure what form the motion queue interface takes.

[Viesturs]

Hello!

After careful reading all 7 pages of this thread I decided to add my opinion.
First of all I will start with and answer to the first post of this thread.
Why should original poster or any other interested person choose EMC instead of Mach?
1) because of "cost of total ownership".
I see 2 aspects here:

a) licence costs
As mentioned, Mach's license cost 175$. What was not mentioned - Windows also is not for free.
EMC is open-source and is released under GPL licence.
It runs on Ubuntu LTS releases with RTAI kernel. Both of them are free of charge.

b) realtime vs non-realtime
Basically it is question of reliability.
This question already was touched, but there is one thing that I would like to add.
It was argued that software step-generation is better done in Mach3, because it can reach higher frequency. It sounds nice in theory, but since there is no mechanism that would ensure that Mach's process is priority over other Window's processes it is very likely that different interrupts will occur (especially for fast moves, where each interrupt of control for 0.01s can lead to a high-speed move being done 0,01s longer than needed. Since plasma tables and other machines easily exceed velocity of 6000mm/min, which is 100mm/s = 1mm/0,01s; so 1mm errors are very easy to produce) thus threatening machine's performance and subsequently quality of the produced parts suffer.
What I am trying to say is that additional hardware that would take the realtime part of the control, generate step signals, close feedback loop etc is _mandatory_ for reliable operation of Mach.
This concept of delegating some of the realtime tasks to other hardware is not bad, it is used also for EMC and other controls.
The problem lies in the fact that Mach does not care about it - it is not working in realtime and thus by definition not meant to be able to work with any kind of a feedback from these devices thus limiting the overall performance - even with step/dir servo drives Mach will not be aware, if following error is exceeded (motor stalled) or any other problem. Some fault signal from drive can be routed to Mach, but the reaction can come way too late, because it is not realtime, there are buffers etc.
EMC works in realtime, it closes the PID loop and it is in full control of what is happening with the machine, thus providing much safer and efficient operation.

This requirement for additional hardware adds to operate machine in a safe and reliable way adds to the total cost of the implementation.
As pointed out previously, hardware for EMC to do step generation, count encoder pulses, can be acquired for less cost and provide considerably larger functionality.

2) visual look
Here are 2 screenshots:
Mach default GUI (my apologies, could not find any larger picture):
http://www.machsupport.com/images/mach_program.jpg

EMC2 default GUI:
http://www.linuxcnc.org/docs/html/axis_2.3.png

It is pretty much a question of personal preference.
What I think that all those contrasting colors and flashing lights in Mach GUI is it is always reminding me these "one- armed bandits":
Deal Or No Deal Fruit Machine review on Fruit Machines Info

Mach is far from looking professional. I am not saying that default EMC GUI (called Axis) is perfect, but they cannot be compared.
If "professional" is meant to be "like those really industrial controllers" the I think that "Touchy" GUI is getting closest to that - it is special GUI, intended for touch-screens, with large buttons and with switching to different tabs at the bottom of the screen. Some pictures are here:
http://wiki.linuxcnc.org/uploads/Scr...MC2-Touchy.png
EMC Documentation Wiki: GTK Themes

Axis with GladeVCP also looks good:
EMC Documentation Wiki: GladeVcpSetup

It was argued that Mach has ability to produce custom screens.
Welcome to EMC, it has PyVCP panels:
Python Virtual Control Panels (pyVCP)

Recently GladeVCP panels have been introduced, which look so much better:
GladeVCP

And creating these panels is not difficult, it just requires 30 min of reading before first attempts to understand, how to do it. At least for pyvcp, I have not yet played with gladevcp.

Actually here are more screenshots:
EMC Documentation Wiki: Screenshots
Note: "touchy" color scheme is depending on the overall desktop color scheme

3) user-friendliness
One of the posters mentioned that wizards, available in Mach, have made his life a lot easier, when setting the machine up.
Unfortunately it was not mentioned that together with EMC2 user installs:

- Stepconf wizard: supposed to be used to set up stepper machines, extremely useful, when software step-generation is used, because it allows for quick and easy configuration of LPT pins and assigning them to frequently-used functions. I used it, when I was setting up my first machine 2 years ago. I had ~30 min experience with Linux at that time, it required me less than 15 minutes to get motors moving;
- Pncconf: supposed to be used for more advanced configurations, when Mesa I/O cards are used as well as closed-loop servos are controlled;

I noticed some arguments about Linux being hard to learn. I would like to ask anyone, who wants to use this argument, how much time they have spent to get familiar with it? I guess that majority - less than few hours.
2 years ago I had _zero_ experience with Linux and, of course, I heard all those "Linux is a scary monster" views, so I was very reserved trying EMC.
Several days later I knew that Linux is to stay on my PC, several months later I knew that Windows is not to stay on my PC. Half a year later some problems emerged with parents' PC with Windows on it. I did not ask them anything, installed Ubuntu there and showed only 2 things - how to launch Mozilla and Openoffice. They are still using it, and I did the same with girlfriend's notebook. She also is still using it and has not asked to install Windows there.

I am not saying that Windows is evil and Linux is saint, I see problems with Linux as well, but that is not even close to what I do not like about Windows.
And I get it for free

4) configurability
It was argued that most 3 or 4 axes machines are simple enough that even such a simple application as Mach can satisfy all the hobbyist needs.

I think that there are few things that cannot be implemented in Mach (maybe it can be done in attached hardware for additional cost, but not in the program itself):

a) configurability:
In less than a year that I have spent in working with CNC machines, I already have had 2 cases, where I had to implement EMC, because owners had previously tried to use Mach, but had failed:

- plasma table with 2 separate THC sensors
Client wanted to use 2 independent height sensors for plasma. It was not possible in Mach, I did it pretty easy in EMC, once the required behavior was sorted out;

- 2-spindle CNC mill for wood. This machine has 2 totally independent spindles and the trick is that it needs to be able either move each spindle independently (one in XY plane, the other in UV or whatever plane) or synchronously (both follow XY coordinates). Mach is not able to distinguish joint from axis, so there is no way for it to home 4 joints separately and then move them according to only X and Y commands.
Not to mention ability to switch from one mode to another.

I suspect that many will try to argue that this is far from hobbyist level.
I think that it is very close, because it actually is what the gantry style machines are about - there are 2 joints that need to be assigned to one axis. Mach is not able to distinguish that thus homing each side of gantry to its own home switch (that is needed to square the gantry and thus ensure correct machine's geometry _every_ time it is used) is possible, but requires unreliable workarounds. EMC capable to do it out-of-the box (with gantrykins).

b) different kinds of treating incoming signals (only few examples are mentioned):
- proper wiring in the machine to avoid any noise in the incoming signals require experience and sometimes also additional cost to avoid such a noise;
EMC is running in real-time, so it can reliably and predictably filter incoming signals to ignore the noise:
DEBOUNCE
- EMC can easily be told to do something, when rising or falling edge of particular signal has been detected:
ONESHOT

AFAIK Mach might probably capable of something similar, but those definitely will not be important things, since it has no direct access to i/o pins in realtime.

c) kinematics
Mach is not able of doing any kinematics calculations.
Basic concept is described here:
Kinematics

- Even apart from robotic arms and other nice machines, which Mach has not seen even in its dreams, there are cases, where kinematics calculations are necessary. For example, I am now installing a machine with several tools: spindle for plywood routing, laser for plywood engraving and also a knife for fabric cutting. First two tools would not create a problem for Mach, but it definitely cannot handle the knife - the knife has to be rotated so that it _always_ is oriented in the direction of the movement. That requires calculation of tangent angle of the current XY move and assigning the calculated angle to a particular joint, which rotates the knife.

- I think that these videos perfectly describes, how a small EMC tweak can do things that are otherwise impossible - turn internal hexagon on a simple lathe:
http://www.youtube.com/watch?v=T4q8gCpeY1A]Hexagonal Boring - YouTube
Eccentric turning:
http://www.youtube.com/watch?v=FpP7iTKuWpw]Eccentric / Non-circular turning using CNC - YouTube

I built this welding robot:
http://www.youtube.com/watch?v=O2oaBtkpNpE]Welding robot with EMC2.wmv - YouTube
I suspect that any other alternative CNC control system alone would cost as much as this entire arm (the MIG welder and base frame were provided by client).

All the industrial robots (ABB and Motoman (ex Yaskawa) I have seen have motor position commands in their code, so the code is totally unreadable by human.

The fact that EMC is doing kinematics calculations allows to feed "normal" g-code with X, Y, Z etc words to EMC. The g-code for the machine can be written by hand or it can be prepared with some kind of CAM package and verified/edited by operator, if necessary, which provides:
- safer operation: potentially dangerous mistakes in code can be spotted before the code is executed and something has happened - tool crashed in material etc
- time savings: minor mistakes (like one number in F word or S word) can be fixed a lot quicker by hand than the file edited in CAM, postprocessed, brought to CNC machine

d) industrial applications
EMC's versatility determines that it is far more suitable for industrial application than Mach - it can be used on a broader range of equipment thus allowing _all_ the machines in a workshop to use the same CNC controller, making operators' life easier - less things to learn, less things to mess up.

Even better - with rcslib all the machines in workshop can be operated in a centralised manner, allowing more precise billing of machine-time to client, easier maintenance and more efficient g-code management - machine operators are not the ones responsible for preparation of g-code for parts.

5) lock-in
It was mentioned in one of the posts: when serious money is involved, companies tend to buy industrial equipment, depreciate it in 4 years and then buy new one.
That determines that overhead cost is a very large part of the total production cost.
Few months ago I saw new Doosan turning center with a 180K EUR price tag.
If it is depreciated in 5 years, it means 180/ (5*12) = 3000 EUR/month.
Is there something wrong with the main structure of machine after 5 years of usage?
From what I have seen - no.
There might be issues with CNC controls and electronics. Maybe guideways are starting to wear out.
Mostly the machines are in good shape to continue to work. There are so many examples (at least in EMC community) that machines with age of 20 and more years are still in service.

That is why I am convinced that it is much more cost-effective to mechanically retrofit machines every 5-7 years, spend 10K-15K EUR on renovating worn-out parts and continue using them. 5 years of service for such machine will cost as much as half a year of new machine.

How do You think, why chinese can produce everything cheaper?
It is not only low labor cost, but it is also low cost of their equipment and very tight planning on procedures.

I see incredible potential for reductions in cost of equipment.
Unfortunately that ice is so thick that it would take years to break it and change the way industry thinks.
Michael Dell managed to do that in PC industry 30 years ago.

Here is one "beautiful" example from my experience. Actually, this is the reason, why I started doing these CNC things:
I purchased used CNC machine. Its CNC controls were DOS-based. It worked fine, but the procedure to generate file and to load it in the machine was annoying. It took me close to 5 minutes just to copy the file from PC to machine - had to restart from OS with CAM package (win xp) to OS, which could run DOS as virtual machine (win 200, because MS Virtual PC did not support DOS guest on xp host), then start up virtual DOS machine on PC, restart CNC machine to create telnet connection, transfer file.
And guess what happened, if I found some small mistake in file? I had to start everything all over again.
After few months of working with it my patience was over and I asked the manufacturer, how can I get something more up-to-date and how much would that cost.
Their answer was - we do not cooperate with the authors of that CNC control system any more, so cannot do anything.
I wrote to the authors of the CNC controls with a question to provide me with an upgrade options to something more up-to-date, but they did not bother to respond at all.

I suspect that there are many situations, where particular equipment is not used, because there is no support resolve an issue or the support is too expensive (for example, I know a situation, when HDD drive in Siemens CNC controller died. Operators wanted to change it, but it turned out that it was not IDE or SATA HDD, but some proprietary Siemens interface HDD; the price tag for the HDD change was 5000 EUR).

Mach is a closed-source application. Its authors can stop releasing bug fixes or new versions any time. And this can be caused by variety of reasons, for example, Artsoft is bought by some of their industrial competitors just to get rid of it.
Or licence price can increase or something else can happen and Mach users would have tied hands in such a situation.

On the other hand, EMC is opensource:
* any user can fix any bug (by themselves or with a help from other users or by paid programmers, if the issue is critical and with a financial impact);

* my clients are independent from me, they can switch to any other specialist (inhouse or outsourced) to maintain their machines, if I stop providing my services, if they think my pricing is too high or if they think that I have bad attitude or whatever reason.


These are my reasons, why should anyone use EMC instead of Mach.
Is there any reason, why should anyone use Mach instead of EMC? I have not seen one yet.


TomKerekes, here is some reading about the internals of EMC, hopefully it answers some of Your questions and You and maybe others will find it interesting to read:
EMC internals

Viesturs

[ger21]

What I am trying to say is that additional hardware that would take the realtime part of the control, generate step signals, close feedback loop etc is _mandatory_ for reliable operation of Mach.

What about the tens of thousands of users that do use Mach3 reliably without additional hardware? For most users, your statement is totally incorrect.

I think that it is very close, because it actually is what the gantry style machines are about - there are 2 joints that need to be assigned to one axis. Mach is not able to distinguish that thus homing each side of gantry to its own home switch (that is needed to square the gantry and thus ensure correct machine's geometry _every_ time it is used) is possible, but requires unreliable workarounds. EMC capable to do it out-of-the box (with gantrykins).

What unreliable workarounds??? Check a box and Mach3 homes both sides of a gantry to their own switch. Out of the box.

b) different kinds of treating incoming signals (only few examples are mentioned):
- proper wiring in the machine to avoid any noise in the incoming signals require experience and sometimes also additional cost to avoid such a noise;
EMC is running in real-time, so it can reliably and predictably filter incoming signals to ignore the noise:
DEBOUNCE

Mach3 has a debounce setting as well. Not sure how it differs internally from EMC, but as long as it works, who cares?

2) visual look

Looks OK to me
Mach3 Screenshot

I am not saying that Windows is evil and Linux is saint, I see problems with Linux as well, but that is not even close to what I do not like about Windows.

This really sums up your entire post. You dislike Windows (and probably all things Microsoft) so you use Linux, which is better in all ways to Windows in your opinion.

[Bubba]

Viesturs
This is the most comprehensive analysis I have seen todate! Excellent presentation and Thank You.

[Al_The_Man]

Viesturs
This is the most comprehensive analysis I have seen todate! Excellent presentation and Thank You.

+1 on that!.
Al.

[Viesturs]

What about the tens of thousands of users that do use Mach3 reliably without additional hardware? For most users, your statement is totally incorrect.

I am not saying that Mach is not working. Just like You say, the number of its users speaks for itself.
I just think that it is not completely safe and there is higher risk for less precision. It does not mean that it always is there and that Mach is crap. I just think that non-realtime control with software step generation especially on a fast machine is a significant risk, which should be considered.

What unreliable workarounds??? Check a box and Mach3 homes both sides of a gantry to their own switch. Out of the box.

The only thing for gantry machines I have seen are breakout boards, where X or Y step and dir signals are cloned to the slave joint, so Mach is not aware, if there are 3 or 4 joints and, even it was aware, it cannot stop one and keep the other moving.

I will give You an example from my experience:
On one of the machines I retrofitted I saw some awkward solution, where homing switch operated a relay, which interrupted step signal wire, that way stopping the motor movement. Since Mach was not receiving the signal from homing switch, the homing procedure basically was: user is jogging all the axes towards their home and once all motors stop, manually zero all coordinates.
Since that machine is used in producing large series of equal parts, there are fixtures for material.
The machine executes one of the last operations for these parts and since the part already has its final dimensions, the machine has to be very good on repeat-ability. And it consists of 2 parts:
1) Since material in that machine is fixed in the same position all the time, it is very crucial for the homing to be very repeatable, but it was not. It was deviating for some fractions of mm (something around 0,1 mm), but that could be seen on the parts.
2) Also repeat-ability of trajectory deviated and it ruined parts. I checked for any problems with step/dir signal wires and possibility of noise there.

That machine confirmed in practice my conclusion from the first point of this post - cnc control on non-realtime OS in combination with software step generation is disaster.
Probably it may be attributed to the fact that it was illegal copy of windows. I am not sure, if they had bothered to acquire Mach licence either.
Probably there was curved hand problem with the guy, who initially set the machine up.

Mach3 has a debounce setting as well. Not sure how it differs internally from EMC, but as long as it works, who cares?

Ok, if there is this thing, then please provide a link, which explains, how.
I do not see a way, how Mach can reliably, predictably and with repeatedly equal performance filter signal noise, where pulses are 1-5 ms long, if there are buffers between breakout board and Mach and there are very likely to happen disrupts that exceed the length of the noise pulse?

And what about acting on rising or falling edge?

And is there anything like "and" gate?
AND2

Actually, there more than 100 such components (including kinematics modules), that can do almost any logical function:
Realtime Components List
And even if there is none for particular problem, it is easy to modify any of them.

Looks OK to me
Mach3 Screenshot

I agree that this one looks acceptable. Unfortunately it is not possible to determine, if there is anything blinking and changing colors (for example, borders of some button or letters). Other than that it seems to be the best Mach screen I have ever seen.
So why can't the default gui be like that? Or at least something close to that? Now user has to spend his time and effort to make that app usable.

This really sums up your entire post. You dislike Windows (and probably all things Microsoft) so you use Linux, which is better in all ways to Windows in your opinion.

I have been using Windows for 10+ years. Actually I still am using it, because there is no equivalent for SolidEdge (basically the same as SolidWorks) on Ubuntu.
My point was not starting the neverending arguing, which is better. It does not matter - I will not immediately convince You or anybody else, that is not my intention. Both of those OS have their strengths and weaknesses.
What I wanted to say is that, unlike >80% Windows users, I do have seen and experienced, what does Linux mean and I just would like to encourage to try it out and not be afraid of those "I have heard somewhere that somebody's friend had a terrible experience 10 years ago" opinions.
The learning curve is much less steep than majority thinks.

Viesturs