Re: [Emc-users] Linuxcnc on arm

[Nicklas Karlsson]

On Thu, 24 Mar 2016 20:54:56 -0500
Jeff Epler  wrote:

> I dared myself to fix nml-over-tcp, and got it working this evening.
> There are still no working sample configs (I think there's something
> buggy in configs/common/{client,server}.nml) but on my local machine the
> linuxcncrsh-tcp test passes, and by using edited copies of its tcp.nml I
> used axis and tklinuxcnc remotely across two computers on my network to
> home, jog, and run MDI commands.  All tests were between 64-bit linux
> computers.
> ...
> Jeff

I read some nice docuentation on machinekit and in particular machinekoder 
yesterday but you are the man who know how to make it happen.

It is files in configs/common folder?


Regards Nicklas Karlsson

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm (scheduling)

[Jon Elson]

On 10/16/2016 11:47 AM, Chris Albertson wrote:
> On Sun, Oct 16, 2016 at 1:13 AM, Nicklas Karlsson <
> nicklas.karlsso...@gmail.com> wrote:
>
>> .
>>> The master board sends the latch command on the parallel
>>> port bus to other boards on the bus, as well as the
>>> computer.  The computer would have the luxury of responding
>>> before the next timer tick, nominally 1 ms.
> Yes, this is how to do it but it requires two processors
>1) a big machine like a PC (or ARM cortex-A) that runs most of LinuxCNC
>2) A much smaller real-time processor that actually moves the signals
> between #1 and the machine tools
>
> You said a "latch" would work.  It would but only in the simple case of a
> parallel output port.You need to also worry about other kinds of data,
> maybe even serial data or PWM . Also the data might not be going over
> parallel port.  It might be Ethernet or USB.  New computers lack parallel
> printer ports.
The Pico Systems PPMC was developed in 2001/2002, and 
follows closely what others have done for real time 
control.  You latch the machine state (encoder position) at 
one tick of the timer, the computer computes new velocities, 
and the new velocities take effect when the timer generates 
the next tick.

The PPMC, Universal Stepper Controller and Universal PWM 
Controller all use FPGAs, so they are quite a bit more 
real-time than a CPU. Our FPGA takes the place of the 
real-time processor.

Yes, USB has its own real-time clock, and won't submit to 
anybody else's idea of real time.  Ethernet can work, but it 
is a lot of trouble.  You can put a parallel port in any 
computer that has a PCI or PCIe slot.  We have found that 
not all plug in parport cards work, though.
> In a modern factory they have the computers in racks and maybe 100 meters
> of cable going to the machines.  So I think yo might want to allow for a
> large physical distance between #1 and #2.
Pretty rare to have CNC controls 100m from the machine.
> I think the above is pretty much how the FPGA in the Mesa cards works.  The
> PC sends data and parameters and the card generates waveforms and meters it
> out in real time.
>
Yes, but we've been doing it before Mesa was in this business.

Jon


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm (scheduling)

[Nicklas Karlsson]

On Sun, 16 Oct 2016 09:47:26 -0700
Chris Albertson  wrote:

> On Sun, Oct 16, 2016 at 1:13 AM, Nicklas Karlsson <
> nicklas.karlsso...@gmail.com> wrote:
> 
> > .
> > > The master board sends the latch command on the parallel
> > > port bus to other boards on the bus, as well as the
> > > computer.  The computer would have the luxury of responding
> > > before the next timer tick, nominally 1 ms.
> >
> 
> Yes, this is how to do it but it requires two processors
>   1) a big machine like a PC (or ARM cortex-A) that runs most of LinuxCNC
>   2) A much smaller real-time processor that actually moves the signals
> between #1 and the machine tools

Execution of the Linuxcnc thread do not have to be accurate in the short time, 
arrival time of received packets could be averaged. For 100 receive times and 
full period jitter average would be within 1 percent of the computer clock 
triggering thread.

I have been thinking about running the real time part of linuxcnc on a cheap 
small computer without user interface and run user interface on ordinary 
computer. NML should already have support for this but I did not yet get time 
to try it. I am still working on the drivers. One reason for this is the cheap 
small computers available nowadays, it would also remove real time demands from 
the user interface computer and add possibility for "remote" control.


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm (scheduling)

[Chris Albertson]

On Sun, Oct 16, 2016 at 1:13 AM, Nicklas Karlsson <
nicklas.karlsso...@gmail.com> wrote:

> .
> > The master board sends the latch command on the parallel
> > port bus to other boards on the bus, as well as the
> > computer.  The computer would have the luxury of responding
> > before the next timer tick, nominally 1 ms.
>

Yes, this is how to do it but it requires two processors
  1) a big machine like a PC (or ARM cortex-A) that runs most of LinuxCNC
  2) A much smaller real-time processor that actually moves the signals
between #1 and the machine tools

You said a "latch" would work.  It would but only in the simple case of a
parallel output port.You need to also worry about other kinds of data,
maybe even serial data or PWM . Also the data might not be going over
parallel port.  It might be Ethernet or USB.  New computers lack parallel
printer ports.

In a modern factory they have the computers in racks and maybe 100 meters
of cable going to the machines.  So I think yo might want to allow for a
large physical distance between #1 and #2.

I think the above is pretty much how the FPGA in the Mesa cards works.  The
PC sends data and parameters and the card generates waveforms and meters it
out in real time.





-- 

Chris Albertson
Redondo Beach, California
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm (interrupt --> servo thread)

[Nicklas Karlsson]

On Sat, 15 Oct 2016 16:06:23 -0500
Jon Elson  wrote:

> On 10/14/2016 12:09 PM, Erik Friesen wrote:
> > I guess I am not following how a hardware interrupt gets mapped to the
> > userspace/lcnc servo thread.  Any pointers on this?

If the thread is implemented as a function call it is all very simple. Get a 
suitable periodic interrupt up and running and add the function calls. They 
could be added statically before compile as ordinary function calls or 
dynamically by a list of function pointers. If threads are known at compile 
static would suffice otherwise dynamic by function pointer is needed.

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm (interrupt system)

[Nicklas Karlsson]

On Sat, 15 Oct 2016 16:06:23 -0500
Jon Elson  wrote:

> On 10/14/2016 12:09 PM, Erik Friesen wrote:
> > I guess I am not following how a hardware interrupt gets mapped to the
> > userspace/lcnc servo thread.  Any pointers on this?
> >
> >
> Supposedly, this is fairly easy to do on the rt-preempt 
> kernel.  It seems it was harder to do this through RTAI.
> Michael Haberler says he has tested this on machinekit, but 
> of course the interrupt system on the ARMs is totally 
> different than on X86.
> 
> Jon

Map an interrupt to a servo thread in linuxcnc running a linux kernel I have no 
idea.

I however know the ARM Cortex-M* model have a nested interrupt controller with 
priority and with priorities set correct it is possible to implement 
rate-monotonic scheduling in hardware with this. I works fo simple systems and 
there are quite few threads in linuxcnc although more might be needed for the 
communication.

The highet end ARMs to my knowledge lack this interrupt controller. They are 
fast but lack the hardware to rely on any theory for real time tasks.

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm (scheduling)

[Nicklas Karlsson]

> >> ... It looks like it might
> >> be easier with the uspace / rt-preempt kernel than with
> >> rtai.  It would reduce latency/jitter to ns levels.

If you build the system so that within servo period is OK things will get a lot 
easier and will fit with ordinary theory fo real time scheduling, dead time 
equal to period.

> Yes, actually, it WOULD.  All the Pico Systems motion 
> control boards can latch the position when the internal 
> timer ticks. ...

This is the way to do it.

> ...
> The master board sends the latch command on the parallel 
> port bus to other boards on the bus, as well as the 
> computer.  The computer would have the luxury of responding 
> before the next timer tick, nominally 1 ms.

This is a good way to get it synchronized a hardware 1kHz signal and the full 
1ms period left for software jitter software.

> As long as the computer never took more than the timer 
> period to complete its work, it would never cause ANY 
> latency at all!  The computer's updated velocity info would 
> not become effective until the next timer tick.

Then you use EDF or rate-monotonic scheduling it will make a perfect fit with 
the theory.

> Jon

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Jon Elson]

On 10/14/2016 09:50 PM, Chris Albertson wrote:
> No, it would not get you to ns levels.
>
>
>I've
>> wanted to set this up on X86 through the parallel port for
>> some time (since about 2002, in fact) but it would take some
>> serious hacking on the PPMC driver.  It looks like it might
>> be easier with the uspace / rt-preempt kernel than with
>> rtai.  It would reduce latency/jitter to ns levels.
>>
Yes, actually, it WOULD.  All the Pico Systems motion 
control boards can latch the position when the internal 
timer ticks.  So, the position latching would be accurate 
down to the jitter of the crystal oscillator.  (If multiple 
boards were used, then the latching would be accurate to the 
difference between the clocks on the different boards, so 
jitter would increase to 1 us, maximum, or 100ns if the 
encoders were updating at 10 MHz clock.)
The master board sends the latch command on the parallel 
port bus to other boards on the bus, as well as the 
computer.  The computer would have the luxury of responding 
before the next timer tick, nominally 1 ms.
As long as the computer never took more than the timer 
period to complete its work, it would never cause ANY 
latency at all!  The computer's updated velocity info would 
not become effective until the next timer tick.

Jon

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Jon Elson]

On 10/14/2016 12:09 PM, Erik Friesen wrote:
> I guess I am not following how a hardware interrupt gets mapped to the
> userspace/lcnc servo thread.  Any pointers on this?
>
>
Supposedly, this is fairly easy to do on the rt-preempt 
kernel.  It seems it was harder to do this through RTAI.
Michael Haberler says he has tested this on machinekit, but 
of course the interrupt system on the ARMs is totally 
different than on X86.

Jon


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Chris Albertson]

No, it would not get you to ns levels.   The reason is that the
computer is not always in a state where it can be interrupted.   The
hardware trigger (line going low) would happen but it has to wait
until the computer looks at the trigger signal.   It only does this
between machine instructions and on X86 these take different lengths
of time (details vary with CPU type) and also, mor important is that
the kernel will some time disable interrupts.   It tries not to do
this for long but it is unavoidable in a multi-taking OS.

If you need perfect interrupt latency get a CPU where every
instruction takes exactly one clock cycle and don't run a multi-task
OS on it.

I good example of a hardware interrupt on an X86 is then you connect a
GPS receiver's "Pulse Pe Second" output to a port in the computer's
main board.  This is normally done when you need to build a stratum
zero NTP server for accurate time.   The pulse itself is typically
within 10 or 20 nano seconds of that actual time of day when the UTC
second "ticks".   The interrupt handler in Linux is simple.  It just
reads the internal nanosecond counter inside the CPU and stores the
current count of nanoseconds from power up on RAM and sets a flag to
show it got a new value then returns.  About a half dozen lines of C
code.

We look at the log of captured counters and see the delay from GPS
pulse to interrupt hander is variable over a few microseconds.   There
are many thousands of NTP servers using GPS reference clocks and they
all see about the same little on their interrupts, a few microseconds.
   To do better you need different hardware

Nano seconds are HARD to do.  Remember that the sped of light is about
one foot per nano second. so you need to account of every inch of wire
and then there are those cheap crystals they use inside your computer
and driver boards that drift on the order of "a few parts per
billion."  "A few PPB" sounds good until you remember that a
nanosecond is a billionth of a second.

Bottom line is that PC hardware is going to be stuck at the "few micro
seconds" level and NEVER get to "few nano seconds" level no matter
what you try.  But all is not lost you can buy programmable logic
devices and micro controllers now for under five or ten bucks.







  I've
> wanted to set this up on X86 through the parallel port for
> some time (since about 2002, in fact) but it would take some
> serious hacking on the PPMC driver.  It looks like it might
> be easier with the uspace / rt-preempt kernel than with
> rtai.  It would reduce latency/jitter to ns levels.
>

-- 

Chris Albertson
Redondo Beach, California

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Jeff Epler]

On Fri, Oct 14, 2016 at 08:11:38AM -0500, Charles Steinkuehler wrote:
> Setup a Mesa card with a periodic timer that triggers a capture of the
> current position and generates an interrupt (the Mesa VHDL code
> already supports this).  In the servo thread, instead of waiting on a
> software timer, you wait on the hardware interrupt.

linxucnc doesn't support threads that wait for a hardware interrupt yet, pull
requests are welcome though.

given the state of linuxcnc, peter has done something interesting in hostmot2:
the FPGA has a PLL that samples encoders shortly before it anticipates getting
a read request.  this substantially reduces jitter in position feedback.

Jeff

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Peter C. Wallace]

On Fri, 14 Oct 2016, Erik Friesen wrote:

> Date: Fri, 14 Oct 2016 13:09:53 -0400
> From: Erik Friesen <e...@aercon.net>
> Reply-To: "Enhanced Machine Controller (EMC)"
> <emc-users@lists.sourceforge.net>
> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
> Subject: Re: [Emc-users] Linuxcnc on arm
> 
> I guess I am not following how a hardware interrupt gets mapped to the
> userspace/lcnc servo thread.  Any pointers on this?

As far as I know this is only done currently with Machinekit
(so their source should have an decent example)


>
> On Fri, Oct 14, 2016 at 11:45 AM, Jon Elson <el...@pico-systems.com> wrote:
>> On 10/14/2016 08:11 AM, Charles Steinkuehler wrote:
>>> On 10/14/2016 7:11 AM, Erik Friesen wrote:
>>>> @Sebastian Kuzminsky Thanks for those docs.
>>>>
>>>> @Charles Steinkuehler
>>>>
>>>> How would you link an interrupt to linuxcnc?
>>> Setup a Mesa card with a periodic timer that triggers a capture of the
>>> current position and generates an interrupt (the Mesa VHDL code
>>> already supports this).  In the servo thread, instead of waiting on a
>>> software timer, you wait on the hardware interrupt.
>>>
>> Pico Systems motion control boards also support this.  I've
>> wanted to set this up on X86 through the parallel port for
>> some time (since about 2002, in fact) but it would take some
>> serious hacking on the PPMC driver.  It looks like it might
>> be easier with the uspace / rt-preempt kernel than with
>> rtai.  It would reduce latency/jitter to ns levels.
>>
>> Not sure if this is a project suitable for the codefest, but
>> I'll think about it.
>>
>> Jon
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@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.


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Erik Friesen]

I guess I am not following how a hardware interrupt gets mapped to the
userspace/lcnc servo thread.  Any pointers on this?

On Fri, Oct 14, 2016 at 11:45 AM, Jon Elson  wrote:
> On 10/14/2016 08:11 AM, Charles Steinkuehler wrote:
>> On 10/14/2016 7:11 AM, Erik Friesen wrote:
>>> @Sebastian Kuzminsky Thanks for those docs.
>>>
>>> @Charles Steinkuehler
>>>
>>> How would you link an interrupt to linuxcnc?
>> Setup a Mesa card with a periodic timer that triggers a capture of the
>> current position and generates an interrupt (the Mesa VHDL code
>> already supports this).  In the servo thread, instead of waiting on a
>> software timer, you wait on the hardware interrupt.
>>
> Pico Systems motion control boards also support this.  I've
> wanted to set this up on X86 through the parallel port for
> some time (since about 2002, in fact) but it would take some
> serious hacking on the PPMC driver.  It looks like it might
> be easier with the uspace / rt-preempt kernel than with
> rtai.  It would reduce latency/jitter to ns levels.
>
> Not sure if this is a project suitable for the codefest, but
> I'll think about it.
>
> Jon
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Jon Elson]

On 10/14/2016 08:11 AM, Charles Steinkuehler wrote:
> On 10/14/2016 7:11 AM, Erik Friesen wrote:
>> @Sebastian Kuzminsky Thanks for those docs.
>>
>> @Charles Steinkuehler
>>
>> How would you link an interrupt to linuxcnc?
> Setup a Mesa card with a periodic timer that triggers a capture of the
> current position and generates an interrupt (the Mesa VHDL code
> already supports this).  In the servo thread, instead of waiting on a
> software timer, you wait on the hardware interrupt.
>
Pico Systems motion control boards also support this.  I've 
wanted to set this up on X86 through the parallel port for 
some time (since about 2002, in fact) but it would take some 
serious hacking on the PPMC driver.  It looks like it might 
be easier with the uspace / rt-preempt kernel than with 
rtai.  It would reduce latency/jitter to ns levels.

Not sure if this is a project suitable for the codefest, but 
I'll think about it.

Jon

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Charles Steinkuehler]

On 10/14/2016 7:11 AM, Erik Friesen wrote:
> @Sebastian Kuzminsky Thanks for those docs.
> 
> @Charles Steinkuehler
> 
> How would you link an interrupt to linuxcnc?

Setup a Mesa card with a periodic timer that triggers a capture of the
current position and generates an interrupt (the Mesa VHDL code
already supports this).  In the servo thread, instead of waiting on a
software timer, you wait on the hardware interrupt.

-- 
Charles Steinkuehler
char...@steinkuehler.net

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Erik Friesen]

@Sebastian Kuzminsky Thanks for those docs.

@Charles Steinkuehler

How would you link an interrupt to linuxcnc?



On Thu, Oct 13, 2016 at 9:15 PM, Charles Steinkuehler
 wrote:
> On 10/13/2016 8:01 PM, Chris Albertson wrote:
>>
>> For sophisticated motion control you really need both. (my internet is
>> in robots, no as much CNC) One to run an OS and drive a user interface
>> and screen and talk over a network and so on.  and a smaller processor
>> to make I/O lines go up and down and drive motors and read encoders.
>>  In LinuxCNC we sometimes have two processors a PC and a Mesa card.
>> On an ARM based CNC, I think you'd see an "A" type perhaps it is a
>> Raspberry Pi or perhaps it is an iPhone app.  Then you'd have "M"
>> types physically driving the hardware.
>
> This is what I like about the BeagleBone (the PRU substitutes for a
> Cortex-M for hard-real-time bit-twiddling) and the Xilinx/Altera
> SoC+FPGA combinations (where you can put the Mesa open-source VHDL
> firmware in the FPGA).
>
> It works particularly well if you drive the servo-thread timing via
> interrupts from the hardware (with position captured by the hardware
> when it fires the interrupt), thus side-stepping the relatively poor
> ARM Cortex-A interrupt latency and jitter.
>
> --
> Charles Steinkuehler
> char...@steinkuehler.net
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm (software library, static <--> dynamic)

[Nicklas Karlsson]

I forgot to mention the system clock. As is in the software libraries it is
a variable although in almost all applications I have written clock
frequency is assumed to be constant. Then I started to program I usually
defined clock frequency to be constant since it is known at compile time. I
do not think the variable approach will be of much use if frequency is
changed while running anyway, or do the drivers handle a change of clock
frequency?

2016-10-14 12:06 GMT+02:00 Nicklas Karlsson :

> It might you used to register call back style functions but it is a lot
> simpler to tell which functions will be called if function calls are added
> in interrupt handler. The software I write usually is very simple and one
> of the reasons is I use the static approach, it have limitations but are
> simpler then enough.
>
> 2016-10-14 10:42 GMT+02:00 Chris Albertson :
>
>> You can choose to any of several libraries.   I have an ARM M3 right
>> now using the Arduino IDE.   Can't get much simpler than that.
>> Another one, an M4 here is being programmed using "mbed" library
>> because I need to do something more complex that needs an RTOS but
>> mbed is also very simple, certainly no call backs.
>>
>> But some times dynamic switching is required.  I had a motor driver
>> chip that has a pin that is normally an enable input but if a fault
>> occurs it switches direction.   the uP has to dynamically reconfigure
>> a pin to read this. Also some serial busses are bidirectional
>>
>> That said, I think in 2016 programmers are used to using call back
>> style programming because we have been writing GIUs that have to
>> handle mouse events for so long.
>>
>> Point is that you can use this or something else if you are the one
>> writing the code.
>>
>> On Thu, Oct 13, 2016 at 9:38 PM, Nicklas Karlsson
>>  wrote:
>> >> TheCortex M is more like the Arduino then Pi.  The M rarely runs an
>> >> operating system and the software burned into flash and from an end
>> >> user's level the software never change.   You see the Arm Cortex M
>> >> inside things like inkjet printers and microwave ovens and the like.
>> >
>> > The librarys supplied from the manufacturers have a problem here, they
>> assumme everything change dynamically while in reality it does not.
>> Software could be made simpler by not using there software libraries. A
>> good example is with there drivers callback functions are registered
>> dynamically and if this is done once during startup software will become
>> simpler by just adding the function calls to the interrupt handler, with
>> this method it is simple to analyse what functions will be called.
>> >
>> > 
>> --
>> > Check out the vibrant tech community on one of the world's most
>> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> > ___
>> > Emc-users mailing list
>> > Emc-users@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/emc-users
>>
>>
>>
>> --
>>
>> Chris Albertson
>> Redondo Beach, California
>>
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>
>
>
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm (software library, static <--> dynamic)

[Nicklas Karlsson]

It might you used to register call back style functions but it is a lot
simpler to tell which functions will be called if function calls are added
in interrupt handler. The software I write usually is very simple and one
of the reasons is I use the static approach, it have limitations but are
simpler then enough.

2016-10-14 10:42 GMT+02:00 Chris Albertson :

> You can choose to any of several libraries.   I have an ARM M3 right
> now using the Arduino IDE.   Can't get much simpler than that.
> Another one, an M4 here is being programmed using "mbed" library
> because I need to do something more complex that needs an RTOS but
> mbed is also very simple, certainly no call backs.
>
> But some times dynamic switching is required.  I had a motor driver
> chip that has a pin that is normally an enable input but if a fault
> occurs it switches direction.   the uP has to dynamically reconfigure
> a pin to read this. Also some serial busses are bidirectional
>
> That said, I think in 2016 programmers are used to using call back
> style programming because we have been writing GIUs that have to
> handle mouse events for so long.
>
> Point is that you can use this or something else if you are the one
> writing the code.
>
> On Thu, Oct 13, 2016 at 9:38 PM, Nicklas Karlsson
>  wrote:
> >> TheCortex M is more like the Arduino then Pi.  The M rarely runs an
> >> operating system and the software burned into flash and from an end
> >> user's level the software never change.   You see the Arm Cortex M
> >> inside things like inkjet printers and microwave ovens and the like.
> >
> > The librarys supplied from the manufacturers have a problem here, they
> assumme everything change dynamically while in reality it does not.
> Software could be made simpler by not using there software libraries. A
> good example is with there drivers callback functions are registered
> dynamically and if this is done once during startup software will become
> simpler by just adding the function calls to the interrupt handler, with
> this method it is simple to analyse what functions will be called.
> >
> > 
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
>
> --
>
> Chris Albertson
> Redondo Beach, California
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm (software library, static <--> dynamic)

[Chris Albertson]

You can choose to any of several libraries.   I have an ARM M3 right
now using the Arduino IDE.   Can't get much simpler than that.
Another one, an M4 here is being programmed using "mbed" library
because I need to do something more complex that needs an RTOS but
mbed is also very simple, certainly no call backs.

But some times dynamic switching is required.  I had a motor driver
chip that has a pin that is normally an enable input but if a fault
occurs it switches direction.   the uP has to dynamically reconfigure
a pin to read this. Also some serial busses are bidirectional

That said, I think in 2016 programmers are used to using call back
style programming because we have been writing GIUs that have to
handle mouse events for so long.

Point is that you can use this or something else if you are the one
writing the code.

On Thu, Oct 13, 2016 at 9:38 PM, Nicklas Karlsson
 wrote:
>> TheCortex M is more like the Arduino then Pi.  The M rarely runs an
>> operating system and the software burned into flash and from an end
>> user's level the software never change.   You see the Arm Cortex M
>> inside things like inkjet printers and microwave ovens and the like.
>
> The librarys supplied from the manufacturers have a problem here, they 
> assumme everything change dynamically while in reality it does not. Software 
> could be made simpler by not using there software libraries. A good example 
> is with there drivers callback functions are registered dynamically and if 
> this is done once during startup software will become simpler by just adding 
> the function calls to the interrupt handler, with this method it is simple to 
> analyse what functions will be called.
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



-- 

Chris Albertson
Redondo Beach, California

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm (software library, static <--> dynamic)

[Nicklas Karlsson]

> TheCortex M is more like the Arduino then Pi.  The M rarely runs an
> operating system and the software burned into flash and from an end
> user's level the software never change.   You see the Arm Cortex M
> inside things like inkjet printers and microwave ovens and the like.

The librarys supplied from the manufacturers have a problem here, they assumme 
everything change dynamically while in reality it does not. Software could be 
made simpler by not using there software libraries. A good example is with 
there drivers callback functions are registered dynamically and if this is done 
once during startup software will become simpler by just adding the function 
calls to the interrupt handler, with this method it is simple to analyse what 
functions will be called.

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Charles Steinkuehler]

On 10/13/2016 8:01 PM, Chris Albertson wrote:
> 
> For sophisticated motion control you really need both. (my internet is
> in robots, no as much CNC) One to run an OS and drive a user interface
> and screen and talk over a network and so on.  and a smaller processor
> to make I/O lines go up and down and drive motors and read encoders.
>  In LinuxCNC we sometimes have two processors a PC and a Mesa card.
> On an ARM based CNC, I think you'd see an "A" type perhaps it is a
> Raspberry Pi or perhaps it is an iPhone app.  Then you'd have "M"
> types physically driving the hardware.

This is what I like about the BeagleBone (the PRU substitutes for a
Cortex-M for hard-real-time bit-twiddling) and the Xilinx/Altera
SoC+FPGA combinations (where you can put the Mesa open-source VHDL
firmware in the FPGA).

It works particularly well if you drive the servo-thread timing via
interrupts from the hardware (with position captured by the hardware
when it fires the interrupt), thus side-stepping the relatively poor
ARM Cortex-A interrupt latency and jitter.

-- 
Charles Steinkuehler
char...@steinkuehler.net



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Chris Albertson]

On 10/13/16, Erik Friesen  wrote:
> To clarify my question, I am trying to understand at what level lcnc
> accesses hardware peripherals.  For example, suppose I build a board with
> an spi dac peripheral to the arm, as well as write the kernel driver, if
> necessary.  What type of glue do I need to provide in this situation?
>
Fear off the is an ARM Cortex A and also a Cortex M.   The "A" type is
what is inside your phone and what powers the Rasberry Piand Beagle
Bone.  These typically run a UNIX-like OS.   Either Linux or in the
case of Apple actually UNIX.   They are not much different from the
the PC based Linux systems we all know about.

The trend is to have very simple and general kernel level device
drives that do little more than moderate access to the hardware.  Then
there is a user space library that handles protocolThe prime
example is USB hardware.   This is the same on Linux ARM and Linus PC.

The ARM does have a LOT more peripheral hardware built-in and the
details expand on the chip. They are all different.

TheCortex M is more like the Arduino then Pi.  The M rarely runs an
operating system and the software burned into flash and from an end
user's level the software never change.   You see the Arm Cortex M
inside things like inkjet printers and microwave ovens and the like.

For sophisticated motion control you really need both. (my internet is
in robots, no as much CNC) One to run an OS and drive a user interface
and screen and talk over a network and so on.  and a smaller processor
to make I/O lines go up and down and drive motors and read encoders.
 In LinuxCNC we sometimes have two processors a PC and a Mesa card.
On an ARM based CNC, I think you'd see an "A" type perhaps it is a
Raspberry Pi or perhaps it is an iPhone app.  Then you'd have "M"
types physically driving the hardware.

The A types ARMs will act pretty much like PCs to an end user or
casual programmer and the "M" typically uses a library that "hides"
the fact that ll the chips are different.   I can simply read "analog
pin 1" and don't need to know the details.  This means my code runs on
many different ARMs with no or little change.  In the Cortex M there
is no "driver" level there is only user space. (or we can claim that
it is all driver and there is no user.)

I currently have serval small "M" type in my desk in the space between
the keyboard and my monitor that I am typing o program.  They are
cheap as dirt, like $4 and less but I can easy keep upgrading an
encoder with 64 pulses per rev that issuing 12,000 RPM.   I can run
four PID loops for four motors and if I know more about control theory
if would not oscillate.  But an"M" is cheap enough and small enough
and uses such little amount of power that I can use one for each
motor.

One could use an FPGA (like Mesa) but the ARM cortex M is now so darn
fast and cheap and VERY easy to program that I'd use that.  Just for
scale, if my motor runs at 12,000 rpm  the "M" chips I have can
execute as many as 500,000 instructions for each revolution of the
motor.
-- 

Chris Albertson
Redondo Beach, California

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Erik Friesen]

Interesting info on spidev, but it doesn't surprise me.  Isn't that
because they are non blocking read/writes to manage slow spi clocks,
etc?  The calls end up in spi_sync, that says "This call may only be
used from a context that may sleep" so I would expect not so good
performance with this.  My first thought would be a blocking/non
sleeping hardware call, although I am not clear if this would require
direct register calls to the spi memory locations.  With a 10mhz spi
ic maybe that would take too long.

On Thu, Oct 13, 2016 at 5:33 PM, Jeff Epler  wrote:
> If your device uses PREEMPT-RT realtime, then you can use any userspace
> interface (ioctl, read, write, recv, send, etc) that gives you
> acceptable latency in practice.  Otherwise, you basically get to do
> direct memory-mapped control of the applicable registers in your SOC,
> because for xenomai and rtai you can't use standard kernel or syscall
> interfaces in realtime context (but you can for setup/cleanup code, for
> instance to get actually map MMIO regions)
>
> The SPI hardware interface, with /dev/spidev as a userspace API, is
> perfect on paper; however, I have experenced that the quality of the
> driver implementation is often poor, both in latency and in, well,
> actually working!
>
> Here are some notes about various ARM SBCs and SPI interface hardware.
> Except for odroid c2, these are all my direct experience.
>
> odroid u3: /dev/spidev working with good latency (good enough for 1kHz)
> after kernel driver modifications, linuxcnc driver hm2_spi, mesa 7i90
> fpga card
>
> odroid c2: reported non-working (only supports 8-bit transfers)
>
> odroid xu4: does not honor spidev byte order ioctl (hardcoded in
> devicetree).  poor latency even after kernel driver modifications
> (probably ok for 500Hz, probably not for 1kHz).  hm2_spi driver again.
>
> raspberry pi 3: only supports 8-bit transfers.  contributed
> register-level driver, confirmed working on preempt-rt (only--will need
> work for other supported rtoses), hm2_rpspi
>
> Jeff
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Jeff Epler]

If your device uses PREEMPT-RT realtime, then you can use any userspace
interface (ioctl, read, write, recv, send, etc) that gives you
acceptable latency in practice.  Otherwise, you basically get to do
direct memory-mapped control of the applicable registers in your SOC,
because for xenomai and rtai you can't use standard kernel or syscall
interfaces in realtime context (but you can for setup/cleanup code, for
instance to get actually map MMIO regions)

The SPI hardware interface, with /dev/spidev as a userspace API, is
perfect on paper; however, I have experenced that the quality of the
driver implementation is often poor, both in latency and in, well,
actually working!  

Here are some notes about various ARM SBCs and SPI interface hardware.
Except for odroid c2, these are all my direct experience.

odroid u3: /dev/spidev working with good latency (good enough for 1kHz)
after kernel driver modifications, linuxcnc driver hm2_spi, mesa 7i90
fpga card

odroid c2: reported non-working (only supports 8-bit transfers)

odroid xu4: does not honor spidev byte order ioctl (hardcoded in
devicetree).  poor latency even after kernel driver modifications
(probably ok for 500Hz, probably not for 1kHz).  hm2_spi driver again.

raspberry pi 3: only supports 8-bit transfers.  contributed
register-level driver, confirmed working on preempt-rt (only--will need
work for other supported rtoses), hm2_rpspi

Jeff

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Sebastian Kuzminsky]

On 10/13/2016 12:24 PM, Erik Friesen wrote:
> To clarify my question, I am trying to understand at what level lcnc
> accesses hardware peripherals.  For example, suppose I build a board with
> an spi dac peripheral to the arm, as well as write the kernel driver, if
> necessary.  What type of glue do I need to provide in this situation?

LinuxCNC interfaces with hardware peripherals through HAL, the Hardware 
Abstraction Layer.  Each hardware peripheral is represented by a HAL 
"component".  A HAL component is a piece of software that talks to its 
hardware and presents HAL pins to the rest of LinuxCNC.  A HAL component 
is thus a kind of device driver.  It talks to LinuxCNC via HAL pins, and 
talks to its hardware in whatever way is appropriate for that hardware.

Each HAL component runs either in "realtime" context, or "non-realtime". 
  Since you're talking about motion control and 4 kHz update rates, you 
want a realtime component.  Realtime components run in realtime threads, 
that's the "addf" stuff you see in .hal files.

Here's a diagram that shows the LinuxCNC architecture:


http://linuxcnc.org/docs/2.7/html/code/code-notes.html#_architecture_overview

Your component would sit down in the bottom left, in the "realtime 
hardware devices" box.

Realtime components can be written in C or in a domain-specific language 
called "comp".  Take a look at src/hal/drivers/hal_speaker.c and 
src/hal/drivers/serport.comp for some simple examples.

Some info on how to get started hacking on LinuxCNC are in these documents:

http://linuxcnc.org/docs/devel/html/code/contributing-to-linuxcnc.html
http://linuxcnc.org/docs/devel/html/code/building-linuxcnc.html

Feel free to ask follow-on questions if any of this is not clear.


-- 
Sebastian Kuzminsky

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Erik Friesen]

Haas drives are basically pwm amplifiers that apparently need a 5v+- signal
120 degrees apart.  Why bother with pwm, why not just put a good spi dac
controlled from the i.mx6?  Then add a couple encoder ic's, or run a pic32
or similar to handle the qei.

On Thu, Oct 13, 2016 at 2:58 PM, Nicklas Karlsson <
nicklas.karlsso...@gmail.com> wrote:

> Then you would need a powerful analog amplifier, unless it is a control
> signal for a driver. An analog amplifier waste energy, a more efficient
> method is to use an inverter card and then you use the PWM module in the
> micro controller to generate signals for the inverter.
>
> You also need to chose a suitable micro controller, the high end usually
> are good for hard drives and similar but not for PWM generation. Micro
> controllers with a Cortex-M* CPU usually have support PWM generation and
> are more or less built for this purpose, they may be cheap from around $1
> each in large quantity and maybe $10-$20 for the more powerful.
>
>
>
> On Thu, 13 Oct 2016 14:24:54 -0400
> Erik Friesen  wrote:
>
> > In this scenario, the dac would be driving a bldc, so it would need to be
> > updated around 4-8khz.
> >
> > On Thu, Oct 13, 2016 at 2:24 PM, Erik Friesen  wrote:
> >
> > > To clarify my question, I am trying to understand at what level lcnc
> > > accesses hardware peripherals.  For example, suppose I build a board
> with
> > > an spi dac peripheral to the arm, as well as write the kernel driver,
> if
> > > necessary.  What type of glue do I need to provide in this situation?
> > >
> > > On Thu, Oct 13, 2016 at 1:50 PM, Nicklas Karlsson <
> > > nicklas.karlsso...@gmail.com> wrote:
> > >
> > >> On the Cortex-M* model usually used on micro controllers there use to
> be
> > >> a reference manual. Usually there is register to configure pin
> > >> functionality, GPIO is a common default value and a register to select
> > >> direction input or output.
> > >>
> > >> There use to a library but software complexity become lower by
> accessing
> > >> the registers directly unless there is a need to change things
> dynamically.
> > >> The libraries are usually written for dynamic access while software
> almost
> > >> always only have need for simpler static access. To register callback
> > >> functions at an interrupt handler is a perfect example, if the same
> > >> function(s) is registered at every startup they could be added
> statically
> > >> and it is possible to generate a call graph.
> > >>
> > >>
> > >> On Thu, 13 Oct 2016 13:27:55 -0400
> > >> Erik Friesen  wrote:
> > >>
> > >> > Resurrecting this thread, can anyone point me to docs, or other info
> > >> what
> > >> > it takes to link GPIO, or SPI devices into linuxcnc on an arm?  On
> what
> > >> > level does this happen?  Userspace, Kernelspace, etc?  I have done a
> > >> bit of
> > >> > kernel programming for the i.mx6.
> > >> >
> > >> > On Thu, Mar 24, 2016 at 8:19 AM, Ron Ginger <
> rongin...@roadrunner.com>
> > >> > wrote:
> > >> >
> > >> > > I was helping a commercial screw machine shop that had a couple
> little
> > >> > > KX1 mills. One was getting rather tired after 5 or 6 years of
> > >> production
> > >> > > use and having repeatability problem. I was speaking with the
> general
> > >> > > manager and asked "well how long do you expect a machine to
> last?" and
> > >> > > without a hint of a smile he whipped back "40 years"
> > >> > >
> > >> > > The KX1 was installed less then 50 feet from a row of screw
> machines
> > >> > > maybe as old as I am (73 years) and they were clanking away
> dropping
> > >> > > parts into a bin.
> > >> > >
> > >> > > ron ginger
> > >> > >
> > >> > > > Who wants to use and maintain (if it is possible) an original
> CNC
> > >> control
> > >> > > > made prior to 2000 ??
> > >> > > >
> > >> > > > Dave
> > >> > > >
> > >> > >
> > >> > >
> > >> > > 
> > >> > > --
> > >> > > 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=/4140
> > >> > > ___
> > >> > > Emc-users mailing list
> > >> > > Emc-users@lists.sourceforge.net
> > >> > > https://lists.sourceforge.net/lists/listinfo/emc-users
> > >> > >
> > >> > 
> > >> --
> > >> > Check out the vibrant tech community on one of the world's most
> > >> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> > >> > ___
> > >> > Emc-users mailing list
> > >> > Emc-users@lists.sourceforge.net
> > >> > https://lists.sourceforge.net/lists/listinfo/emc-users
> > >>
> > >> 
> > >> --

Re: [Emc-users] Linuxcnc on arm

[Nicklas Karlsson]

Then you would need a powerful analog amplifier, unless it is a control signal 
for a driver. An analog amplifier waste energy, a more efficient method is to 
use an inverter card and then you use the PWM module in the micro controller to 
generate signals for the inverter.

You also need to chose a suitable micro controller, the high end usually are 
good for hard drives and similar but not for PWM generation. Micro controllers 
with a Cortex-M* CPU usually have support PWM generation and are more or less 
built for this purpose, they may be cheap from around $1 each in large quantity 
and maybe $10-$20 for the more powerful.



On Thu, 13 Oct 2016 14:24:54 -0400
Erik Friesen  wrote:

> In this scenario, the dac would be driving a bldc, so it would need to be
> updated around 4-8khz.
> 
> On Thu, Oct 13, 2016 at 2:24 PM, Erik Friesen  wrote:
> 
> > To clarify my question, I am trying to understand at what level lcnc
> > accesses hardware peripherals.  For example, suppose I build a board with
> > an spi dac peripheral to the arm, as well as write the kernel driver, if
> > necessary.  What type of glue do I need to provide in this situation?
> >
> > On Thu, Oct 13, 2016 at 1:50 PM, Nicklas Karlsson <
> > nicklas.karlsso...@gmail.com> wrote:
> >
> >> On the Cortex-M* model usually used on micro controllers there use to be
> >> a reference manual. Usually there is register to configure pin
> >> functionality, GPIO is a common default value and a register to select
> >> direction input or output.
> >>
> >> There use to a library but software complexity become lower by accessing
> >> the registers directly unless there is a need to change things dynamically.
> >> The libraries are usually written for dynamic access while software almost
> >> always only have need for simpler static access. To register callback
> >> functions at an interrupt handler is a perfect example, if the same
> >> function(s) is registered at every startup they could be added statically
> >> and it is possible to generate a call graph.
> >>
> >>
> >> On Thu, 13 Oct 2016 13:27:55 -0400
> >> Erik Friesen  wrote:
> >>
> >> > Resurrecting this thread, can anyone point me to docs, or other info
> >> what
> >> > it takes to link GPIO, or SPI devices into linuxcnc on an arm?  On what
> >> > level does this happen?  Userspace, Kernelspace, etc?  I have done a
> >> bit of
> >> > kernel programming for the i.mx6.
> >> >
> >> > On Thu, Mar 24, 2016 at 8:19 AM, Ron Ginger 
> >> > wrote:
> >> >
> >> > > I was helping a commercial screw machine shop that had a couple little
> >> > > KX1 mills. One was getting rather tired after 5 or 6 years of
> >> production
> >> > > use and having repeatability problem. I was speaking with the general
> >> > > manager and asked "well how long do you expect a machine to last?" and
> >> > > without a hint of a smile he whipped back "40 years"
> >> > >
> >> > > The KX1 was installed less then 50 feet from a row of screw machines
> >> > > maybe as old as I am (73 years) and they were clanking away dropping
> >> > > parts into a bin.
> >> > >
> >> > > ron ginger
> >> > >
> >> > > > Who wants to use and maintain (if it is possible) an original CNC
> >> control
> >> > > > made prior to 2000 ??
> >> > > >
> >> > > > Dave
> >> > > >
> >> > >
> >> > >
> >> > > 
> >> > > --
> >> > > 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=/4140
> >> > > ___
> >> > > Emc-users mailing list
> >> > > Emc-users@lists.sourceforge.net
> >> > > https://lists.sourceforge.net/lists/listinfo/emc-users
> >> > >
> >> > 
> >> --
> >> > Check out the vibrant tech community on one of the world's most
> >> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> >> > ___
> >> > Emc-users mailing list
> >> > Emc-users@lists.sourceforge.net
> >> > https://lists.sourceforge.net/lists/listinfo/emc-users
> >>
> >> 
> >> --
> >> Check out the vibrant tech community on one of the world's most
> >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> >> ___
> >> Emc-users mailing list
> >> Emc-users@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/emc-users
> >>
> >
> >
> --
> Check out the vibrant tech community on one of the world's most 
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> 

Re: [Emc-users] Linuxcnc on arm

[Erik Friesen]

In this scenario, the dac would be driving a bldc, so it would need to be
updated around 4-8khz.

On Thu, Oct 13, 2016 at 2:24 PM, Erik Friesen  wrote:

> To clarify my question, I am trying to understand at what level lcnc
> accesses hardware peripherals.  For example, suppose I build a board with
> an spi dac peripheral to the arm, as well as write the kernel driver, if
> necessary.  What type of glue do I need to provide in this situation?
>
> On Thu, Oct 13, 2016 at 1:50 PM, Nicklas Karlsson <
> nicklas.karlsso...@gmail.com> wrote:
>
>> On the Cortex-M* model usually used on micro controllers there use to be
>> a reference manual. Usually there is register to configure pin
>> functionality, GPIO is a common default value and a register to select
>> direction input or output.
>>
>> There use to a library but software complexity become lower by accessing
>> the registers directly unless there is a need to change things dynamically.
>> The libraries are usually written for dynamic access while software almost
>> always only have need for simpler static access. To register callback
>> functions at an interrupt handler is a perfect example, if the same
>> function(s) is registered at every startup they could be added statically
>> and it is possible to generate a call graph.
>>
>>
>> On Thu, 13 Oct 2016 13:27:55 -0400
>> Erik Friesen  wrote:
>>
>> > Resurrecting this thread, can anyone point me to docs, or other info
>> what
>> > it takes to link GPIO, or SPI devices into linuxcnc on an arm?  On what
>> > level does this happen?  Userspace, Kernelspace, etc?  I have done a
>> bit of
>> > kernel programming for the i.mx6.
>> >
>> > On Thu, Mar 24, 2016 at 8:19 AM, Ron Ginger 
>> > wrote:
>> >
>> > > I was helping a commercial screw machine shop that had a couple little
>> > > KX1 mills. One was getting rather tired after 5 or 6 years of
>> production
>> > > use and having repeatability problem. I was speaking with the general
>> > > manager and asked "well how long do you expect a machine to last?" and
>> > > without a hint of a smile he whipped back "40 years"
>> > >
>> > > The KX1 was installed less then 50 feet from a row of screw machines
>> > > maybe as old as I am (73 years) and they were clanking away dropping
>> > > parts into a bin.
>> > >
>> > > ron ginger
>> > >
>> > > > Who wants to use and maintain (if it is possible) an original CNC
>> control
>> > > > made prior to 2000 ??
>> > > >
>> > > > Dave
>> > > >
>> > >
>> > >
>> > > 
>> > > --
>> > > 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=/4140
>> > > ___
>> > > Emc-users mailing list
>> > > Emc-users@lists.sourceforge.net
>> > > https://lists.sourceforge.net/lists/listinfo/emc-users
>> > >
>> > 
>> --
>> > Check out the vibrant tech community on one of the world's most
>> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> > ___
>> > Emc-users mailing list
>> > Emc-users@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/emc-users
>>
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>
>
>
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Erik Friesen]

To clarify my question, I am trying to understand at what level lcnc
accesses hardware peripherals.  For example, suppose I build a board with
an spi dac peripheral to the arm, as well as write the kernel driver, if
necessary.  What type of glue do I need to provide in this situation?

On Thu, Oct 13, 2016 at 1:50 PM, Nicklas Karlsson <
nicklas.karlsso...@gmail.com> wrote:

> On the Cortex-M* model usually used on micro controllers there use to be a
> reference manual. Usually there is register to configure pin functionality,
> GPIO is a common default value and a register to select direction input or
> output.
>
> There use to a library but software complexity become lower by accessing
> the registers directly unless there is a need to change things dynamically.
> The libraries are usually written for dynamic access while software almost
> always only have need for simpler static access. To register callback
> functions at an interrupt handler is a perfect example, if the same
> function(s) is registered at every startup they could be added statically
> and it is possible to generate a call graph.
>
>
> On Thu, 13 Oct 2016 13:27:55 -0400
> Erik Friesen  wrote:
>
> > Resurrecting this thread, can anyone point me to docs, or other info what
> > it takes to link GPIO, or SPI devices into linuxcnc on an arm?  On what
> > level does this happen?  Userspace, Kernelspace, etc?  I have done a bit
> of
> > kernel programming for the i.mx6.
> >
> > On Thu, Mar 24, 2016 at 8:19 AM, Ron Ginger 
> > wrote:
> >
> > > I was helping a commercial screw machine shop that had a couple little
> > > KX1 mills. One was getting rather tired after 5 or 6 years of
> production
> > > use and having repeatability problem. I was speaking with the general
> > > manager and asked "well how long do you expect a machine to last?" and
> > > without a hint of a smile he whipped back "40 years"
> > >
> > > The KX1 was installed less then 50 feet from a row of screw machines
> > > maybe as old as I am (73 years) and they were clanking away dropping
> > > parts into a bin.
> > >
> > > ron ginger
> > >
> > > > Who wants to use and maintain (if it is possible) an original CNC
> control
> > > > made prior to 2000 ??
> > > >
> > > > Dave
> > > >
> > >
> > >
> > > 
> > > --
> > > 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=/4140
> > > ___
> > > Emc-users mailing list
> > > Emc-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/emc-users
> > >
> > 
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Nicklas Karlsson]

On the Cortex-M* model usually used on micro controllers there use to be a 
reference manual. Usually there is register to configure pin functionality, 
GPIO is a common default value and a register to select direction input or 
output.

There use to a library but software complexity become lower by accessing the 
registers directly unless there is a need to change things dynamically. The 
libraries are usually written for dynamic access while software almost always 
only have need for simpler static access. To register callback functions at an 
interrupt handler is a perfect example, if the same function(s) is registered 
at every startup they could be added statically and it is possible to generate 
a call graph.


On Thu, 13 Oct 2016 13:27:55 -0400
Erik Friesen  wrote:

> Resurrecting this thread, can anyone point me to docs, or other info what
> it takes to link GPIO, or SPI devices into linuxcnc on an arm?  On what
> level does this happen?  Userspace, Kernelspace, etc?  I have done a bit of
> kernel programming for the i.mx6.
> 
> On Thu, Mar 24, 2016 at 8:19 AM, Ron Ginger 
> wrote:
> 
> > I was helping a commercial screw machine shop that had a couple little
> > KX1 mills. One was getting rather tired after 5 or 6 years of production
> > use and having repeatability problem. I was speaking with the general
> > manager and asked "well how long do you expect a machine to last?" and
> > without a hint of a smile he whipped back "40 years"
> >
> > The KX1 was installed less then 50 feet from a row of screw machines
> > maybe as old as I am (73 years) and they were clanking away dropping
> > parts into a bin.
> >
> > ron ginger
> >
> > > Who wants to use and maintain (if it is possible) an original CNC control
> > > made prior to 2000 ??
> > >
> > > Dave
> > >
> >
> >
> > 
> > --
> > 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=/4140
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
> --
> Check out the vibrant tech community on one of the world's most 
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Erik Friesen]

Resurrecting this thread, can anyone point me to docs, or other info what
it takes to link GPIO, or SPI devices into linuxcnc on an arm?  On what
level does this happen?  Userspace, Kernelspace, etc?  I have done a bit of
kernel programming for the i.mx6.

On Thu, Mar 24, 2016 at 8:19 AM, Ron Ginger 
wrote:

> I was helping a commercial screw machine shop that had a couple little
> KX1 mills. One was getting rather tired after 5 or 6 years of production
> use and having repeatability problem. I was speaking with the general
> manager and asked "well how long do you expect a machine to last?" and
> without a hint of a smile he whipped back "40 years"
>
> The KX1 was installed less then 50 feet from a row of screw machines
> maybe as old as I am (73 years) and they were clanking away dropping
> parts into a bin.
>
> ron ginger
>
> > Who wants to use and maintain (if it is possible) an original CNC control
> > made prior to 2000 ??
> >
> > Dave
> >
>
>
> 
> --
> 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=/4140
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[W. Martinjak]

On 2016-05-12 03:49, Jeff Epler wrote:
> On Thu, Mar 24, 2016 at 08:54:56PM -0500, Jeff Epler wrote:
>> The work is on a branch, "[origin/]jepler/master/nml-tcp" and will not
>> make it into a release branch anytime soon.
> I changed my mind about this.  The branch has now been merged into
> master, so nml-over-tcp may be a working feature in the next major
> release of linuxcnc.
Good news.

Thanks
> Jeff
matsche

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

Max Planck


--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm --> NML over TCP

[Nicklas Karlsson]

> On Thu, Mar 24, 2016 at 08:54:56PM -0500, Jeff Epler wrote:
> > The work is on a branch, "[origin/]jepler/master/nml-tcp" and will not
> > make it into a release branch anytime soon.
> 
> I changed my mind about this.  The branch has now been merged into
> master, so nml-over-tcp may be a working feature in the next major
> release of linuxcnc.
> 
> Jeff

Sound great, hopefully I will be able to work my way up from the circuit boards 
to a higher level very soon.

I am pretty sure possibility to separate user inteface from real time will have 
it's advantages.

--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Jeff Epler]

On Thu, Mar 24, 2016 at 08:54:56PM -0500, Jeff Epler wrote:
> The work is on a branch, "[origin/]jepler/master/nml-tcp" and will not
> make it into a release branch anytime soon.

I changed my mind about this.  The branch has now been merged into
master, so nml-over-tcp may be a working feature in the next major
release of linuxcnc.

Jeff

--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm (NML-over-tcp)

[Nicklas Karlsson]

> On Sun, Mar 20, 2016 at 04:51:39PM +, 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

I have an engraver and (NML-over-tcp) would be a perfect solution.

To control engraver over network via Linuxcnc run on computer is not a perfect 
solution. To have an extra computer for the engraver is neither especially 
practical.

To run real time tasks locally on engraver and GUI on computer over network 
should work really well. It would also be practical with some remote control to 
jog engraver in position before starting. For remote control I lake cables, 
they do not run away or require batteries. A joystick bolted to engraver might 
be a good solution.


Nicklas Karlsson

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Nicklas Karlsson]

> one change/improvement I see is a move towards linear motors instead of
> spindle/belt drives. And parallel kinematics (tripod, hexapod) seem to
> become more popular, mainly because the required algorithms can now
> fairly easily be implemented due to plenty of processing power.
> 
> ...
> 
> Regards,
> Philipp

I have hexapod standing, it is probably 10 or 15 years old. The state of the 
electronic box is unknown but I plan to use linuxcnc anyway.


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=278785351=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Philipp Burch]

Hi everyone,

On 26.03.2016 17:40, Dave Cole wrote:
> On 3/26/2016 3:59 AM, Nicklas Karlsson wrote:
>> Electronics have improved but then it come to mechanics or servo drives are 
>> there any new innovations?
> 
>>> Electronics have improved but then it come to mechanics or servo drives are 
>>> there any new innovations?
> 
> Yes, they make and sell things now that could not be made economically 40 
> years ago.  Digital servo drives are a big improvement over analog servo 
> drives.  Plus many of them are programmable so they can run motion routines 
> with little assistance.   Then there are network connected Digital servo 
> drives and those get rid of a lot of wiring.

one change/improvement I see is a move towards linear motors instead of
spindle/belt drives. And parallel kinematics (tripod, hexapod) seem to
become more popular, mainly because the required algorithms can now
fairly easily be implemented due to plenty of processing power.

When it comes to small-scale systems operating in the sub-micrometer
areas, piezoelectric actuators may be considered a recent innovation.

Regards,
Philipp



signature.asc
Description: OpenPGP digital signature
--
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=/4140___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Todd Zuercher]

It depends on what you call a "tractor". A brand new $300,000.00 John Deere, is 
a far different beast from what a state of the art tractor was 30-40 years ago 
(or even 10-20).

- Original Message -
From: "Chris Albertson" <albertson.ch...@gmail.com>
To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
Sent: Saturday, March 26, 2016 12:00:44 PM
Subject: Re: [Emc-users] Linuxcnc on arm

All technology is like that.  When it is new change happens very fast and
then as in matures the rate of change becomes slower.  An example is
airplanes.  We know what a Write Flyer looked like on 1905 but by 1915 the
planes used in world war I were much different and by the 1930, another 15
years we have some aluminum mono planes and by 1945 we had the P51 Mustang
and the Germans had an experimental jet fighter.But today when a new
airliner comes out (say the 777) it looks a lot like the old one.   What
happens is that engineers think of the easy and obvious improvements first
and then as time goes by only incremental changes are left.   Other times
change is limited by economics.  The more complex device requires more
engineering time and more expensive factory equipment but it would raise
the price above what the market wants to pay.  So the product is kind of
stuck.  Tractors are that way, we can add electronic controls but the basic
design is very stable now.Machine tool mechanics and servo motors are
what I'd call very mature technology and I'd not expect rapid change.

On Sat, Mar 26, 2016 at 1:59 AM, Nicklas Karlsson <
nicklas.karlsso...@gmail.com> wrote:

> My tractor is very old, probably more than 40 years and is still used.
> Motor broke down once more than 15 years ago but is fixed. There are still
> spare parts available. Tractors built the same way today so there are no
> new innovation.
>
> Electronics have improved but then it come to mechanics or servo drives
> are there any new innovations?


-- 

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=278785351=/4140
___
Emc-users mailing list
Emc-users@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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Chris Albertson]

All technology is like that.  When it is new change happens very fast and
then as in matures the rate of change becomes slower.  An example is
airplanes.  We know what a Write Flyer looked like on 1905 but by 1915 the
planes used in world war I were much different and by the 1930, another 15
years we have some aluminum mono planes and by 1945 we had the P51 Mustang
and the Germans had an experimental jet fighter.But today when a new
airliner comes out (say the 777) it looks a lot like the old one.   What
happens is that engineers think of the easy and obvious improvements first
and then as time goes by only incremental changes are left.   Other times
change is limited by economics.  The more complex device requires more
engineering time and more expensive factory equipment but it would raise
the price above what the market wants to pay.  So the product is kind of
stuck.  Tractors are that way, we can add electronic controls but the basic
design is very stable now.Machine tool mechanics and servo motors are
what I'd call very mature technology and I'd not expect rapid change.

On Sat, Mar 26, 2016 at 1:59 AM, Nicklas Karlsson <
nicklas.karlsso...@gmail.com> wrote:

> My tractor is very old, probably more than 40 years and is still used.
> Motor broke down once more than 15 years ago but is fixed. There are still
> spare parts available. Tractors built the same way today so there are no
> new innovation.
>
> Electronics have improved but then it come to mechanics or servo drives
> are there any new innovations?


-- 

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=278785351=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Dave Cole]

On 3/26/2016 3:59 AM, Nicklas Karlsson wrote:
> Electronics have improved but then it come to mechanics or servo drives are 
> there any new innovations?

>>Electronics have improved but then it come to mechanics or servo drives are 
>>there any new innovations?

Yes, they make and sell things now that could not be made economically 40 years 
ago.  Digital servo drives are a big improvement over analog servo drives.  
Plus many of them are programmable so they can run motion routines with little 
assistance.   Then there are network connected Digital servo drives and those 
get rid of a lot of wiring.

BTW, I have a 1939 Ford tractor.  It even has rubber tires even though many of 
them were made with steel lug wheels at the time.  :-)
And yes, you can still buy parts for a Ford 9N tractor.  The Chinese make most 
of them!  :-(

Dave



--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Nicklas Karlsson]

My tractor is very old, probably more than 40 years and is still used. Motor 
broke down once more than 15 years ago but is fixed. There are still spare 
parts available. Tractors built the same way today so there are no new 
innovation.

Electronics have improved but then it come to mechanics or servo drives are 
there any new innovations?

Regards Nicklas Karlsson



> I was helping a commercial screw machine shop that had a couple little 
> KX1 mills. One was getting rather tired after 5 or 6 years of production 
> use and having repeatability problem. I was speaking with the general 
> manager and asked "well how long do you expect a machine to last?" and 
> without a hint of a smile he whipped back "40 years"
> 
> The KX1 was installed less then 50 feet from a row of screw machines 
> maybe as old as I am (73 years) and they were clanking away dropping 
> parts into a bin.
> 
> ron ginger
> 
> > Who wants to use and maintain (if it is possible) an original CNC control
> > made prior to 2000 ??
> >
> > Dave
> >
> 
> 
> --
> 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=/4140
> ___
> Emc-users mailing list
> Emc-users@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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Nicklas Karlsson]

Sounds great.

I spent the last months working on servo drives, in particular to get some 
hardware easy to work with built from not to expensive parts. Soon I will move 
to higher level and hopefully be able to contribute something to Linuxcnc.

Regards Nicklas Karlsson


On Thu, 24 Mar 2016 20:54:56 -0500
Jeff Epler  wrote:

> I dared myself to fix nml-over-tcp, and got it working this evening.
> There are still no working sample configs (I think there's something
> buggy in configs/common/{client,server}.nml) but on my local machine the
> linuxcncrsh-tcp test passes, and by using edited copies of its tcp.nml I
> used axis and tklinuxcnc remotely across two computers on my network to
> home, jog, and run MDI commands.  All tests were between 64-bit linux
> computers.
> 
> This is approximately the level of functionality we think nml-over-tcp
> had in linuxcnc 2.6, except that it should also have the reliable
> command reception feature we added in 2.7, which is what broke
> nml-over-tcp when it was first introduced.
> 
> The work is on a branch, "[origin/]jepler/master/nml-tcp" and will not
> make it into a release branch anytime soon.
> 
> 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=/4140
> ___
> Emc-users mailing list
> Emc-users@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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[TJoseph Powderly]

wow! thx Jeff
tomp

On 03/25/2016 09:54 AM, Jeff Epler wrote:
> I dared myself to fix nml-over-tcp, and got it working this evening.
>


--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Jeff Epler]

I dared myself to fix nml-over-tcp, and got it working this evening.
There are still no working sample configs (I think there's something
buggy in configs/common/{client,server}.nml) but on my local machine the
linuxcncrsh-tcp test passes, and by using edited copies of its tcp.nml I
used axis and tklinuxcnc remotely across two computers on my network to
home, jog, and run MDI commands.  All tests were between 64-bit linux
computers.

This is approximately the level of functionality we think nml-over-tcp
had in linuxcnc 2.6, except that it should also have the reliable
command reception feature we added in 2.7, which is what broke
nml-over-tcp when it was first introduced.

The work is on a branch, "[origin/]jepler/master/nml-tcp" and will not
make it into a release branch anytime soon.

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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Dave Cole]

Depending on the machine and the original construction, the iron can 
last a lot longer than the controls if it is well maintained and lubed.

I've worked on many 40+ year old machines but almost all of them were 
pre-1970 vintage.  Heavy iron and built with replaceable/regrindable 
ways etc.

Dave

On 3/24/2016 7:19 AM, Ron Ginger wrote:
> I was helping a commercial screw machine shop that had a couple little
> KX1 mills. One was getting rather tired after 5 or 6 years of production
> use and having repeatability problem. I was speaking with the general
> manager and asked "well how long do you expect a machine to last?" and
> without a hint of a smile he whipped back "40 years"
>
> The KX1 was installed less then 50 feet from a row of screw machines
> maybe as old as I am (73 years) and they were clanking away dropping
> parts into a bin.
>
> ron ginger
>
>> Who wants to use and maintain (if it is possible) an original CNC control
>> made prior to 2000 ??
>>
>> Dave
>>
>
> --
> 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=/4140
> ___
> Emc-users mailing list
> Emc-users@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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Gene Heskett]

On Thursday 24 March 2016 08:19:12 Ron Ginger wrote:

> I was helping a commercial screw machine shop that had a couple little
> KX1 mills. One was getting rather tired after 5 or 6 years of
> production use and having repeatability problem. I was speaking with
> the general manager and asked "well how long do you expect a machine
> to last?" and without a hint of a smile he whipped back "40 years"
>
> The KX1 was installed less then 50 feet from a row of screw machines
> maybe as old as I am (73 years) and they were clanking away dropping
> parts into a bin.
>
> ron ginger
>
And I expect each one was individually 20x heavier than the KX1, and 
probably factory setup with a 1 shot lube system.  Methinks said GM 
needs introduced to the you get what you pay for reality. Sheesh..

> > Who wants to use and maintain (if it is possible) an original CNC
> > control made prior to 2000 ??
> >
> > Dave
>
> --
> 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=/4140
> ___
> Emc-users mailing list
> Emc-users@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 

--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Dave Cole]

True, but at some point that becomes uneconomical.I know a guy who 
had a Mazak lathe with ancient controls and he dumped over $10K in 
boards and labor into it to get it running again and it
was not a large lathe.

Dave

On 3/24/2016 6:50 AM, Todd Zuercher wrote:
> I can't imagine anyone "wants to" but it is done.  Fanuc still supports and 
> maintains the controls for one of our old (an ancient 11M) CNCs built in 1984 
> (and much older stuff too).  And this is one of the reasons they get the big 
> bucks for their stuff and why they're so popular.
>
> - Original Message -
> From: "Dave Cole" <linuxcncro...@gmail.com>
> To: emc-users@lists.sourceforge.net
> Sent: Wednesday, March 23, 2016 9:45:31 PM
> Subject: Re: [Emc-users] Linuxcnc on arm
>
> Who wants to use and maintain (if it is possible) an original CNC control
> made prior to 2000 ??
>
> Dave
>
>
> --
> 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=/4140
> ___
> Emc-users mailing list
> Emc-users@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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Ron Ginger]

I was helping a commercial screw machine shop that had a couple little 
KX1 mills. One was getting rather tired after 5 or 6 years of production 
use and having repeatability problem. I was speaking with the general 
manager and asked "well how long do you expect a machine to last?" and 
without a hint of a smile he whipped back "40 years"

The KX1 was installed less then 50 feet from a row of screw machines 
maybe as old as I am (73 years) and they were clanking away dropping 
parts into a bin.

ron ginger

> Who wants to use and maintain (if it is possible) an original CNC control
> made prior to 2000 ??
>
> Dave
>


--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Todd Zuercher]

I can't imagine anyone "wants to" but it is done.  Fanuc still supports and 
maintains the controls for one of our old (an ancient 11M) CNCs built in 1984 
(and much older stuff too).  And this is one of the reasons they get the big 
bucks for their stuff and why they're so popular.

- Original Message -
From: "Dave Cole" <linuxcncro...@gmail.com>
To: emc-users@lists.sourceforge.net
Sent: Wednesday, March 23, 2016 9:45:31 PM
Subject: Re: [Emc-users] Linuxcnc on arm

Who wants to use and maintain (if it is possible) an original CNC control
made prior to 2000 ??

Dave


--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Dave Cole]

>>doing it with x86 isn't very feasible.

Why not?   Unless you have serious space or cost constraint issues
going with a PC based solution is still your best bet.  What are the chances of 
you finding a replacement ARM board of the
proper type 10 years from now.Siemens routinely uses PC components in their 
CNC systems.
The #1 failure point for PCs used to be hard drives.
The #2 was power supplies (for me).

SSDs seem to have fixed the #1 problem.
A careful selection of power supplies seems to work for #2.

I've been retiring PCs for the last few years not because of failure but 
because they either draw too much power, or the hardware is becoming too old, 
lacks the desired performance and may no longer well supported by the software. 
 The PCs are usually still running fine when they are removed.

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

I think that depends greatly on the quality of the retrofit.   Is there a 
wiring diagram?  Is there a backup of the computer drives?

Who wants to use and maintain (if it is possible) an original CNC control
made prior to 2000 ??

Dave



On 3/23/2016 6:22 AM, Erik Friesen 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 <
> nicklas.karlsso...@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  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=/4140
 ___
 Emc-users mailing list
 Emc-users@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=/4140
>>> 

Re: [Emc-users] Linuxcnc on arm

[ceenbot]

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

--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[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
 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 <
> e...@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=/4140
> ___
> Emc-users mailing list
> Emc-users@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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[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, ceen...@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.
>


--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[ceenbot]

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 <
e...@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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[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  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 <
> nicklas.karlsso...@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  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=/4140
> > > > ___
> > > > Emc-users mailing list
> > > > Emc-users@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/emc-users
> > >
> > >
> > >
> > --
> > > Transform Data into Opportunity.
> > > 

Re: [Emc-users] Linuxcnc on arm

[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" <e...@aercon.net>
To: "Enhanced Machine Controller (EMC)" <emc-users@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 <
nicklas.karlsso...@gmail.com> wrote:


--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[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 <
nicklas.karlsso...@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  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=/4140
> > > ___
> > > Emc-users mailing list
> > > Emc-users@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=/4140
> > ___
> > Emc-users mailing list
> > Emc-users@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=/4140
> ___
> Emc-users mailing list
> Emc-users@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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm (NML-over-TCP)

[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=/4140
> ___
> Emc-users mailing list
> Emc-users@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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[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  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=/4140
> > ___
> > Emc-users mailing list
> > Emc-users@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=/4140
> ___
> Emc-users mailing list
> Emc-users@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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm (NML-over-TCP)

[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

--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[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=/4140
> ___
> Emc-users mailing list
> Emc-users@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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm (NML-over-TCP)

[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  wrote:

> On Sun, Mar 20, 2016 at 04:51:39PM +, 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=/4140
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


-- 
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=278785351=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Jeff Epler]

On Sun, Mar 20, 2016 at 04:51:39PM +, 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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Chris Albertson]

On Tue, Mar 22, 2016 at 3:31 AM, Nicklas Karlsson <
nicklas.karlsso...@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=/4140
> > ___
> > Emc-users mailing list
> > Emc-users@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=/4140
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>



-- 

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=278785351=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

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



--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[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

--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[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

--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

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


--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[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=/4140
> ___
> Emc-users mailing list
> Emc-users@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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[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)

--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

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


--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[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=/4140
> ___
> Emc-users mailing list
> Emc-users@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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[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  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=/4140
> ___
> Emc-users mailing list
> Emc-users@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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[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 +
Ralph Stirling <ralph.stirl...@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 [bari00...@gmail.com]
> Sent: Sunday, March 20, 2016 10:02 AM
> To: emc-users@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=/4140
> ___
> Emc-users mailing list
> Emc-users@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=/4140
> ___
> Emc-users mailing list
> Emc-users@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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[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=/4140
> ___
> Emc-users mailing list
> Emc-users@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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[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  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=/4140
> ___
> Emc-users mailing list
> Emc-users@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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[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

--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[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

--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[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


--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[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

--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

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


--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[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 [bari00...@gmail.com]
Sent: Sunday, March 20, 2016 10:02 AM
To: emc-users@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=/4140
___
Emc-users mailing list
Emc-users@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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[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

--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

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


--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

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


--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[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 [albertson.ch...@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 <
nicklas.karlsso...@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 Analy

Re: [Emc-users] Linuxcnc on arm

[Chris Albertson]

On Sun, Mar 20, 2016 at 12:10 AM, Nicklas Karlsson <
nicklas.karlsso...@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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[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

--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Erik Friesen]

FYI, the nxgen controller runs around $15K.

On Wed, Mar 16, 2016 at 12:10 PM, andy pugh  wrote:

> On 16 March 2016 at 15:52, W. Martinjak  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=83_85_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=/4140
> ___
> Emc-users mailing list
> Emc-users@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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[andy pugh]

On 16 March 2016 at 12: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.


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

--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[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 
>
> 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=/4140
> ___
> Emc-users mailing list
> Emc-users@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 

--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[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

--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[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

--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[Sebastian Kuzminsky]

On 03/16/2016 10:17 AM, andy pugh wrote:
> On 16 March 2016 at 16:03, W. Martinjak  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

--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

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


--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[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 :

> 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=/4140
> ___
> Emc-users mailing list
> Emc-users@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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[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  wrote:
>>> http://store.mesanet.com/index.php?route=product/product=83_85_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


--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[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:nicklas.karlsso...@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=/4140
> ___
> Emc-users mailing list
> Emc-users@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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[W. Martinjak]

On 2016-03-16 17:33, andy pugh wrote:
> On 16 March 2016 at 16:20, W. Martinjak  wrote:
>>> http://store.mesanet.com/index.php?route=product/product=83_85_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


--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc on arm

[W. Martinjak]

On 2016-03-16 17:50, John Dammeyer wrote:
>> -Original Message-
>> From: Peter C. Wallace [mailto:p...@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=/4140
> ___
> Emc-users mailing list
> Emc-users@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


--
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=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users