Thread: [Emc-users] Prempt RT on Linux Mint

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Is it possible to build the Prempt-RT kernel on Linux Mint 13 based on 
Ubuntu Precise or Linux Mint 17 based on Ubuntu Trusty? This is to be 
able to use LinuxCNC uspace with a 7i92.

Thanks
JT

i dont see why not , but the patch will be different probably , i'd need to
try it
why use ubuntu ? , thats another can of worms to get in the way .

debian now has the 2 desktops that minit as

things are moving away from ubuntu ,for lots of reasons , some of it is a
bit deeper , such as python bindings and servicing things such as
rt-preempt , kernels etc
they are now becoming vastly different . from what they were a few years
ago . and will become a even bigger nightmare over the next few years
which will mean ubuntu will not be able to be supported .

On 2 February 2016 at 12:42, John Thornton <jt...@gn...> wrote:

> Is it possible to build the Prempt-RT kernel on Linux Mint 13 based on
> Ubuntu Precise or Linux Mint 17 based on Ubuntu Trusty? This is to be
> able to use LinuxCNC uspace with a 7i92.
>
> Thanks
> JT
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

-- 

The information contained in this message is confidential and is intended
for the addressee only. If you have received this message in error or there
are any problems please notify the originator immediately. The unauthorised
use, disclosure, copying or alteration of this message is strictly
forbidden. This mail and any attachments have been scanned for viruses
prior to leaving the RcTechnix network. RcTechnix will not be liable for
direct, special, indirect or consequential damages arising from alteration
of the contents of this message by a third party or as a result of any
virus being passed on.

RcTechnix reserves the right to monitor and record e-mail messages being
sent to and from this address for the purposes of investigating or
detecting any unauthorised use of its system and ensuring effective
operation.

(c) RcTechnix

On 02/02/2016 04:56 AM, Sarah Armstrong wrote:
> i dont see why not , but the patch will be different probably , i'd need to
> try it
> why use ubuntu ? , thats another can of worms to get in the way .
>
> debian now has the 2 desktops that minit as
>

Why use this, why not use that? This is precisely why LinuCNC has no 
traction in commercial products. Unless things have changed in the last 
2 months, you cannot find a single CNC machine or good kit on the market 
that comes with LinuxCNC. There are two or 3 that mention LinuxCNC as a 
possibility but they do not support it. Why?

That's because NOBODY (manufacturers or distributors) wants to futz with 
testing motherboard latencies, problems with their obsolescence, IO 
boards, controllers, USB issues, etc. All that is a big concern to 
anybody who wants to see LinuxCNC as part of their business.

I asked a number of manufacturers at Makerfaire and other trade shows 
and they either don't know about linuxCNC or simply state it's not a 
good option for them. They all use something or the other that runs on 
Windows PCs only.

LinuxCNC and similar products need to run and be supported for 10+ years 
in order to be accepted by the industry. So far I mostly see LinuxCNC 
being used for retrofits of all kinds of old machines. That's great but 
it is not available in new machines.

Take http://www.cncrouterparts.com for example. They will tell you (at a 
trade show) it's possible to use LinuxCNC but they do not provide such a 
solution. They do support commercial program on alternative OS and USB 
connection. Why? It's too hard to meet LinuxCNC related hardware 
requirements. Especially motherboards.

This is where my problem lies. When I tried to recommend a kit like the 
above to a relative in EU, I get a question about software support right 
away. They could put HW things together, but there is also software. 
They would be OK with LinuxCNC based on my recommendation but I cannot 
be there to help put things together. The easiest option for them 
becomes a machine with software that only runs on Windows even though it 
becomes obsolete or unsupported in a couple of years. I'm sure this is 
not an isolated case.

Somebody mentioned about his interest in starting LinuxCNC related 
business last summer if I remember correctly. I did not see any 
enthusiastic support for his idea on this list. I hope that this is 
changing with "Mesa Reseller in America", a good start but it's not a 
complete solution. I wish John Thornton well, to run successful 
business, and possibly expand on his offering with complete LinuxCNC 
solution from electronics, mechanical hardware (motors, drivers, 
sensors), to software.

> things are moving away from ubuntu ,for lots of reasons , some of it is a
> bit deeper , such as python bindings and servicing things such as
> rt-preempt , kernels etc
> they are now becoming vastly different . from what they were a few years
> ago . and will become a even bigger nightmare over the next few years
> which will mean ubuntu will not be able to be supported .

This leads me to believe there are architectural issues with LinuxCNC 
platform. I could not find roadmap on the website to have a better 
understanding where this is going, short and long term support, and 
upgrade path. All that is important to manufacturers of CNC machines and 
retrofit kits.

A case for different CNC sizes and related COTS hardware could be made 
to match 3 or 4 most common LinuxCNC configurations.

In addition, I believe that linuxCNC needs to be split into two parts 
and "sold as such" by default:
- headless LinuxCNC with hard RT kernel to run on different SBCs to 
handle all CNC IO
- GUI frontend, local or remote, connected to Linux workstation or 
modern tablet over USB, ethernet, or WiFi. Countless digital tablets can 
be had for under $100 that could serve as CNC UI.

A number of open source SBCs are out there ready for CNC use. Open 
source means they can be reordered through independent manufacturers 
years later if need be. Some are better for this than the other, but 
most are fast to handle most CNC tasks without GUI.

There is much more that comes to mind but this is long already.

> On 2 February 2016 at 12:42, John Thornton <jt...@gn...> wrote:
>
>> Is it possible to build the Prempt-RT kernel on Linux Mint 13 based on
>> Ubuntu Precise or Linux Mint 17 based on Ubuntu Trusty? This is to be
>> able to use LinuxCNC uspace with a 7i92.
>>
>> Thanks
>> JT

Open for discussion.

-- 
Rafael

answer/comment in line

On Tue, Feb 2, 2016 at 2:08 PM, Rafael <ra...@li...> wrote:

> On 02/02/2016 04:56 AM, Sarah Armstrong wrote:
> > i dont see why not , but the patch will be different probably , i'd need
> to
> > try it
> > why use ubuntu ? , thats another can of worms to get in the way .
> >
> > debian now has the 2 desktops that minit as
> >
>
> Why use this, why not use that? This is precisely why LinuCNC has no
> traction in commercial products. Unless things have changed in the last
> 2 months, you cannot find a single CNC machine or good kit on the market
> that comes with LinuxCNC. There are two or 3 that mention LinuxCNC as a
> possibility but they do not support it. Why?
>

There is no market for commercial LinuxCNC.
I have considered it.
I even had a commitment by a machine manufacturer to supply me with new
machines without controls.
Maybe there would be a market. Maybe I just didn't want to do it. Maybe I
just don't care if there is or is not a market.
Probably because I like it the way it is.

>
> That's because NOBODY (manufacturers or distributors) wants to futz with
> testing motherboard latencies, problems with their obsolescence, IO
> boards, controllers, USB issues, etc. All that is a big concern to
> anybody who wants to see LinuxCNC as part of their business.
>

If one could identify a market and wanted to do it then it would exist no
matter the obstacles.

>
> I asked a number of manufacturers at Makerfaire and other trade shows
> and they either don't know about linuxCNC or simply state it's not a
> good option for them. They all use something or the other that runs on
> Windows PCs only.
>

The people at Makefaire and other trade shows have a different agenda.
Their focus is the products the control is included in or the products made
with the controls.
LinuxCNC is the focus of most everyone using LinuxCNC.

>
> LinuxCNC and similar products need to run and be supported for 10+ years
> in order to be accepted by the industry. So far I mostly see LinuxCNC
> being used for retrofits of all kinds of old machines. That's great but
> it is not available in new machines.
>
I agree. It allows someone to scratch the itch of putting together a cheap
machine AND making the machine to intensely sweet things.

>
> Take http://www.cncrouterparts.com for example. They will tell you (at a
> trade show) it's possible to use LinuxCNC but they do not provide such a
> solution. They do support commercial program on alternative OS and USB
> connection. Why? It's too hard to meet LinuxCNC related hardware
> requirements. Especially motherboards.
>
It is not difficult to run LinuxCNC on most any motherboard.
If you can accept less than hard real time control then LinuxCNC will do
anything and more than any other control on the market.
When you MUST have fast, hard real time control then LinuxCNC is the ONLY
answer. This drives the 'hard to meet' requirements of LinuxCNC.
The LinuxCNC world does emphasize the hard real time world while telling
people it might be better to use a different product if you don't need the
capabilities of LinuxCNC. I certainly don't disagree with this.
I would venture to say most of the people in the 'other than LinuxCNC'
world would not recognize problems related to less than real time control
issues. The motion issues and any other issues would not be a problem to
most of them.
So what? Who cares - if they are happy with what they have and do not feel
the need to research it any farther the let them be.

> This is where my problem lies. When I tried to recommend a kit like the
> above to a relative in EU, I get a question about software support right
> away. They could put HW things together, but there is also software.
> They would be OK with LinuxCNC based on my recommendation but I cannot
> be there to help put things together. The easiest option for them
> becomes a machine with software that only runs on Windows even though it
> becomes obsolete or unsupported in a couple of years. I'm sure this is
> not an isolated case.
>
In my opinion software support is one of the strong suits of LinuxCNC. You
ask for help - you get help. Many times you are overwhelmed with help.
There is not just one source for help. You find help all over the world.
If you do not wish to learn about the software and how to manipulate it
then you will have problems with ANY control you wish to install.
Every control needs some type of configuration to tune it to the machine.
If you refuse to learn how to configure whichever software you choose to
use then you will be very handicapped trying to use the control and machine.

>
> Somebody mentioned about his interest in starting LinuxCNC related
> business last summer if I remember correctly. I did not see any
> enthusiastic support for his idea on this list. I hope that this is
> changing with "Mesa Reseller in America", a good start but it's not a
> complete solution. I wish John Thornton well, to run successful
> business, and possibly expand on his offering with complete LinuxCNC
> solution from electronics, mechanical hardware (motors, drivers,
> sensors), to software.
>
I certainly wish JT well in his business.
With what I know of him in the LinuxCNC world he would have a good chance
to make a success of a complete LinuxCNC control offering. If he would
choose to do it.

>
> > things are moving away from ubuntu ,for lots of reasons , some of it is a
> > bit deeper , such as python bindings and servicing things such as
> > rt-preempt , kernels etc
> > they are now becoming vastly different . from what they were a few years
> > ago . and will become a even bigger nightmare over the next few years
> > which will mean ubuntu will not be able to be supported .
>
> This leads me to believe there are architectural issues with LinuxCNC
> platform. I could not find roadmap on the website to have a better
> understanding where this is going, short and long term support, and
> upgrade path. All that is important to manufacturers of CNC machines and
> retrofit kits.
>
> A case for different CNC sizes and related COTS hardware could be made
> to match 3 or 4 most common LinuxCNC configurations.
>
> In addition, I believe that linuxCNC needs to be split into two parts
> and "sold as such" by default:
> - headless LinuxCNC with hard RT kernel to run on different SBCs to
> handle all CNC IO
> - GUI frontend, local or remote, connected to Linux workstation or
> modern tablet over USB, ethernet, or WiFi. Countless digital tablets can
> be had for under $100 that could serve as CNC UI.
>
> A number of open source SBCs are out there ready for CNC use. Open
> source means they can be reordered through independent manufacturers
> years later if need be. Some are better for this than the other, but
> most are fast to handle most CNC tasks without GUI.
>
> There is much more that comes to mind but this is long already.
>
> > On 2 February 2016 at 12:42, John Thornton <jt...@gn...> wrote:
> >
> >> Is it possible to build the Prempt-RT kernel on Linux Mint 13 based on
> >> Ubuntu Precise or Linux Mint 17 based on Ubuntu Trusty? This is to be
> >> able to use LinuxCNC uspace with a 7i92.
> >>
> >> Thanks
> >> JT
>
> Open for discussion.
>
> SOMEONE needs to choose a motherboard/chip set to standardize on.
SOMEONE needs to choose I/O to standardize on (for every machine
type/style).
SOMEONE needs to choose a wiring diagram to standardize on (for every
machine type/style).

I am not SOMEONE I am only me. Count me out.

This a little sarcastic and tongue in cheek while being somewhat serious. :)
thanks
Stuart

> --
> Rafael
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

-- 
Addressee is the intended audience.
If you are not the addressee then my consent is not given for you to read
this email furthermore it is my wish you would close this without saving or
reading, and cease and desist from saving or opening my private
correspondence.
Thank you for honoring my wish.

On Tue, 2 Feb 2016, Rafael wrote:

> Date: Tue, 2 Feb 2016 12:08:59 -0800
> From: Rafael <ra...@li...>
> Reply-To: "Enhanced Machine Controller (EMC)"
>     <emc...@li...>
> To: "Enhanced Machine Controller (EMC)" <emc...@li...>
> Subject: Re: [Emc-users] Prempt RT on Linux Mint
>LinuxCNC and similar products need to run and be supported for 10+ years 
>in order to be accepted by the industry. So far I mostly see LinuxCNC 
>being used for retrofits of all kinds of old machines. That's great but 
>it is not available in new machines.
>
>Take http://www.cncrouterparts.com for example. They will tell you (at a 
>trade show) it's possible to use LinuxCNC but they do not provide such a 
>solution. They do support commercial program on alternative OS and USB 
>connection. Why? It's too hard to meet LinuxCNC related hardware 
>requirements. Especially motherboards.

This might be true with parallel port software stepping systems that require a 
high speed base thread for pulse generation and perhaps encoder counting,
but is not the case at all for servo thread only systems, that is systems
that have hardware step generation and encoder counting or Ethercat based 
systems where all the high speed logic is on the drive.

Almost any current motherboard will work with acceptable latency for a servo 
thread only system. With the right I/O hardware and tuning, 100s of usec of
jitter can be tolerated meaning its difficult to find a motherboard 
that does not work

Peter Wallace
Mesa Electronics

On 2 February 2016 at 22:45, Peter C. Wallace <pc...@me...> wrote:
> This might be true with parallel port software stepping systems that require a
> high speed base thread for pulse generation and perhaps encoder counting,
> but is not the case at all for servo thread only systems,

I don't think that it is necessarily the case even with parport-only
systems. There seems to be an obsession with getting super-low latency
and a concomitant belief that unless you can get into single-digit
microseconds you might as well give up.
In practice few stepper systems have hardware that can follow even a
50uS base-thread. I spend a lot of time on the forum saying "Stop
fiddling, it's fine as it is, get on with something productive"

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

> ... There seems to be an obsession with getting super-low latency
> and a concomitant belief that unless you can get into single-digit
> microseconds you might as well give up.

It is small delays happening every now and then that cause problem, there migth be in average one warning per minute for these.

A perfect example of a real time task is a receive buffer communication port which will trigger a task then half hulf. If dead line is missed data is gone and need to be sent again.

Nicklas Karlsson

On 2016-02-02 23:59, andy pugh wrote:
> On 2 February 2016 at 22:45, Peter C. Wallace <pc...@me...> wrote:
>> This might be true with parallel port software stepping systems that require a
>> high speed base thread for pulse generation and perhaps encoder counting,
>> but is not the case at all for servo thread only systems,
> I spend a lot of time on the forum saying "Stop
> fiddling, it's fine as it is, get on with something productive"
>

Hehe, you mean "Stop fiddling with computer problems, get on with fiddling mechanical problems"
:)
The problem of this perpetual discussions is,
all are right with their views but just to prove the own view some points are omitted.

-- 
"In der Wissenschaft siegt nie eine neue Theorie,
nur ihre Gegner sterben nach und nach"

Max Planck

On 02/02/2016 02:59 PM, andy pugh wrote:
> On 2 February 2016 at 22:45, Peter C. Wallace <pc...@me...> wrote:
>> This might be true with parallel port software stepping systems that require a
>> high speed base thread for pulse generation and perhaps encoder counting,
>> but is not the case at all for servo thread only systems,
>

Parallel port is a monkey business. It was never meant to be used as 
such. I know, it started as a cheap IO for simple installations but 
that's not a viable solution now with FPG based interfaces such as Mesa 
cards, USB3.x, etc.

> I don't think that it is necessarily the case even with parport-only
> systems. There seems to be an obsession with getting super-low latency
> and a concomitant belief that unless you can get into single-digit
> microseconds you might as well give up.

Yes, this "obsession with low latency" is a concern that comes up on 
this mailing list every once in a while. PC architecture is not the best 
for handling RT, however, most CNC should not depend on millisecond 
latencies on generic motherboards. That should be handled by the 
interface/controller independently from programs running in user space. 
It makes no sense to me to use modern motherboard and enable only one 
CPU core out many to ensure RT and low latency.

For example, Digital minicomputers were much slower compared to PC 
motherboards, yet they were able to handle industrial applications just 
fine. Application ran in RT OS to handle DIO or analog signals.

Old PDP HW is getting replaced with special PC cards that are able to 
run original software while generic Windows runs on the PC. No latency 
issues. Same should be possible with LinuxCNC IMO.

> In practice few stepper systems have hardware that can follow even a
> 50uS base-thread. I spend a lot of time on the forum saying "Stop
> fiddling, it's fine as it is, get on with something productive"
>

Agree. 3D printing world is growing precisely because of dedicated SBCs 
built with low cost microcontrollers and motor drivers. They handle 
everything including UI for selecting files from tiny memory cards.

Large CNC systems require more computing power of course, but that too 
should not be a problem for decent IO cards independent of motherboard 
latency.

-- 
Rafael

The problem is the EMC2 is an old program designed when hardware was
different.  Today no one would design it as one big app that runs on a
a PC with an RT OS.

Starting over from scratch I'd put the real-time functions on a low
cost commodity single board computer.  One of the best is Texas
Instrument's "launch pad" series.   They start at $12 for an ARM based
SBC.  These are well supported by a big company (TI) that is not going
away soon.   There are others like Beal Board and Pi.  Each of these
boards can have very good timing.   Then you build the GUI to run on
some other platform such as a tablet or phone or web browser or
whatever

The problem is that everyone reading this likely has a day job and
many other things to do and does not want to re-implement software
that works well already.   Maybe you don't have to start over?  Write
a driver for a common SBC and let al the timing be done there.  Then
the hardware for the rest of LinuxCNC is not critical, any old
notebook would work.

Is the interface for drivers documented?

End users WILL buy Linux based solutions only if they never have to
know Linux is inside.  We have proof of this because currently more
people own Linux based computers then Windows.  All those Android
phones and tablets are Linux as are a good percent of home routers, TV
set top boxes and even the firmware inside some printers.  It might
even be the #1 OS in the world right now.   But no one wants it if
they have to learn anything new they want the OS hidden inside the
device.

My interest in CNC is to build robot parts.  Robots are a lot like CNC
machines in that they use steppers, serves and DC motors (some times
all of these on one robot.)  But typically they have many more degrees
of freedom then does a CNC mill but require much less precision.  None
the less the problems are similar.   in the last few year a control
architecture has become popular for robots called "ROS"
> Agree. 3D printing world is growing precisely because of dedicated SBCs
> built with low cost microcontrollers and motor drivers. They handle
> everything including UI for selecting files from tiny memory cards.
>
> Large CNC systems require more computing power of course, but that too
> should not be a problem for decent IO cards independent of motherboard
> latency.
>
>
> --
> Rafael
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-users

-- 

Chris Albertson
Redondo Beach, California

This is exactly what the Machinekit fork of LinuxCNC is for.  Check it
out at http://machinekit.io .  It runs on BeagleBoneBlack's, RaspberryPi2's,
and a variety of other ARM boards with and without FPGA's, as well as
PC hardware.  All bleeding edge under heavy development, so support
is much sketchier than LinuxCNC, although the developers will answer
questions from people who are diligent in researching their problems
and posing concise questions.

-- Ralph
________________________________________
From: Chris Albertson [alb...@gm...]
Sent: Wednesday, February 03, 2016 7:35 AM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Prempt RT on Linux Mint

The problem is the EMC2 is an old program designed when hardware was
different.  Today no one would design it as one big app that runs on a
a PC with an RT OS.

Starting over from scratch I'd put the real-time functions on a low
cost commodity single board computer.  One of the best is Texas
Instrument's "launch pad" series.   They start at $12 for an ARM based
SBC.  These are well supported by a big company (TI) that is not going
away soon.   There are others like Beal Board and Pi.  Each of these
boards can have very good timing.   Then you build the GUI to run on
some other platform such as a tablet or phone or web browser or
whatever

The problem is that everyone reading this likely has a day job and
many other things to do and does not want to re-implement software
that works well already.   Maybe you don't have to start over?  Write
a driver for a common SBC and let al the timing be done there.  Then
the hardware for the rest of LinuxCNC is not critical, any old
notebook would work.

Is the interface for drivers documented?

End users WILL buy Linux based solutions only if they never have to
know Linux is inside.  We have proof of this because currently more
people own Linux based computers then Windows.  All those Android
phones and tablets are Linux as are a good percent of home routers, TV
set top boxes and even the firmware inside some printers.  It might
even be the #1 OS in the world right now.   But no one wants it if
they have to learn anything new they want the OS hidden inside the
device.

My interest in CNC is to build robot parts.  Robots are a lot like CNC
machines in that they use steppers, serves and DC motors (some times
all of these on one robot.)  But typically they have many more degrees
of freedom then does a CNC mill but require much less precision.  None
the less the problems are similar.   in the last few year a control
architecture has become popular for robots called "ROS"
> Agree. 3D printing world is growing precisely because of dedicated SBCs
> built with low cost microcontrollers and motor drivers. They handle
> everything including UI for selecting files from tiny memory cards.
>
> Large CNC systems require more computing power of course, but that too
> should not be a problem for decent IO cards independent of motherboard
> latency.
>
>
> --
> Rafael
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-users

--

Chris Albertson
Redondo Beach, California

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Emc-users mailing list
Emc...@li...
https://lists.sourceforge.net/lists/listinfo/emc-users

On 02/03/2016 07:50 AM, Ralph Stirling wrote:
>
> This is exactly what the Machinekit fork of LinuxCNC is for.  Check it
> out at http://machinekit.io .  It runs on BeagleBoneBlack's, RaspberryPi2's,

I'll sure look into this.

> and a variety of other ARM boards with and without FPGA's, as well as
> PC hardware.  All bleeding edge under heavy development, so support
> is much sketchier than LinuxCNC, although the developers will answer
> questions from people who are diligent in researching their problems
> and posing concise questions.
>
> -- Ralph

Thanks Ralph. It's unfortunate that so much effort needs to go into 
somewhat parallel development but splits or forks like this needs to be 
done at some point. All large projects go through this eventually.

> ________________________________________
> From: Chris Albertson [alb...@gm...]
> Sent: Wednesday, February 03, 2016 7:35 AM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Prempt RT on Linux Mint
>
> The problem is the EMC2 is an old program designed when hardware was
> different.  Today no one would design it as one big app that runs on a
> a PC with an RT OS.
>

I suspected something like this but was afraid to bring it up not being 
a programmer. Thanks Chris for clarifying it.

I looked into source code recently. It's easy to tell that thousands of 
hours went into this product and that it went through different stages 
going all the way to NIST I think. It must be very difficult to modify 
any code because of it's structure when you are not poking around at 
least once a week or so.

> Starting over from scratch I'd put the real-time functions on a low
> cost commodity single board computer.  One of the best is Texas
> Instrument's "launch pad" series.   They start at $12 for an ARM based
> SBC.  These are well supported by a big company (TI) that is not going
> away soon.   There are others like Beal Board and Pi.  Each of these
> boards can have very good timing.   Then you build the GUI to run on
> some other platform such as a tablet or phone or web browser or
> whatever

You can add http://pine64.com/ too.

Problem with all those boards is in the fact that they have no common 
bus so that others could build standard interfaces on open architecture. 
All seem to be built to replace a PC with most of it's functionality.

Want to make a common box, bad luck. Everybody comes with their own 
silly PCB shape, hole positions, and names for add on boards, unsuitable 
connectors on all sides so you need space around them, or include chips 
that are not needed in embedded applications. Who needs audio or 4K 
video on 3D printer or small CNC machine?

In that regard we are back to early 80's or later when some interfaces 
did not work in different PCs even though the connectors were the same.

> The problem is that everyone reading this likely has a day job and
> many other things to do and does not want to re-implement software
> that works well already.   Maybe you don't have to start over?  Write
> a driver for a common SBC and let al the timing be done there.  Then
> the hardware for the rest of LinuxCNC is not critical, any old
> notebook would work.
>
> Is the interface for drivers documented?
>
> End users WILL buy Linux based solutions only if they never have to
> know Linux is inside.  We have proof of this because currently more

Not necessarily. However, embedded systems make Linux practically 
invisible as I've seen in Stratasys 3D printers.

> people own Linux based computers then Windows.  All those Android
> phones and tablets are Linux as are a good percent of home routers, TV
> set top boxes and even the firmware inside some printers.  It might
> even be the #1 OS in the world right now.   But no one wants it if
> they have to learn anything new they want the OS hidden inside the
> device.
>
>
Exactly. That's why CNC application should be split in two, controller 
side and user frontend that could reside in different computer, or even 
different OS.

> My interest in CNC is to build robot parts.  Robots are a lot like CNC
> machines in that they use steppers, serves and DC motors (some times
> all of these on one robot.)  But typically they have many more degrees
> of freedom then does a CNC mill but require much less precision.  None
> the less the problems are similar.   in the last few year a control
> architecture has become popular for robots called "ROS"

Cool. I'm aware of ROS.

Thanks both you guys for good feedback. I won't bug this list with this 
subject anymore.

-- 
Rafael

On Wed, Feb 3, 2016, at 11:49 AM, Rafael wrote:

> 
> Problem with all those boards is in the fact that they have no common 
> bus so that others could build standard interfaces on open architecture. 
> All seem to be built to replace a PC with most of it's functionality.
> 
> Want to make a common box, bad luck. Everybody comes with their own 
> silly PCB shape, hole positions, and names for add on boards, unsuitable 
> connectors on all sides so you need space around them, or include chips 
> that are not needed in embedded applications. Who needs audio or 4K 
> video on 3D printer or small CNC machine?
> 
> In that regard we are back to early 80's or later when some interfaces 
> did not work in different PCs even though the connectors were the same.
> 

Another problem with all these boards is that they have "flash in the pan"
life cycles.  The PC was a stable and viable platform for over two decades,
and you can make an argument that it will remain so for perhaps another
decade before finally disappearing.

RasPI and Beagle and all these other things have life cycles more in line
with smart phones - this year's new shiny is considered obsolete next year,
and the replacement is far less likely to be a "drop-in", so you wind up 
needing new breakout boards or other interface hardware.

-- 
  John Kasunich
  jmk...@fa...

On 02/03/2016 09:00 AM, John Kasunich wrote:
>
>
> On Wed, Feb 3, 2016, at 11:49 AM, Rafael wrote:
>
>>
>> Problem with all those boards is in the fact that they have no common
>> bus so that others could build standard interfaces on open architecture.
>> All seem to be built to replace a PC with most of it's functionality.
>>
>> Want to make a common box, bad luck. Everybody comes with their own
>> silly PCB shape, hole positions, and names for add on boards, unsuitable
>> connectors on all sides so you need space around them, or include chips
>> that are not needed in embedded applications. Who needs audio or 4K
>> video on 3D printer or small CNC machine?
>>
>> In that regard we are back to early 80's or later when some interfaces
>> did not work in different PCs even though the connectors were the same.
>>
>
> Another problem with all these boards is that they have "flash in the pan"
> life cycles.  The PC was a stable and viable platform for over two decades,
> and you can make an argument that it will remain so for perhaps another
> decade before finally disappearing.

You are right about "flash in the pan".

However, PC evolved a lot since it's beginnings. Need for ever higher 
data transfer and adoption for use as servers changed everything.

In order to fix a problem with one embedded system I had to pull out 
very old PC motherboard with IDE controller and old drive to get Linux 
working. Modern PC board would not work.

Buses are changing from mostly parallel to serial. PCI is going that way 
and USB3.x is very promising. It's direction most computer vendors are 
taking. Simplifies cabling over longer distances if nothing else.

> RasPI and Beagle and all these other things have life cycles more in line
> with smart phones - this year's new shiny is considered obsolete next year,
> and the replacement is far less likely to be a "drop-in", so you wind up
> needing new breakout boards or other interface hardware.

Isn't that frustrating? Original Beaglebone way different from the next 
generation, better but still not that great. You can't stack more that 2 
or 3 interfaces on one SBC, they have to be in correct order because of 
high connectors in some cases, and you cannot touch PCB in the middle 
with the scope probe.

I wish people would go to computer museum and see how others dealt with 
this kind of problems before they go to Kickstart or some such to start 
yet another SBC project for entertainment use mostly.

Computer history repeats itself it seems. Mainframes to PCs, and now 
back to "mainframes in the cloud".

-- 
Rafael

...
> Buses are changing from mostly parallel to serial. PCI is going that way
> and USB3.x is very promising. It's direction most computer vendors are
> taking. Simplifies cabling over longer distances if nothing else.

I went to school (computer engineering) in the late 70's' and early
80's back then parallel was always faster.  When serial busses started
outperforming parallel wires I was puzzled for a while then read up
some.  The reason for serial being faster is easy,   There is no
chance of "bit skew" with serial.   Bit Skew is when you have a
parallel cable and some bits travel "faster" because not all
conductors in the cable are equal.  Your max speed is limited by worst
possible case skew.   Serial can run a gigahertz speeds for kilometers
if need be.  A flexible parallel cable would never run that fast.
(But notice there ARE some multi channel serial cables)

At any rate this is the way the computer world is going you to NOT
design a card that pugs into a parallel buss like the old PCs have.
You now connect you device with a high speed serial cable.   Not need
to have a standard form factor.

I'd say that a modern CNC controller would connect to the computer
with either Ethernet or USB.  non-real time code would flow over the
serial cable
-- 

Chris Albertson
Redondo Beach, California

Yeah, and these "skewy" bits were the reason why in the days of parallel 
bus connections all operations had to be acknowledged on separate wires 
so it was made sure the bits had arrived correctly. This made 
connections slow, but terribly reliable. The DEC computer series like 
the VAXes were an example. This reliability was given up for the sake of 
speed, but at the same time, useless games becoming dominant in the 
computer world, it did not matter any more.

Peter

Am 04.02.2016 05:30, schrieb Chris Albertson:
> ...
>> Buses are changing from mostly parallel to serial. PCI is going that way
>> and USB3.x is very promising. It's direction most computer vendors are
>> taking. Simplifies cabling over longer distances if nothing else.
> I went to school (computer engineering) in the late 70's' and early
> 80's back then parallel was always faster.  When serial busses started
> outperforming parallel wires I was puzzled for a while then read up
> some.  The reason for serial being faster is easy,   There is no
> chance of "bit skew" with serial.   Bit Skew is when you have a
> parallel cable and some bits travel "faster" because not all
> conductors in the cable are equal.  Your max speed is limited by worst
> possible case skew.

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
http://www.avast.com

> From: Peter Blodow [mailto:p.b...@dr...]
> Yeah, and these "skewy" bits were the reason why in the days of parallel
> bus connections all operations had to be acknowledged on separate wires
> so it was made sure the bits had arrived correctly. This made
> connections slow, but terribly reliable. The DEC computer series like
> the VAXes were an example. This reliability was given up for the sake of
> speed, but at the same time, useless games becoming dominant in the
> computer world, it did not matter any more.
> 
> Peter

So true, even with PCs.  The buses may be serial but eventually the data
ends up parallel again.   Way back in the early 90's we were working with a
CAN bus ISA card.   The PC sent CAN messages to all the remote nodes to
operate the machine.  Every once in a while there was a glitch.  

It was a year later when I was writing NT 3.51 device drivers that I
stumbled onto the actual problem.  The commands were transferred via ISA bus
into a FIFO on the card.  They used an FPGA for all the address translation
and signalling for latching data.  There were occasions where the rising
edge of a signal was a tad late.  We're talking nano-seconds.  That would
result in the wrong data being latched into the FIFO and the wrong command
would  be sent.  I think the delay was in the order of a single gate
transition time so all the engineer did was add a non inverting buffer  in
series with the signal for the odd (or maybe it was the even) byte and the
problem was fixed.  This was on 386 PCs so they weren't blindingly fast.

With the popularity of ARM cores inside FPGA's and the the encoder/drive
signals done in VHDL the parallel problem hasn't really gone away.  Just
harder to find.

John Dammeyer

> > Problem with all those boards is in the fact that they have no common 
> > bus so that others could build standard interfaces on open architecture. 
> > All seem to be built to replace a PC with most of it's functionality.
> > 
> > Want to make a common box, bad luck. Everybody comes with their own 
> > silly PCB shape, hole positions, and names for add on boards, unsuitable 
> > connectors on all sides so you need space around them, or include chips 
> > that are not needed in embedded applications. Who needs audio or 4K 
> > video on 3D printer or small CNC machine?
> > 
> > In that regard we are back to early 80's or later when some interfaces 
> > did not work in different PCs even though the connectors were the same.
> > 
> 
> Another problem with all these boards is that they have "flash in the pan"
> life cycles.  The PC was a stable and viable platform for over two decades,
> and you can make an argument that it will remain so for perhaps another
> decade before finally disappearing.

Agreee, this is a very strong point. Absolutely best performance is not needed although small random delays once in a few minutes is disturbing.

> -----Original Message-----
> From: John Kasunich [mailto:jmk...@fa...]
> Sent: February-03-16 9:00 AM
> To: emc...@li...
> Subject: Re: [Emc-users] Prempt RT on Linux Mint
> 
> Another problem with all these boards is that they have "flash in the pan"
> life cycles.  The PC was a stable and viable platform for over two
decades,
> and you can make an argument that it will remain so for perhaps another
> decade before finally disappearing.
> 
> RasPI and Beagle and all these other things have life cycles more in line
> with smart phones - this year's new shiny is considered obsolete next
year,
> and the replacement is far less likely to be a "drop-in", so you wind up
> needing new breakout boards or other interface hardware.
>

With the exception that the Beagle is Open Source for software and hardware
and has an edge over the Raspberry with the dual PRU units.  Production is
high enough that they might just stay around for some time.   I have two.  

I also have a Replicape which has the drivers and sensor conditioning to run
a 3D printer.  Now granted size 17 motors aren't really adequate for a big
mill or lathe.  But as a model for an interface card to run LinuxCNC it's
ideal. 

Problem is that the designer of the Replicape built 500 of the current
version for the 3D printing market.  I'd suspect during the time it takes
him to sell all 500, an equivalent cape for LinuxCNC and machine control
would sell 5.  So if the BBB vanished with sales so low who in their right
mind would build 500 BBB clones and 500 MachineKit Capes.  They might build
a dedicated 3D printer wth Beagle and Replicape all on one board.

But then I'm probably what Jim Craig described as one of the "ignorant and
misinformed half-hearted programmers" that doesn't like Linux all that much.
And Jim's comments outline perfectly why the Linux Community is so self
congratulating and why MACH3 and now other CNC programs are still the
_go_to_ choice.  

Just look at Apple, Microsoft and now Android/Google.  My suggestion is:
Create a Linux Installation CD where everything and I do mean everything for
configuration, tweaking, and compiling applications is only done with
windowed interfaces so a user never ever in 10 years of use has to use a
command line.  Then you will have a Linux System that will be adopted by the
masses.  

The measure of how well that is done can be measured by not being able to
run anything from the command line because the only response from the
command line execution would be "Cannot Run From Command Line".

It's a philosophical difference.  Won't happen in Linux other than in the
Google/Android Model.  I've even run Android OS on my BeagleBone Black with
the touch screen.  It's clumsy but it works but then I use an iPhone so it's
probably just a lack of knowledge on the Android.

John Dammeyer.

> >
> > In that regard we are back to early 80's or later when some interfaces
> > did not work in different PCs even though the connectors were the same.
> >
> 
> 
> --
>   John Kasunich
>   jmk...@fa...
> 
>
----------------------------------------------------------------------------
--
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-users

> RasPI and Beagle and all these other things have life cycles more in line
> with smart phones - this year's new shiny is considered obsolete next year,
> and the replacement is far less likely to be a "drop-in", so you wind up
> needing new breakout boards or other interface hardware.

I don't to "breakout boards" I make cables.   The cable uses those 0.1
inch headers and will work with any SBC.
As for software, we have all learned now to fully abstract out the
hardware.   I like using the arduiono for prototypes and learning how
some sensor works, then later move the code to some ARM based SBC.
The ARM will run Linux but the Arduino is easy because there is no OS
to deal with.   You CAN move between platforms if you plan in advance
to do so.

Does no good to wash for the days when nothing changed for decades,
those days are gone, gone, gone....
-- 

Chris Albertson
Redondo Beach, California

> The problem is the EMC2 is an old program designed when hardware was
> different.  Today no one would design it as one big app that runs on a
> a PC with an RT OS.
> 
> Starting over from scratch I'd put the real-time functions on a low
> cost commodity single board computer. ...

The real time functions must be placed on CPU without random unknown delays then everything will be fine. Some known delays from higher priority tasks should however be OK if they are short enough otherwise they belong to lower priority task or there is problem.

> ... Then you build the GUI to run on
> some other platform such as a tablet or phone or web browser or
> whatever

This would indeed be very good.

> ... Then
> the hardware for the rest of LinuxCNC is not critical, any old
> notebook would work.

This is important for the economics. A few years old computers have more than enough computing power, a screen, keyboard and mouse if necessary. It is also likely old computers will be available if they break down.

Nicklas Karlsson

On 2/2/2016 2:08 PM, Rafael wrote:
> Why use this, why not use that? This is precisely why LinuCNC has no
> traction in commercial products. Unless things have changed in the last
> 2 months, you cannot find a single CNC machine or good kit on the market
> that comes with LinuxCNC.
Incorrect. Tormach sells many machines that are operated with LinuxCNC. 
In fact they moved away from windows based controls because of stability 
issues.

>   There are two or 3 that mention LinuxCNC as a
> possibility but they do not support it. Why?
The main reason people don't want to deal with LinuxCNC is because they 
know nothing, or very little about it. And for that matter they don't 
want to know anything about it. Most of the non technical and even most 
of the technical world knows windows they don't know Linux.

Even more people are afraid of change. Especially when it is something 
that they don't really understand (Computers). Most of us on this list 
that use LinuxCNC are very computer literate and are not nearly as 
scared by a computer challenge. If we were we would not be on this list 
in the first place.

If you look at any forum involving mach or any other windows CNC 
controller they say that LinuxCNC is difficult to set up. If you are 
someone looking for a CNC controller and you see that you need to use an 
OS that you don't know with a piece of software that is difficult to set 
up what are you going to use? Of course this misinformation is biased 
and ignorant as probably the person posting it has never even tried 
LinuxCNC or they did a half hearted try at best. After using both mach 
and LinuxCNC, I don't agree with that statement at all. LinuxCNC is just 
as easy as Mach to set up. (and several hundred dollars less expensive)

As a manufacturer you are going to supply and support the product that 
appeals to the most people. Any Linux software will not appeal to more 
people than windows software because msoft has the the majority of the 
world brainwashed.

However if you are supplying a real production machine that needs to be 
reliable day in and day out you should be supplying LinuxCNC because the 
Linux OS is much more robust and reliable than any Windows OS.

The biggest issue with LinuxCNC as it currently stands is that for 
production shops to want to use it there needs to be a 24/7 support and 
On Site Support for the machine and the controller. This could come from 
the machine manufacturer but LinuxCNC.org is not able to provide the On 
Site Troubleshooting support that production shops need. Production 
shops prefer controls like Fanuc etc that have this type of support (at 
a huge cost). Machine downtime is big money to a production shop.

Just 2 cents from a hillbilly engineer.

Jim

Well Linux Mint with Mate is a much better behaved desktop. Having said 
that and I think I tried Debian with Mate with poor results. I'll have 
to dig through my pile of disks to see... maybe not, the only one I 
tried is the net install which only offers gnome, kde, lxde and xfce.

JT

On 2/2/2016 6:56 AM, Sarah Armstrong wrote:
> i dont see why not , but the patch will be different probably , i'd need to
> try it
> why use ubuntu ? , thats another can of worms to get in the way .
>
> debian now has the 2 desktops that minit as
>
>
> things are moving away from ubuntu ,for lots of reasons , some of it is a
> bit deeper , such as python bindings and servicing things such as
> rt-preempt , kernels etc
> they are now becoming vastly different . from what they were a few years
> ago . and will become a even bigger nightmare over the next few years
> which will mean ubuntu will not be able to be supported .
>
>
>
> On 2 February 2016 at 12:42, John Thornton <jt...@gn...> wrote:
>
>> Is it possible to build the Prempt-RT kernel on Linux Mint 13 based on
>> Ubuntu Precise or Linux Mint 17 based on Ubuntu Trusty? This is to be
>> able to use LinuxCNC uspace with a 7i92.
>>
>> Thanks
>> JT
>>
>>
>> ------------------------------------------------------------------------------
>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
>> _______________________________________________
>> Emc-users mailing list
>> Emc...@li...
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>
>
>

I can say a word about my journey through Linux distributions and DEs.
The main reason why I came to Linux was LinuxCNC. I started from Ubuntu 
10 x86 as such image was offered by LinuxCNC. And I made myself 
comfortable with it including for casual tasks.

Later on I moved to Debian Wheezy x86 with xfce together with new image 
from LinuxCNC. It was not easy, I felt not so comfortable, but adapted 
myself and xfce to my needs.

Now I am using Debian Jessie amd64 with KDE Plasma. And I am very happy 
with it. It runs LinuxCNC with SMP PREEMPT RT kernel on a laptop!

And a lot more happier when I found how to:
set Desktop to be "as usual" Activities / Create activity / templates / 
Desktop icons
set Meta (aka MS Start) key for kickoff menu by using ksuperkey
set various custom shortcut keys
use some great apps like Krusader, Kate (one session per config), ...

02/02/2016 03:18 PM, John Thornton rašė:
> Well Linux Mint with Mate is a much better behaved desktop. Having said
> that and I think I tried Debian with Mate with poor results. I'll have
> to dig through my pile of disks to see... maybe not, the only one I
> tried is the net install which only offers gnome, kde, lxde and xfce.
>
> JT

> ...
> That's because NOBODY (manufacturers or distributors) wants to futz with 
> testing motherboard latencies, problems with their obsolescence, IO 
> boards, controllers, USB issues, etc. All that is a big concern to 
> anybody who wants to see LinuxCNC as part of their business.

Preempt RT do not manage priorities properly for interrupts while RTAI and Xenomai do. It is rather simple, execution time to service an interupt every now and then will delay real time tasks with as much time as they take to execute. Then there are SMI which will interrupt anyway. I run control loop at micro controller at 40kHz and it works perfect because it allow nested interrupts with priority.

> ...

> In addition, I believe that linuxCNC needs to be split into two parts 
> and "sold as such" by default:
> - headless LinuxCNC with hard RT kernel to run on different SBCs to 
> handle all CNC IO

There are cheap development board with micro controllers available. Most of them use some kind of Cortex-* CPU with an NVIC for nested interrupts with priority which is really great for real time even though they have a lot less computing power avaiable than an ordinary computer.

I would suggest to investigate possibility to separate code so that the real time tasks could be run on an micro controller. There also development boards available with extra ram so that they can run Linux, maybe even X11 would be possible.

> - GUI frontend, local or remote, connected to Linux workstation or 
> modern tablet over USB, ethernet, or WiFi. Countless digital tablets can 
> be had for under $100 that could serve as CNC UI.

GUI could stay on ordinary computer while real time taska move to cortex-* micro controller, they talk via TCP/IP and maybe even X11.

> ...

Nicklas Karlsson