[Emc-users] Linuxcnc on arm

[Erik Friesen]

I have been doing some work with an i.mx6 of late, and wonder why the quad
couldn't do linuxcnc? It seems there is some obscure reason I read
somewhere.

Older Haas machines use the 68040? 40mhz clunker.

This got me thinking, anyway http://nxgencnc.com/

But I ended up buying a 1996 haas. Going back to rs232 sort of hurts after
networked linuxcnc.

[Philipp Burch]

Hi Erik,

as far as I know, MachineKit is a fork of LinuxCNC designed to run on
ARM platforms:
http://www.machinekit.io/

Bye,
Philipp

On 16.03.2016 13:17, Erik Friesen wrote:
> I have been doing some work with an i.mx6 of late, and wonder why the quad
> couldn't do linuxcnc? It seems there is some obscure reason I read
> somewhere.
>
> Older Haas machines use the 68040? 40mhz clunker.
>
> This got me thinking, anyway http://nxgencnc.com/
>
> But I ended up buying a 1996 haas. Going back to rs232 sort of hurts after
> networked linuxcnc.

[Nicklas Karlsson]

On Wed, 16 Mar 2016 13:22:48 +0100
Philipp Burch <***@hb9etc.ch> wrote:

> Hi Erik,
>
> as far as I know, MachineKit is a fork of LinuxCNC designed to run on
> ARM platforms:
> http://www.machinekit.io/
>
> Bye,
> Philipp
>
> On 16.03.2016 13:17, Erik Friesen wrote:
> > I have been doing some work with an i.mx6 of late, and wonder why the quad
> > couldn't do linuxcnc? It seems there is some obscure reason I read
> > somewhere.
> >
> > Older Haas machines use the 68040? 40mhz clunker.
> >
> > This got me thinking, anyway http://nxgencnc.com/
> >
> > But I ended up buying a 1996 haas. Going back to rs232 sort of hurts after
> > networked linuxcnc.

Do not be confused:
1. Some of the higher end ARM run Linux and it is possible to run Linuxcnc on them.
2. ARM Micro controllers with peripherals suitable for motor control are also available.

I checked ARM on ST home page. The cheap lower end Micro controllers have peripherals suitable for control of inverter switches for motor control but not the higher end. The high end ARM is Multi core and have a lot of CPU power. The lower end have an interrupt controller which allow nested interrupts with priority, rate monotonic scheduling could be done in hardware with this micro controller but I am not sure this interrupt controller is available on the high end ARM.

In short the high end ARM is suitable to build something similar to an ordinary desktop computer while the cheap are suitable to connect to other hardware like: analog input signals, PWM, ...


Nicklas Karlsson

[Stephen Dubovsky]

And there are some that do both 1 *AND* 2. Look at the Xilinx Zynq for
example. Dual gigahertz A9 cores w/ a FPGA core (Spartan/Virtex) that IIRC
is larger than the one used for the Mesa 5i25. Could run a zillion
channels of PWM or even hostmot2. We were porting some code to it for a
work project that had 16+ PWM channels. We didn't need linux but were still
only using one core to do real time control.

SMD

On Wed, Mar 16, 2016 at 9:54 AM, Nicklas Karlsson <
***@gmail.com> wrote:

> On Wed, 16 Mar 2016 13:22:48 +0100
> Philipp Burch <***@hb9etc.ch> wrote:
>
> > Hi Erik,
> >
> > as far as I know, MachineKit is a fork of LinuxCNC designed to run on
> > ARM platforms:
> > http://www.machinekit.io/
> >
> > Bye,
> > Philipp
> >
> > On 16.03.2016 13:17, Erik Friesen wrote:
> > > I have been doing some work with an i.mx6 of late, and wonder why the
> quad
> > > couldn't do linuxcnc? It seems there is some obscure reason I read
> > > somewhere.
> > >
> > > Older Haas machines use the 68040? 40mhz clunker.
> > >
> > > This got me thinking, anyway http://nxgencnc.com/
> > >
> > > But I ended up buying a 1996 haas. Going back to rs232 sort of hurts
> after
> > > networked linuxcnc.
>
> Do not be confused:
> 1. Some of the higher end ARM run Linux and it is possible to run
> Linuxcnc on them.
> 2. ARM Micro controllers with peripherals suitable for motor control are
> also available.
>
> I checked ARM on ST home page. The cheap lower end Micro controllers have
> peripherals suitable for control of inverter switches for motor control but
> not the higher end. The high end ARM is Multi core and have a lot of CPU
> power. The lower end have an interrupt controller which allow nested
> interrupts with priority, rate monotonic scheduling could be done in
> hardware with this micro controller but I am not sure this interrupt
> controller is available on the high end ARM.
>
> In short the high end ARM is suitable to build something similar to an
> ordinary desktop computer while the cheap are suitable to connect to other
> hardware like: analog input signals, PWM, ...
>
>
> Nicklas Karlsson
>
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

[Jon Elson]

On 03/16/2016 07:22 AM, Philipp Burch wrote:
> Hi Erik,
>
> as far as I know, MachineKit is a fork of LinuxCNC designed to run on
> ARM platforms:
> http://www.machinekit.io/
>
>
Yes, it is basically LinuxCNC as far as the user would see,
but has a number of extensions underneath.

But, it doesn't support many of the external hardware
interfaces that are available on the X86 versions.
I think some work is being done to address that.

Jon

[andy pugh]

On 16 March 2016 at 12:17, Erik Friesen <***@aercon.net> wrote:
> I have been doing some work with an i.mx6 of late, and wonder why the quad
> couldn't do linuxcnc? It seems there is some obscure reason I read
> somewhere.


http://buildbot.linuxcnc.org/

Shows that we are building an armhf variant of LinuxCNC for preempt-rt kernels.

--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

[Jeff Epler]

Linuxcnc 2.7 configured for "uspace" realtime builds and runs on x86,
x86_64 and arm. our master branch even builds on 64-bit arm.

However, it needs to be paired with a preempt-rt kernel (which generally
only gets latency low enough for servo-cycle-only designs with smart
I/O) and each individual board needs individual hardware drivers.
Nobody has contributed these to the linuxcnc project.

Jeff

[W. Martinjak]

Wow,

6 weeks after I asked this question on the devel-list
https://sourceforge.net/p/emc/mailman/message/34817886/
and irc
http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2016-02-03.html#10:00:50

there is suddenly an answer.
And without chunk on the user-list.

What I've done wrong?





On 2016-03-16 13:38, Jeff Epler wrote:
> Linuxcnc 2.7 configured for "uspace" realtime builds and runs on x86,
> x86_64 and arm. our master branch even builds on 64-bit arm.
>
> However, it needs to be paired with a preempt-rt kernel (which generally
> only gets latency low enough for servo-cycle-only designs with smart
> I/O) and each individual board needs individual hardware drivers.
> Nobody has contributed these to the linuxcnc project.
>
> Jeff
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

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

Max Planck

[W. Martinjak]

On 2016-03-16 14:54, W. Martinjak wrote:
> there is suddenly an answer. And without chunk on the user-list.

Ok, I retract this.
It's emty.

http://buildbot.linuxcnc.org/dists/wheezy/2.7-rtpreempt/binary-armhf/
http://buildbot.linuxcnc.org/dists/wheezy/master-rtpreempt/binary-armhf/


>
>
>
>
> On 2016-03-16 13:38, Jeff Epler wrote:
>> Linuxcnc 2.7 configured for "uspace" realtime builds and runs on x86,
>> x86_64 and arm. our master branch even builds on 64-bit arm.
>>
>> However, it needs to be paired with a preempt-rt kernel (which generally
>> only gets latency low enough for servo-cycle-only designs with smart
>> I/O) and each individual board needs individual hardware drivers.
>> Nobody has contributed these to the linuxcnc project.
>>
>> Jeff
>>
>> ------------------------------------------------------------------------------
>> Transform Data into Opportunity.
>> Accelerate data analysis in your applications with
>> Intel Data Analytics Acceleration Library.
>> Click to learn more.
>> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
>> _______________________________________________
>> Emc-users mailing list
>> Emc-***@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users

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

Max Planck

[Sebastian Kuzminsky]

On 03/16/2016 08:25 AM, W. Martinjak wrote:
> It's emty.
>
> http://buildbot.linuxcnc.org/dists/wheezy/2.7-rtpreempt/binary-armhf/
> http://buildbot.linuxcnc.org/dists/wheezy/master-rtpreempt/binary-armhf/

We build and test on arm, but we currently don't produce debian packages.

LinuxCNC 2.7 and newer work on Wheezy on armhf, you just have to build
it yourself:

http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf


--
Sebastian Kuzminsky

[W. Martinjak]

On 2016-03-16 16:28, Sebastian Kuzminsky wrote:
> We build and test on arm, but we currently don't produce debian packages.
>
> LinuxCNC 2.7 and newer work on Wheezy on armhf, you just have to build
> it yourself:
>
> http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf
>
>

Ok, and any suggestions for the toolchain and build sequence?

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

Max Planck

[andy pugh]

On 16 March 2016 at 16:03, W. Martinjak <***@play-pla.net> wrote:

> Ok, and any suggestions for the toolchain and build sequence?

Probably simplest to compile on the device itself rather than get
involved in the complexities of cross-compiling.

--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

[Sebastian Kuzminsky]

On 03/16/2016 10:17 AM, andy pugh wrote:
> On 16 March 2016 at 16:03, W. Martinjak <***@play-pla.net> wrote:
>
>> Ok, and any suggestions for the toolchain and build sequence?
>
> Probably simplest to compile on the device itself rather than get
> involved in the complexities of cross-compiling.

I agree with Andy. The buildbot builds that i linked earlier in this
thread run on an Odroid U3 board running Debian Wheezy, and they just do
regular native builds.


--
Sebastian Kuzminsky

[Jeff Epler]

On Wed, Mar 16, 2016 at 04:17:06PM +0000, andy pugh wrote:
> Probably simplest to compile on the device itself rather than get
> involved in the complexities of cross-compiling.

I don't think cross-compiling linuxcnc presently works. Some ARMs are
quite speedy enough to do incremental development of linuxcnc right on
them (Odroid U3), others aren't (original PI B). Of course, this also
depends on your general degree of patience.

Just like a million other things people ask about, patches to enable
cross-building of linuxcnc will be thoughtfully considered but they
ain't gonna write themselves.

One last note: The real problem is getting a kernel working on your
specific ARM board that gives you the realtime performance you need. Do
that first, and use the standard and small "cyclictest" to test latency
before you go to the trouble of starting on linuxcnc. Second, make sure
you still hit those latency goals when accessing your user interface
hardware (odroid u3 had unacceptable latencies when accessing the spi
interface, until I fixe dit). Every ARM SBC is different and terrible
in its own way. Not even Debian has enough smarts to ship a
(non-realtime) kernel that boots e.g., on a PI and an Odroid, and
there's NFW that linuxcnc.org wants to get into the dreary business of
building, testing, and supprorting any more kernels than we do.

Jeff

[John Dammeyer]

As I understand it, the MachineKit was forked from an earlier version of
LinuxCNC and LinuxCNC requires a real time kernel to run.

Why is it that the real time kernel hasn't become a basic part of Linux so
that the orphan Linux is the one without the kernel?

Surely by now we've moved past the 486DX4-100 level of processors. IC've
written an RTOS for an 8 bit NEC78C10, worked with VRTX RTOS on x86 CPUs and
written software for Motorola MC68070 processors running OS9-68K.

The ARMs and current crop of PCs are orders of magnitude faster and more
powerful so why is it that the real time part of Linux isn't the defacto
standard for Linux. If it were wouldn't the latest LinuxCNC run on just
about anything?

Seems a simple question. Is there a simple answer?

John Dammeyer




> -----Original Message-----
> From: Sebastian Kuzminsky [mailto:***@highlab.com]
> Sent: March-16-16 8:29 AM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Linuxcnc on arm
>
>
> On 03/16/2016 08:25 AM, W. Martinjak wrote:
> > It's emty.
> >
> > http://buildbot.linuxcnc.org/dists/wheezy/2.7-rtpreempt/binary-armhf/
> > http://buildbot.linuxcnc.org/dists/wheezy/master-rtpreempt/binary-
> armhf/
>
> We build and test on arm, but we currently don't produce debian packages.
>
> LinuxCNC 2.7 and newer work on Wheezy on armhf, you just have to build
> it yourself:
>
> http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf
>
>
> --
> Sebastian Kuzminsky
>
>
----------------------------------------------------------------------------
--
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

[bari]

Real time is not one of the main concerns of the kernel devs. The kernel
has graphics drivers that interfere with real time as well as X.

On 03/16/2016 11:24 AM, John Dammeyer wrote:
> As I understand it, the MachineKit was forked from an earlier version of
> LinuxCNC and LinuxCNC requires a real time kernel to run.
>
> Why is it that the real time kernel hasn't become a basic part of Linux so
> that the orphan Linux is the one without the kernel?
>
> Surely by now we've moved past the 486DX4-100 level of processors. IC've
> written an RTOS for an 8 bit NEC78C10, worked with VRTX RTOS on x86 CPUs and
> written software for Motorola MC68070 processors running OS9-68K.
>
> The ARMs and current crop of PCs are orders of magnitude faster and more
> powerful so why is it that the real time part of Linux isn't the defacto
> standard for Linux. If it were wouldn't the latest LinuxCNC run on just
> about anything?
>
> Seems a simple question. Is there a simple answer?
>
> John Dammeyer
>

[Nicklas Karlsson]

> Real time is not one of the main concerns of the kernel devs. The kernel
> has graphics drivers that interfere with real time as well as X.

Probably right no one are interested enough. Good real time performance require proper priority of everything handled from interrupts, I also read system management interrupts are not possible to get rid of. Knowlegde about which real time tasks exist within kernel like serial receive buffers which must be handled before filled up next time or accept lose data is probably another issue I never even heard anyone mention.


Nicklas Karlsson

[bari]

We noticed a lot of funny business in the kernel and X that violated the
scheduler in RTAI. I think that the devs focus on the problem they are
trying to solve and if it messes with real time and nobody notices or
complains they consider their job done and move on.

On 03/16/2016 11:42 AM, Nicklas Karlsson wrote:
> Probably right no one are interested enough. Good real time performance require proper priority of everything handled from interrupts, I also read system management interrupts are not possible to get rid of. Knowlegde about which real time tasks exist within kernel like serial receive buffers which must be handled before filled up next time or accept lose data is probably another issue I never even heard anyone mention.
>
>
>

[John Dammeyer]

But see here's where I'm confused. If Linux already provides priorities of
tasks:
http://www.thegeekstuff.com/2013/08/nice-renice-command-examples/
then the LinuxCNC as a task can run higher than anything else.
If the motion/encoder control is offloaded to a device driver, which should
have even higher priority then where does the real time kernel of the
LinuxCNC fit in?
John Dammeyer

> -----Original Message-----
> From: Nicklas Karlsson [mailto:***@gmail.com]
> Sent: March-16-16 9:42 AM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Linuxcnc on arm
>
>
> > Real time is not one of the main concerns of the kernel devs. The kernel
> > has graphics drivers that interfere with real time as well as X.
>
> Probably right no one are interested enough. Good real time performance
> require proper priority of everything handled from interrupts, I also read
> system management interrupts are not possible to get rid of. Knowlegde
> about which real time tasks exist within kernel like serial receive
buffers
> which must be handled before filled up next time or accept lose data is
> probably another issue I never even heard anyone mention.
>
>
> Nicklas Karlsson
>
>
----------------------------------------------------------------------------
--
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

[Nicklas Karlsson]

> But see here's where I'm confused. If Linux already provides priorities of
> tasks:
> http://www.thegeekstuff.com/2013/08/nice-renice-command-examples/
> then the LinuxCNC as a task can run higher than anything else.
> If the motion/encoder control is offloaded to a device driver, which should
> have even higher priority then where does the real time kernel of the
> LinuxCNC fit in?

For rate monotonic or earliest dead line first scheduling the priority for the linuxcnc kernel is assigned according to often it is executed. Even though proof of why these schedulings schemes are optimal under som conditions are hard assignment of priority is rather simple => assign according to periodicity.

https://en.wikipedia.org/wiki/Rate-monotonic_scheduling
https://en.wikipedia.org/wiki/Earliest_deadline_first_scheduling

Nicklas Karlsson

[bari]

It only sort of does. If a kernel or X dev decides to access hardware
directly to get his project done he probably will. Unfortunately there
is no kernel police and no really agreed upon rules that they explicitly
follow.

On 03/16/2016 12:10 PM, John Dammeyer wrote:
> But see here's where I'm confused. If Linux already provides priorities of
> tasks:
> http://www.thegeekstuff.com/2013/08/nice-renice-command-examples/
> then the LinuxCNC as a task can run higher than anything else.
> If the motion/encoder control is offloaded to a device driver, which should
> have even higher priority then where does the real time kernel of the
> LinuxCNC fit in?
> John Dammeyer
>
>

[Nicklas Karlsson]

Maybe they just need to read about real time scheduling to assign an approriate priority or do the execution in a thread with appropriate priority.

If there is a receive buffer execution should be triggered no later than half full and must be emptied before it may be filled. With time known to make buffer half full maximum periodicity is known and an appropriate priority could be assigned.


> It only sort of does. If a kernel or X dev decides to access hardware
> directly to get his project done he probably will. Unfortunately there
> is no kernel police and no really agreed upon rules that they explicitly
> follow.
>
> On 03/16/2016 12:10 PM, John Dammeyer wrote:
> > But see here's where I'm confused. If Linux already provides priorities of
> > tasks:
> > http://www.thegeekstuff.com/2013/08/nice-renice-command-examples/
> > then the LinuxCNC as a task can run higher than anything else.
> > If the motion/encoder control is offloaded to a device driver, which should
> > have even higher priority then where does the real time kernel of the
> > LinuxCNC fit in?
> > John Dammeyer
> >
> >
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

[John Dammeyer]

So how is that different from a non pre-emptive RTOS kernel?

My understanding, and it's very superficial, is that the real time component
of linux puts a scheduler in front of the basic LINUX kernel. So now the
micro-stepping or DC-Servo/encoder support can get predictable low latency
response to events.

Building that into the kernel so that an application like LinuxCNC can
acquire the resources to get the same level of access above other hardware
seems obvious. For a non LinuxCNC system perhaps the video or network or
serial port driver will want higher priority than default. That's a system
configuration issue. Not whether the scheduling by the kernel is hard real
time or soft multi-threaded.

John Dammeyer



> From: bari [mailto:***@gmail.com]
> It only sort of does. If a kernel or X dev decides to access hardware
> directly to get his project done he probably will. Unfortunately there
> is no kernel police and no really agreed upon rules that they explicitly
> follow.
>
> On 03/16/2016 12:10 PM, John Dammeyer wrote:
> > But see here's where I'm confused. If Linux already provides priorities
of
> > tasks:
> > http://www.thegeekstuff.com/2013/08/nice-renice-command-examples/
> > then the LinuxCNC as a task can run higher than anything else.
> > If the motion/encoder control is offloaded to a device driver, which
> should
> > have even higher priority then where does the real time kernel of the
> > LinuxCNC fit in?
> > John Dammeyer
> >
> >
>
>
>
----------------------------------------------------------------------------
--
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

[Jerry Scharf]

Here's my take, which may be as old and tired as I am.

The real issues in RT vs. not RT is not one of standard process scheduling.
There are many knobs and hooks that can control that. The real problem is
in the kernel and drivers, where you can and often have to lock out
interrupts. If those are not designed to work correctly and cooperatively,
things stop being RT. When the person writing the graphics card driver is
told to get as much performance as they can, they often stop thinking about
how polite they are to other time critical things. They have almost no
incentive to be careful and lots of incentive to do what makes things go
the fastest.

One issue in particular that becomes difficult is spin locks for
multiprocessor kernels. They have to deal with the memory access system and
adding complexity in these has dramatic system throughput impacts even when
code branches are not executed. I am not a multiprocessor kernel expert but
I have worked with a few. Small differences in how the locking works can
raise and lower system throughput by 10%. Hard to sell adding things to the
generic kernel that slow everyone down and are only useful to a small
percentage of users.

This work was from 20 years ago, but I know of nothing that has changed in
what OS locks need to do that change the impact of this kind of locking.
Improving lock delays is one of the biggest things that OS designers do and
they spend years on it.


jerry


On Wed, Mar 16, 2016 at 12:11 PM, John Dammeyer <***@autoartisans.com>
wrote:

> So how is that different from a non pre-emptive RTOS kernel?
>
> My understanding, and it's very superficial, is that the real time
> component
> of linux puts a scheduler in front of the basic LINUX kernel. So now the
> micro-stepping or DC-Servo/encoder support can get predictable low latency
> response to events.
>
> Building that into the kernel so that an application like LinuxCNC can
> acquire the resources to get the same level of access above other hardware
> seems obvious. For a non LinuxCNC system perhaps the video or network or
> serial port driver will want higher priority than default. That's a system
> configuration issue. Not whether the scheduling by the kernel is hard real
> time or soft multi-threaded.
>
> John Dammeyer
>
>
>
> > From: bari [mailto:***@gmail.com]
> > It only sort of does. If a kernel or X dev decides to access hardware
> > directly to get his project done he probably will. Unfortunately there
> > is no kernel police and no really agreed upon rules that they explicitly
> > follow.
> >
> > On 03/16/2016 12:10 PM, John Dammeyer wrote:
> > > But see here's where I'm confused. If Linux already provides
> priorities
> of
> > > tasks:
> > > http://www.thegeekstuff.com/2013/08/nice-renice-command-examples/
> > > then the LinuxCNC as a task can run higher than anything else.
> > > If the motion/encoder control is offloaded to a device driver, which
> > should
> > > have even higher priority then where does the real time kernel of the
> > > LinuxCNC fit in?
> > > John Dammeyer
> > >
> > >
> >
> >
> >
>
> ----------------------------------------------------------------------------
> --
> > Transform Data into Opportunity.
> > Accelerate data analysis in your applications with
> > Intel Data Analytics Acceleration Library.
> > Click to learn more.
> > http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> > _______________________________________________
> > Emc-users mailing list
> > Emc-***@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>



--
Jerry Scharf
FINsix IT
650.285.6361 w
650.279.7017 m

[bari]

That's why we'd need the kernel police to enforce the rules, if there
were kernel rules that everyone would agree on.

On 03/16/2016 02:36 PM, Jerry Scharf wrote:
> The real problem is
> in the kernel and drivers, where you can and often have to lock out
> interrupts. If those are not designed to work correctly and cooperatively,
> things stop being RT. When the person writing the graphics card driver is
> told to get as much performance as they can, they often stop thinking about
> how polite they are to other time critical things. They have almost no
> incentive to be careful and lots of incentive to do what makes things go
> the fastest.

[Jcd]

So what makes the real time Linux like machine kit or for a regular PC. If drivers can muck things up.

Sent from John's iPhone 4S

On 2016-03-16, at 2:05 PM, bari <***@gmail.com> wrote:

>
> That's why we'd need the kernel police to enforce the rules, if there
> were kernel rules that everyone would agree on.
>
> On 03/16/2016 02:36 PM, Jerry Scharf wrote:
>> The real problem is
>> in the kernel and drivers, where you can and often have to lock out
>> interrupts. If those are not designed to work correctly and cooperatively,
>> things stop being RT. When the person writing the graphics card driver is
>> told to get as much performance as they can, they often stop thinking about
>> how polite they are to other time critical things. They have almost no
>> incentive to be careful and lots of incentive to do what makes things go
>> the fastest.
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

[bari]

RTAI patches the kernel with an interrupt pipeline and handler that can
take over real time interrupts but drivers can still interfere with it.

Things used to be worse. Especially with integrated GPU's. We did lots
of RTAI development over the past few years and we had difficulty
building custom RTAI kernels with jitter (measured using only the
latency test) <5uS on AMD APU's (with integrated GPU's) made in the past
5 years. 5+ years ago people were having problems with boards with
integrated graphics. Getting them under 100k uS was not possible without
using an external GPU card.

We didn't touch any nvidia or Intel silicon but most AMD boards were
under 25uS with integrated graphics.



On 03/16/2016 04:12 PM, Jcd wrote:
> So what makes the real time Linux like machine kit or for a regular PC. If drivers can muck things up.

[bari]

One more thing I forgot to mention that can add to poor real time
performance on x86 is BIOS/firmware. Intel has forced the use of their
Intel Management Engine that allows for remote control, phone home,
backdoor etc and operates completely out of band. So you'd never notice
it unless you monitor the network activity or the hardware and look for
unexplained delays.

http://www.slideshare.net/codeblue_jp/igor-skochinsky-enpub
Has a good write-up and sideshow on how it works.

On 03/16/2016 04:12 PM, Jcd wrote:
> So what makes the real time Linux like machine kit or for a regular PC. If drivers can muck things up.

[Gene Heskett]

On Saturday 19 March 2016 10:35:07 bari wrote:

> One more thing I forgot to mention that can add to poor real time
> performance on x86 is BIOS/firmware. Intel has forced the use of their
> Intel Management Engine that allows for remote control, phone home,
> backdoor etc and operates completely out of band. So you'd never
> notice it unless you monitor the network activity or the hardware and
> look for unexplained delays.
>
> http://www.slideshare.net/codeblue_jp/igor-skochinsky-enpub
> Has a good write-up and sideshow on how it works.

Interesting link.

And no way to turn it off? Makes me glad this machine is an old old quad
core phenom. I haven't seen a thing I couldn't ID in wiresharks output.

But 3 of the other machines here, those running real machinery, are
intel, 2-3 yo atoms, or 5-6 yo in a Dell Compact. AMD stuff cannot do
real time since about K6, which was tolerable, ran one for quite a spell
till I replaced it with the atom stuff, reducing my power bill.

I would assume, if they are "calling home" that I could see the traffic
with wireshark or tcpdump? Hard to see in all the other traffic as I
maintain an sshfs share, and an ssh login session to them all from here.
So its pretty noisy in terms of net traffic here at the Heskett Cottage.

> On 03/16/2016 04:12 PM, Jcd wrote:
> > So what makes the real time Linux like machine kit or for a regular
> > PC. If drivers can muck things up.
>
> ----------------------------------------------------------------------
>-------- Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[bari]

All of memleak's work on RTAI the past few years (which is now RTAI 5
without a single credit) was done on AMD hardware made in the past 7 years.

Every bit of AMD silicon we touched ran under 25uS on the latency test.
Just for fun we had a few tweaked <4uS max jitter.

IME can't be turned off since for security reasons. Security from you.

It would be interesting to monitor it on wireshark to see what triggers
it to phone home or when it's controlled by hackers. Maybe it kicks in
when you trigger interest by using certain words or visit certain websites.


On 03/19/2016 11:55 AM, Gene Heskett wrote:
> And no way to turn it off? Makes me glad this machine is an old old quad
> core phenom. I haven't seen a thing I couldn't ID in wiresharks output.
>
> But 3 of the other machines here, those running real machinery, are
> intel, 2-3 yo atoms, or 5-6 yo in a Dell Compact. AMD stuff cannot do
> real time since about K6, which was tolerable, ran one for quite a spell
> till I replaced it with the atom stuff, reducing my power bill.
>
> I would assume, if they are "calling home" that I could see the traffic
> with wireshark or tcpdump? Hard to see in all the other traffic as I
> maintain an sshfs share, and an ssh login session to them all from here.
> So its pretty noisy in terms of net traffic here at the Heskett Cottage.

[Gene Heskett]

On Saturday 19 March 2016 13:08:43 bari wrote:

> All of memleak's work on RTAI the past few years (which is now RTAI 5
> without a single credit) was done on AMD hardware made in the past 7
> years.

No credits? 'Scuse me but thats not excusable, PM needs to understand
TANSTAAFL.
>
> Every bit of AMD silicon we touched ran under 25uS on the latency
> test. Just for fun we had a few tweaked <4uS max jitter.

This is not an rtai kernel, but 3.16.0-0.bpo.4-amd64.

latencytest is running here right now, and while the 25 u-s loop last
interval displayed is consistently in the 600ns area, the Max Jitter is
horrible at 10050977, and Max Interval of 10075977 which is reason
enough I'd never in my right mind ever attempt to drive machinery with
it without a 5i25 or better card doing the stepper generation, even then
100 milliseconds of lag would trigger the cards WDT, and quite
justifiably so.

> IME can't be turned off since for security reasons. Security from you.

Gee, thanks intel. I love you too...

> It would be interesting to monitor it on wireshark to see what
> triggers it to phone home or when it's controlled by hackers. Maybe it
> kicks in when you trigger interest by using certain words or visit
> certain websites.
>
> On 03/19/2016 11:55 AM, Gene Heskett wrote:
> > And no way to turn it off? Makes me glad this machine is an old old
> > quad core phenom. I haven't seen a thing I couldn't ID in wiresharks
> > output.
> >
> > But 3 of the other machines here, those running real machinery, are
> > intel, 2-3 yo atoms, or 5-6 yo in a Dell Compact. AMD stuff cannot
> > do real time since about K6, which was tolerable, ran one for quite
> > a spell till I replaced it with the atom stuff, reducing my power
> > bill.
> >
> > I would assume, if they are "calling home" that I could see the
> > traffic with wireshark or tcpdump? Hard to see in all the other
> > traffic as I maintain an sshfs share, and an ssh login session to
> > them all from here. So its pretty noisy in terms of net traffic here
> > at the Heskett Cottage.
>
> ----------------------------------------------------------------------
>-------- Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[Nicklas Karlsson]

On Sat, 19 Mar 2016 13:50:22 -0400
Gene Heskett <***@wdtv.com> wrote:

> On Saturday 19 March 2016 13:08:43 bari wrote:
>
> > All of memleak's work on RTAI the past few years (which is now RTAI 5
> > without a single credit) was done on AMD hardware made in the past 7
> > years.
>
> No credits? 'Scuse me but thats not excusable, PM needs to understand
> TANSTAAFL.
> >
> > Every bit of AMD silicon we touched ran under 25uS on the latency
> > test. Just for fun we had a few tweaked <4uS max jitter.
>
> This is not an rtai kernel, but 3.16.0-0.bpo.4-amd64.

I am pretty sure I read about some disagreement between RTAI and preemt RT. I tried RTAI but had problem with Ethernet, since did not have enough time to look at the driver myself I used Premt RT.

I am thinking about split in two with real time threads on micro controller and the computer for the user interface. It would also be a flexible solution then it come to choice of user interface but require extra hardware.

>
> latencytest is running here right now, and while the 25 u-s loop last
> interval displayed is consistently in the 600ns area, the Max Jitter is
> horrible at 10050977, and Max Interval of 10075977 which is reason
> enough I'd never in my right mind ever attempt to drive machinery with
> it without a 5i25 or better card doing the stepper generation, even then
> 100 milliseconds of lag would trigger the cards WDT, and quite
> justifiably so.
>
> > IME can't be turned off since for security reasons. Security from you.
>
> Gee, thanks intel. I love you too...
>
> > It would be interesting to monitor it on wireshark to see what
> > triggers it to phone home or when it's controlled by hackers. Maybe it
> > kicks in when you trigger interest by using certain words or visit
> > certain websites.
> >
> > On 03/19/2016 11:55 AM, Gene Heskett wrote:
> > > And no way to turn it off? Makes me glad this machine is an old old
> > > quad core phenom. I haven't seen a thing I couldn't ID in wiresharks
> > > output.
> > >
> > > But 3 of the other machines here, those running real machinery, are
> > > intel, 2-3 yo atoms, or 5-6 yo in a Dell Compact. AMD stuff cannot
> > > do real time since about K6, which was tolerable, ran one for quite
> > > a spell till I replaced it with the atom stuff, reducing my power
> > > bill.
> > >
> > > I would assume, if they are "calling home" that I could see the
> > > traffic with wireshark or tcpdump? Hard to see in all the other
> > > traffic as I maintain an sshfs share, and an ssh login session to
> > > them all from here. So its pretty noisy in terms of net traffic here
> > > at the Heskett Cottage.
> >
> > ----------------------------------------------------------------------
> >-------- Transform Data into Opportunity.
> > Accelerate data analysis in your applications with
> > Intel Data Analytics Acceleration Library.
> > Click to learn more.
> > http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> > _______________________________________________
> > Emc-users mailing list
> > Emc-***@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
> soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page <http://geneslinuxbox.net:6309/gene>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

[Chris Albertson]

On Sat, Mar 19, 2016 at 12:08 PM, Nicklas Karlsson <
***@gmail.com> wrote:

> On Sat, 19 Mar 2016 13:50:22 -0400
> Gene Heskett <***@wdtv.com> wrote:
>
>
> I am thinking about split in two with real time threads on micro
> controller and the computer for the user interface. It would also be a
> flexible solution then it come to choice of user interface but require
> extra hardware.
>

If I were designing this in the current century (the 21st) I'd divide the
functions roughly in to three (not two) and place them as follows
1) "Hard" real time functions, on a small micro processor not running any
OS. Maybe something like an ARM I'd like size the uP so that it could
handle four axis and use multiple uP if more axis were needed
2) The user interface _managment_ and higher level non-real time functions
on a generic "Posix" platform (written in a portable high level language)
This could be a PC, Mac, Linux/86, LinuxARM)
3) Rendering of the GUI, that is driving the actual screen and
mouse/keyboard. This would be web-abased and like targeted to a mobile
device like a cheep $100 Android but of course could run on the same
machine as #2 above.

Another words just as you said except I'd drive the screen with some kind
of network protocol (like HTML or whatever) that would be wireless if the
user prefers that.

One of the more modern architectures I like is ROS (Robot Operating System)
and it can do something like LinuxCNC like for example drive a pick and
place machine or an robot that welds auto bodies on a factory floor. ROS
is to comp-lex for most CNC machines but it's architecture is good. It
uses a very large number of processes that communicate via message passing
(publisher/subscribber model) and each processor can run on a separate
computer if you like. Some real-time, some not. This allows me to do
things like swap in a simulated sensor for the real on without a even a
restart just be redirecting message routing. And of course message logging
(and later playback) is a great debugging tool.

One need not go as far as ROS but I'd decouple into three parts (1) RT
stuff, (2) the "guts", and (3) the physical display and user input device




--

Chris Albertson
Redondo Beach, California

[Nicklas Karlsson]

> > I am thinking about split in two with real time threads on micro
> > controller and the computer for the user interface. It would also be a
> > flexible solution then it come to choice of user interface but require
> > extra hardware.
> >
>
> If I were designing this in the current century (the 21st) I'd divide the
> functions roughly in to three (not two) and place them as follows
> 1) "Hard" real time functions, on a small micro processor not running any
> OS. Maybe something like an ARM I'd like size the uP so that it could
> handle four axis and use multiple uP if more axis were needed

Yes

> 2) The user interface _managment_ and higher level non-real time functions
> on a generic "Posix" platform (written in a portable high level language)
> This could be a PC, Mac, Linux/86, LinuxARM)

Yes

> 3) Rendering of the GUI, that is driving the actual screen and
> mouse/keyboard. This would be web-abased and like targeted to a mobile
> device like a cheep $100 Android but of course could run on the same
> machine as #2 above.

Then linuxcnc is split in two as in 1) and 2) above it is more or less done, Why not gtk as now?


> Another words just as you said except I'd drive the screen with some kind
> of network protocol (like HTML or whatever) that would be wireless if the
> user prefers that.

On Linux there are X11 but I expect there would be a special purpose protocol between GUI and machine. In practice which buttons user pressed and values back. High speed values like encoder values for hal scope would not be a proble screen update is rather slow and a small delay would be a jerk on the screen not the part.

> ...

I plan to start looking at as soon as I get my first machines up and running.


Regards Nicklas Karlsson

[Chris Albertson]

On Sun, Mar 20, 2016 at 12:10 AM, Nicklas Karlsson <
***@gmail.com> wrote:

> > > I am thinking about split in two with real time threads on micro
> > > controller and the computer for the user interface. It would also be a
> > > flexible solution then it come to choice of user interface but require
> > > extra hardware.
> > >
> >
> > If I were designing this in the current century (the 21st) I'd divide the
> > functions roughly in to three (not two) and place them as follows
> > 1) "Hard" real time functions, on a small micro processor not running any
> > OS. Maybe something like an ARM I'd like size the uP so that it could
> > handle four axis and use multiple uP if more axis were needed
>
> Yes
>
> > 2) The user interface _managment_ and higher level non-real time
> functions
> > on a generic "Posix" platform (written in a portable high level language)
> > This could be a PC, Mac, Linux/86, LinuxARM)
>
> Yes
>

How to connect the little uP to the larger computer? WiFi? Will the uP
run some OS?
Take a look at the RISC OS for ARM. It uses "cooperative multitasking"
which means your task runs on the bare hardware with interrupts disabled if
you like
"eCos" might be better.

Could this little uP running (say) eCos actually be a soft-core CPU
implemented inside an FPGA? That runs the cost up but gives access to
nearly unlimited hardware support for pulse generation and even directly
doing micro stepping.

>
> > 3) Rendering of the GUI, that is driving the actual screen and
> > mouse/keyboard. This would be web-abased and like targeted to a mobile
> > device like a cheep $100 Android but of course could run on the same
> > machine as #2 above.
>
> Then linuxcnc is split in two as in 1) and 2) above it is more or less
> done, Why not gtk as now?
>

1) Because it will not be long before someone wants to re-build the PC part
on (say) an iPhone. Why not? Why even use a PC at all?
2) A mouse is hard to use in a shop environment while standing up. The
glass touch screen works better. Should at least preserve the option in
the future to use a glass touch screen and multi touch gestures
3) does GTK run on all the platforms users might want to run on. You know
the first platform to be requested is the Raspberry Pi3. Then if it runs
on that ARM based system why not the iPad? In 5 years all home computers
will have touch screens like the "surface" and all but server class
machines may be running on ARM not Intel.
4) 3D touch is becoming popular and may go mainstream. Will GTK do 3D
touch? It would be a nice feature you look at a "cut through" of a 3D part
you are making and the pressure of your finger changes the z-axis cut
plane. Or in a simulation pressure moves the time line or the speed of the
simulation. People's expectations are moving and a 1990's style GIU will
look silly in the 2020's (which are only four years away. Pick something
that will still be cutting edge in 2020.

>
>
> > Another words just as you said except I'd drive the screen with some kind
> > of network protocol (like HTML or whatever) that would be wireless if the
> > user prefers that.
>
> On Linux there are X11 but I expect there would be a special purpose
> protocol between GUI and machine. In practice which buttons user pressed
> and values back.
>
> So yo are going to update the protocol every time you update the GUI?
Use something that already exists. HTML5 might work


--

Chris Albertson
Redondo Beach, California

[Ralph Stirling]

The MachineKit folk are a year or two ahead of you guys
in thinking about the distributed control approach. You
ought to go over to their site and study their roadmap in
detail before spending lots of time reinventing wheels again.
They use zeromq and protobuf for communication between
the various components of the motion control system (trajectory
planner, hal, gui, etc). This runs over ethernet. They have
built their code to run on everything from x86, to ARM
(BeagleBoneBlack, RPi2), to SOC fpga's. So check out
http://machinekit.io, and subscribe to their email list or forum.
It is still very bleeding edge, and under heavy development.
If you want to set up machines and run them, stick with
LinuxCNC, if you want to mostly tinker and try out new ideas,
then MachineKit might be the ticket. Eventually it will be a
powerful platform.

-- Ralph
________________________________________
From: Chris Albertson [***@gmail.com]
Sent: Sunday, March 20, 2016 9:38 AM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Linuxcnc on arm

On Sun, Mar 20, 2016 at 12:10 AM, Nicklas Karlsson <
***@gmail.com> wrote:

> > > I am thinking about split in two with real time threads on micro
> > > controller and the computer for the user interface. It would also be a
> > > flexible solution then it come to choice of user interface but require
> > > extra hardware.
> > >
> >
> > If I were designing this in the current century (the 21st) I'd divide the
> > functions roughly in to three (not two) and place them as follows
> > 1) "Hard" real time functions, on a small micro processor not running any
> > OS. Maybe something like an ARM I'd like size the uP so that it could
> > handle four axis and use multiple uP if more axis were needed
>
> Yes
>
> > 2) The user interface _managment_ and higher level non-real time
> functions
> > on a generic "Posix" platform (written in a portable high level language)
> > This could be a PC, Mac, Linux/86, LinuxARM)
>
> Yes
>

How to connect the little uP to the larger computer? WiFi? Will the uP
run some OS?
Take a look at the RISC OS for ARM. It uses "cooperative multitasking"
which means your task runs on the bare hardware with interrupts disabled if
you like
"eCos" might be better.

Could this little uP running (say) eCos actually be a soft-core CPU
implemented inside an FPGA? That runs the cost up but gives access to
nearly unlimited hardware support for pulse generation and even directly
doing micro stepping.

>
> > 3) Rendering of the GUI, that is driving the actual screen and
> > mouse/keyboard. This would be web-abased and like targeted to a mobile
> > device like a cheep $100 Android but of course could run on the same
> > machine as #2 above.
>
> Then linuxcnc is split in two as in 1) and 2) above it is more or less
> done, Why not gtk as now?
>

1) Because it will not be long before someone wants to re-build the PC part
on (say) an iPhone. Why not? Why even use a PC at all?
2) A mouse is hard to use in a shop environment while standing up. The
glass touch screen works better. Should at least preserve the option in
the future to use a glass touch screen and multi touch gestures
3) does GTK run on all the platforms users might want to run on. You know
the first platform to be requested is the Raspberry Pi3. Then if it runs
on that ARM based system why not the iPad? In 5 years all home computers
will have touch screens like the "surface" and all but server class
machines may be running on ARM not Intel.
4) 3D touch is becoming popular and may go mainstream. Will GTK do 3D
touch? It would be a nice feature you look at a "cut through" of a 3D part
you are making and the pressure of your finger changes the z-axis cut
plane. Or in a simulation pressure moves the time line or the speed of the
simulation. People's expectations are moving and a 1990's style GIU will
look silly in the 2020's (which are only four years away. Pick something
that will still be cutting edge in 2020.

>
>
> > Another words just as you said except I'd drive the screen with some kind
> > of network protocol (like HTML or whatever) that would be wireless if the
> > user prefers that.
>
> On Linux there are X11 but I expect there would be a special purpose
> protocol between GUI and machine. In practice which buttons user pressed
> and values back.
>
> So yo are going to update the protocol every time you update the GUI?
Use something that already exists. HTML5 might work


--

Chris Albertson
Redondo Beach, California
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
_______________________________________________
Emc-users mailing list
Emc-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[bari]

How have they lowered the cost of the control and GUI hardware?

I'd like to have a machine controller and GUI for less than the cost of
a new low cost x86 PC and display. Is there a working BOM yet for this?

On 03/20/2016 11:51 AM, Ralph Stirling wrote:
> The MachineKit folk are a year or two ahead of you guys
> in thinking about the distributed control approach. You
> ought to go over to their site and study their roadmap in
> detail before spending lots of time reinventing wheels again.
> They use zeromq and protobuf for communication between
> the various components of the motion control system (trajectory
> planner, hal, gui, etc). This runs over ethernet. They have
> built their code to run on everything from x86, to ARM
> (BeagleBoneBlack, RPi2), to SOC fpga's. So check out
> http://machinekit.io, and subscribe to their email list or forum.
> It is still very bleeding edge, and under heavy development.
> If you want to set up machines and run them, stick with
> LinuxCNC, if you want to mostly tinker and try out new ideas,
> then MachineKit might be the ticket. Eventually it will be a
> powerful platform.
>
>

[Ralph Stirling]

I don't think their immediate focus is lowering cost, but in reorganizing
the system for distributed modularity. The basic BBB implementation
is pretty low cost, though, and is in use by a lot of people for 3d printing.

They have a gui running on Android devices, so you can have a $40 BBB,
a $70 "cape" that connects four stepper motors, and your phone for gui.
The step pulse generation is done by the PRU module in the BBB's ARM
processor.

Check them out, don't rely on my summary.

-- Ralph
________________________________________
From: bari [***@gmail.com]
Sent: Sunday, March 20, 2016 10:02 AM
To: emc-***@lists.sourceforge.net
Subject: Re: [Emc-users] Linuxcnc on arm

How have they lowered the cost of the control and GUI hardware?

I'd like to have a machine controller and GUI for less than the cost of
a new low cost x86 PC and display. Is there a working BOM yet for this?

On 03/20/2016 11:51 AM, Ralph Stirling wrote:
> The MachineKit folk are a year or two ahead of you guys
> in thinking about the distributed control approach. You
> ought to go over to their site and study their roadmap in
> detail before spending lots of time reinventing wheels again.
> They use zeromq and protobuf for communication between
> the various components of the motion control system (trajectory
> planner, hal, gui, etc). This runs over ethernet. They have
> built their code to run on everything from x86, to ARM
> (BeagleBoneBlack, RPi2), to SOC fpga's. So check out
> http://machinekit.io, and subscribe to their email list or forum.
> It is still very bleeding edge, and under heavy development.
> If you want to set up machines and run them, stick with
> LinuxCNC, if you want to mostly tinker and try out new ideas,
> then MachineKit might be the ticket. Eventually it will be a
> powerful platform.
>
>


------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
_______________________________________________
Emc-users mailing list
Emc-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[bari]

It sounds like it's more fun than practical. My Android phone hardly
works as a phone. I can't imagine using it to control a VMC. I'd like to
see an old 60's TV as a GUI with a re-purposed Calliope used for a
keyboard or similar.

On 03/20/2016 12:19 PM, Ralph Stirling wrote:
> I don't think their immediate focus is lowering cost, but in reorganizing
> the system for distributed modularity. The basic BBB implementation
> is pretty low cost, though, and is in use by a lot of people for 3d printing.
>
> They have a gui running on Android devices, so you can have a $40 BBB,
> a $70 "cape" that connects four stepper motors, and your phone for gui.
> The step pulse generation is done by the PRU module in the BBB's ARM
> processor.
>
>

[Nicklas Karlsson]

Then it come to telephones real buttons are at an advantage then dialing. The touch screen is however nice for other purposes.



On Sun, 20 Mar 2016 12:50:44 -0500
bari <***@gmail.com> wrote:

> It sounds like it's more fun than practical. My Android phone hardly
> works as a phone. I can't imagine using it to control a VMC. I'd like to
> see an old 60's TV as a GUI with a re-purposed Calliope used for a
> keyboard or similar.
>
> On 03/20/2016 12:19 PM, Ralph Stirling wrote:
> > I don't think their immediate focus is lowering cost, but in reorganizing
> > the system for distributed modularity. The basic BBB implementation
> > is pretty low cost, though, and is in use by a lot of people for 3d printing.
> >
> > They have a gui running on Android devices, so you can have a $40 BBB,
> > a $70 "cape" that connects four stepper motors, and your phone for gui.
> > The step pulse generation is done by the PRU module in the BBB's ARM
> > processor.
> >
> >
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

[TJoseph Powderly]

555 ( hahaha in Thai )
no! use old hammond organ for that buzzy sound
reminds me of herbie hancock 'rockit'
https://www.youtube.com/watch?v=GHhD4PD75zY
tomp

On 03/21/2016 01:50 AM, bari wrote:
> It sounds like it's more fun than practical. My Android phone hardly
> works as a phone. I can't imagine using it to control a VMC. I'd like to
> see an old 60's TV as a GUI with a re-purposed Calliope used for a
> keyboard or similar.
>
> On 03/20/2016 12:19 PM, Ralph Stirling wrote:
>> I don't think their immediate focus is lowering cost, but in reorganizing
>> the system for distributed modularity. The basic BBB implementation
>> is pretty low cost, though, and is in use by a lot of people for 3d printing.
>>
>> They have a gui running on Android devices, so you can have a $40 BBB,
>> a $70 "cape" that connects four stepper motors, and your phone for gui.
>> The step pulse generation is done by the PRU module in the BBB's ARM
>> processor.
>>
>>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

[Nicklas Karlsson]

It might also be as simple as company selling BBB employ people to make it work well on their hardware. I got the impression BBB is good hardware for 3D printers and similar. For a CNC machine with an computer screen I am however not sure.


On Sun, 20 Mar 2016 17:19:07 +0000
Ralph Stirling <***@wallawalla.edu> wrote:

> I don't think their immediate focus is lowering cost, but in reorganizing
> the system for distributed modularity. The basic BBB implementation
> is pretty low cost, though, and is in use by a lot of people for 3d printing.
>
> They have a gui running on Android devices, so you can have a $40 BBB,
> a $70 "cape" that connects four stepper motors, and your phone for gui.
> The step pulse generation is done by the PRU module in the BBB's ARM
> processor.
>
> Check them out, don't rely on my summary.
>
> -- Ralph
> ________________________________________
> From: bari [***@gmail.com]
> Sent: Sunday, March 20, 2016 10:02 AM
> To: emc-***@lists.sourceforge.net
> Subject: Re: [Emc-users] Linuxcnc on arm
>
> How have they lowered the cost of the control and GUI hardware?
>
> I'd like to have a machine controller and GUI for less than the cost of
> a new low cost x86 PC and display. Is there a working BOM yet for this?
>
> On 03/20/2016 11:51 AM, Ralph Stirling wrote:
> > The MachineKit folk are a year or two ahead of you guys
> > in thinking about the distributed control approach. You
> > ought to go over to their site and study their roadmap in
> > detail before spending lots of time reinventing wheels again.
> > They use zeromq and protobuf for communication between
> > the various components of the motion control system (trajectory
> > planner, hal, gui, etc). This runs over ethernet. They have
> > built their code to run on everything from x86, to ARM
> > (BeagleBoneBlack, RPi2), to SOC fpga's. So check out
> > http://machinekit.io, and subscribe to their email list or forum.
> > It is still very bleeding edge, and under heavy development.
> > If you want to set up machines and run them, stick with
> > LinuxCNC, if you want to mostly tinker and try out new ideas,
> > then MachineKit might be the ticket. Eventually it will be a
> > powerful platform.
> >
> >
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

[Jon Elson]

On 03/20/2016 12:02 PM, bari wrote:
> How have they lowered the cost of the control and GUI hardware?
>
>
Pololu-style drivers are under $5 from China, I use the 8825
version, good up to about 2 A at modest voltage.

The CRAMPS board (that I make to Charles Steinkuehler's
design) is $79.95, and mounts up to 6 Pololu-style drivers,
and handles 6 limits switch inputs. It also has inputs for
4 temperature sensors (or other analog inputs) and 3 heater
outputs and two fans or LED lights, or whatever you want.
The latter stuff is aimed at 3D printers.

The Beagle Bone is currently available for about $55.

So, a complete controller for a 3-axis machine can be set up
for $150 plus power supplies. You can connect an LCD panel,
keyboard and mouse directly, or use a laptop or other
computer through USB or Ethernet for the human interface.

Jon

[Nicklas Karlsson]

Micro controllers with SPI or UART is the cheap stuff for control of switches for servo motors. Ether with or without cat is the expensive stuff at least compared to the cost of a cheap micro controller. One important point is also communication distances within a CNC machine is usually short.


> How have they lowered the cost of the control and GUI hardware?
>
> I'd like to have a machine controller and GUI for less than the cost of
> a new low cost x86 PC and display. Is there a working BOM yet for this?
>
> On 03/20/2016 11:51 AM, Ralph Stirling wrote:
> > The MachineKit folk are a year or two ahead of you guys
> > in thinking about the distributed control approach. You
> > ought to go over to their site and study their roadmap in
> > detail before spending lots of time reinventing wheels again.
> > They use zeromq and protobuf for communication between
> > the various components of the motion control system (trajectory
> > planner, hal, gui, etc). This runs over ethernet. They have
> > built their code to run on everything from x86, to ARM
> > (BeagleBoneBlack, RPi2), to SOC fpga's. So check out
> > http://machinekit.io, and subscribe to their email list or forum.
> > It is still very bleeding edge, and under heavy development.
> > If you want to set up machines and run them, stick with
> > LinuxCNC, if you want to mostly tinker and try out new ideas,
> > then MachineKit might be the ticket. Eventually it will be a
> > powerful platform.
> >
> >
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

[Jon Elson]

On 03/20/2016 11:51 AM, Ralph Stirling wrote:
> The MachineKit folk are a year or two ahead of you guys
> in thinking about the distributed control approach. You
> ought to go over to their site and study their roadmap in
> detail before spending lots of time reinventing wheels again.
> They use zeromq and protobuf for communication between
> the various components of the motion control system (trajectory
> planner, hal, gui, etc). This runs over ethernet. They have
> built their code to run on everything from x86, to ARM
> (BeagleBoneBlack, RPi2), to SOC fpga's. So check out
> http://machinekit.io, and subscribe to their email list or forum.
> It is still very bleeding edge, and under heavy development.
> If you want to set up machines and run them, stick with
> LinuxCNC, if you want to mostly tinker and try out new ideas,
> then MachineKit might be the ticket. Eventually it will be a
> powerful platform.
>
Yes, all of the above. PLUS, the Beagle Bone has a BUILT IN
deterministic microcontroller that runs at 200 MHz.
So, you get instructions in 5 ns, plenty fast for most step
generation, PWM and such tasks. (There are actually TWO of
these microcontrollers, but I think they only support one at
the moment.) The CRAMPS board (don't really care for the
name!) holds up to 6 Pololu-style step drivers plus a lot of
other useful I/O. I run it over Ethernet, you can also
connect to it with IP over USB.

Jon

[Jeff Epler]

On Sun, Mar 20, 2016 at 04:51:39PM +0000, Ralph Stirling wrote:
> The MachineKit folk are a year or two ahead of you guys
> in thinking about the distributed control approach.
[snip]

The original "NIST EMC", a distant ancestor of LinuxCNC, already had a
distributed control approach with NML-over-TCP ten years ago. This was
never widely used among LinuxCNC users, and we know that it is entirely
broken in the 2.7 release due to the way we improved behavior with
multiple (local) user interface programs. We would still be happy to
accept patches that make NML-over-TCP work again.

More background:
https://sourceforge.net/p/emc/bugs/328/
http://mid.gmane.org/20141024221851.GB54584%40unpythonic.net

There is also a test of nml-over-tcp in the branch
"[origin/]jepler/test-nml-over-tcp". This branch also contains a fix of
(some) 64-bit problems in the code, but it is missing a fix for the
reliable command reception code that was added in linuxcnc 2.7.

Jeff

[Nicklas Karlsson]

I read the diagram and EMCTASK is connected by NML:
First step would be to get it to work again.
Second to move lower parts to micro controller.

Then lower parts are on micro controller there is no need to care about real time perfomance in GUI.

Are all NML communication paths via NML-over-TCP? Only downwards? Only upwards?


Regards Nicklas Karlsson



On Tue, 22 Mar 2016 11:56:35 -0500
Jeff Epler <***@unpythonic.net> wrote:

> On Sun, Mar 20, 2016 at 04:51:39PM +0000, Ralph Stirling wrote:
> > The MachineKit folk are a year or two ahead of you guys
> > in thinking about the distributed control approach.
> [snip]
>
> The original "NIST EMC", a distant ancestor of LinuxCNC, already had a
> distributed control approach with NML-over-TCP ten years ago. This was
> never widely used among LinuxCNC users, and we know that it is entirely
> broken in the 2.7 release due to the way we improved behavior with
> multiple (local) user interface programs. We would still be happy to
> accept patches that make NML-over-TCP work again.
>
> More background:
> https://sourceforge.net/p/emc/bugs/328/
> http://mid.gmane.org/20141024221851.GB54584%40unpythonic.net
>
> There is also a test of nml-over-tcp in the branch
> "[origin/]jepler/test-nml-over-tcp". This branch also contains a fix of
> (some) 64-bit problems in the code, but it is missing a fix for the
> reliable command reception code that was added in linuxcnc 2.7.
>
> Jeff
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


--
Nicklas Karlsson <***@gmail.com>

[Jeff Epler]

nml is the protocol/library between UIs and task, as well as between task
and iocontrol. task (not realtime) uses a shared memory interface to
talk to motion (realtime).

Jeff

[Nicklas Karlsson]

In diagram there are first NML and then shared memory. If I put shared memory buffer in micro controller it would talk NML with the EMCTASK.


> nml is the protocol/library between UIs and task, as well as between task
> and iocontrol. task (not realtime) uses a shared memory interface to
> talk to motion (realtime).
>
> Jeff
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

[Nicklas Karlsson]

> > > > I am thinking about split in two with real time threads on micro
> > > > controller and the computer for the user interface. It would also be a
> > > > flexible solution then it come to choice of user interface but require
> > > > extra hardware.
> > > >
> > >
> > > If I were designing this in the current century (the 21st) I'd divide the
> > > functions roughly in to three (not two) and place them as follows
> > > 1) "Hard" real time functions, on a small micro processor not running any
> > > OS. Maybe something like an ARM I'd like size the uP so that it could
> > > handle four axis and use multiple uP if more axis were needed
> >
> > Yes
> >
> > > 2) The user interface _managment_ and higher level non-real time
> > functions
> > > on a generic "Posix" platform (written in a portable high level language)
> > > This could be a PC, Mac, Linux/86, LinuxARM)
> >
> > Yes
> >
>
> How to connect the little uP to the larger computer? WiFi? Will the uP
> run some OS?

This will be the interface between them and is an important point. WiFi, Ethernet, UART or whatever should not be important. What should matter is format of data sent.

> Could this little uP running (say) eCos actually be a soft-core CPU
> implemented inside an FPGA? That runs the cost up but gives access to
> nearly unlimited hardware support for pulse generation and even directly
> doing micro stepping.

What kind of CPU used for real time should not matter very much. If real time threads are implemented as functions called regularly it should work equally well to call them from an operating system as from an interrupt.

Then it come to FPGA most seems to think about signal generation although current micro controllers are very good at this. A FPGA may however implement as many SPI ports as needed which is a fast communication bus available on most micro controllers. It use three singel direction lines which may be isolated cheap and maximum speed is usually in the range 15-50Mbit/s.

> > > 3) Rendering of the GUI, that is driving the actual screen and
> > > mouse/keyboard. This would be web-abased and like targeted to a mobile
> > > device like a cheep $100 Android but of course could run on the same
> > > machine as #2 above.
> >
> > Then linuxcnc is split in two as in 1) and 2) above it is more or less
> > done, Why not gtk as now?
> >
>
> 1) Because it will not be long before someone wants to re-build the PC part
> on (say) an iPhone. Why not? Why even use a PC at all?

Then GUI have been split in two it should work equally to send command from a GUI as from some kind of other software. For example tell linuxcnc to machine a part, wait for it to finnish then tell a robot to remove the part or whatever is needed.


> > So yo are going to update the protocol every time you update the GUI?

If you ssh a linux computer possible with the "-x" switch this is exactly what X11 do today. It can run a graphical program remotely.

> Use something that already exists. HTML5 might work

Or same as today, I think it is GTK. Everything already exist within Linuxcnc so nothing new need to be invented.


Nicklas Karlsson

[bari]

How real time do you want the GUI? Is a few second lag behind the
machines state ok? How about E-stop or Start/Stop from the UI? What's
safe? 1 second max, 10 seconds? If you are milling while at the beach
miles away does it matter? What problem are we solving?

On 03/20/2016 02:10 AM, Nicklas Karlsson wrote:
> Then linuxcnc is split in two as in 1) and 2) above it is more or less done, Why not gtk as now?
>
>
>> >Another words just as you said except I'd drive the screen with some kind
>> >of network protocol (like HTML or whatever) that would be wireless if the
>> >user prefers that.
> On Linux there are X11 but I expect there would be a special purpose protocol between GUI and machine. In practice which buttons user pressed and values back. High speed values like encoder values for hal scope would not be a proble screen update is rather slow and a small delay would be a jerk on the screen not the part.
>
>> >...
> I plan to start looking at as soon as I get my first machines up and running.

[Jon Elson]

On 03/20/2016 11:57 AM, bari wrote:
> How real time do you want the GUI? Is a few second lag behind the
> machines state ok? How about E-stop or Start/Stop from the UI? What's
> safe? 1 second max, 10 seconds? If you are milling while at the beach
> miles away does it matter? What problem are we solving?
>
>
E-stop should be handled with a hardware approach.

Jon

[bari]

But if my phone has the GUI and I'm at the beach do I need to run an
extra pair of conductors back to the machine?

On 03/20/2016 01:22 PM, Jon Elson wrote:
> On 03/20/2016 11:57 AM, bari wrote:
>> How real time do you want the GUI? Is a few second lag behind the
>> machines state ok? How about E-stop or Start/Stop from the UI? What's
>> safe? 1 second max, 10 seconds? If you are milling while at the beach
>> miles away does it matter? What problem are we solving?
>>
>>
> E-stop should be handled with a hardware approach.
>
>
> On 03/20/2016 12:19 PM, Ralph Stirling wrote:
>>
>>
>> They have a gui running on Android devices, so you can have a $40 BBB,
>> a $70 "cape" that connects four stepper motors, and your phone for gui.
>> The step pulse generation is done by the PRU module in the BBB's ARM
>> processor.
>>
>>

[Bertho Stultiens]

On 03/22/2016 11:15 AM, bari wrote:
>>> How real time do you want the GUI? Is a few second lag behind the
>>> machines state ok? How about E-stop or Start/Stop from the UI? What's
>>> safe? 1 second max, 10 seconds? If you are milling while at the beach
>>> miles away does it matter? What problem are we solving?
>> E-stop should be handled with a hardware approach.
> But if my phone has the GUI and I'm at the beach do I need to run an
> extra pair of conductors back to the machine?

If you want to do it right, then yes, you need to run a few extra wires
to your phone. And then some current-loop to ensure that your long
running wires are still working.

The whole point of an emergency stop is that it is virtually impossible
not to work. It must really work in an emergency, not just when you
happen to have a network connection...

Wires and real switches are still several orders of magnitude more
reliable than the best wireless network. Even wired networks are not as
reliable because there are so many intermediate levels that can fail.
Making a "fail-safe" system is a hard job, and using physical wires and
switches is still the best way.

--
Greetings Bertho

(disclaimers are disclaimed)

[bari]

Well I'm glad that machinekit now has this scenario covered.

> On 03/22/2016 05:31 AM, Nicklas Karlsson wrote:
>> No the real time tasks in the work shop may be running by themself or waiting for answer from GUI but you can't trust the emergency stop. If you are on the beach emergency stop will not matter anyway unless you are machining a large bomb.
>>
>>
>>


On 03/22/2016 05:27 AM, Bertho Stultiens wrote:
> On 03/22/2016 11:15 AM, bari wrote:
>>>> How real time do you want the GUI? Is a few second lag behind the
>>>> machines state ok? How about E-stop or Start/Stop from the UI? What's
>>>> safe? 1 second max, 10 seconds? If you are milling while at the beach
>>>> miles away does it matter? What problem are we solving?
>>> E-stop should be handled with a hardware approach.
>> But if my phone has the GUI and I'm at the beach do I need to run an
>> extra pair of conductors back to the machine?
> If you want to do it right, then yes, you need to run a few extra wires
> to your phone. And then some current-loop to ensure that your long
> running wires are still working.
>
> The whole point of an emergency stop is that it is virtually impossible
> not to work. It must really work in an emergency, not just when you
> happen to have a network connection...
>
> Wires and real switches are still several orders of magnitude more
> reliable than the best wireless network. Even wired networks are not as
> reliable because there are so many intermediate levels that can fail.
> Making a "fail-safe" system is a hard job, and using physical wires and
> switches is still the best way.
>

[Nicklas Karlsson]

No the real time tasks in the work shop may be running by themself or waiting for answer from GUI but you can't trust the emergency stop. If you are on the beach emergency stop will not matter anyway unless you are machining a large bomb.



> But if my phone has the GUI and I'm at the beach do I need to run an
> extra pair of conductors back to the machine?
>
> On 03/20/2016 01:22 PM, Jon Elson wrote:
> > On 03/20/2016 11:57 AM, bari wrote:
> >> How real time do you want the GUI? Is a few second lag behind the
> >> machines state ok? How about E-stop or Start/Stop from the UI? What's
> >> safe? 1 second max, 10 seconds? If you are milling while at the beach
> >> miles away does it matter? What problem are we solving?
> >>
> >>
> > E-stop should be handled with a hardware approach.
> >
> >
> > On 03/20/2016 12:19 PM, Ralph Stirling wrote:
> >>
> >>
> >> They have a gui running on Android devices, so you can have a $40 BBB,
> >> a $70 "cape" that connects four stepper motors, and your phone for gui.
> >> The step pulse generation is done by the PRU module in the BBB's ARM
> >> processor.
> >>
> >>
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

[Chris Albertson]

On Tue, Mar 22, 2016 at 3:31 AM, Nicklas Karlsson <
***@gmail.com> wrote:

> No the real time tasks in the work shop may be running by themself or
> waiting for answer from GUI but you can't trust the emergency stop. If you
> are on the beach emergency stop will not matter anyway unless you are
> machining a large bomb.
>
>
No one would use a phone as the only GUI device. Of course you would have
a physical "stop" switch just like you have a physical end mill and motors
too. Actually a phone is an unlikely GUI device. It is just to small.
I'd rather use a cheap Android tablet, or even two of them. I'm setting
up a tablet as a DRO display now. It will just do that one job for the
rest of it's life.

>
>
> > But if my phone has the GUI and I'm at the beach do I need to run an
> > extra pair of conductors back to the machine?
> >
> > On 03/20/2016 01:22 PM, Jon Elson wrote:
> > > On 03/20/2016 11:57 AM, bari wrote:
> > >> How real time do you want the GUI? Is a few second lag behind the
> > >> machines state ok? How about E-stop or Start/Stop from the UI? What's
> > >> safe? 1 second max, 10 seconds? If you are milling while at the beach
> > >> miles away does it matter? What problem are we solving?
> > >>
> > >>
> > > E-stop should be handled with a hardware approach.
> > >
> > >
> > > On 03/20/2016 12:19 PM, Ralph Stirling wrote:
> > >>
> > >>
> > >> They have a gui running on Android devices, so you can have a $40 BBB,
> > >> a $70 "cape" that connects four stepper motors, and your phone for
> gui.
> > >> The step pulse generation is done by the PRU module in the BBB's ARM
> > >> processor.
> > >>
> > >>
> >
> >
> >
> ------------------------------------------------------------------------------
> > Transform Data into Opportunity.
> > Accelerate data analysis in your applications with
> > Intel Data Analytics Acceleration Library.
> > Click to learn more.
> > http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
> > _______________________________________________
> > Emc-users mailing list
> > Emc-***@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>



--

Chris Albertson
Redondo Beach, California

[Jon Elson]

On 03/22/2016 05:15 AM, bari wrote:
> But if my phone has the GUI and I'm at the beach do I need to run an
> extra pair of conductors back to the machine?
>
> On 03/20/2016 01:22 PM, Jon Elson wrote:
>> On 03/20/2016 11:57 AM, bari wrote:
>>> How real time do you want the GUI? Is a few second lag behind the
>>> machines state ok? How about E-stop or Start/Stop from the UI? What's
>>> safe? 1 second max, 10 seconds? If you are milling while at the beach
>>> miles away does it matter? What problem are we solving?
>>>
>>>
>> E-stop should be handled with a hardware approach.
>>
>>
>>
Especially so! How else will you stop the machine when the
batteries in your phone run down and you lose the cell
connection?

Obviously a more serious concern when running a 20 ton
machine tool than a desktop 3D printer.

Jon

[Nicklas Karlsson]

> On 03/22/2016 05:15 AM, bari wrote:
> > But if my phone has the GUI and I'm at the beach do I need to run an
> > extra pair of conductors back to the machine?
> >
> > On 03/20/2016 01:22 PM, Jon Elson wrote:
> >> On 03/20/2016 11:57 AM, bari wrote:
> >>> How real time do you want the GUI? Is a few second lag behind the
> >>> machines state ok? How about E-stop or Start/Stop from the UI? What's
> >>> safe? 1 second max, 10 seconds? If you are milling while at the beach
> >>> miles away does it matter? What problem are we solving?
> >>>
> >>>
> >> E-stop should be handled with a hardware approach.
> >>
> >>
> >>
> Especially so! How else will you stop the machine when the
> batteries in your phone run down and you lose the cell
> connection?
>
> Obviously a more serious concern when running a 20 ton
> machine tool than a desktop 3D printer.
>
> Jon

User interface in a telephone may not be the most useful application but would be a possibility. To separate real time from others would however be useful. The procotol in between might also be useful to control machine via software on a higher level for example tell machine to start then robot have inserted part but this may be the wrong way to do it or?


Nicklas Karlsson

[bari]

On 03/22/2016 11:13 AM, Nicklas Karlsson wrote:
>>
> User interface in a telephone may not be the most useful application but would be a possibility. To separate real time from others would however be useful. The procotol in between might also be useful to control machine via software on a higher level for example tell machine to start then robot have inserted part but this may be the wrong way to do it or?
>
>
> Nicklas Karlsson
>
>
What problem are you solving? The 1-40 ton machine is there in front of
me with the GUI and the controller.

Is this for fun so the CNC glue gun con men can sell people something
else that doesn't really accomplish much? Extruding thermoplastics is a
very small subset of additive manufacturing. We already have controls.
The work ahead is in the materials and hybrid tech to combine
technologies e.g. SLA, Inkjet, FDM into one machine or assembly line.

[Gregg Eshelman]

Here's a 3D printer manufacturer that decided to skimp on the failsafes. They figured that their proprietary software and insisting that the printer be sent back to fix *any* problem, including clogged nozzles, would suffice. (Somebody didn't read about the Therac 25. Should be mandatory for anyone doing *any* kind of software controlled hardware, of any size or deadliness potential.)

This owner unclogged the nozzle himself and forgot to re-tighten the fastener on the heater cartridge. It fell out and the software wasn't programmed to sense the extreme discrepancy  between commanded and sensed temperature. Hello, thermal runaway.
Most open source 3D printer software has that safety function in case of heater or thermistor malfunction.
http://hackaday.com/2016/03/21/ask-hackaday-mrrf-edition-3d-printers-can-catch-fire/


From: Jon Elson <***@pico-systems.com>
To: Enhanced Machine Controller (EMC) <emc-***@lists.sourceforge.net>
Sent: Tuesday, March 22, 2016 9:40 AM
Subject: Re: [Emc-users] Linuxcnc on arm

On 03/22/2016 05:15 AM, bari wrote:

>> E-stop should be handled with a hardware approach.

Especially so!  How else will you stop the machine when the
batteries in your phone run down and you lose the cell
connection?

Obviously a more serious concern when running a 20 ton
machine tool than a desktop 3D printer.

Jon

[Nicklas Karlsson]

Same problem as ordinary software except the emergency stop. I expect there would be big red hard wired button for emergency stop as usual.

The problem solved is demand for GUI is same or at least similar as for other software.



On Sun, 20 Mar 2016 11:57:18 -0500
bari <***@gmail.com> wrote:

> How real time do you want the GUI? Is a few second lag behind the
> machines state ok? How about E-stop or Start/Stop from the UI? What's
> safe? 1 second max, 10 seconds? If you are milling while at the beach
> miles away does it matter? What problem are we solving?
>
> On 03/20/2016 02:10 AM, Nicklas Karlsson wrote:
> > Then linuxcnc is split in two as in 1) and 2) above it is more or less done, Why not gtk as now?
> >
> >
> >> >Another words just as you said except I'd drive the screen with some kind
> >> >of network protocol (like HTML or whatever) that would be wireless if the
> >> >user prefers that.
> > On Linux there are X11 but I expect there would be a special purpose protocol between GUI and machine. In practice which buttons user pressed and values back. High speed values like encoder values for hal scope would not be a proble screen update is rather slow and a small delay would be a jerk on the screen not the part.
> >
> >> >...
> > I plan to start looking at as soon as I get my first machines up and running.
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

[Gregg Eshelman]

Somewhere back in the archives of thedailywtf.com is one about when the company that wrote Wireshark got bought by another company. During integration of the two companies systems, the Wireshark guys used it to help sort things out, then one day it and some of their other software tools were banned from the network as malware.
The idiots running the company that bought them banned the very products they'd just bought from their own systems.




From: Gene Heskett <***@wdtv.com>

I would assume, if they are "calling home" that I could see the traffic
with wireshark or tcpdump?  Hard to see in all the other traffic as I
maintain an sshfs share, and an ssh login session to them all from here. 
So its pretty noisy in terms of net traffic here at the Heskett Cottage.

[Gene Heskett]

On Sunday 20 March 2016 04:28:35 Gregg Eshelman wrote:

> Somewhere back in the archives of thedailywtf.com is one about when
> the company that wrote Wireshark got bought by another company. During
> integration of the two companies systems, the Wireshark guys used it
> to help sort things out, then one day it and some of their other
> software tools were banned from the network as malware. The idiots
> running the company that bought them banned the very products they'd
> just bought from their own systems.

Thus reinforcing the fact that you can't fix stupid. And if they come
from a winderz environment, its really hard to fix ignorant too.
Sigh...

>
> From: Gene Heskett <***@wdtv.com>
>
> I would assume, if they are "calling home" that I could see the
> traffic with wireshark or tcpdump?  Hard to see in all the other
> traffic as I maintain an sshfs share, and an ssh login session to them
> all from here. So its pretty noisy in terms of net traffic here at the
> Heskett Cottage.
>
>
> ----------------------------------------------------------------------
>-------- Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[Nicklas Karlsson]

That's why I think the other direction and put the real time stuff on a micro controller, there are no graphic drivers to think about. I think it is the motion-command-handler and motion-controller threads.

I expect bandwidth required to communicate with the GUI would be rather low. With real time demand removed from the GUI it could be more freely deployed on for example a wireless device.


> That's why we'd need the kernel police to enforce the rules, if there
> were kernel rules that everyone would agree on.
>
> On 03/16/2016 02:36 PM, Jerry Scharf wrote:
> > The real problem is
> > in the kernel and drivers, where you can and often have to lock out
> > interrupts. If those are not designed to work correctly and cooperatively,
> > things stop being RT. When the person writing the graphics card driver is
> > told to get as much performance as they can, they often stop thinking about
> > how polite they are to other time critical things. They have almost no
> > incentive to be careful and lots of incentive to do what makes things go
> > the fastest.
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

[Nicklas Karlsson]

> So how is that different from a non pre-emptive RTOS kernel?
>
> My understanding, and it's very superficial, is that the real time component
> of linux puts a scheduler in front of the basic LINUX kernel. So now the
> micro-stepping or DC-Servo/encoder support can get predictable low latency
> response to events.
>
> Building that into the kernel so that an application like LinuxCNC can
> acquire the resources to get the same level of access above other hardware
> seems obvious. For a non LinuxCNC system perhaps the video or network or
> serial port driver will want higher priority than default. That's a system
> configuration issue. Not whether the scheduling by the kernel is hard real
> time or soft multi-threaded.

Real time scheduling would probably make sense for all serial receive buffers, there is a natural dead line then buffer get full. Or how should execution time be assigned to processes otherwise?

>
> John Dammeyer
>
>
>
> > From: bari [mailto:***@gmail.com]
> > It only sort of does. If a kernel or X dev decides to access hardware
> > directly to get his project done he probably will. Unfortunately there
> > is no kernel police and no really agreed upon rules that they explicitly
> > follow.
> >
> > On 03/16/2016 12:10 PM, John Dammeyer wrote:
> > > But see here's where I'm confused. If Linux already provides priorities
> of
> > > tasks:
> > > http://www.thegeekstuff.com/2013/08/nice-renice-command-examples/
> > > then the LinuxCNC as a task can run higher than anything else.
> > > If the motion/encoder control is offloaded to a device driver, which
> > should
> > > have even higher priority then where does the real time kernel of the
> > > LinuxCNC fit in?
> > > John Dammeyer
> > >
> > >
> >
> >
> >
> ----------------------------------------------------------------------------
> --
> > Transform Data into Opportunity.
> > Accelerate data analysis in your applications with
> > Intel Data Analytics Acceleration Library.
> > Click to learn more.
> > http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> > _______________________________________________
> > Emc-users mailing list
> > Emc-***@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


--
Nicklas Karlsson <***@gmail.com>

[John Dammeyer]

Seems that's a fault of the graphics drivers and their implementation. The
whole point of an RTOS is that tasks can run at priorities that serve their
needs. How would placing the video at a higher priority be any different
than an non-real time system that allows the video to run to completion.

Is the problem so simple that the RTOS system clock isn't allowed to
interrupt the video even if it's just long enough to allow the video driver
to continue to run at an elevated priority? I can see that with older video
hardware from the early 90's but surely things are different now?

John


> Real time is not one of the main concerns of the kernel devs. The kernel
> has graphics drivers that interfere with real time as well as X.
>
> > The ARMs and current crop of PCs are orders of magnitude faster and
> more
> > powerful so why is it that the real time part of Linux isn't the defacto
> > standard for Linux. If it were wouldn't the latest LinuxCNC run on just
> > about anything?
> >
> > Seems a simple question. Is there a simple answer?
> >
> > John Dammeyer
> >
>
>
>
----------------------------------------------------------------------------
--
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

[Nicklas Karlsson]

On Wed, 16 Mar 2016 09:50:33 -0700
"John Dammeyer" <***@autoartisans.com> wrote:

> Seems that's a fault of the graphics drivers and their implementation. The
> whole point of an RTOS is that tasks can run at priorities that serve their
> needs.

You hit the nail!

Exception is if missed dead line is preferred so that some tasks could be made real time. If linuxcnc is run on a communication bus it would probably be preferred to miss a dead line on other buses or a jerk on the screen instead instead of missing a dead line in linuxcnc. With a 1kHz servo period I expect there other tasks that must be handled with higher priorities.

Nicklas Karlsson

[Gene Heskett]

On Wednesday 16 March 2016 12:50:33 John Dammeyer wrote:

> Seems that's a fault of the graphics drivers and their implementation.
> The whole point of an RTOS is that tasks can run at priorities that
> serve their needs. How would placing the video at a higher priority
> be any different than an non-real time system that allows the video to
> run to completion.
>
> Is the problem so simple that the RTOS system clock isn't allowed to
> interrupt the video even if it's just long enough to allow the video
> driver to continue to run at an elevated priority? I can see that
> with older video hardware from the early 90's but surely things are
> different now?
>
> John

A lot of that difference is because the proprietary drivers lock the
IRQ's out till they are done, which in my last experiments could be as
long as 200 milliseconds for the nvidia (spit) blob. Thats wrecked
parts and stalled steppers any way you care to measure it. The nouveau
driver doesn't do that, so RAI works fine. I can't testify about the
ati drivers as I blacklisted those cards at least 8 years ago for the
simple reason that Alex D. lies worse than a politician.
>
> > Real time is not one of the main concerns of the kernel devs. The
> > kernel has graphics drivers that interfere with real time as well as
> > X.
> >
> > > The ARMs and current crop of PCs are orders of magnitude faster
> > > and
> >
> > more
> >
> > > powerful so why is it that the real time part of Linux isn't the
> > > defacto standard for Linux. If it were wouldn't the latest
> > > LinuxCNC run on just about anything?
> > >
> > > Seems a simple question. Is there a simple answer?
> > >
See the other answers too John. Yes, its a simple question, but there
is, sadly, chapter and verse enough of why not to write a boring novel
with.

> > > John Dammeyer
>
> ----------------------------------------------------------------------
>------ --
>
> > Transform Data into Opportunity.
> > Accelerate data analysis in your applications with
> > Intel Data Analytics Acceleration Library.
> > Click to learn more.
> > http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> > _______________________________________________
> > Emc-users mailing list
> > Emc-***@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
> ----------------------------------------------------------------------
>-------- Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[Jon Elson]

On 03/16/2016 11:50 AM, John Dammeyer wrote:
> Seems that's a fault of the graphics drivers and their implementation. The
> whole point of an RTOS is that tasks can run at priorities that serve their
> needs. How would placing the video at a higher priority be any different
> than an non-real time system that allows the video to run to completion.
>
>
Some video drivers do HUGE DMA transfers between screen and
main memory, bursting 10's of megabytes back and forth.
These are totally unthrottled transfers, running as fast as
the memories and busses can go, and thereby locking out the
CPU from the memory for the duration. Since this is not
caused by a process executing in the CPU, it is totally
beyond the control of the RT scheduler. Usually using a
generic video driver reduces the problem as these drivers
don't activate such acceleration features.

Jon

[Nicklas Karlsson]

> On 03/16/2016 11:50 AM, John Dammeyer wrote:
> > Seems that's a fault of the graphics drivers and their implementation. The
> > whole point of an RTOS is that tasks can run at priorities that serve their
> > needs. How would placing the video at a higher priority be any different
> > than an non-real time system that allows the video to run to completion.
> >
> >
> Some video drivers do HUGE DMA transfers between screen and
> main memory, bursting 10's of megabytes back and forth.
> These are totally unthrottled transfers, running as fast as
> the memories and busses can go, and thereby locking out the
> CPU from the memory for the duration. Since this is not
> caused by a process executing in the CPU, it is totally
> beyond the control of the RT scheduler. Usually using a
> generic video driver reduces the problem as these drivers
> don't activate such acceleration features.
>
> Jon

Even though huge DMA transfers currently are out of control from RT scheduler they should not be for good real time perfomance. I go for the micro controllers, slow but predictable, 25µs period run perfect because there are just little code to run each time.

Nicklas Karlsson

[Peter C. Wallace]

On Wed, 16 Mar 2016, John Dammeyer wrote:

> Date: Wed, 16 Mar 2016 09:24:33 -0700
> From: John Dammeyer <***@autoartisans.com>
> Reply-To: "Enhanced Machine Controller (EMC)"
> <emc-***@lists.sourceforge.net>
> To: "'Enhanced Machine Controller (EMC)'" <emc-***@lists.sourceforge.net>
> Subject: Re: [Emc-users] Linuxcnc on arm
>
> As I understand it, the MachineKit was forked from an earlier version of
> LinuxCNC and LinuxCNC requires a real time kernel to run.
>
> Why is it that the real time kernel hasn't become a basic part of Linux so
> that the orphan Linux is the one without the kernel?
>
> Surely by now we've moved past the 486DX4-100 level of processors. IC've
> written an RTOS for an 8 bit NEC78C10, worked with VRTX RTOS on x86 CPUs and
> written software for Motorola MC68070 processors running OS9-68K.
>
> The ARMs and current crop of PCs are orders of magnitude faster and more
> powerful so why is it that the real time part of Linux isn't the defacto
> standard for Linux. If it were wouldn't the latest LinuxCNC run on just
> about anything?
>
> Seems a simple question. Is there a simple answer?
>
> John Dammeyer
>


Preempt-RT will be mainlined into stock linux fairly soon now so its just
becomes a kernel config option but I doubt real time kernels will ever be
standard for common desktop distributions as they typically have
lower performance (excluding latency) than non RT kernels

>
>
>
>> -----Original Message-----
>> From: Sebastian Kuzminsky [mailto:***@highlab.com]
>> Sent: March-16-16 8:29 AM
>> To: Enhanced Machine Controller (EMC)
>> Subject: Re: [Emc-users] Linuxcnc on arm
>>
>>
>> On 03/16/2016 08:25 AM, W. Martinjak wrote:
>>> It's emty.
>>>
>>> http://buildbot.linuxcnc.org/dists/wheezy/2.7-rtpreempt/binary-armhf/
>>> http://buildbot.linuxcnc.org/dists/wheezy/master-rtpreempt/binary-
>> armhf/
>>
>> We build and test on arm, but we currently don't produce debian packages.
>>
>> LinuxCNC 2.7 and newer work on Wheezy on armhf, you just have to build
>> it yourself:
>>
>> http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf
>>
>>
>> --
>> Sebastian Kuzminsky
>>
>>
> ----------------------------------------------------------------------------
> --
>> Transform Data into Opportunity.
>> Accelerate data analysis in your applications with
>> Intel Data Analytics Acceleration Library.
>> Click to learn more.
>> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
>> _______________________________________________
>> Emc-users mailing list
>> Emc-***@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.

[John Dammeyer]

> -----Original Message-----
> From: Peter C. Wallace [mailto:***@mesanet.com]
> >
> > The ARMs and current crop of PCs are orders of magnitude faster and more
> > powerful so why is it that the real time part of Linux isn't the defacto
> > standard for Linux. If it were wouldn't the latest LinuxCNC run on just
> > about anything?
> >
> > Seems a simple question. Is there a simple answer?
> >
> > John Dammeyer
> >
>
>
> Preempt-RT will be mainlined into stock linux fairly soon now so its just
> becomes a kernel config option but I doubt real time kernels will ever be
> standard for common desktop distributions as they typically have
> lower performance (excluding latency) than non RT kernels
>
Lower performance? That seems like an urban legend rather than fact. Or to
be more precise, when a bench mark is run on the Preempt-RT it runs slower
than on the current standard system. And given the speed of processors
and that memory, disk and display are the limiting factors how is that even
valid for CNC systems? Even on desktops. Is the Linux world so focused on
video games that require optimum graphics performance.

The push (and market) in both the windows CNC world and clearly in the
LinuxCNC is for external hardware to do the physical real time part for
stepping and encoders especially for new hardware. Like the MACH3 world for
people happily running LinuxCNC turning out parts are treating their
equipment like a tool. If the tool isn't broken and does the job most won't
replace it.

In either case that turns the main box part into something that is nothing
but a trajectory planner and a graphical display interface. All it has to
do is provide the motion information to the control part in a timely
fashion.

John Dammeyer

[W. Martinjak]

On 2016-03-16 17:50, John Dammeyer wrote:
>> -----Original Message-----
>> From: Peter C. Wallace [mailto:***@mesanet.com]
>>> The ARMs and current crop of PCs are orders of magnitude faster and more
>>> powerful so why is it that the real time part of Linux isn't the defacto
>>> standard for Linux. If it were wouldn't the latest LinuxCNC run on just
>>> about anything?
>>>
>>> Seems a simple question. Is there a simple answer?
>>>
>>> John Dammeyer
>>>
>>
>> Preempt-RT will be mainlined into stock linux fairly soon now so its just
>> becomes a kernel config option but I doubt real time kernels will ever be
>> standard for common desktop distributions as they typically have
>> lower performance (excluding latency) than non RT kernels
>>
> Lower performance? That seems like an urban legend rather than fact. Or to
> be more precise, when a bench mark is run on the Preempt-RT it runs slower
> than on the current standard system. And given the speed of processors
> and that memory, disk and display are the limiting factors how is that even
> valid for CNC systems? Even on desktops. Is the Linux world so focused on
> video games that require optimum graphics performance.
>
> The push (and market) in both the windows CNC world and clearly in the
> LinuxCNC is for external hardware to do the physical real time part for
> stepping and encoders especially for new hardware. Like the MACH3 world for
> people happily running LinuxCNC turning out parts are treating their
> equipment like a tool. If the tool isn't broken and does the job most won't
> replace it.
>
> In either case that turns the main box part into something that is nothing
> but a trajectory planner and a graphical display interface. All it has to
> do is provide the motion information to the control part in a timely
> fashion.
>
> John Dammeyer
>

The problem is different.
RT means looking around and fulfill all tasks in a defined timeslot.
Performance means in most cases move data as fast as you can.
And in some cases it's mutually exclusive.


>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

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

Max Planck

[John Dammeyer]

----Original Message-----
> From: W. Martinjak [mailto:***@play-pla.net]
>
> The problem is different.
> RT means looking around and fulfill all tasks in a defined timeslot.
> Performance means in most cases move data as fast as you can.
> And in some cases it's mutually exclusive.

So what you are saying is standard Linux is just like windows and a task
(thread, application, device driver) can take over the processor and use as
much time as it likes. Totally co-operative rather than pre-emptive.

That an RTOS component adds the time slicing so that every X time period a
task of equal priority gets to use that time slice or part of it to do it's
function.

Or does the first system call an application make to the OS result in an
evaluation of process priorities which results in the highest priority task
getting control which may be different from the task that called the OS.
.
In other words a
while (1 ) { };

loop will break Linux since nothing can pre-empt an infinite loop?

If that doesn't break standard Linux then there's some sort of pre-emptive
multi-tasking going on already.

Perhaps when people use the term Real Time Linux for LinuxCNC they are
talking about something different?

John Dammeyer

[Nicklas Karlsson]

> > The problem is different.
> > RT means looking around and fulfill all tasks in a defined timeslot.
> > Performance means in most cases move data as fast as you can.
> > And in some cases it's mutually exclusive.
>
> So what you are saying is standard Linux is just like windows and a task
> (thread, application, device driver) can take over the processor and use as
> much time as it likes. Totally co-operative rather than pre-emptive.

NO standard Linux use more like fair scheduling.

> That an RTOS component adds the time slicing so that every X time period a
> task of equal priority gets to use that time slice or part of it to do it's
> function.

This is more like ordinary scheduling, clock cycles shared fairly.

> Or does the first system call an application make to the OS result in an
> evaluation of process priorities which results in the highest priority task
> getting control which may be different from the task that called the OS.

In real time scheduling time slost is one method but most common is highest priority task is executed until it have nothing more to do right now. Highest priority task execute until done is the method used in the two most common scheduling schemes Rate monotonic and earliest dead line first. In rate monotonic priority is static and depend on how oftern task need to execute. In earliest dead line first priority is dynamic and depend on time until next dead line. Both are optimal.

There are some preconditions and rules which must be followed, you could read more about it here.

https://en.wikipedia.org/wiki/Rate-monotonic_scheduling
https://en.wikipedia.org/wiki/Earliest_deadline_first_scheduling

> .
> In other words a
> while (1 ) { };
>
> loop will break Linux since nothing can pre-empt an infinite loop?
>
> If that doesn't break standard Linux then there's some sort of pre-emptive
> multi-tasking going on already.
>
> Perhaps when people use the term Real Time Linux for LinuxCNC they are
> talking about something different?
>
> John Dammeyer
>
>
>
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

[Nicklas Karlsson]

> Preempt-RT will be mainlined into stock linux fairly soon now so its just
> becomes a kernel config option but I doubt real time kernels will ever be
> standard for common desktop distributions as they typically have
> lower performance (excluding latency) than non RT kernels

There exist natural real time tasks like serial receive buffers in Linux. Then I started to work a few years ago programming an 8-bit micro controller they did not have nested interrupts with priority while some of the new ARM cortex-* CPUs used in many micro controllers have today.

To put it another way: With priorities handled correct for interrupts all work appropiate for this priority level could be done within interrupt handler. Old style without priority is to exit interrupt handler as soon as possible which still may hold off higher priority tasks and shuffle away work until later but then should it be done?


Nicklas Karlsson

[andy pugh]

On 16 March 2016 at 16:24, John Dammeyer <***@autoartisans.com> wrote:
> Why is it that the real time kernel hasn't become a basic part of Linux so
> that the orphan Linux is the one without the kernel?

With PREEMPT-RT it pretty much is.

As for why RTAI wasn't ever just built-in, I am not sure. Possibly
worries about security, as it gives very low-level access.

--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

[Nicklas Karlsson]

> On 16 March 2016 at 16:24, John Dammeyer <***@autoartisans.com> wrote:
> > Why is it that the real time kernel hasn't become a basic part of Linux so
> > that the orphan Linux is the one without the kernel?
>
> With PREEMPT-RT it pretty much is.
>
> As for why RTAI wasn't ever just built-in, I am not sure. Possibly
> worries about security, as it gives very low-level access.

Memory protection against access outside allowed memory areas? Timer to abort execution if not done in time?

Ordinary computers already have memory protection but maybe it's not good enough. A timer to abort an interrupt if not done in allocated time I never heard about although the hardware for it would be cheap.


Nicklas Karlsson

[Jon Elson]

On 03/16/2016 11:24 AM, John Dammeyer wrote:
> As I understand it, the MachineKit was forked from an earlier version of
> LinuxCNC and LinuxCNC requires a real time kernel to run.
>
> Why is it that the real time kernel hasn't become a basic part of Linux so
> that the orphan Linux is the one without the kernel?
You'd better ask Linus Torvalds this question.
>
> Surely by now we've moved past the 486DX4-100 level of processors. IC've
> written an RTOS for an 8 bit NEC78C10, worked with VRTX RTOS on x86 CPUs and
> written software for Motorola MC68070 processors running OS9-68K.
>
> The ARMs and current crop of PCs are orders of magnitude faster and more
> powerful so why is it that the real time part of Linux isn't the defacto
> standard for Linux.
But, there are a NUMBER of RT patches and options for
various Linux kernels. Rtai, RT-preempt, Xenomai are the
first ones to come to mind. RT-preempt is
included/available for most kernels, but doesn't give
stellar RT latency. However, it is probably good enough for
most hardware-assisted motion control systems.

Jon

[bari]

The i.mx6 can easily run Linuxcnc. The issues that you'll run into are
the high cost of the i.mx6 boards and getting the GUI to run fast
enough. Some i.mx6 quads are under $20ea, but the boards they end up on
tend to be priced closer to $100. Well above the price of a new suitable
x86 board. The i.mx6 has integrated Ethernet so hm2_eth just might work
and it also has PCIe.

I considered making an i.mx6 board last year targeted for Linuxcnc but
there isn't enough interest if the cost is much higher than an x86 solution.
http://openlunchbox.com/open-sbc/

On 03/16/2016 07:17 AM, Erik Friesen wrote:
> I have been doing some work with an i.mx6 of late, and wonder why the quad
> couldn't do linuxcnc? It seems there is some obscure reason I read
> somewhere.
>

[Yanjun Luo]

Hi,
I think Raspberry Pi Module 3 is a good choice, I'll try it when I get a
board soon.

Regards,
Yanjun Luo.



2016-03-16 23:25 GMT+08:00 bari <***@gmail.com>:

> The i.mx6 can easily run Linuxcnc. The issues that you'll run into are
> the high cost of the i.mx6 boards and getting the GUI to run fast
> enough. Some i.mx6 quads are under $20ea, but the boards they end up on
> tend to be priced closer to $100. Well above the price of a new suitable
> x86 board. The i.mx6 has integrated Ethernet so hm2_eth just might work
> and it also has PCIe.
>
> I considered making an i.mx6 board last year targeted for Linuxcnc but
> there isn't enough interest if the cost is much higher than an x86
> solution.
> http://openlunchbox.com/open-sbc/
>
> On 03/16/2016 07:17 AM, Erik Friesen wrote:
> > I have been doing some work with an i.mx6 of late, and wonder why the
> quad
> > couldn't do linuxcnc? It seems there is some obscure reason I read
> > somewhere.
> >
>
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

[andy pugh]

On 16 March 2016 at 15:35, Yanjun Luo <***@gmail.com> wrote:
> Hi,
> I think Raspberry Pi Module 3 is a good choice, I'll try it when I get a
> board soon

The problem with the Pi is that the obvious choice for IO, Ethernet,
is connected via the USB bus.

--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

[W. Martinjak]

On 2016-03-16 16:41, andy pugh wrote:
> On 16 March 2016 at 15:35, Yanjun Luo <***@gmail.com> wrote:
>> Hi,
>> I think Raspberry Pi Module 3 is a good choice, I'll try it when I get a
>> board soon
> The problem with the Pi is that the obvious choice for IO, Ethernet,
> is connected via the USB bus.
>

But SPI works well and in conjunction with an FPGA/CPLD very well.

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

Max Planck

[andy pugh]

On 16 March 2016 at 15:52, W. Martinjak <***@play-pla.net> wrote:

>> The problem with the Pi is that the obvious choice for IO, Ethernet,
>> is connected via the USB bus.
>>
>
> But SPI works well and in conjunction with an FPGA/CPLD very well.

That might be an interesting setup with:
http://store.mesanet.com/index.php?route=product/product&path=83_85&product_id=291

--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

[Erik Friesen]

FYI, the nxgen controller runs around $15K.

On Wed, Mar 16, 2016 at 12:10 PM, andy pugh <***@gmail.com> wrote:

> On 16 March 2016 at 15:52, W. Martinjak <***@play-pla.net> wrote:
>
> >> The problem with the Pi is that the obvious choice for IO, Ethernet,
> >> is connected via the USB bus.
> >>
> >
> > But SPI works well and in conjunction with an FPGA/CPLD very well.
>
> That might be an interesting setup with:
>
> http://store.mesanet.com/index.php?route=product/product&path=83_85&product_id=291
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1916
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

[W. Martinjak]

On 2016-03-16 17:10, andy pugh wrote:
> SPI works well and in conjunction with an FPGA/CPLD very well.
> That might be an interesting setup with:
> http://store.mesanet.com/index.php?route=product/product&path=83_85&product_id=291
>

Yep.
Can you point me to the spec of the spi protocoll of this card?
Or the source?

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

Max Planck

[andy pugh]

On 16 March 2016 at 16:20, W. Martinjak <***@play-pla.net> wrote:
>
>> http://store.mesanet.com/index.php?route=product/product&path=83_85&product_id=291

> Can you point me to the spec of the spi protocoll of this card?
> Or the source?

The spec is in the manual:
http://www.mesanet.com/pdf/parallel/7i90hdman.pdf

The source is:
http://git.linuxcnc.org/gitweb?p=hostmot2-firmware.git;a=tree;h=756a26b2fb7df3550b08f8568c80b728818b9a8b;hb=756a26b2fb7df3550b08f8568c80b728818b9a8b

But you shouldn't need all of that, as the driver exists: (But is only
tested on Odroid as far as I am aware)
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/hal/drivers/mesa-hostmot2/hm2_spi.c;h=adf2327d35e54c0877e0bdbda8600611febe5313;hb=HEAD

--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

[W. Martinjak]

On 2016-03-16 17:33, andy pugh wrote:
> On 16 March 2016 at 16:20, W. Martinjak <***@play-pla.net> wrote:
>>> http://store.mesanet.com/index.php?route=product/product&path=83_85&product_id=291
>> Can you point me to the spec of the spi protocoll of this card?
>> Or the source?
> The spec is in the manual:
> http://www.mesanet.com/pdf/parallel/7i90hdman.pdf
>
> The source is:
> http://git.linuxcnc.org/gitweb?p=hostmot2-firmware.git;a=tree;h=756a26b2fb7df3550b08f8568c80b728818b9a8b;hb=756a26b2fb7df3550b08f8568c80b728818b9a8b
>
> But you shouldn't need all of that, as the driver exists: (But is only
> tested on Odroid as far as I am aware)
> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/hal/drivers/mesa-hostmot2/hm2_spi.c;h=adf2327d35e54c0877e0bdbda8600611febe5313;hb=HEAD
>
Thanks!
Will dig into ...

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

Max Planck

[W. Martinjak]

Wow, 25% more expensive.
:/

http://www.shop.cncmonster.de/LinuxCNC/FPGA-Karten/USB/Parallelport/7I90HD-Parallel-SPI-Anything-I-O-card::393.html?MODsid=ab1fd9c2053920f289f27a2a6c15f815


Do you know some cheaper offers on this side of the pond?


On 2016-03-16 17:33, andy pugh wrote:
> On 16 March 2016 at 16:20, W. Martinjak <***@play-pla.net> wrote:
>>> http://store.mesanet.com/index.php?route=product/product&path=83_85&product_id=291
>> Can you point me to the spec of the spi protocoll of this card?
>> Or the source?
> The spec is in the manual:
> http://www.mesanet.com/pdf/parallel/7i90hdman.pdf
>
> The source is:
> http://git.linuxcnc.org/gitweb?p=hostmot2-firmware.git;a=tree;h=756a26b2fb7df3550b08f8568c80b728818b9a8b;hb=756a26b2fb7df3550b08f8568c80b728818b9a8b
>
> But you shouldn't need all of that, as the driver exists: (But is only
> tested on Odroid as far as I am aware)
> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/hal/drivers/mesa-hostmot2/hm2_spi.c;h=adf2327d35e54c0877e0bdbda8600611febe5313;hb=HEAD
>

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

Max Planck

[Erik Friesen]

I am using the embeddedarm ts4900, seems more industrialized than the
beagle/rasberi pi solutions. Plus, you can get answers on the phone in a
pinch. The buck tends to stop nowhere with the rasberi solutions.

My first go around was with the RiotBoard, which would randomly refuse to
boot.

On Wed, Mar 16, 2016 at 11:52 AM, W. Martinjak <***@play-pla.net> wrote:

> On 2016-03-16 16:41, andy pugh wrote:
> > On 16 March 2016 at 15:35, Yanjun Luo <***@gmail.com> wrote:
> >> Hi,
> >> I think Raspberry Pi Module 3 is a good choice, I'll try it when I get a
> >> board soon
> > The problem with the Pi is that the obvious choice for IO, Ethernet,
> > is connected via the USB bus.
> >
>
> But SPI works well and in conjunction with an FPGA/CPLD very well.
>
> --
> "In der Wissenschaft siegt nie eine neue Theorie,
> nur ihre Gegner sterben nach und nach"
>
> Max Planck
>
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

[bari]

I spent the past few days looking over the current state of ARM SOC's
for Linuxcnc and the open 3D driver situation hasn't changed much.

i.mx6 uses a Vivante GPU and you can build RT kernels and build from
open GPU driver source. The problem is NXP sells their 1-cores for ~$15
and their duals for ~$30 and the quads for ~$55. I get more bang for
the buck with x86. I didn't find any vendors selling i.mx6 parts out the
back door since they can now get better ARM SOC's in China for a
fraction of the price from Allwinner and Rockchip.

Allwinner uses mostly Mali and PowerVR for GPU's. Their SOC's tend to
sell for under $10ea but the GPU and other hardware driver source is
missing.

Samsung Exynos are low cost but they only sell the good parts you'd want
to use to a chosen few customers.

Snapdragon and Tegra K1 are under $20 and have open 3D drivers but like
Samsung only sell SOC's to a select few.

Rockchip uses Mail and also sells SOC's under $10 ea but the like with
Allwinner the drivers are closed.

Broadcom has open 3D drivers for the RPi devices. But dealing with
Broadcom makes me ill and they like Samsung only sell the good parts
you'd want to a chosen few.

Mediatek also uses Mali.

Who and what did I miss?

On 03/16/2016 07:17 AM, Erik Friesen wrote:
> I have been doing some work with an i.mx6 of late, and wonder why the quad
> couldn't do linuxcnc? It seems there is some obscure reason I read
> somewhere.
>
> Older Haas machines use the 68040? 40mhz clunker.
>
> This got me thinking, anyway http://nxgencnc.com/
>
> But I ended up buying a 1996 haas. Going back to rs232 sort of hurts after
> networked linuxcnc.
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

[Nicklas Karlsson]

Then it come to 3D graphics this is the strong point on ordinary computer. Strong point of micro controller is: 3D graphics, hard drives or other unknown will not disturb execution, they are very simple and run software from the internal flash.

My idea is to split linuxcnc in two and only run lower parts on ARM or other micro controller, OS would probably be FreeRtos or none at all. Then i look in developer manual there are diagram with NML in between and old versions already have support for NML over tcp.


On Tue, 22 Mar 2016 17:32:11 -0500
bari <***@gmail.com> wrote:

> I spent the past few days looking over the current state of ARM SOC's
> for Linuxcnc and the open 3D driver situation hasn't changed much.
>
> i.mx6 uses a Vivante GPU and you can build RT kernels and build from
> open GPU driver source. The problem is NXP sells their 1-cores for ~$15
> and their duals for ~$30 and the quads for ~$55. I get more bang for
> the buck with x86. I didn't find any vendors selling i.mx6 parts out the
> back door since they can now get better ARM SOC's in China for a
> fraction of the price from Allwinner and Rockchip.
>
> Allwinner uses mostly Mali and PowerVR for GPU's. Their SOC's tend to
> sell for under $10ea but the GPU and other hardware driver source is
> missing.
>
> Samsung Exynos are low cost but they only sell the good parts you'd want
> to use to a chosen few customers.
>
> Snapdragon and Tegra K1 are under $20 and have open 3D drivers but like
> Samsung only sell SOC's to a select few.
>
> Rockchip uses Mail and also sells SOC's under $10 ea but the like with
> Allwinner the drivers are closed.
>
> Broadcom has open 3D drivers for the RPi devices. But dealing with
> Broadcom makes me ill and they like Samsung only sell the good parts
> you'd want to a chosen few.
>
> Mediatek also uses Mali.
>
> Who and what did I miss?
>
> On 03/16/2016 07:17 AM, Erik Friesen wrote:
> > I have been doing some work with an i.mx6 of late, and wonder why the quad
> > couldn't do linuxcnc? It seems there is some obscure reason I read
> > somewhere.
> >
> > Older Haas machines use the 68040? 40mhz clunker.
> >
> > This got me thinking, anyway http://nxgencnc.com/
> >
> > But I ended up buying a 1996 haas. Going back to rs232 sort of hurts after
> > networked linuxcnc.
> > ------------------------------------------------------------------------------
> > Transform Data into Opportunity.
> > Accelerate data analysis in your applications with
> > Intel Data Analytics Acceleration Library.
> > Click to learn more.
> > http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> > _______________________________________________
> > Emc-users mailing list
> > Emc-***@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

[Erik Friesen]

I don't want bang for my buck. What I want is a control board I can drop
into my haas, and doing it with x86 isn't very feasible. Dropping a
embeddedarm ts4900 on a custom baseboard would be real slick, and it seems
that it could surely compete with the 1990's era motorola running at 40mhz.

Anyway, that is just dreaming. Reality is that when you want to sell
equipment, most will run far and fast from self retrofits.

On Wed, Mar 23, 2016 at 2:51 AM, Nicklas Karlsson <
***@gmail.com> wrote:

> Then it come to 3D graphics this is the strong point on ordinary computer.
> Strong point of micro controller is: 3D graphics, hard drives or other
> unknown will not disturb execution, they are very simple and run software
> from the internal flash.
>
> My idea is to split linuxcnc in two and only run lower parts on ARM or
> other micro controller, OS would probably be FreeRtos or none at all. Then
> i look in developer manual there are diagram with NML in between and old
> versions already have support for NML over tcp.
>
>
> On Tue, 22 Mar 2016 17:32:11 -0500
> bari <***@gmail.com> wrote:
>
> > I spent the past few days looking over the current state of ARM SOC's
> > for Linuxcnc and the open 3D driver situation hasn't changed much.
> >
> > i.mx6 uses a Vivante GPU and you can build RT kernels and build from
> > open GPU driver source. The problem is NXP sells their 1-cores for ~$15
> > and their duals for ~$30 and the quads for ~$55. I get more bang for
> > the buck with x86. I didn't find any vendors selling i.mx6 parts out the
> > back door since they can now get better ARM SOC's in China for a
> > fraction of the price from Allwinner and Rockchip.
> >
> > Allwinner uses mostly Mali and PowerVR for GPU's. Their SOC's tend to
> > sell for under $10ea but the GPU and other hardware driver source is
> > missing.
> >
> > Samsung Exynos are low cost but they only sell the good parts you'd want
> > to use to a chosen few customers.
> >
> > Snapdragon and Tegra K1 are under $20 and have open 3D drivers but like
> > Samsung only sell SOC's to a select few.
> >
> > Rockchip uses Mail and also sells SOC's under $10 ea but the like with
> > Allwinner the drivers are closed.
> >
> > Broadcom has open 3D drivers for the RPi devices. But dealing with
> > Broadcom makes me ill and they like Samsung only sell the good parts
> > you'd want to a chosen few.
> >
> > Mediatek also uses Mali.
> >
> > Who and what did I miss?
> >
> > On 03/16/2016 07:17 AM, Erik Friesen wrote:
> > > I have been doing some work with an i.mx6 of late, and wonder why the
> quad
> > > couldn't do linuxcnc? It seems there is some obscure reason I read
> > > somewhere.
> > >
> > > Older Haas machines use the 68040? 40mhz clunker.
> > >
> > > This got me thinking, anyway http://nxgencnc.com/
> > >
> > > But I ended up buying a 1996 haas. Going back to rs232 sort of hurts
> after
> > > networked linuxcnc.
> > >
> ------------------------------------------------------------------------------
> > > Transform Data into Opportunity.
> > > Accelerate data analysis in your applications with
> > > Intel Data Analytics Acceleration Library.
> > > Click to learn more.
> > > http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> > > _______________________________________________
> > > Emc-users mailing list
> > > Emc-***@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
> >
> >
> ------------------------------------------------------------------------------
> > Transform Data into Opportunity.
> > Accelerate data analysis in your applications with
> > Intel Data Analytics Acceleration Library.
> > Click to learn more.
> > http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
> > _______________________________________________
> > Emc-users mailing list
> > Emc-***@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

[Nicklas Karlsson]

ARM-Cortex-M* CPUs have a nested vectored interrupt NVIC controller with selectable interrupt priorities. The NVIC is suitable for real time scheduling according to rate monotonic, FreeRtos may be added on top if needed, in particular there is nothing uknown disturbing. There are plenty of micro controllers using this and interrupts may be from peripherals like timers or communication buses. The micro controllers usually have suitable perihperals for control of motor switches and in some cases switches for switch mode power converters.

Maybe you do not have to dream for long: There are support communication although currently broken via NML. These micro controllers are cheap and common.

There are also ARM-Cortex-A* CPUs usually with better performance but I do not know if they have the NVIC. I do not think the ARM-Cortex-A* come in devices with peripherals suitable for control of power electronics. I think the ARM-Cortex-A* is more suitable for tasks similar to an ordinary desktop computer.

In short:
Embedded for real time tasks without graphics => ARM-Cortex-M*
Graphics => ARM-Cortex-A* or the usual X86.


Regards Nicklas Karlsson


On Wed, 23 Mar 2016 07:22:39 -0400
Erik Friesen <***@aercon.net> wrote:

> I don't want bang for my buck. What I want is a control board I can drop
> into my haas, and doing it with x86 isn't very feasible. Dropping a
> embeddedarm ts4900 on a custom baseboard would be real slick, and it seems
> that it could surely compete with the 1990's era motorola running at 40mhz.
>
> Anyway, that is just dreaming. Reality is that when you want to sell
> equipment, most will run far and fast from self retrofits.
>
> On Wed, Mar 23, 2016 at 2:51 AM, Nicklas Karlsson <
> ***@gmail.com> wrote:
>
> > Then it come to 3D graphics this is the strong point on ordinary computer.
> > Strong point of micro controller is: 3D graphics, hard drives or other
> > unknown will not disturb execution, they are very simple and run software
> > from the internal flash.
> >
> > My idea is to split linuxcnc in two and only run lower parts on ARM or
> > other micro controller, OS would probably be FreeRtos or none at all. Then
> > i look in developer manual there are diagram with NML in between and old
> > versions already have support for NML over tcp.
> >
> >
> > On Tue, 22 Mar 2016 17:32:11 -0500
> > bari <***@gmail.com> wrote:
> >
> > > I spent the past few days looking over the current state of ARM SOC's
> > > for Linuxcnc and the open 3D driver situation hasn't changed much.
> > >
> > > i.mx6 uses a Vivante GPU and you can build RT kernels and build from
> > > open GPU driver source. The problem is NXP sells their 1-cores for ~$15
> > > and their duals for ~$30 and the quads for ~$55. I get more bang for
> > > the buck with x86. I didn't find any vendors selling i.mx6 parts out the
> > > back door since they can now get better ARM SOC's in China for a
> > > fraction of the price from Allwinner and Rockchip.
> > >
> > > Allwinner uses mostly Mali and PowerVR for GPU's. Their SOC's tend to
> > > sell for under $10ea but the GPU and other hardware driver source is
> > > missing.
> > >
> > > Samsung Exynos are low cost but they only sell the good parts you'd want
> > > to use to a chosen few customers.
> > >
> > > Snapdragon and Tegra K1 are under $20 and have open 3D drivers but like
> > > Samsung only sell SOC's to a select few.
> > >
> > > Rockchip uses Mail and also sells SOC's under $10 ea but the like with
> > > Allwinner the drivers are closed.
> > >
> > > Broadcom has open 3D drivers for the RPi devices. But dealing with
> > > Broadcom makes me ill and they like Samsung only sell the good parts
> > > you'd want to a chosen few.
> > >
> > > Mediatek also uses Mali.
> > >
> > > Who and what did I miss?
> > >
> > > On 03/16/2016 07:17 AM, Erik Friesen wrote:
> > > > I have been doing some work with an i.mx6 of late, and wonder why the
> > quad
> > > > couldn't do linuxcnc? It seems there is some obscure reason I read
> > > > somewhere.
> > > >
> > > > Older Haas machines use the 68040? 40mhz clunker.
> > > >
> > > > This got me thinking, anyway http://nxgencnc.com/
> > > >
> > > > But I ended up buying a 1996 haas. Going back to rs232 sort of hurts
> > after
> > > > networked linuxcnc.
> > > >
> > ------------------------------------------------------------------------------
> > > > Transform Data into Opportunity.
> > > > Accelerate data analysis in your applications with
> > > > Intel Data Analytics Acceleration Library.
> > > > Click to learn more.
> > > > http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> > > > _______________________________________________
> > > > Emc-users mailing list
> > > > Emc-***@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/emc-users
> > >
> > >
> > >
> > ------------------------------------------------------------------------------
> > > Transform Data into Opportunity.
> > > Accelerate data analysis in your applications with
> > > Intel Data Analytics Acceleration Library.
> > > Click to learn more.
> > > http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
> > > _______________________________________________
> > > Emc-users mailing list
> > > Emc-***@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
> >
> > ------------------------------------------------------------------------------
> > Transform Data into Opportunity.
> > Accelerate data analysis in your applications with
> > Intel Data Analytics Acceleration Library.
> > Click to learn more.
> > http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
> > _______________________________________________
> > Emc-users mailing list
> > Emc-***@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

[c***@in-front.com]

I second the point about not using a PC. Most of the CNC reliability issues I see are with backplane card edge connectors for DC servo drives and connectors subject to vibration/chafing of gold plating and oxidation of tin plating. A consumer grade PC motherboard is not meant for machine vibration. USB keyboard, PCI slot and SATA connectors seem to be a weak point as their insertion lifetimes are on the order of 50 or so. I would prefer a 1 or 2 PCB solution with tightly coupled interconnects (possibly soldered) board to board just to eliminate potential sources of connector failure.

My still functional 29 year old Bridgeport Interact 412 uses a Heidenhain 151 CNC controller. It's 12MHz TMS9995 microprocessor is surrounded with TTL counters for encoder position and associated logic that generates 0-10V spindle and brush DC servo command data. Any single core 1GHz A9 would run circles around what I have now. The cost of a PC versus a purpose-built embedded CNC controller is not an issue for me as long as the controller does not creep into the thousands of $$. Machine reliability and up time come first but safety is right up there as well. You can imagine what servo runaway is like when an encoder cable is broken. In my case mouse chewed.

I've been following the BBB discussions and think the BBB would work for the networking & GUI and any RT servo timing should be handled by a FPGA. The BBB's 200MHz PRUs are OK for a simple 3D machine but my 6 head pick and place has X & Y axes, (12) Nema 11 stepper motors and 112 pneumatic feeders. A little beyond a BBB's I/O count.

We developed a FPGA based stepper algorithm using the popular DRV8825 Reprap microstepping driver. The 8825 phase current is dynamically varied based on RPM and these tables are stored in the FPGA. Changing phase current vs. RPM allows us to tune around motor and carriage resonance points. We took a Nema 17 stepper and had it spinning at 3000RPM with 40-bit speed resolution. At full speed the 32x microstepping clock was 320kHz. Probably something a PRU could do in assembly language but is more flexible with VHDL.

I'm considering the BBB and a Spartan-6 cape for ~$100 and the Zynq-based Snickerdoodle for $62-$157. The TS-4900 also looks appealing.


Dennis


On Wed, Mar 23, 2016 at 6:27 AM, Erik Friesen <
***@aercon.net> wrote:
>
> I don't want bang for my buck.  What I want is a control board I can drop
> into my haas, and doing it with x86 isn't very feasible.  Dropping a
> embeddedarm ts4900 on a custom baseboard would be real slick, and it seems
> that it could surely compete with the 1990's era motorola running at 40mhz.

[bari]

Do you have to exchange your SATA and PCIe devices very often? I only do
with my test systems. The controllers for machines might get a SATA or
PCIe device swapped once in it's lifetime of several years.

On 03/23/2016 02:28 PM, ***@in-front.com wrote:
> I second the point about not using a PC. Most of the CNC reliability issues I see are with backplane card edge connectors for DC servo drives and connectors subject to vibration/chafing of gold plating and oxidation of tin plating. A consumer grade PC motherboard is not meant for machine vibration. USB keyboard, PCI slot and SATA connectors seem to be a weak point as their insertion lifetimes are on the order of 50 or so. I would prefer a 1 or 2 PCB solution with tightly coupled interconnects (possibly soldered) board to board just to eliminate potential sources of connector failure.
>

[c***@in-front.com]

There isn't a need to exchange parts once they are in place. Board manufacturers get by with flash gold plated connectors because they are lower cost and the flash plating is only good for so many swipes before the connector cannot meet its original spec of contact resistance, current capacity, etc. The spec for PCI connector plating Finish 4 is a mere 2 mating cycles. If subject to any vibration like my pneumatic ATC exhibits on the machine it wiggles the contact surfaces just a little and chafes a bit more. My pick and place accelerates its carriage to maybe 1-2m/s with Sanmotion drives and servos. You can feel vibration & movement on the frame of the machine no matter how the 1600# machine is anchored down.

My Bridgeport probably started having connector issues after 20 years of use. Now maybe once a month I get a servo amp fault or other random issue related to the card cage. I remove the cards and clean PCB fingers with alcohol then insert the cards a number of times to get into fresh metal. This works again for a while. I just need something I can count on without the machine faulting. Then I would make more parts.


Dennis


On Wed, 23 Mar 2016 15:11
<***@gmail.com> wrote:

>
> Do you have to exchange your SATA and PCIe devices very often? I only do
> with my test systems. The controllers for machines might get a SATA or
> PCIe device swapped once in it's lifetime of several years.

[Nicklas Karlsson]

1. I have a chosen a DRV8824 for stepper while you use DRV8825 and I think only maximum current is different.
2. You talk about TS-4900 or BBB with Cortex-A* CPU there I had chosen an ordinary computer.
3. Instead of FPGA I have chosen cheap STM32 micro controllers.

I work with electronic development so it is important for me to familiar with these micro controllers while you just want to get machine running. I tested timer output switching at around 4MHz with DMA update of compare value a few hours ago. I also use same micro controller for servo motors, it is more or less built for this purpose.


Regards Nicklas Karlsson



On Wed, 23 Mar 2016 14:28:44 -0500
<***@in-front.com> wrote:

> I second the point about not using a PC. Most of the CNC reliability issues I see are with backplane card edge connectors for DC servo drives and connectors subject to vibration/chafing of gold plating and oxidation of tin plating. A consumer grade PC motherboard is not meant for machine vibration. USB keyboard, PCI slot and SATA connectors seem to be a weak point as their insertion lifetimes are on the order of 50 or so. I would prefer a 1 or 2 PCB solution with tightly coupled interconnects (possibly soldered) board to board just to eliminate potential sources of connector failure.
>
> My still functional 29 year old Bridgeport Interact 412 uses a Heidenhain 151 CNC controller. It's 12MHz TMS9995 microprocessor is surrounded with TTL counters for encoder position and associated logic that generates 0-10V spindle and brush DC servo command data. Any single core 1GHz A9 would run circles around what I have now. The cost of a PC versus a purpose-built embedded CNC controller is not an issue for me as long as the controller does not creep into the thousands of $$. Machine reliability and up time come first but safety is right up there as well. You can imagine what servo runaway is like when an encoder cable is broken. In my case mouse chewed.
>
> I've been following the BBB discussions and think the BBB would work for the networking & GUI and any RT servo timing should be handled by a FPGA. The BBB's 200MHz PRUs are OK for a simple 3D machine but my 6 head pick and place has X & Y axes, (12) Nema 11 stepper motors and 112 pneumatic feeders. A little beyond a BBB's I/O count.
>
> We developed a FPGA based stepper algorithm using the popular DRV8825 Reprap microstepping driver. The 8825 phase current is dynamically varied based on RPM and these tables are stored in the FPGA. Changing phase current vs. RPM allows us to tune around motor and carriage resonance points. We took a Nema 17 stepper and had it spinning at 3000RPM with 40-bit speed resolution. At full speed the 32x microstepping clock was 320kHz. Probably something a PRU could do in assembly language but is more flexible with VHDL.
>
> I'm considering the BBB and a Spartan-6 cape for ~$100 and the Zynq-based Snickerdoodle for $62-$157. The TS-4900 also looks appealing.
>
>
> Dennis
>
>
> On Wed, Mar 23, 2016 at 6:27 AM, Erik Friesen <
> ***@aercon.net> wrote:
> >
> > I don't want bang for my buck.  What I want is a control board I can drop
> > into my haas, and doing it with x86 isn't very feasible.  Dropping a
> > embeddedarm ts4900 on a custom baseboard would be real slick, and it seems
> > that it could surely compete with the 1990's era motorola running at 40mhz.
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

[Todd Zuercher]

That is simply because the majority of people want to be able to call up the manufacturer and get an answer or have them fix it when they have a problem. That doesn't happen with retrofits.

----- Original Message -----
From: "Erik Friesen" <***@aercon.net>
To: "Enhanced Machine Controller (EMC)" <emc-***@lists.sourceforge.net>
Sent: Wednesday, March 23, 2016 7:22:39 AM
Subject: Re: [Emc-users] Linuxcnc on arm

Anyway, that is just dreaming. Reality is that when you want to sell
equipment, most will run far and fast from self retrofits.

On Wed, Mar 23, 2016 at 2:51 AM, Nicklas Karlsson <
***@gmail.com> wrote: