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