Gerry
UCCNC 2017 Screenset
http://www.thecncwoodworker.com/2017.html
Mach3 2010 Screenset
http://www.thecncwoodworker.com/2010.html
JointCAM - CNC Dovetails & Box Joints
http://www.g-forcecnc.com/jointcam.html
(Note: The opinions expressed in this post are my own and are not necessarily those of CNCzone and its management)
IMHO it is RTOS (EMC) vs Kernel level hack (Mach 3 no hardware assist) vs Hardware (Galil, Delta Tau) discussion.
and the more I learn about using a RTOS on a general purpose CPU vs VHDL and a FPGA, I fall in the later camp.
BTW: My RTOS experience is limited to VXWorks for the FIRST Robotics competition world of which I am a Mentor.
Welcome to the FIRST Robotics Competition | USFIRST.org
and if your really looking to get in the mud, read these ->
Is an RTOS really the best way to design embedded systems? « State Space
I hate RTOSes « State Space
My two cents... (I may have posted this in another thread - my apologies)
I started with Mach on a slaved router with a G100. After a couple of years messing around with the G100 that never eventuated, I swapped to the smooth stepper. That had bugs with the axis slaving, and after a couple of years of waiting for bug fixes, I gave up and moved to emc.
I'm using cheap atom motherboards with a mesa 5i20 to do closed loop control of my slaved mill. I found some bugs immediately with slaved axis (max speed problems) and fixed them myself in 30 minutes.
When it came to cnc'ing my lathe, I didn't even consider mach because of its one pulse per revolution spindle sync. There is no way it could thread properly on my underpowered lathe.
For me, it was the open source-ness of emc that won me over.
Oh Yeah
VERY BIASED, but a fun read and there are some good points, especially around event based stuff & HSM's.
Fundamentally, I am a crappy developer.
Outside the "hello World" level stuff I find a RTOS to be hard compared to a VHDL/FPGA solution, especially when I roll in lots of I/O and some of it needs to respond with various qualities of service, such as when I am homing to a switch and I need that chain to be VERY low latency and no jitter.
So for me, a RTOS combined with the skill required to write solid C/C++ code is more time consuming than a VHDL solution, which given it's large pincount and parallel RTL level execution environment is plain easier.
BTW: my Mill is a Mach3/Smothstepper solution, VERY happy with it, lots of user threads to help solve problems.
MY "projects" are not typical CNCZone stuff. Given that I asked around with folks who do a LOT of this stuff (and they get paid very well in the process) and they pointed me to Galil.
Very happy, I can write motion specific code in their DSL, integrate with external processes via some simple C++ and a Ethernet link, and lots of good tools and a small but decent forum.
I do hope that as Gecko goes down this trail, he keeps in mind the tooling required to make it successful, meaning the tools required to execute, debug, monitor and manage the whole lifecycle of the app living in his FPGA/controller. Without that stuff, it is a expensive paper weight.
Well low latency feedback is what EMC is all about ( You must of course qualify 'low' )
In general you don't need to write C++ code (but you could if you want, C is more common).
Emc has a 'language' called comp which hides the low level boiler code required for realtime code. Comp uses C behind the scenes, in fact if your component is complicated you add C code to the comp program. There are many Comp programs included with EMC that can be 'wired' together to form complex tasks without writing any realtime code.
I agree with the money issue of windows verses linux being a wash.
I don't see the big barrier between using Linux vrs Windows especially if you are using it just as a machine controller.
But I do understand it is a barrier for people. The unknown scares people.
Anyone interested in machines beyond a basic stepper mill would have no problem switching to a different OS. Machinists use OEM controls are the time - the old ones don't use a PC OS at all.
But when your talking basic 3 axis stepper mill machines try them both. It's relatively cheap and only takes a little time.
If you like to tinker 'under the hood' EMC is your choice.
If you want to service your own machines EMC is a good choice.
If you have odd machines to run EMC may be the choice.
If EMC does what you want and something else doesn't - EMC
If you want ( and are capable or can get someone else to ) to add a function to the controller EMC is probably the best chance.
If you want true closed loop control without buying a proprietary (expensive?) black box Who's motion control functions can not be expanded - the use EMC
If you want to learn the very least to run a machine use Mach ( it's Windows )
If you think that a user base of tens of thousand people gets you better advice - use Mach
If custom screens are your thing - for now use Mach.
If you need 'jog while paused' use Mach - EMC doesn't allow this.
If you want to use a USB motion controller box use Mach
At this point I am not even talking about EMC vs Mach3, that horse has been beaten to death.
What I am trying to say is that at times one should consider using a FPGA and/or a FPGA with a CPU vs a CPU with a RTOS.
Simple Intel D525MW mini-ITX board with on-board dual-core Atom CPU, which cost ~100 USD, gives around 10K ns latency. If second core is isolated just for real-time tasks (with isolcpus boot parameter), then those numbers decrease even more.
I have built 4 such machines and have tested that.
Is 10 us latency low enough?
Just as Chester said, low-latency (meaning - real-time) performance is what EMC is about!
Ok, I agree that running _only_ machine control on a CPU without any OS at all would be best solution - there would be less load to CPU thus faster response and less jitter, less code to maintain and less chance for something to go wrong.Originally Posted by ad_bfl
There are attempts to port EMC to ARM processors, but I do not know, how far is that.
I think that current situation, that EMC comes on Ubuntu LTS distributions with RTAI kernel is optimal solution:
1) Ubuntu is very easy to install, so even newbies can easily set machine up;
2) RTAI ensures stable real-time performance;
3) there is fully capable OS for connecting to web or running CAM application
I think You are kidding Yourself, if You think that casual user will start compiling something and do whatever more than just install Ubuntu, install EMC (both are installed together with less than 15 mouse clicks from liveCD) and start setting up EMC for his particular machine - either by starting with any of existing sample configurations or by using Stepconfwizard or Pncconf.Originally Posted by BobWarfield
Finding appropriate menu entry to launch EMC takes less than a minute, finding a folder with sample configs takes approximately the same.
The same is for Mach - why would casual Mach user need some deep knowledge about Windows? Ok, he/she would have to know, how to download and install an application, because that is not automated. And that is it, rest is configuring the application itself, non-OS related stuff.
EMC is provided with manuals, so anyone interested in very basics of EMC has a lot of materials available for reading.
Oh - that is one thing... Emc is an installed program on the livecd - when you install the emc/ubuntu live cd you get emc . It then will get updated automatically with each new release of emc2. (unless it is a major version release - then you have to set the update manager to the new versions repository.. - and directions on how to update configs if any) (I am paraphrasing)
sam
Why would you want an added hardware box to patch the lack of real time performance in your main CPU OS?
As far a user level RTOs problems go they seem to be pretty much non-existent with EMC/RTAI (this is user level real time HAL and components)
Why not just run everything (as EMC does) in one place with a modern PC that has many times the performance of the external box. A CNC machine will likely have PC control of some type anyway, you not use the PC as the highest performance embedded processor you can get?
This results in a cleaner open architecture (not an old fashioned drip feed buffered system driving a proprietary external box)
More and more high performance motion systems are getting away from this old fashioned buffered approach with high speed real time links driven from (guess what) a RTOS on a PC! This includes Ethercat and Sercos III based systems
A buffered system with multiple loci of control is inherently more complicated and limited than a system with a common temporal control locus.
There are definitely systems where external control boxes are needed, for example where greater than about 10 KHz control loops are required, but these are not normal CNC systems.
The great thing about EMCs architecture is that if a real time feature is added
it becomes available to _all_ EMC users, not just the ones who happen to have the right external box. This includes features like rigid tapping, threading, probing, gearing, kinematics and reverse kinematics, all kinds of spindle synchronized motion etc. All real time motion
Everyone keeps dragging this back to EMC and CNC context which is very appropriate given the nature of the forum.
Given I am a crappy developer, I find it easier to spawn off the time critical stuff and motion control to standalone hardware, and leave the rest in the desktop/server.
That seperation of concerns is likely why we are having this debate.
All my Opencv Image processing stuff runs just fine in my server and I leave all the motion control stuff to the Galil hardware. If I crash my server processing some ugly images, the motion system keeps right on chugging making product.
In the CNC context, there is a LOT of human interaction on the loop, not so much in my use case, that is why I am drawn to a more standalone motion solution vs a EMC type approach.
I do think the emc stuff is real neat, I went so far as to buy the RCS handbook to understand the basis for EMC, and dug into the RTAI stuff. Hats off to that community.
One question for the EMC crowd, FreeRTOS - can EMC be ported to it? I have no clue about the acceptance of RTAI, but I do see a lots of FreeRTOS.
Also, I suspect that most folk setting up their first CNC machine expect to be using their everyday computer as the controller. Even if they expect to switch to a dedicated PC later they probably start with their everyday computer, and so that will mean Mach for them.
I suspect the only reason I started with EMC2 was that my everyday computer is a Mac, so there was no way that was going to be the CNC controller.
I think most folk setting up their second CNC build probably go straight to a dedicated (and often "embedded", ie bare motherboard inside equipment case) approach. This might be why you occasionally find trans-controlluals with an older Mach box and a newer EMC2 box :-)
.Set up a a stepper driven machine only using software and the parallel port. Is EMC somehow much safer than Mach3? I don't see it
Well, I have heard one tale of a Mach3 machine running away. This was a parport, stepper, software pulse machine, so a runaway seems a very odd failure mode. I don't want to read too much into that, though, as I don't know the full story, and EMC2 has had occasional out-of-control bugs at times.
H'mmm... found that interesting. I often do a feedhold for replacing a bit then just going back to where I paused or slightly before. I would assume EMC has an easy way to start where you left off ?
The statement has also made me curious if EMC has any ability to allow you to manually jog an axis while running code ? Or if Mach can for that matter ?
I don't currently use either, but have downloaded the EMC ISO to drop on a spare PC. It will be real easy for me to try it on a small engraver standing here.
Chris L
I have posted in other threads where this has come up. I didn't know I was missing jog while paused... Run from line works perfectly for me. there was actually a hack some one made that allowed jog while paused but all it was was a automated 'run from line'
If someone wants to add it - patches are welcome
sam
The 'hack' was actually jog while at toolchange. it replaced the manual toolchange prompt component.
Yes, and no.
You can start from any program line, though some elements of the machine state are not "sticky" so you have to turn the spindle and coolant back in in MDI typically. You also need to position the tool somewhere where re-starting the G-code will have the right result. Run-from-line is also not ideal if, for example, you are 4 feet into a 5 foot cut in steel which takes 30 minutes.
I am not sure why you would want to (perhaps engraving something which keeps moving) and you can't do it in standard EMC2. However if you knew you were going to want to do so you could insert an "offset" function in your HAL linked to an onscreen spinbox or physical encoder without too much trouble.The statement has also made me curious if EMC has any ability to allow you to manually jog an axis while running code
Simple answer is tracking error. closing the loop in hardware includes a real time tracking error. A pulse train tells a drive to 'go here." The drive starts moving and moves to "here." There is a slight time delay between commands and execution. because of not knowing exactly. Minor to be sure but there is a reason a hardware derive will fault out if the tracking error becomes too large.
Lets say the Y axis is holding steady while the X axis is plowing along and starts lagging the pulse stream. It won't be much of a lag or it will fault out, yet there is a lag up to several thousandths. While the X is lagging, Y is ordered to move. Suddenly you are not making parts to print.
With EMC, you have a control that flat knows where the Axes are. If something is lagging, EMC knows not to move any other axis until it is where it should be before the move. Mach can't do this by the very nature of how it makes controls work.
If all you are doing is steppers, Mach is just fine. When you go to servos, I think I want a control that doesn't allow for lag. EMC is the smart choice for that picture. Why do I use EMC? I'm cheap and figured as long time ago I only wanted to learn a control once. The only real whines about EMC are that it has a steep learning curve. It isn't that steep. Way less than Pro E. About on par with AutoCAD for dificulty.