Quote Originally Posted by BobWarfield View Post
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!

(chair)

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.