[ger21]

Gerry,

Dell, HP and Lenovo are all selling PC's and laptops configured with Linux.

Linux Open Source Solutions | Dell

HP Open Source and Linux - Linux for HP Workstations

Linux for Personal Systems

I'm seeing a lot of new laptops, desktops and servers at work coming in with Linux rather than Windows as the OS.

Mark

You didn't provide any links to desktops or laptops for sale, and I couldn't find any at Dell, other than servers.

[ad_bfl]

Gerry
It's a EMC vs Mach3 thread not Windows vs Linux.
I am following this thread to learn something about the functionality, versatility and usability of those two applications. I have my own opinion in the Windows versus Linux issue but is not belonging here.

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

[samco]

embeddedgurus? I am sure they are biased..... They are into embedded systems.. ( probably in the same way I think emc is the best )

Is an RTOS really the best way to design embedded systems? « State Space

I hate RTOSes « State Space

[ftkalcevic]

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.

[ad_bfl]

embeddedgurus? I am sure they are biased..... They are into embedded systems.. ( probably in the same way I think emc is the best )

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.

[chester88]

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

[ad_bfl]

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.

[wendtmk]

You didn't provide any links to desktops or laptops for sale, and I couldn't find any at Dell, other than servers.

You originally said you couldn't find any major manufacturers that sold the computers with Linux on them. You can get them from Dell, you just have to ask for it. Same for HP & Lenovo.

Mark

[Viesturs]

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.

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!

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.

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.

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

You're kidding yourself if you think a casual user is going to pick up Linux in an hour or two.

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

[samco]

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

[PCW_MESA]

I just got a Galil motion controller based project off the ground, and I have been using Mach3 and EMC both for a couple of years.

All I can say after having used this "industrial" strength Galil motion controller I will never go back to General purpose desktop CPU motion controller/environment, even a really good one with a RTOS like EMC, or a Mach3/smoothstepper combo.

Clean pulse trains, quick response to a E Stops, homing, syncing multiple servos, gearing, I/O, make the cost worthwhile.

One thing I have not read in this thread is issues with RTOS based solutions in general. Dig a bit in that direction, try writing some "real time" code on your RTOS of choice and suddenly a stand alone motion system based a CPU and a BIG FPGA make a lot of sense.

And before everyone starts talking about how expensive those solutions can become, look at the overall cost and the performance/results. IMHO it is like the difference between buying good tooling vs low end stuff, no comparison.

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

[ad_bfl]

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.

[andypugh]

Yes, it is. What percentage of PC users run Linux? 5%?
Even if it were 10%, that means 9 out of 10 people choosing control software would most likely prefer something that runs in windows, due to their familiarity with it.

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.

[andypugh]

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.

That is a familiarity thing, I guess, though.
I taught myself C because I had an Ardunio project, and moved on from that to writing drivers for EMC2 (again, in C).
I have no idea how to write _non_ realtime code. I wouldn't know where to start :-)

[datac]

If you need 'jog while paused' use Mach - EMC doesn't allow this

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.

[samco]

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

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.

[chester88]

The 'hack' was actually jog while at toolchange. it replaced the manual toolchange prompt component.

[samco]

Yes - there you go. (like I say - I have not felt like I was missing it)

sam

The 'hack' was actually jog while at toolchange. it replaced the manual toolchange prompt component.

[andypugh]

I would assume EMC has an easy way to start where you left off ?

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.

The statement has also made me curious if EMC has any ability to allow you to manually jog an axis while running code

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.

[MrWild]

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

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.