Re: [Emc-users] Real-time OS for machine controllers

[Nathan Hartman]

On Tue, Jan 21, 2020 at 4:09 PM bari  wrote:
>
> FreeRTOS sure is popular.  Have you compared it to other open source
> Posix standard real-time OS's such as NuttX and RTEMS?
>
> http://www.nuttx.org/

NuttX is now an Apache.org Podling:

https://nuttx.apache.org

This RTOS has been around for quite a few years. The latest release
(as of November 16, 2019), version 8.2, is the 133rd versioned release
of NuttX.

From the front page of the site: "NuttX is a real-time operating
system (RTOS) with an emphasis on standards compliance and small
footprint. Scalable from 8-bit to 32-bit microcontroller environments,
the primary governing standards in NuttX are Posix and ANSI standards.
Additional standard APIs from Unix and other common RTOS’s (such as
VxWorks) are adopted for functionality not available under these
standards, or for functionality that is not appropriate for
deeply-embedded environments (such as fork())."

Some other RTOSes out there are derived from NuttX.

Cheers,
Nathan


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[andy pugh]

On Wed, 22 Jan 2020 at 07:58, Chris Albertson  wrote:
>  I'd say to anyone re-designing LinuxCNC to keep
> this picture on your wall.   The new software shoud scale from a small
> Harbor freight mill to a light's out factory floor.

I don't think that LinuxCNC would be a good starting point for this.

LinuxCNC is what it is. It is a machine controller that runs on a PC.
Anything else is something else, and it probably doesn't make sense to
try to make LinuxCNC in to that thing (whatever it is)

If you want a single system that runs your CAD and a web browser and
that also runs a CNC machine perfectly adequately then you have a
choice of LinuxCNC or Mach3, and both perform that task perfectly
adequately.

If you want dedicated realtime hardware running the machines with an
administrative interface on a separate machine (possibly controlling
many realtime nodes) then LinuxCNC isn't really a sensible starting
point for that.

All in my opinion of course.

-- 
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, 1912


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Gene Heskett]

On Wednesday 22 January 2020 03:06:38 andy pugh wrote:

> On Wed, 22 Jan 2020 at 07:58, Chris Albertson 
 wrote:
> >  I'd say to anyone re-designing LinuxCNC to keep
> > this picture on your wall.   The new software shoud scale from a
> > small Harbor freight mill to a light's out factory floor.
>
> I don't think that LinuxCNC would be a good starting point for this.
>
> LinuxCNC is what it is. It is a machine controller that runs on a PC.
> Anything else is something else, and it probably doesn't make sense to
> try to make LinuxCNC in to that thing (whatever it is)
>
> If you want a single system that runs your CAD and a web browser and
> that also runs a CNC machine perfectly adequately then you have a
> choice of LinuxCNC or Mach3, and both perform that task perfectly
> adequately.
>
> If you want dedicated realtime hardware running the machines with an
> administrative interface on a separate machine (possibly controlling
> many realtime nodes) then LinuxCNC isn't really a sensible starting
> point for that.
>
> All in my opinion of course.

I can't say as it would be ideal.

OTOH, once we figure out how much bandwidth can be shoved thru an spi 
port, the current implementation supposedly supporting 5 channels, it 
does seem to me that much more complex operations than I am currently 
doing with one spi channel should be possible. I do think, from what I 
have observed on my scope, that we could use at least 4 of those 
channels if we could write a driver that handled 2 spi data trains in 
parallel, moving two 32 bit packets, to/from cards such as the 7i90HD. 

There is plenty of the quiet time between packets now with only one spi 
in use.

The kernel I'm running on the rpi4 is totally crippled, its stuck in the 
on-demand scheduler and somehow I built it with all that write protected 
so I can't poke it to change it.  But that rpi4b is running a 1 
kilohertz servo thread without showing a single latency overflow in many 
hours of uptime, while only running at 850 megahertz.  Huge difference 
between the rpi3b, and the rpi4b. I have another kernel built from the 
same source but have not put it on a 64G card yet. Not sure what I'm 
doing but I think this new kernel is locked in performance mode, at 
least 1.7x faster than the one currently running.

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Jon Elson]

On 01/21/2020 11:55 PM, Chris Albertson wrote:

Yes.  I would not blindly recommend any of the RTOSes without a doing a
more detailed design of the application.  Nutx might be better.  They
are VERY different from Linux. Linux boots of a disk that allows you to
run other independent apps.   This other class of OS must if linked in with
the application code and when the machine boots it will only run that code.
  one does not bot an RTOS then run an app, rather the ROS is a library that
you apps links to.

I find it very useful to have my CNC control on my local 
network.  I have hundreds of often-used
toolpath programs on it, and back it up every once in a 
while. Also, I can generate new

toolpaths on CAD systems and download them to the CNC computer.

Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[John Dammeyer]

> -Original Message-
> From: Jon Elson [mailto:el...@pico-systems.com]
> 
> On 01/21/2020 11:55 PM, Chris Albertson wrote:
> > Yes.  I would not blindly recommend any of the RTOSes without a doing a
> > more detailed design of the application.  Nutx might be better.  They
> > are VERY different from Linux. Linux boots of a disk that allows you to
> > run other independent apps.   This other class of OS must if linked in with
> > the application code and when the machine boots it will only run that code.
> >   one does not bot an RTOS then run an app, rather the ROS is a library that
> > you apps links to.
> >
> I find it very useful to have my CNC control on my local
> network.  I have hundreds of often-used
> toolpath programs on it, and back it up every once in a
> while. Also, I can generate new
> toolpaths on CAD systems and download them to the CNC computer.
> 
> Jon
> 

What a fascinating discussion.  Be prepared. What follows is pretty long.

Takes me back to the mid 80's when I wrote our own RTOS for the NEC 78C10 
series of micro-processors.  Or even earlier when I wrote code to move an XY 
gantry laser cutter system.  The motion control code was all done in 8085 
Assembler and specifically just to demo motion.  Not accept programs; just move 
hardware.

I believe it's important to separate the components of the system in the sense 
of describing what they do.  Initially the 8080/Z80/6502/6800 based systems 
clearly separated the Basic hardware dependant I/O System (BIOS) from the 
System that Operated and interacted with the end user (the OS) and the software 
Applications (Apps)  that end users used.

Apple did a really good job of blending them all into one since they also 
supplied the 6502 hardware.   Before the IBM PC the Micropolis DOS, Northstar 
DOS and CP/M could all be ported to different hardware although Micropolis and 
Northstar both used proprietary disk drive hardware.  Seattle Computer Products 
DOS-86 was out just before CP/M-86 for the 8086 S-100 bus computers.  And 
needing a vehicle for his Basic Interpreter, Microsoft quickly purchase DOS-86 
renaming it to MSDOS 1.0 and sold licenses through IBM for the new 8 bit 
version of the 8086.  (8088).  

Meanwhile on the minicomputer side was Unix (I wrote graphics software on a 
PDP-10 in University) but for the most part that was still all terminal based.  
Graphics were limited.  And then along came the APPLE MAC.  And shortly after 
that WIN-286, WIN-386, WIN-3.0 and finally the one that lasted for a while 
WIN-3.1.

My time then, from 1992 to 1994, was spent writing software for an OS9-68K 
(upgraded OS9 for the 16 bit 68000 processor like the one used in the Apple 
MAC).  EMAC editor until I convinced them to give us PCs so we could edit the 
programs using CodeWright from Borland.  Visual editing that detected CR or LF 
or Both for end of lines.  Syntax highlighting.  Etc.  Via serial port we still 
compiled on the OS9-68K system and then burned EPROMs to take out onto the shop 
floor to insert into the equipment.

Somewhere around this time Linux showed up along with the GNU (GNU is Not 
Unix). And with the various Linux flavours (and books) regardless of the 
open software concept, only the most expert and dedicated could port to new 
hardware.  Far more difficult than an MP/M-86 port I did in the 80's.

Complexity aside, Linux has probably kept the hardware, the OS and the User 
Interface more separated than any other system.  So now what does that have to 
do with LinuxCNC (formally EMC)

The real time nature of machine control means that an event needs to be 
responded to within a specific amount of time or the event becomes an error.  
In the past when any retrofitting to CNC (Computer Numerically Controlled with 
punched paper tape) the motors ran with +/-10V signals and fed back position 
with resolvers or encoders.  The control was all hardware and with EMC that was 
moved into the PC.  

That's why you still see proponents of these systems stating the best place for 
the closed loop is in the actual PC generating the G-Code.   Because LinuxCNC 
could produce a voltage and read the encoder and close loop PID control the 
motor. But the advent of inexpensive stepper motors that were reliable enough, 
when not overloaded, to run open loop changed the game for everyone.  The 
interrupt driven device driver for MACH2 and then MACH3 using the simple 
parallel port and only step/dir signals changed the world.  Retrofitting big 
commercial mills still required closed loop at some point and although, over 
the years we've seen a number of Servo/Encoder/Resolver units with fault 
outputs if motion is incorrect, for many systems closing the loop inside 
LinuxCNC was the only solution.

Meanwhile the 3D printing world, with 8 bit micro-controllers doing extremely 
fast step/dir of lightweight motors, has changed the perspective of what is 
needed for CNC in general.  The loss of the parallel port on PCs no

Re: [Emc-users] Real-time OS for machine controllers

[R C]

makes me wonder why a "cnc controller" doesn't work like a printer (yeah 
sounds naive),



but 30-40 years ago it was unthinkable to print something half decent 
without using ink and a hand cranked machine (stenciling).


Now you can have a color printer for next to nothing, you send the job 
by hitting "print"  it selects paper, ink, folds, staples, sorts (some 
even bind).



same for plotters. 3D-printers you can do with a USB connection, or an 
SD card.  all these things have stepper motors, etc etc.



Also all those things dropped in price drastically, everyone knows,  the 
CNC machining industry,  well, maybe they are just perpetuating their


customers depending on them (like they did with computers a decade or 
two/three ago.



or is it that much more difficult to build a box for a CNC machine you 
connect a USB to  or connect to the network for "next to nothing" ?


:)  Ron







On 1/22/20 1:06 AM, andy pugh wrote:

On Wed, 22 Jan 2020 at 07:58, Chris Albertson  wrote:

  I'd say to anyone re-designing LinuxCNC to keep
this picture on your wall.   The new software shoud scale from a small
Harbor freight mill to a light's out factory floor.

I don't think that LinuxCNC would be a good starting point for this.

LinuxCNC is what it is. It is a machine controller that runs on a PC.
Anything else is something else, and it probably doesn't make sense to
try to make LinuxCNC in to that thing (whatever it is)

If you want a single system that runs your CAD and a web browser and
that also runs a CNC machine perfectly adequately then you have a
choice of LinuxCNC or Mach3, and both perform that task perfectly
adequately.

If you want dedicated realtime hardware running the machines with an
administrative interface on a separate machine (possibly controlling
many realtime nodes) then LinuxCNC isn't really a sensible starting
point for that.

All in my opinion of course.




___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Les Newell]

PCs are cheap, easily available and easy to code on. They provide huge 
amounts of processing power for little money and are very well suited to 
GUI applications. However they are not designed for hard real time work. 
LinuxCNC does a good job but even then it tends to be a bit touchy if 
not paired with some form of control hardware to take over the really 
tight timing. Mesa's FPGA cards are a good example. I do a fair amount 
of repair an maintenance on a variety of CNC machines. The majority of 
them go the same route and use a PC for the front end and some sort of 
custom hardware or PLC for motion control.


How complicated does your controller have to be? Mesa's FPGA boards for 
example are pretty dumb and need feeding every 1ms, which LinuxCNC 
handles quite easily on most PC hardware. How much do you gain by moving 
more of the motion control to external hardware?


Les




___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Chris Albertson]

The trouble with the Mesa FPGA design is that it depends on a computer with
good real-time performance.   It can generate steps but I don't thing you
can run a position or velocity PID control loop on the FPGA.

You asked about "my controler".  No this is not my idea, this is how most
current designs work today.  You "push" the real-time control down stram as
close to the physical motor as possible. In the old days computers
where expensive and you wanted to minimize their number but tocay a 32-bit
computer with floating point math, RAM and quita a lot of
peripheral hardware cost as littel as $1.I buy these $3 PCBs for
controlling up to two servo motors with quadarue feedback

ebay.com/itm/1pcs-STM32F103C8T6-ARM-STM32-Minimum-System


The above part sells for under $2 and there is a CAD drawing and a
schematic if you scroll down.This will run a couple motors and encoders
and talk over USB all at the same time.  For $20 you can get something 100X
more powerful. Or in a larger project use several of the above.   Last
order I bought ten of these.

So how complex is the controller?  Very complex.  It is an entire 32-bit
computer with FLASH memory and USB running an RTOS.  It is not at all like
a 1980's vintage microprocessor.  These old chips needed special
programming hardware and were not easy to use.   Today we program FLASH via
the built-in USB interface.Yes the thing is complex but today such a
machine costs $1.78 with free shipping and is very easy to use.   You can
buy them by the dozen.

There are four or five development platforms.   The Arduino platform works
for simple stuff.  You can set up Eclipse and GCC, "mbed" is easy to use
and STM has a very good and professional level system too that is free.

As a reference, I have a few quadcopter racing drones.  These use four
three-phas brushless motors that must be controled VERY accuratly using an
8000 Hz PID loop.   The main controler PCB is 32mm square and ha a high-end
STM32 microcontroller.  There are four high speed serial interfaces to fur
motor drivers and each drive has another STM32 microcontroller to do motor
commutation and feeds back power used to the man computer.The main
computer runs an RTOS and talks to the two digital radio, IMU and GPS.
 Fits in a 32mm space and costs maybe $30.  Again VERY complex but they are
easy to use.




On Thu, Jan 23, 2020 at 6:54 AM Les Newell 
wrote:

> PCs are cheap, easily available and easy to code on. They provide huge
> amounts of processing power for little money and are very well suited to
> GUI applications. However they are not designed for hard real time work.
> LinuxCNC does a good job but even then it tends to be a bit touchy if
> not paired with some form of control hardware to take over the really
> tight timing. Mesa's FPGA cards are a good example. I do a fair amount
> of repair an maintenance on a variety of CNC machines. The majority of
> them go the same route and use a PC for the front end and some sort of
> custom hardware or PLC for motion control.
>
> How complicated does your controller have to be? Mesa's FPGA boards for
> example are pretty dumb and need feeding every 1ms, which LinuxCNC
> handles quite easily on most PC hardware. How much do you gain by moving
> more of the motion control to external hardware?
>
> Les
>
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


-- 

Chris Albertson
Redondo Beach, California

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Peter C. Wallace]

On Thu, 23 Jan 2020, Chris Albertson wrote:


Date: Thu, 23 Jan 2020 10:17:44 -0800
From: Chris Albertson 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "Enhanced Machine Controller (EMC)" 
Subject: Re: [Emc-users] Real-time OS for machine controllers

The trouble with the Mesa FPGA design is that it depends on a computer with
good real-time performance.   It can generate steps but I don't thing you
can run a position or velocity PID control loop on the FPGA.


LinuxCNCs design paradigm requires realtime, this is a design decision that is 
supported by our Hostmot2 real time firmware. We have other firmware that 
implements motion in the FPGA but this is not suited to LinuxCNCs model.



You might argue that its an old fashioned model but many high performance CNC 
systems and Robotics controllers use LinuxCNCs model of a capable real time host 
(real OS with file I/O loadable modules, unlimited memory, massive floating 
point performance etc etc) Some of these use Linux and others use real time 
windows varients often with Ethercat Peripherals. This makes for a powerful 
extensible realtime toolkit (like LinuxCNCs HAL) and complex realtime 
responsive coordinated motion. Basically for this type of system you still
need a very capable real time controller hub even if the motor controllers 
implement torque, velocity, or position loops



Peter Wallace
Mesa Electronics



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[John Dammeyer]

> -Original Message-
> From: Peter C. Wallace [mailto:p...@mesanet.com]


> > Date: Thu, 23 Jan 2020 10:17:44 -0800
> > From: Chris Albertson 
> >
> > The trouble with the Mesa FPGA design is that it depends on a computer
> with
> > good real-time performance.   It can generate steps but I don't thing you
> > can run a position or velocity PID control loop on the FPGA.
> 
> LinuxCNCs design paradigm requires realtime, this is a design decision that is
> supported by our Hostmot2 real time firmware. We have other firmware that
> implements motion in the FPGA but this is not suited to LinuxCNCs model.
> 
> 
> You might argue that its an old fashioned model but many high performance
> CNC
> systems and Robotics controllers use LinuxCNCs model of a capable real time
> host
> (real OS with file I/O loadable modules, unlimited memory, massive floating
> point performance etc etc) Some of these use Linux and others use real time
> windows varients often with Ethercat Peripherals. This makes for a powerful
> extensible realtime toolkit (like LinuxCNCs HAL) and complex realtime
> responsive coordinated motion. Basically for this type of system you still
> need a very capable real time controller hub even if the motor controllers
> implement torque, velocity, or position loops
> 
> 
> Peter Wallace
> Mesa Electronics


And that really sums it up nicely.  As long as there are 'PC compatible' 
machines out there as desktop/tower to embedded boxes the need for an ARM based 
Machine Tool CNC controller like the ones for 3D printers is tiny.   MachineKit 
for the Beagle is cool but my Xylotex Cape has the limit switch polarities 
inverted and that can't be changed.  It's why I shelved it and changed to a BC 
Government Surplus VISTA capable PC that currently dual boots WIN-XP and 
LinuxCNC.  And I have a MESA 7i92H for it.

MESA fills a need.  It's a pity that it doesn't also fill that same need for 
MACH4.  Then an user could choose between OS platforms evaluating both without 
swapping hardware.

I think though, to address the original theme of this thread, the users out 
there running LinuxCNC on their machines may never visit this or any other 
forum.  They buy from a supplier that has MESA hardware all in a box.  Then 
they put the machine to work and just use it.  It's likely the real number of 
LinuxCNC users is way way larger than one thinks.  Might even exceed HAAS 
systems by an order of magnitude.

John









___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Gene Heskett]

On Thursday 23 January 2020 13:17:44 Chris Albertson wrote:

> The trouble with the Mesa FPGA design is that it depends on a computer
> with good real-time performance.   It can generate steps but I don't
> thing you can run a position or velocity PID control loop on the FPGA.
>
> You asked about "my controler".  No this is not my idea, this is how
> most current designs work today.  You "push" the real-time control
> down stram as close to the physical motor as possible. In the old
> days computers where expensive and you wanted to minimize their number
> but tocay a 32-bit computer with floating point math, RAM and quita a
> lot of
> peripheral hardware cost as littel as $1.I buy these $3 PCBs for
> controlling up to two servo motors with quadarue feedback
>
> ebay.com/itm/1pcs-STM32F103C8T6-ARM-STM32-Minimum-System
> Development-Board-Module-For-Arduino/183440464510?epid=10003269727&hash
>=item2ab5e75a7e:g:klEAAOSwi1pboKF~>
>
> The above part sells for under $2 and there is a CAD drawing and a
> schematic if you scroll down.This will run a couple motors and
> encoders and talk over USB all at the same time.  For $20 you can get
> something 100X more powerful. Or in a larger project use several of
> the above.   Last order I bought ten of these.
>
> So how complex is the controller?  Very complex.  It is an entire
> 32-bit computer with FLASH memory and USB running an RTOS.  It is not
> at all like a 1980's vintage microprocessor.  These old chips needed
> special programming hardware and were not easy to use.   Today we
> program FLASH via the built-in USB interface.Yes the thing is
> complex but today such a machine costs $1.78 with free shipping and is
> very easy to use.   You can buy them by the dozen.
>
> There are four or five development platforms.   The Arduino platform
> works for simple stuff.  You can set up Eclipse and GCC, "mbed" is
> easy to use and STM has a very good and professional level system too
> that is free.
>
> As a reference, I have a few quadcopter racing drones.  These use four
> three-phas brushless motors that must be controled VERY accuratly
> using an 8000 Hz PID loop.   The main controler PCB is 32mm square and
> ha a high-end STM32 microcontroller.  There are four high speed serial
> interfaces to fur motor drivers and each drive has another STM32
> microcontroller to do motor commutation and feeds back power used to
> the man computer.The main computer runs an RTOS and talks to the
> two digital radio, IMU and GPS. Fits in a 32mm space and costs maybe
> $30.  Again VERY complex but they are easy to use.
>
I looked at that, but fail to groc, lack of docs linkage, and probably 
some NIH syndrome on my part, how 2 of those would co-ordinate with each 
other to maintain the gcode paths for a 4 axis movement would be done?

Thats not a schematic, but a logic diagram with black boxes for the 
active parts.  Furinstance, Where does the step/dir's come out to drive 
the motor power drivers? Too much, too new, for me to comprehend 
quickly.

OTOH, I am getting very very close to a perfectly working rpi4 running 
this big lathe. So my attention is on that, and building more optimized 
kernels ATM.  Currently zero overruns while running  on-demand at 850 
kilohertz clocking, reported when stopping LinuxCNC after several hours 
run-time. And the kernel installed isn't even rpi specific, the next one 
I built yesterday is striped of other stuff an rpi4 doesn't need. 
>
> On Thu, Jan 23, 2020 at 6:54 AM Les Newell 
>
> wrote:
> > PCs are cheap, easily available and easy to code on. They provide
> > huge amounts of processing power for little money and are very well
> > suited to GUI applications. However they are not designed for hard
> > real time work. LinuxCNC does a good job but even then it tends to
> > be a bit touchy if not paired with some form of control hardware to
> > take over the really tight timing. Mesa's FPGA cards are a good
> > example. I do a fair amount of repair an maintenance on a variety of
> > CNC machines. The majority of them go the same route and use a PC
> > for the front end and some sort of custom hardware or PLC for motion
> > control.
> >
> > How complicated does your controller have to be? Mesa's FPGA boards
> > for example are pretty dumb and need feeding every 1ms, which
> > LinuxCNC handles quite easily on most PC hardware. How much do you
> > gain by moving more of the motion control to external hardware?
> >
> > Les
> >
> >
> >
> >
> > ___
> > 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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brand

Re: [Emc-users] Real-time OS for machine controllers

[Andy Pugh]

> On 23 Jan 2020, at 22:03, John Dammeyer  wrote:
> 
>  It's likely the real number of LinuxCNC users is way way larger than one 
> thinks.  Might even exceed HAAS systems by an order of magnitude.

I think PCW mentioned 10,000 boards of a particular type out in the wild. 




___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Stuart Stevenson]

I don't know how many machines a month Haas sells now but around the year
2000 they were selling 1000 a month.

On Thu, Jan 23, 2020, 3:44 PM Andy Pugh  wrote:

>
>
> > On 23 Jan 2020, at 22:03, John Dammeyer  wrote:
> >
> >  It's likely the real number of LinuxCNC users is way way larger than
> one thinks.  Might even exceed HAAS systems by an order of magnitude.
>
> I think PCW mentioned 10,000 boards of a particular type out in the wild.
>
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[John Dammeyer]

> -Original Message-
> From: Andy Pugh [mailto:bodge...@gmail.com]
> Sent: January-23-20 1:42 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Real-time OS for machine controllers
> 
> 
> 
> > On 23 Jan 2020, at 22:03, John Dammeyer 
> wrote:
> >
> >  It's likely the real number of LinuxCNC users is way way larger than one
> thinks.  Might even exceed HAAS systems by an order of magnitude.
> 
> I think PCW mentioned 10,000 boards of a particular type out in the wild.
> 
> 
> 
And given that there are lots of Chinese CNC packages all offering MACH3 with 
it  (the unlicensed pirated version) I'm going to guess at least 10x more of 
WINDOWS/MACH3 when you include CNC routers in addition to milling machines. 

I have one friend who has MACH3 on both machines and also a licensed copy of 
MACH4 that he hasn't bothered using since MACH3 does what he wants.  He builds 
parts for high performance drag racers and other things.

I showed him the LinuxCNC install.  He wasn't interested at all since what he 
has works with what Fusion360 generates.

John Dammeyer





___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[R C]

That is definitely true, I think.  Also, I think that RTOS is sort of a 
left-over from a few decades ago, because back then ther were no


other options.  Nowadays it still has a place, although of course there 
are different way more sophisticated solutions.


That pretty much works the same is in HPC,  most will opt for low cost 
or one step up from that for personal and business solutions.


No one has a need, nor can afford computers that cost hundreds of 
millions,  so why should they use networking technology, or filesystems, 
that cost tens of


millions., sure it' much faster but no one with a pc or even a few Dell 
servers/cluster had a need for that.




I know I saw linux-cnc years ago, when I was first trying some CNC 
stuff, but got sidetracked for a year or 10.  Some version was already 
around, although I messed a bit with turbocnc (which is still around in 
some sort of form I saw).


What I think is a plus, if you don't need to go to extremes, is that 
linux-cnc comes in a complete OS with application distribution, you 
install it and everything is there.



As for extremes, and I work in 'extremes' when it comes to computing, 
nothing of the shelf will really ever work. If You have a CNC machine, 
that was invested many millions in, it's not an issue to drop hundreds 
of k's in hardware to run it, but there will be very few that do, or 
want to do, that even.



my 2 cts


Ron

On 1/23/20 7:33 AM, Les Newell wrote:
PCs are cheap, easily available and easy to code on. They provide huge 
amounts of processing power for little money and are very well suited 
to GUI applications. However they are not designed for hard real time 
work. LinuxCNC does a good job but even then it tends to be a bit 
touchy if not paired with some form of control hardware to take over 
the really tight timing. Mesa's FPGA cards are a good example. I do a 
fair amount of repair an maintenance on a variety of CNC machines. The 
majority of them go the same route and use a PC for the front end and 
some sort of custom hardware or PLC for motion control.


How complicated does your controller have to be? Mesa's FPGA boards 
for example are pretty dumb and need feeding every 1ms, which LinuxCNC 
handles quite easily on most PC hardware. How much do you gain by 
moving more of the motion control to external hardware?


Les




___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[R C]

I always wondered why FPGAs are(still?)  that popular...

Way back when, in some research work I did, in my field they were mostly 
used for building stuff that didn't exist, as a test bed.



For fun we once implemented a univac on it, because we could.


Ron



On 1/23/20 12:29 PM, Peter C. Wallace wrote:

On Thu, 23 Jan 2020, Chris Albertson wrote:


Date: Thu, 23 Jan 2020 10:17:44 -0800
From: Chris Albertson 
Reply-To: "Enhanced Machine Controller (EMC)"
    
To: "Enhanced Machine Controller (EMC)" 


Subject: Re: [Emc-users] Real-time OS for machine controllers

The trouble with the Mesa FPGA design is that it depends on a 
computer with
good real-time performance.   It can generate steps but I don't thing 
you

can run a position or velocity PID control loop on the FPGA.


LinuxCNCs design paradigm requires realtime, this is a design decision 
that is supported by our Hostmot2 real time firmware. We have other 
firmware that implements motion in the FPGA but this is not suited to 
LinuxCNCs model.



You might argue that its an old fashioned model but many high 
performance CNC systems and Robotics controllers use LinuxCNCs model 
of a capable real time host (real OS with file I/O loadable modules, 
unlimited memory, massive floating point performance etc etc) Some of 
these use Linux and others use real time windows varients often with 
Ethercat Peripherals. This makes for a powerful extensible realtime 
toolkit (like LinuxCNCs HAL) and complex realtime responsive 
coordinated motion. Basically for this type of system you still
need a very capable real time controller hub even if the motor 
controllers implement torque, velocity, or position loops



Peter Wallace
Mesa Electronics



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Jon Elson]

On 01/23/2020 03:42 PM, Andy Pugh wrote:



On 23 Jan 2020, at 22:03, John Dammeyer  wrote:

  It's likely the real number of LinuxCNC users is way way larger than one 
thinks.  Might even exceed HAAS systems by an order of magnitude.

I think PCW mentioned 10,000 boards of a particular type out in the wild.


Not all Mesa gear is used with LinuxCNC, as is the case with 
some of my servo amps, too.  But, yes, probably a lot
of his motion controllers are used with LinuxCNC.  I have no 
idea how many machines Tormach has sold with LinuxCNC.


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Jon Elson]

On 01/23/2020 06:52 PM, R C wrote:

I always wondered why FPGAs are(still?)  that popular...

Because you can develop quite a bit of custom logic on a $10 
chip. One of my motion controller
boards packs 4 quadrature counters capable of up to 5 
million counts/second and 4 PWM generators
with a 40 MHz clock (giving 25 ns pulse width resolution) 
plus 16 digital inputs and 8 digital outputs

on one $10 chip.

I could buy a bunch of chips that do all these separate 
functions and put them on a board, but that

would end up costing a LOT more than $10.

And, unless you are making millions of devices, a custom 
chip with those features would cost

somewhere between $250K and 1 million $ to make the masks.

Even the automakers are using FPGAs in cars.  I think it is 
the reconfigurability and time to develop

with FPGAs is a big plus.

Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[bari]

The guy down the hall from me has been keeping RTAI alive for LCNC the
past few years. I'm not sure if real time performance would be much
better using QNX vs Linux + RTAI on a PC.

http://blackberry.qnx.com/en/software-solutions/embedded-software/industrial/qnx-nuetrino-rtos

There would be trade-offs on hardware support to port LCNC to QNX,
especially when it comes to GPU acceleration. RTAI and preempt_rt
perform pretty well on many low cost PC's with base threads down in the
few microseconds range for software stepping.

Going with a motion controller where the real time control is closer to
the motors give us what? I still need a GUI on some display at least 12"
across. A smartphone display might be OK for a CNC glue gun but not to
control my 2 ton+ VMC or lathe.

The ~$2 STM32 boards gives you an ARM processor with unprotected IO. You
need many more parts around that to buffer, level shift and ESD suppress.

On 1/23/20 12:17 PM, Chris Albertson wrote:
> The trouble with the Mesa FPGA design is that it depends on a computer with
> good real-time performance.   It can generate steps but I don't thing you
> can run a position or velocity PID control loop on the FPGA.
>
> You asked about "my controler".  No this is not my idea, this is how most
> current designs work today.  You "push" the real-time control down stram as
> close to the physical motor as possible. In the old days computers
> where expensive and you wanted to minimize their number but tocay a 32-bit
> computer with floating point math, RAM and quita a lot of
> peripheral hardware cost as littel as $1.I buy these $3 PCBs for
> controlling up to two servo motors with quadarue feedback



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[John Dammeyer]

Comments between.

> -Original Message-
> From: bari [mailto:bari00...@gmail.com]
> The guy down the hall from me has been keeping RTAI alive for LCNC the
> past few years. I'm not sure if real time performance would be much
> better using QNX vs Linux + RTAI on a PC.
I think one first has to define exactly what needs to be real time.  I doubt 
QNX is free.
> 
> http://blackberry.qnx.com/en/software-solutions/embedded-
> software/industrial/qnx-nuetrino-rtos
> 
> There would be trade-offs on hardware support to port LCNC to QNX,
> especially when it comes to GPU acceleration. RTAI and preempt_rt
> perform pretty well on many low cost PC's with base threads down in the
> few microseconds range for software stepping.
One of the reasons to use Linux or Windows is that as the motherboards (CPUs) 
change from one core to 2 cores to 8 cores to 1 core with two peripheral 
processors etc. the basic work to make the system has been done.  When you plug 
in that USB WiFi dongle it's usually possible to find a driver.  Same with a 
parallel port card or camera card or a second Ethernet card

If you are using Ethernet and UDP then it's a launch and forget method on a 
private Ethernet.  Or if TCP/IP then reliable ordered messaging.  So the 
workhorse for screen and outside world communications is there.

> 
> Going with a motion controller where the real time control is closer to
> the motors give us what? I still need a GUI on some display at least 12"
> across. A smartphone display might be OK for a CNC glue gun but not to
> control my 2 ton+ VMC or lathe.

And there's the rub.  In the past, connecting all the encoder/resolvers and 
motor input into a PCI card and having the PC do all the work made sense.  
Especially since the only other option was an 8 or maybe 16 bit processor that 
used EPROMs.  (I'm talking 1990's here).
> 
> The ~$2 STM32 boards gives you an ARM processor with unprotected IO. You
> need many more parts around that to buffer, level shift and ESD suppress.

This will be true for anything regardless of where the I/O begins.  Note the 
MESA cards have buffers.  The Xylotex Cape for the Beagle has buffers.  The 
question to ask or answer is where do you want that to be.  At one point it was 
on the PC motherboard and came out as a DB-25.  Thousands of machines still run 
with that interface.  At the moment mine does.

I really don't know what is going on under the covers for either the MESA 
Ethernet 7i92H or the Ethernet Smooth Stepper for MACH.  But considering the 
power of the processors running machines back in the 90's or early 2000's and 
that the mechanics for the metal cutting haven't changed much,  my guess is 
that some 32 bit processor _not_ running Linux so that the graphics/USB/etc. 
doesn't cripple the real time behaviour will be the solution.

For example a PIC32 with USB (for firmware upgrades) and Ethernet (for Control) 
along with a CAN bus (CANopen control of non-real time peripherals) and the 
Free RTOS could be the building block. The software on the PC written in say 
Lazarus (Object Pascal, write once, compile anywhere) which is available free 
with graphical capabilities on machine for Linux (PCs and Pi and Beaglebone) , 
Windows and MACs.  

This approach doesn't get mentioned.  A small 32 bit processor like this could 
even have a small LCD display with a few buttons for basic machine operation.  
Enough to move axis, turn on/off spindle etc.  Simple switch with local/remote 
mode.  I look at the world this way because that's the type of stuff I've been 
designing and writing software for over the last 25 years or so.

If I understand the Hardware Abstraction Layer correctly this is, in effect, 
already being done on the LinuxCNC PC.  But when I run the stress test on my PC 
the machine has some pretty long latencies.  But it's not needed.

IMHO
John Dammeyer

> 
> On 1/23/20 12:17 PM, Chris Albertson wrote:
> > The trouble with the Mesa FPGA design is that it depends on a computer
> with
> > good real-time performance.   It can generate steps but I don't thing you
> > can run a position or velocity PID control loop on the FPGA.
> >
> > You asked about "my controler".  No this is not my idea, this is how most
> > current designs work today.  You "push" the real-time control down stram
> as
> > close to the physical motor as possible. In the old days computers
> > where expensive and you wanted to minimize their number but tocay a 32-
> bit
> > computer with floating point math, RAM and quita a lot of
> > peripheral hardware cost as littel as $1.I buy these $3 PCBs for
> > controlling up to two servo motors with quadarue feedback
> 
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-use

Re: [Emc-users] Real-time OS for machine controllers

[Gene Heskett]

On Friday 24 January 2020 00:45:17 John Dammeyer wrote:

> Comments between.
>
> > -Original Message-
> > From: bari [mailto:bari00...@gmail.com]
> > The guy down the hall from me has been keeping RTAI alive for LCNC
> > the past few years. I'm not sure if real time performance would be
> > much better using QNX vs Linux + RTAI on a PC.
>
> I think one first has to define exactly what needs to be real time.  I
> doubt QNX is free.
>
> > http://blackberry.qnx.com/en/software-solutions/embedded-
> > software/industrial/qnx-nuetrino-rtos
> >
> > There would be trade-offs on hardware support to port LCNC to QNX,
> > especially when it comes to GPU acceleration. RTAI and preempt_rt
> > perform pretty well on many low cost PC's with base threads down in
> > the few microseconds range for software stepping.
>
> One of the reasons to use Linux or Windows is that as the motherboards
> (CPUs) change from one core to 2 cores to 8 cores to 1 core with two
> peripheral processors etc. the basic work to make the system has been
> done.  When you plug in that USB WiFi dongle it's usually possible to
> find a driver.  Same with a parallel port card or camera card or a
> second Ethernet card
>
> If you are using Ethernet and UDP then it's a launch and forget method
> on a private Ethernet.  Or if TCP/IP then reliable ordered messaging. 
> So the workhorse for screen and outside world communications is there.
>
> > Going with a motion controller where the real time control is closer
> > to the motors give us what? I still need a GUI on some display at
> > least 12" across. A smartphone display might be OK for a CNC glue
> > gun but not to control my 2 ton+ VMC or lathe.
>
> And there's the rub.  In the past, connecting all the
> encoder/resolvers and motor input into a PCI card and having the PC do
> all the work made sense.  Especially since the only other option was
> an 8 or maybe 16 bit processor that used EPROMs.  (I'm talking 1990's
> here).
>
> > The ~$2 STM32 boards gives you an ARM processor with unprotected IO.
> > You need many more parts around that to buffer, level shift and ESD
> > suppress.
>
> This will be true for anything regardless of where the I/O begins. 
> Note the MESA cards have buffers.

Not all, the 7i90 being a rather glaring exception, it's cheap for it 
capabilities but needs another $135 in 7i42TA's to protect it. I suspect 
that any of the Mesa cards that output via 50 pin scsi connectors have 
similar restrictions.

> The Xylotex Cape for the Beagle has 
> buffers.  The question to ask or answer is where do you want that to
> be.  At one point it was on the PC motherboard and came out as a
> DB-25.  Thousands of machines still run with that interface.  At the
> moment mine does.
>
> I really don't know what is going on under the covers for either the
> MESA Ethernet 7i92H or the Ethernet Smooth Stepper for MACH.  But
> considering the power of the processors running machines back in the
> 90's or early 2000's and that the mechanics for the metal cutting
> haven't changed much,  my guess is that some 32 bit processor _not_
> running Linux so that the graphics/USB/etc. doesn't cripple the real
> time behaviour will be the solution.
>
> For example a PIC32 with USB (for firmware upgrades) and Ethernet (for
> Control) along with a CAN bus (CANopen control of non-real time
> peripherals) and the Free RTOS could be the building block. The
> software on the PC written in say Lazarus (Object Pascal, write once,
> compile anywhere) which is available free with graphical capabilities
> on machine for Linux (PCs and Pi and Beaglebone) , Windows and MACs.
>
> This approach doesn't get mentioned.  A small 32 bit processor like
> this could even have a small LCD display with a few buttons for basic
> machine operation.  Enough to move axis, turn on/off spindle etc. 
> Simple switch with local/remote mode.  I look at the world this way
> because that's the type of stuff I've been designing and writing
> software for over the last 25 years or so.
>
> If I understand the Hardware Abstraction Layer correctly this is, in
> effect, already being done on the LinuxCNC PC.  But when I run the
> stress test on my PC the machine has some pretty long latencies.  But
> it's not needed.
>
> IMHO
> John Dammeyer
>
> > On 1/23/20 12:17 PM, Chris Albertson wrote:
> > > The trouble with the Mesa FPGA design is that it depends on a
> > > computer
> >
> > with
> >
> > > good real-time performance.   It can generate steps but I don't
> > > thing you can run a position or velocity PID control loop on the
> > > FPGA.
> > >
> > > You asked about "my controler".  No this is not my idea, this is
> > > how most current designs work today.  You "push" the real-time
> > > control down stram
> >
> > as
> >
> > > close to the physical motor as possible. In the old days
> > > computers where expensive and you wanted to minimize their number
> > > but tocay a 32-
> >
> > bit
> >
> > > computer with floating point math, RAM and

Re: [Emc-users] Real-time OS for machine controllers

[Les Newell]

On 23/01/2020 18:17, Chris Albertson wrote:

The trouble with the Mesa FPGA design is that it depends on a computer with
good real-time performance.


It's rare to find a PC that can't maintain the 1kHz timing loop. Most 
can even do this using Ethernet to communicate with the Mesa board. I 
have 4 machines using this exact arrangement. Two are running off cheap 
thin clients picked up off eBay. I think the other two mini PCs came 
from Ali Express. My lathe used to run off a Dell until that failed and 
was replaced by a HP machine I happened to have laying around. It now 
runs a Wyse thin client.



It can generate steps but I don't thing you
can run a position or velocity PID control loop on the FPGA.


The Mesa FPGA is easily powerful enough to run a PID loop but there is 
no need to do so. Let's face it PID loops are pretty simple and can be 
implemented with basic fixed point math.


There is some merit in moving the whole real-time section to a dedicated 
hardware platform and this is what most commercial CNC machines do. 
However that leaves you tied in to whatever hardware platform you have 
selected. My Hurco mill is a good example. It's motion controller board 
failed and Hurco could not supply a replacement or repair the board. The 
owner ended up selling it to me for pretty much scrap price. It is in 
pretty much perfect mechanical condition.


Will your $2 board be available in 10 years? I wouldn't be surprised if 
it becomes difficult to obtain within 2 years. Short of the planet being 
hit by an asteroid or similar disaster, you can be sure hardware running 
Linux will be available in 10+ years.


If Mesa were to go out of business tomorrow it would not be a huge task 
to develop a replacement for the FPGA board because it does not have to 
do all that much.




You asked about "my controler".  No this is not my idea, this is how most
current designs work today.  You "push" the real-time control down stram as
close to the physical motor as possible.


By 'your controller' I wasn't really referring to your specific 
hardware. I guess I should have said 'the controller'.


Most of the CNC machines I have worked on use a PC based GUI and a PLC 
or similar motion controller. That then talks to the drives, which are 
usually relatively dumb (velocity or torque control). The exact 
implementation varies but the basic topology remains pretty much the 
same. Having intelligent drives with built in trajectory planning causes 
more problems than it solves.



So how complex is the controller?  Very complex.  It is an entire 32-bit
computer with FLASH memory and USB running an RTOS.


I'm not talking about the complexity of modern microcontrollers. The 
complexity is in the software.


When it comes to debugging there is no comparison between Linux/Windows 
and embedded hardware. Arduino has virtually no real debugging support. 
You can't even use breakpoints. Want to see the value of a variable at a 
certain point? You can't set a watch or a breakpoint so your only 
alternative is to write some code to print that value to a terminal, 
recompile, download etc. Even when using JTAG or other dedicated 
debugging interfaces, debugging tends to be flaky and limited on most 
microcontrollers. I've worked with embedded processors for many years, 
everything from 8051 in assembly to various ARMs in C++. I've developed 
all sorts of stuff from DSP harmonic synthesis to networked I/O 
controllers with many hundreds of I/Os so I have a pretty good knowledge 
of what is involved in embedded development.


Open source projects have to have a very low barrier for entry to 
succeed. The harder it is to start developing the fewer developers you 
will have that are willing to work on it and therefore the less likely 
that project is to succeed. There are far more developers who are 
familiar with Windows/Linux than there are that are familiar with STM32 
development. Is LinuxCNC the perfect solution? Maybe not but it works 
and it works well. I've used Mach, UCCNC, Eding CNC and even developed 
my own hardware and software. If I want something that is reliable, 
versatile and keeps working LinuxCNC is the best I've found without 
spending huge amounts of money.



As a reference, I have a few quadcopter racing drones.  These use four
three-phas brushless motors that must be controled VERY accuratly using an
8000 Hz PID loop.



The drives may be using pretty powerful processors but if you take a 
step back they aren't much different from the 30+ year old 'dumb' 
Siemens analog drives in my router. You send them velocity or torque 
commands and the return velocity or position data. How they actually do 
that is merely an implementation detail.




The main
computer runs an RTOS and talks to the two digital radio, IMU and GPS.
  Fits in a 32mm space and costs maybe $30.  Again VERY complex but they are
easy to use.


Easy for the end user but not the developers. I have been involved in 
tri and quad copters since the e

Re: [Emc-users] Real-time OS for machine controllers

[Les Newell]

Not all, the 7i90 being a rather glaring exception, it's cheap for it
capabilities but needs another $135 in 7i42TA's to protect it. I suspect
that any of the Mesa cards that output via 50 pin scsi connectors have
similar restrictions.



Yes, the FPGA boards do need buffering but any logic level I/O device 
needs buffering to control relays etc. You also need to protect inputs. 
If you want to roll your own I have a design for a Mesa compatible I/O 
buffer board that has opto isolated inputs and 100mA Darlington outputs 
that can be configured to drive high side or low side. I/Os are 
configurable at build time in groups of 8. Each group can be input or 
output, high side or low side. All thru hole components for ease of hand 
soldering. I originally designed it as a practice project when 
transitioning to using Kicad and have used it on a couple of machines 
now. I've been meaning to release it as open source hardware but never 
found the round tuits. If anyone is interested I'll knock up some docs 
and stick it on the wiki page or something.


Les



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Gene Heskett]

On Friday 24 January 2020 07:34:27 Les Newell wrote:

> > Not all, the 7i90 being a rather glaring exception, it's cheap for
> > it capabilities but needs another $135 in 7i42TA's to protect it. I
> > suspect that any of the Mesa cards that output via 50 pin scsi
> > connectors have similar restrictions.
>
> Yes, the FPGA boards do need buffering but any logic level I/O device
> needs buffering to control relays etc. You also need to protect
> inputs. If you want to roll your own I have a design for a Mesa
> compatible I/O buffer board that has opto isolated inputs and 100mA
> Darlington outputs that can be configured to drive high side or low
> side. I/Os are configurable at build time in groups of 8. Each group
> can be input or output, high side or low side. All thru hole
> components for ease of hand soldering. I originally designed it as a
> practice project when transitioning to using Kicad and have used it on
> a couple of machines now. I've been meaning to release it as open
> source hardware but never found the round tuits. If anyone is
> interested I'll knock up some docs and stick it on the wiki page or
> something.
>
> Les

Opto stuff, with their speed limits, are much more trouble than they're 
worth, I've cut many of them out of bobs. A limiting resistor and a 
schotkey diode to each rail s/b be input protection limit enough.

And yes, I'd be interested in something that I could run thru pcb2gcode 
and make myself, and I suspect I am not alone. I've even done the drill 
holes at only 40 thou into the board from each side and made them meet 
in the middle of the board.  And I've got lots of board. The 7i90HD is a 
good start on a do anything board, but it sure needs protection, its 
very easily damaged by stray noise.
>
>
> ___
> 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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Jon Elson]

On 01/23/2020 11:45 PM, John Dammeyer wrote:
I really don't know what is going on under the covers for 
either the MESA Ethernet 7i92H or the Ethernet Smooth 
Stepper for MACH. But considering the power of the 
processors running machines back in the 90's or early 
2000's and that the mechanics for the metal cutting 
haven't changed much, my guess is that some 32 bit 
processor _not_ running Linux so that the 
graphics/USB/etc. doesn't cripple the real time behaviour 
will be the solution.
You keep going around and around saying that LinuxCNC 
doesn't work. Thousands of people are using it daily, and
know it DOES work!  If you want to do software stepping, how 
about Machinekit on the Beagle Bone, using the PRU
to do the step generation?  This works amazingly well, and 
costs about $145 plus keyboard, mouse and LCD screen.
Or, you can network into the Beagle and use some other 
machine for the man-machine interface.


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Les Newell]

Hi Gene,


Opto stuff, with their speed limits, are much more trouble than they're
worth, I've cut many of them out of bobs. A limiting resistor and a
schotkey diode to each rail s/b be input protection limit enough.


I have to disagree. Unless you need high speed, such as for encoders, 
optos are very worthwhile. Their slow speed helps mask out any short 
duration noise on the line. The isolation is also good for reducing noise.



And yes, I'd be interested in something that I could run thru pcb2gcode
and make myself, and I suspect I am not alone.


The layout is pretty tight for mechanical etching. If I remember 
correctly some track gaps are only 0.006". Making the board very 
configurable had the down side of also making it pretty tight in places. 
It's a 100mm x 100mm board and some Chinese PCB manufacturers are 
offering crazy low prices to build this size board. I used to make my 
own boards but these days it is so cheap to get them made it is not 
worth the effort. I've found the Chinese made boards to be very good 
quality. I just checked on pcbshopper.com and you can get 5 delivered to 
your door for a total of $8.33 in 23 days or if you are in more of a 
hurry how about $13.38 in 16 days?



  I've even done the drill
holes at only 40 thou into the board from each side and made them meet
in the middle of the board.  And I've got lots of board. The 7i90HD is a
good start on a do anything board, but it sure needs protection, its
very easily damaged by stray noise.


I've used quite a few of the Mesa FPGA boards and I've only ever killed 
one - that was by feeding 24V back down one of the outputs. Maybe you 
should consider using optos ;-)


Les



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Chris Albertson]

If you can tolerate latency, then your "hub" does not need what we call
"hard" real-time capability.  It only needs to keep up with the average
workload, averaged over whatever latency you can tolerate.  Video streaming
works this way.They can't reliably send video and the 60 Hz frame rate
so they buffer a few seconds of video on your phone and the real-time
viewer lives on the phone  not the server.

g-code could be the same way.   The penalty is that when you press the "go"
button the milling machine would take a few seconds the start working while
the data buffers into the low-level motor controllers. Today a
step/direction controller has no memory so it must be fed steps in real
time.  But if it has a 10,000 step memory you could just transfer blocks
ever half second and the controller would work down the queue."Steps"
are the wrong kind of data for this but "states" are what is used.

You are correct in that some real-time ability is needed at every level.
But we could design things so the requirements are VEY loose at the highest
level for 0.5-second latencies being acceptable.   One you need only that,
then even an iPhone is a good enough platform.

On Thu, Jan 23, 2020 at 11:32 AM Peter C. Wallace  wrote:

> On Thu, 23 Jan 2020, Chris Albertson wrote:
>
> > Date: Thu, 23 Jan 2020 10:17:44 -0800
> > From: Chris Albertson 
> > Reply-To: "Enhanced Machine Controller (EMC)"
> >     
> > To: "Enhanced Machine Controller (EMC)"  >
> > Subject: Re: [Emc-users] Real-time OS for machine controllers
> >
> > The trouble with the Mesa FPGA design is that it depends on a computer
> with
> > good real-time performance.   It can generate steps but I don't thing you
> > can run a position or velocity PID control loop on the FPGA.
>
> LinuxCNCs design paradigm requires realtime, this is a design decision
> that is
> supported by our Hostmot2 real time firmware. We have other firmware that
> implements motion in the FPGA but this is not suited to LinuxCNCs model.
>
>
> You might argue that its an old fashioned model but many high performance
> CNC
> systems and Robotics controllers use LinuxCNCs model of a capable real
> time host
> (real OS with file I/O loadable modules, unlimited memory, massive
> floating
> point performance etc etc) Some of these use Linux and others use real
> time
> windows varients often with Ethercat Peripherals. This makes for a
> powerful
> extensible realtime toolkit (like LinuxCNCs HAL) and complex realtime
> responsive coordinated motion. Basically for this type of system you still
> need a very capable real time controller hub even if the motor controllers
> implement torque, velocity, or position loops
>
>
> Peter Wallace
> Mesa Electronics
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


-- 

Chris Albertson
Redondo Beach, California

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Gene Heskett]

On Friday 24 January 2020 12:14:01 Les Newell wrote:

> Hi Gene,
>
> > Opto stuff, with their speed limits, are much more trouble than
> > they're worth, I've cut many of them out of bobs. A limiting
> > resistor and a schotkey diode to each rail s/b be input protection
> > limit enough.
>
> I have to disagree. Unless you need high speed, such as for encoders,
> optos are very worthwhile. Their slow speed helps mask out any short
> duration noise on the line. The isolation is also good for reducing
> noise.
>
> > And yes, I'd be interested in something that I could run thru
> > pcb2gcode and make myself, and I suspect I am not alone.
>
> The layout is pretty tight for mechanical etching. If I remember
> correctly some track gaps are only 0.006". Making the board very
> configurable had the down side of also making it pretty tight in
> places. It's a 100mm x 100mm board and some Chinese PCB manufacturers
> are offering crazy low prices to build this size board. I used to make
> my own boards but these days it is so cheap to get them made it is not
> worth the effort. I've found the Chinese made boards to be very good
> quality. I just checked on pcbshopper.com and you can get 5 delivered
> to your door for a total of $8.33 in 23 days or if you are in more of
> a hurry how about $13.38 in 16 days?
>
Humm pcbshopper.com, got a project "code" I can order and a doc & BOM I 
can DL? Currently using a 5i25 with a 7i76D on p3 on two of my mills but 
any sneeze of the power crashes the sserial link requiring a full power 
down, count to ten reboot.  All supplies must die totally to recover.

And I'd like to see if the 7i90HD thru the parport could run it more 
dependably. So I have the cost of three 7i42TA's as impetus to look at 
building your board instead.

> >   I've even done the drill
> > holes at only 40 thou into the board from each side and made them
> > meet in the middle of the board.  And I've got lots of board. The
> > 7i90HD is a good start on a do anything board, but it sure needs
> > protection, its very easily damaged by stray noise.
>
> I've used quite a few of the Mesa FPGA boards and I've only ever
> killed one - that was by feeding 24V back down one of the outputs.
> Maybe you should consider using optos ;-)

I wound up fixing my admittedly hasty original layout/hookup, which was 
giving me switching noise from the stepper drivers at around 40 volts 
p-p and 3ns rise times. With everything on a single point ground bolt, 
the noise fell into a black hole and is now under 100mv. But I have also 
fitted 3 7i42TA's because that also gave me std screw terminals to wire 
it up with. No more jumpers jumping off an unmarked pin in the 50 
pinners just cause I opened the garage door. 

Best.  Fix.  Ever.

And I'm still running on a 7i90 with 2 blown stepgens. But with 8 to 
choose from, the hal file reassignments were trivial, and has been 
working for 2 years now.  Switched from an rpi3 which was dragging its 
tongue on the floor to an rpi4 last fall, sweet. No latency overruns, 
none!  And I still have about 30 spare outputs/inputs if I ever get a 
tool turret carriage.

> Les
>
Thanks Les.

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Andy Pugh]

> On 24 Jan 2020, at 19:51, Chris Albertson  wrote:
> 
> But we could design things so the requirements are VEY loose at the highest
> level for 0.5-second latencies being acceptable.

Not rigid tapping. 




___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Les Newell]

Humm pcbshopper.com, got a project "code" I can order and a doc & BOM I
can DL?



Pcbshopper is just a price comparison site. You enter the board details 
and they poll various suppliers for the best price.


Currently all I have are the KiCad project and the Gerbers. I need to 
write some docs. I designed this board a couple of years ago so I need 
to look back through my records to see exactly what I have.


Where would be the best place for the files? Is there a place on the 
LCNC website? Maybe on Github?


Les



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Les Newell]

On 24 Jan 2020, at 19:51, Chris Albertson  wrote:

But we could design things so the requirements are VEY loose at the highest
level for 0.5-second latencies being acceptable.

Not rigid tapping.


And jogging would be horrible.

Les



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[John Dammeyer]

Hi Jon,
> -Original Message-
> From: Jon Elson [mailto:el...@pico-systems.com]
> 
> On 01/23/2020 11:45 PM, John Dammeyer wrote:
> > I really don't know what is going on under the covers for
> > either the MESA Ethernet 7i92H or the Ethernet Smooth
> > Stepper for MACH. But considering the power of the
> > processors running machines back in the 90's or early
> > 2000's and that the mechanics for the metal cutting
> > haven't changed much, my guess is that some 32 bit
> > processor _not_ running Linux so that the
> > graphics/USB/etc. doesn't cripple the real time behaviour
> > will be the solution.
> You keep going around and around saying that LinuxCNC
> doesn't work. Thousands of people are using it daily, and
> know it DOES work!  If you want to do software stepping, how
> about Machinekit on the Beagle Bone, using the PRU
> to do the step generation?  This works amazingly well, and
> costs about $145 plus keyboard, mouse and LCD screen.
> Or, you can network into the Beagle and use some other
> machine for the man-machine interface.
> 
> Jon

I'm _not_ saying LinuxCNC doesn't work.  
The opposite in fact and I've run the BBB with the Xylotex cape so I can attest 
that it does especially with the dual PRU I/O processors.  Even posted a 
youtube video on that.  

Where the beagle falls down on the Linux side of things, say compared to a Pi 
or a PC, is the video processing just isn't as good.  And it shows even when 
just running normal Linux compared to normal Linux on a Pi.

Where my LinuxCNC box falls apart is with the parallel port for stepping with 
very high latency issues and that one time warning when LinuxCNC starts up that 
I've basically got my motion parameters set too high for the system.  

The solution is of course the MESA 7 I92H which solves that problem.

Or when I run MACH3 on WIN-XP with the parallel port with a 65KHz clock rate.   
Then that exact same PC doesn't have any high speed step rate issues.

Now like the BBB I/O, the PC parallel port is directly coupled to the processor 
motherboard and therefore the processor.  That LinuxCNC cannot run the same 
step rates as the WIN-XP system on identical hardware (dual boot PC remember) 
shows that there is some sort of issue with PC hardware that LinuxCNC is not 
able to solve.  Might well be video drivers.  USB drivers.  Network Drivers.  
Might be how it handles the BIOS parameters.  

Offload that I/O to a USB/Ethernet smooth stepper for MACH or the MESA 7i92H 
for LinuxCNC and the latency problems (there are others in Windows) go away.

And that, I think, is the point that everyone is making.  It's not like the PC 
parallel port is used with SPI or I2C on each output pin to expand I/O.  Some 
of the LinuxCNC solutions involve plugging a board into the PCI bus and using 
either co-processors or FPGA (which could have a co-processor built into them) 
to handle the heavy lifting.  The others involve using Ethernet and processing 
outside the box again.

I agree there are probably thousands if not tens of thousands of LinuxCNC 
systems out there running from the parallel port.  And odds are they are 
running micro-steppers that, if they are lucky, require at most 15kHz to 18kHz 
step rates before the stepper motor torque falls off so badly that they lock 
up.  So the Parallel port version of LinuxCNC has no issues on those systems.

But the latency warning for 50khz step rates for the DC Servos under LinuxCNC 
that doesn't happen on WIN-XP and MACH3 suggests that I've reached the upper 
limit of the LinuxCNC OS and the parallel port with this particular 
configuration.

But as I've been saying, the moment you add some sort of external FPGA or 
processor based external card that offloads the heavy processing for high speed 
encoder/step/SSERIAL etc. then it's not just LinuxCNC anymore but a PC  
dependent on outside hardware.   And that's what the subject line and 
discussion was about I thought.  If the motion control was offloaded to a 
separate processor then just about any PC remote or right there can load 
G-Code, display tool paths and control the machine.  

Without a PCI plug in card.  So we really are talking about Ethernet Based 
control; perhaps even WiFi.  Now we're back to the question as to why should it 
be LinuxCNC when it could be a dedicated processing I/O module with Ethernet 
connectivity running an RTOS with pre-emptive scheduling.  A small BoB sized 
board with a single cable (antenna or Ethernet) out to the outside world.  And 
with a clearly documented interface the software that connects to this no 
longer has to run on a particular PC running a particular OS.

I hope that clears it up.
John Dammeyer








___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Stuart Stevenson]

What should be the roll of LinuxCNC going forward?

Regards
Stuart

On Fri, Jan 24, 2020, 1:18 PM John Dammeyer  wrote:

> Hi Jon,
> > -Original Message-
> > From: Jon Elson [mailto:el...@pico-systems.com]
> >
> > On 01/23/2020 11:45 PM, John Dammeyer wrote:
> > > I really don't know what is going on under the covers for
> > > either the MESA Ethernet 7i92H or the Ethernet Smooth
> > > Stepper for MACH. But considering the power of the
> > > processors running machines back in the 90's or early
> > > 2000's and that the mechanics for the metal cutting
> > > haven't changed much, my guess is that some 32 bit
> > > processor _not_ running Linux so that the
> > > graphics/USB/etc. doesn't cripple the real time behaviour
> > > will be the solution.
> > You keep going around and around saying that LinuxCNC
> > doesn't work. Thousands of people are using it daily, and
> > know it DOES work!  If you want to do software stepping, how
> > about Machinekit on the Beagle Bone, using the PRU
> > to do the step generation?  This works amazingly well, and
> > costs about $145 plus keyboard, mouse and LCD screen.
> > Or, you can network into the Beagle and use some other
> > machine for the man-machine interface.
> >
> > Jon
>
> I'm _not_ saying LinuxCNC doesn't work.
> The opposite in fact and I've run the BBB with the Xylotex cape so I can
> attest that it does especially with the dual PRU I/O processors.  Even
> posted a youtube video on that.
>
> Where the beagle falls down on the Linux side of things, say compared to a
> Pi or a PC, is the video processing just isn't as good.  And it shows even
> when just running normal Linux compared to normal Linux on a Pi.
>
> Where my LinuxCNC box falls apart is with the parallel port for stepping
> with very high latency issues and that one time warning when LinuxCNC
> starts up that I've basically got my motion parameters set too high for the
> system.
>
> The solution is of course the MESA 7 I92H which solves that problem.
>
> Or when I run MACH3 on WIN-XP with the parallel port with a 65KHz clock
> rate.   Then that exact same PC doesn't have any high speed step rate
> issues.
>
> Now like the BBB I/O, the PC parallel port is directly coupled to the
> processor motherboard and therefore the processor.  That LinuxCNC cannot
> run the same step rates as the WIN-XP system on identical hardware (dual
> boot PC remember) shows that there is some sort of issue with PC hardware
> that LinuxCNC is not able to solve.  Might well be video drivers.  USB
> drivers.  Network Drivers.  Might be how it handles the BIOS parameters.
>
> Offload that I/O to a USB/Ethernet smooth stepper for MACH or the MESA
> 7i92H for LinuxCNC and the latency problems (there are others in Windows)
> go away.
>
> And that, I think, is the point that everyone is making.  It's not like
> the PC parallel port is used with SPI or I2C on each output pin to expand
> I/O.  Some of the LinuxCNC solutions involve plugging a board into the PCI
> bus and using either co-processors or FPGA (which could have a co-processor
> built into them) to handle the heavy lifting.  The others involve using
> Ethernet and processing outside the box again.
>
> I agree there are probably thousands if not tens of thousands of LinuxCNC
> systems out there running from the parallel port.  And odds are they are
> running micro-steppers that, if they are lucky, require at most 15kHz to
> 18kHz step rates before the stepper motor torque falls off so badly that
> they lock up.  So the Parallel port version of LinuxCNC has no issues on
> those systems.
>
> But the latency warning for 50khz step rates for the DC Servos under
> LinuxCNC that doesn't happen on WIN-XP and MACH3 suggests that I've reached
> the upper limit of the LinuxCNC OS and the parallel port with this
> particular configuration.
>
> But as I've been saying, the moment you add some sort of external FPGA or
> processor based external card that offloads the heavy processing for high
> speed encoder/step/SSERIAL etc. then it's not just LinuxCNC anymore but a
> PC  dependent on outside hardware.   And that's what the subject line and
> discussion was about I thought.  If the motion control was offloaded to a
> separate processor then just about any PC remote or right there can load
> G-Code, display tool paths and control the machine.
>
> Without a PCI plug in card.  So we really are talking about Ethernet Based
> control; perhaps even WiFi.  Now we're back to the question as to why
> should it be LinuxCNC when it could be a dedicated processing I/O module
> with Ethernet connectivity running an RTOS with pre-emptive scheduling.  A
> small BoB sized board with a single cable (antenna or Ethernet) out to the
> outside world.  And with a clearly documented interface the software that
> connects to this no longer has to run on a particular PC running a
> particular OS.
>
> I hope that clears it up.
> John Dammeyer
>
>
>
>
>
>
>
>
> 

Re: [Emc-users] Real-time OS for machine controllers

[Stuart Stevenson]

Integration into ERP systems?
Integration into metrology?
Machine cell controller?
Focus on lights out operation. I know one shop owner that claims most of
his operators already run 'lights out'.

Other ideas?

Thanks
Stuart

On Fri, Jan 24, 2020, 1:29 PM Stuart Stevenson  wrote:

> What should be the roll of LinuxCNC going forward?
>
> Regards
> Stuart
>
> On Fri, Jan 24, 2020, 1:18 PM John Dammeyer 
> wrote:
>
>> Hi Jon,
>> > -Original Message-
>> > From: Jon Elson [mailto:el...@pico-systems.com]
>> >
>> > On 01/23/2020 11:45 PM, John Dammeyer wrote:
>> > > I really don't know what is going on under the covers for
>> > > either the MESA Ethernet 7i92H or the Ethernet Smooth
>> > > Stepper for MACH. But considering the power of the
>> > > processors running machines back in the 90's or early
>> > > 2000's and that the mechanics for the metal cutting
>> > > haven't changed much, my guess is that some 32 bit
>> > > processor _not_ running Linux so that the
>> > > graphics/USB/etc. doesn't cripple the real time behaviour
>> > > will be the solution.
>> > You keep going around and around saying that LinuxCNC
>> > doesn't work. Thousands of people are using it daily, and
>> > know it DOES work!  If you want to do software stepping, how
>> > about Machinekit on the Beagle Bone, using the PRU
>> > to do the step generation?  This works amazingly well, and
>> > costs about $145 plus keyboard, mouse and LCD screen.
>> > Or, you can network into the Beagle and use some other
>> > machine for the man-machine interface.
>> >
>> > Jon
>>
>> I'm _not_ saying LinuxCNC doesn't work.
>> The opposite in fact and I've run the BBB with the Xylotex cape so I can
>> attest that it does especially with the dual PRU I/O processors.  Even
>> posted a youtube video on that.
>>
>> Where the beagle falls down on the Linux side of things, say compared to
>> a Pi or a PC, is the video processing just isn't as good.  And it shows
>> even when just running normal Linux compared to normal Linux on a Pi.
>>
>> Where my LinuxCNC box falls apart is with the parallel port for stepping
>> with very high latency issues and that one time warning when LinuxCNC
>> starts up that I've basically got my motion parameters set too high for the
>> system.
>>
>> The solution is of course the MESA 7 I92H which solves that problem.
>>
>> Or when I run MACH3 on WIN-XP with the parallel port with a 65KHz clock
>> rate.   Then that exact same PC doesn't have any high speed step rate
>> issues.
>>
>> Now like the BBB I/O, the PC parallel port is directly coupled to the
>> processor motherboard and therefore the processor.  That LinuxCNC cannot
>> run the same step rates as the WIN-XP system on identical hardware (dual
>> boot PC remember) shows that there is some sort of issue with PC hardware
>> that LinuxCNC is not able to solve.  Might well be video drivers.  USB
>> drivers.  Network Drivers.  Might be how it handles the BIOS parameters.
>>
>> Offload that I/O to a USB/Ethernet smooth stepper for MACH or the MESA
>> 7i92H for LinuxCNC and the latency problems (there are others in Windows)
>> go away.
>>
>> And that, I think, is the point that everyone is making.  It's not like
>> the PC parallel port is used with SPI or I2C on each output pin to expand
>> I/O.  Some of the LinuxCNC solutions involve plugging a board into the PCI
>> bus and using either co-processors or FPGA (which could have a co-processor
>> built into them) to handle the heavy lifting.  The others involve using
>> Ethernet and processing outside the box again.
>>
>> I agree there are probably thousands if not tens of thousands of LinuxCNC
>> systems out there running from the parallel port.  And odds are they are
>> running micro-steppers that, if they are lucky, require at most 15kHz to
>> 18kHz step rates before the stepper motor torque falls off so badly that
>> they lock up.  So the Parallel port version of LinuxCNC has no issues on
>> those systems.
>>
>> But the latency warning for 50khz step rates for the DC Servos under
>> LinuxCNC that doesn't happen on WIN-XP and MACH3 suggests that I've reached
>> the upper limit of the LinuxCNC OS and the parallel port with this
>> particular configuration.
>>
>> But as I've been saying, the moment you add some sort of external FPGA or
>> processor based external card that offloads the heavy processing for high
>> speed encoder/step/SSERIAL etc. then it's not just LinuxCNC anymore but a
>> PC  dependent on outside hardware.   And that's what the subject line and
>> discussion was about I thought.  If the motion control was offloaded to a
>> separate processor then just about any PC remote or right there can load
>> G-Code, display tool paths and control the machine.
>>
>> Without a PCI plug in card.  So we really are talking about Ethernet
>> Based control; perhaps even WiFi.  Now we're back to the question as to why
>> should it be LinuxCNC when it could be a dedicated processing I/O module
>> with Ethernet connectivity running an RT

Re: [Emc-users] Real-time OS for machine controllers

[bari]

On 1/24/20 12:47 PM, Les Newell wrote:
>
>>> On 24 Jan 2020, at 19:51, Chris Albertson
>>>  wrote:
>>>
>>> But we could design things so the requirements are VEY loose at the
>>> highest
>>> level for 0.5-second latencies being acceptable.
>> Not rigid tapping.
>>
> And jogging would be horrible.
>

When the issue comes up for a replacement for LinuxCNC with a more
modern software it is always for stepper only systems and not servo.
They have not thought through the issues of 5+ axis servo or rigid
tapping or synchronizing axis motion with lasers , galvos or inkjet
printheads, all of which I do with LCNC. I know that I work on lots of
hybrid systems that combine different technologies and LinuxCNC lets me
do that pretty easily. That is why we (we being mostly the guy down the
hall from me) have been keeping RTAI alive.

If there is a way to move to a different system architecture with the
GUI on a 12 inch (30.5cm) plus display and have the motion control
offloaded to a separate real-time processor that gives me more features
and flexibility than I have now I might be interested.

Moving to a different system architecture with the GUI on one device and
the motion control offloaded to a separate real-time processor that just
gives me "more modern" isn't worth my development time.  It will also
take lots more work than making the mods I do now or keeping RTAI going.
Changing the system architecture will have to give me more than I have
now to make such development worthwhile.

The display will have to be large enough to display all the controls
plus be rugged and reliable, so NOT a smartphone. I also don't want to
control any machine that can easily kill someone or me over a wireless
connection.




___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[bari]

One thing that has come up when using LinuxCNC to control robots in an
automation cell is controlling more than one robot or machine at a time.
Or having LinuxCNC control the hand-off of parts between machines and/or
robots.

On 1/24/20 1:33 PM, Stuart Stevenson wrote:
> Integration into ERP systems?
> Integration into metrology?
> Machine cell controller?
> Focus on lights out operation. I know one shop owner that claims most of
> his operators already run 'lights out'.
>
> Other ideas?
>
> Thanks
> Stuart
>
> On Fri, Jan 24, 2020, 1:29 PM Stuart Stevenson  wrote:
>
>> What should be the roll of LinuxCNC going forward?
>>
>>



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Gene Heskett]

On Friday 24 January 2020 13:46:37 Les Newell wrote:

> > Humm pcbshopper.com, got a project "code" I can order and a doc &
> > BOM I can DL?
>
> Pcbshopper is just a price comparison site. You enter the board
> details and they poll various suppliers for the best price.
>
> Currently all I have are the KiCad project and the Gerbers. I need to
> write some docs. I designed this board a couple of years ago so I need
> to look back through my records to see exactly what I have.
>
> Where would be the best place for the files? Is there a place on the
> LCNC website? Maybe on Github?
>
> Les
>
Because I'm somewhat spooked by the all eggs in one basket that github 
uses, I think I'd use our wiki.

Thanks Les.

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Gene Heskett]

On Friday 24 January 2020 13:47:38 Les Newell wrote:

> >> On 24 Jan 2020, at 19:51, Chris Albertson
> >>  wrote:
> >>
> >> But we could design things so the requirements are VEY loose at the
> >> highest level for 0.5-second latencies being acceptable.
> >
> > Not rigid tapping.
>
> And jogging would be horrible.
>
> Les
>
Strike 2.

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Gene Heskett]

On Friday 24 January 2020 15:03:46 bari wrote:

> One thing that has come up when using LinuxCNC to control robots in an
> automation cell is controlling more than one robot or machine at a
> time. Or having LinuxCNC control the hand-off of parts between
> machines and/or robots.
>
I don't believe hal would have a problem doing that, although for serious 
lengths of queues I think I'd put a pile between the machines for a 
buffer. That would complexify the hal, but no more than any other flow 
control scheme. And it could be done right now plus fabbing the 
mechanics.
> On 1/24/20 1:33 PM, Stuart Stevenson wrote:
> > Integration into ERP systems?
> > Integration into metrology?
> > Machine cell controller?
> > Focus on lights out operation. I know one shop owner that claims
> > most of his operators already run 'lights out'.
> >
> > Other ideas?
> >
> > Thanks
> > Stuart
> >
> > On Fri, Jan 24, 2020, 1:29 PM Stuart Stevenson  
wrote:
> >> What should be the roll of LinuxCNC going forward?
>
> ___
> 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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[R C]

How are you going to do ethernet, wifi or "what ever communication"  
that is reliable (which means the process has to be able to take 
priority), without using PCI or anything like it on PC style hardware, 
or even non-PC computing hardware?


If you'd use anything affordable (which means Intel/ARM/'other' based 
stuff, you are just moving the problem around, because


at some point in the process you need a very well timed/orchestrated 
mechanism to make steppermotors (or even servos) do what you want them 
to do.


Whatever the approach, at some point somewhere you need some hardware 
function that does that, even if you'd have a specific controller, FPGA, 
whatever, then


that piece has to take that function over, the problem didn't go away.


Can you make that "hardware function" more reliable or less intrusive?  
Of course, that is why there are these special controllers, but that 
also costs more money for the


hardware/software. (It is possible to do that with networking too, by 
replacing ethernet with IB (InfiniBand) or so, however again...  that is 
expensive and does not


make the hardware dependency go away, you just relocate it).


Maybe a "good way forward" for those that are looking for that "forward" 
for LinuxCNC is, besides using PCI/Parallel port hardware, also support 
other hardware, where you can just select a device/protocol to do your 
stepping with. (if that doesn't already exist).



just another 2cnts,


Ron


On 1/24/20 12:15 PM, John Dammeyer wrote:

Hi Jon,

-Original Message-
From: Jon Elson [mailto:el...@pico-systems.com]

On 01/23/2020 11:45 PM, John Dammeyer wrote:

I really don't know what is going on under the covers for
either the MESA Ethernet 7i92H or the Ethernet Smooth
Stepper for MACH. But considering the power of the
processors running machines back in the 90's or early
2000's and that the mechanics for the metal cutting
haven't changed much, my guess is that some 32 bit
processor _not_ running Linux so that the
graphics/USB/etc. doesn't cripple the real time behaviour
will be the solution.

You keep going around and around saying that LinuxCNC
doesn't work. Thousands of people are using it daily, and
know it DOES work!  If you want to do software stepping, how
about Machinekit on the Beagle Bone, using the PRU
to do the step generation?  This works amazingly well, and
costs about $145 plus keyboard, mouse and LCD screen.
Or, you can network into the Beagle and use some other
machine for the man-machine interface.

Jon

I'm _not_ saying LinuxCNC doesn't work.
The opposite in fact and I've run the BBB with the Xylotex cape so I can attest 
that it does especially with the dual PRU I/O processors.  Even posted a 
youtube video on that.

Where the beagle falls down on the Linux side of things, say compared to a Pi 
or a PC, is the video processing just isn't as good.  And it shows even when 
just running normal Linux compared to normal Linux on a Pi.

Where my LinuxCNC box falls apart is with the parallel port for stepping with 
very high latency issues and that one time warning when LinuxCNC starts up that 
I've basically got my motion parameters set too high for the system.

The solution is of course the MESA 7 I92H which solves that problem.

Or when I run MACH3 on WIN-XP with the parallel port with a 65KHz clock rate.   
Then that exact same PC doesn't have any high speed step rate issues.

Now like the BBB I/O, the PC parallel port is directly coupled to the processor 
motherboard and therefore the processor.  That LinuxCNC cannot run the same 
step rates as the WIN-XP system on identical hardware (dual boot PC remember) 
shows that there is some sort of issue with PC hardware that LinuxCNC is not 
able to solve.  Might well be video drivers.  USB drivers.  Network Drivers.  
Might be how it handles the BIOS parameters.

Offload that I/O to a USB/Ethernet smooth stepper for MACH or the MESA 7i92H 
for LinuxCNC and the latency problems (there are others in Windows) go away.

And that, I think, is the point that everyone is making.  It's not like the PC 
parallel port is used with SPI or I2C on each output pin to expand I/O.  Some 
of the LinuxCNC solutions involve plugging a board into the PCI bus and using 
either co-processors or FPGA (which could have a co-processor built into them) 
to handle the heavy lifting.  The others involve using Ethernet and processing 
outside the box again.

I agree there are probably thousands if not tens of thousands of LinuxCNC 
systems out there running from the parallel port.  And odds are they are 
running micro-steppers that, if they are lucky, require at most 15kHz to 18kHz 
step rates before the stepper motor torque falls off so badly that they lock 
up.  So the Parallel port version of LinuxCNC has no issues on those systems.

But the latency warning for 50khz step rates for the DC Servos under LinuxCNC 
that doesn't happen on WIN-XP and MACH3 suggests that I've reached the upper 
limit of the LinuxCNC OS and t

Re: [Emc-users] Real-time OS for machine controllers

[R C]

On 1/24/20 1:27 PM, Gene Heskett wrote:

On Friday 24 January 2020 15:03:46 bari wrote:


One thing that has come up when using LinuxCNC to control robots in an
automation cell is controlling more than one robot or machine at a
time. Or having LinuxCNC control the hand-off of parts between
machines and/or robots.


I don't believe hal would have a problem doing that, although for serious
lengths of queues I think I'd put a pile between the machines for a
buffer. That would complexify the hal, but no more than any other flow
control scheme. And it could be done right now plus fabbing the
mechanics.



If you are controlling more than one CNC machine, or robots at a time, 
you are actually talking


about a parallel system. (Work gets done in parallel.) That is exactly 
what HPCs/Supercomputers do,


And in parallel/HPC computing it is very well understood that you have 
to offload hardware/time dependent


work. That was figured out after the first (original) Cray 
supercomputers (SGI tried not to but failed). If you want


scalable parallel production, you have to offload work, and you start to 
need equipment that manages that too.



The issues with running different and/or multiple machines running in 
parallel, from what I hear, sounds very similar  to the what


HPC/Supercomputing has been dealing with all the time, scalability. (oh 
and :) all these parallel computers use some sort of Linux, because


it scales really well).





On 1/24/20 1:33 PM, Stuart Stevenson wrote:

Integration into ERP systems?
Integration into metrology?
Machine cell controller?
Focus on lights out operation. I know one shop owner that claims
most of his operators already run 'lights out'.

Other ideas?

Thanks
Stuart

On Fri, Jan 24, 2020, 1:29 PM Stuart Stevenson 

wrote:

What should be the roll of LinuxCNC going forward?

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Andy Pugh]

> On 24 Jan 2020, at 22:06, bari  wrote:
> 
> One thing that has come up when using LinuxCNC to control robots in an
> automation cell is controlling more than one robot or machine at a time.

That feels like a low-hanging fruit. Multiple LinuxCNC instances and a shared 
HAL area on one PC. 




___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Jon Elson]

On 01/24/2020 01:15 PM, John Dammeyer wrote:
   


Where the beagle falls down on the Linux side of things, say compared to a Pi 
or a PC, is the video processing just isn't as good.  And it shows even when 
just running normal Linux compared to normal Linux on a Pi.
Well, I DO see a bit of sluggishness compared to a fast 
Intel CPU with graphics card, but it is
completely tolerable, to me.  And, LinuxCNC has been run on 
a Pi, but that port is apparently not

ready for prime time, yet.

Where my LinuxCNC box falls apart is with the parallel port for stepping with 
very high latency issues and that one time warning when LinuxCNC starts up that 
I've basically got my motion parameters set too high for the system.
There are desktop PCs that have horrible real time 
performance, for a variety of reasons, and some that have
amazingly good RT latency.  I make a line of 3 different 
motion controllers that use the parallel port as a 
communications
path to an FPGA.  On a variety of CPUs, the entire servo 
thread cycle takes from 100 - 200 us to service up to 4 axes,
so a 1 KHz servo thread is totally reliable.  With these 
units, there is NO base thread, essentially the base thread is
moved out to the hardware.  These devices support 
step/direction systems, and PWM and analog servo systems.

I've been making these since 2002.

   Might well be video drivers.
There are clearly video drivers combined with certain video 
chips/cards that totally trash the realtime performance.
Partly, that is do to trying to do software-generated 
stepping on a multi-purpose CPU.  That's why I just don't

recommend doing that.

Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[John Dammeyer]

Hi Ron,
I was contemplating your reply and this whole RTOS for Machine Control while I 
was assembling this small module.
http://www.autoartisans.com/mill/PWMSpindle-1.jpg
It's a carrier and I/O interface for a PWM to 10V board from China.  It also 
translates that same PWM signal as step/dir into RS422 to drive the 1.8kW 
Bergerda AC Servo I purchased to turn my spindle from 0 to 3000 RPM.

The reason for this is to be able to still swap back and forth between MACH3 
and LinuxCNC using the parallel port for I/O.  Part of my research into all 
this.  The Windows Parallel Port interface (or Smooth Stepper) and MACH3 with a 
simple check box can make the STEP pin a PWM pin for spindle speed.   The HAL 
file also lets me do that with the parallel port although I've not tried the 
STEP option on that pin yet.

The MESA 7i92H cannot do this.  It can be programmed with a different FPGA file 
to have a STEP Generator on that pin instead of the PWM but it requires 
reprogramming the 7i92H and of course a restart of LinuxCNC.  Not as easy as a 
checkbox. 

Anyway, while I was assembling this board, the expression "If all you have is a 
hammer, everything looks like a nail" popped into my head.   I'm sure there are 
tens of thousands of mills out there that are manual with no power feed.  
Others with a single or dual power feed.   Then there's DRO's/

An article I read today in the #288 Model Engineer's Workshop magazine 
discussed adding a spindle RPM readout and another on switching the DRO head 
between a mill and a lathe. 

The very first thing I did with my mill 13 years ago was add a Shumatech DRO 
kit and some inexpensive scales.  I've never looked back.  Nor looked at the 
hand wheel scales.A few years later I added a stepper motor to the knee to 
give it power feed.  I used a surplus ELS I had lying around to move it up and 
down.  And since it was calibrated to the knee I could set zero and even move 
to predefined positions.  All still manually though.  Plus the mill had a power 
feed on the X axis.

I've seen other articles on adding power feed to mills using anything from 
electric drills to quite sophisticated operations.  Those mill owners aren't 
running LinuxCNC or MACH.  So if all you have is LinuxCNC the idea that there 
might be other types of fasteners and not just nails can appear to dominate 
one's thinking without even realizing it.

Now that I'm adding CNC to the mill I've noticed something about the way I work 
on it and at times I miss that 'manual' operation.  After all with a DRO 
cutting a bolt circle is a no brainer.  But cutting an arc without a rotary 
table (my previous approach) is virtually impossible.  So I'm wondering if 
maybe we are all overthinking this.

A standalone box that drives 3 to 5 axis, detects/controls spindle RPM and 
other I/O like a power draw bar, even tool changer carousel.  Buttons like the 
one on the Axis screen or the MACH flyout tab that let you step/jog increments 
and an MPG input for that sort of interface.  Like the AXIS and MACH screens,  
a DRO showing positions so we need at least 4 lines and 20 characters or maybe 
a midsize LCD display.  Perhaps touch screen and like the DRO the ability to do 
a predefined series of assists like hole circles perhaps even arcs.

At this point about the only thing missing is G-Code interpretation.  Or am I 
missing something?  

So this box, has one or two DB-25 output connectors that match a PC along with 
a couple of RS232/RS485 ports.Connected to that is the standard, custom for 
the machine, BoB drive hardware.  On the other end of the box an Ethernet port 
for connection to something...  And perhaps a USB port for installing updated 
firmware.  What you now have is a standalone DRO c/w power feed on all axis 
that is up and running within a second of power being applied with time 
sensitive stuff running under RTOS control.  

I believe that this is the concept that was initially introduced with this 
subject line.  And the PC, if even connected and powered up services as the 
visual user interface with graphical display of tool path etc.  Not only that, 
remove this box and connect the DB-25 cables to the back of a PC or MESA 7i92H 
and you have that PC based CNC system without the hardware by just selecting a 
different HAL INI file set.

So why have the box at all if you're prepared to also power up a PC that runs 
LinuxCNC?  One might ask the question the other way.  Why aren't all the manual 
mills in the world running LinuxCNC with a PC and monitor on a stand right by 
the mill?  Maybe because some one-of  tasks are just easier with a manual mill 
and many mills in the world are used for one-of tasks.  So perhaps a box with 
an RTOS and limited automation fills a void.

Just throwing ideas up in the air.
John Dammeyer




> -Original Message-
> From: R C [mailto:cjv...@gmail.com]
> Se

Re: [Emc-users] Real-time OS for machine controllers

[John Dammeyer]

> -Original Message-
> > Where the beagle falls down on the Linux side of things, say compared to a
> Pi or a PC, is the video processing just isn't as good.  And it shows even 
> when
> just running normal Linux compared to normal Linux on a Pi.
> Well, I DO see a bit of sluggishness compared to a fast
> Intel CPU with graphics card, but it is
> completely tolerable, to me.  And, LinuxCNC has been run on
> a Pi, but that port is apparently not
> ready for prime time, yet.
> > Where my LinuxCNC box falls apart is with the parallel port for stepping
> with very high latency issues and that one time warning when LinuxCNC
> starts up that I've basically got my motion parameters set too high for the
> system.
> There are desktop PCs that have horrible real time
> performance, for a variety of reasons, and some that have
> amazingly good RT latency.  I make a line of 3 different
> motion controllers that use the parallel port as a
> communications
> path to an FPGA.  On a variety of CPUs, the entire servo
> thread cycle takes from 100 - 200 us to service up to 4 axes,
> so a 1 KHz servo thread is totally reliable.  With these
> units, there is NO base thread, essentially the base thread is
> moved out to the hardware.  These devices support
> step/direction systems, and PWM and analog servo systems.
> I've been making these since 2002.
> >Might well be video drivers.
> There are clearly video drivers combined with certain video
> chips/cards that totally trash the realtime performance.
> Partly, that is do to trying to do software-generated
> stepping on a multi-purpose CPU.  That's why I just don't
> recommend doing that.
> 
> Jon

Hi Jon,
But that's my point.  If I go through 4 different PCs from different sources 
and each has latency issues at some point I'm going to say the heck with direct 
control and let's use an Ethernet driven device.  At this point the step 
generation and closed loop has moved out of the PC hasn't it?

And  BTW, these PCs are 1.8GHz and 2.4GHz.  Given we were doing EMACs back in 
the 90's with 33MHz PCs (maybe with Fedora?  Don't remember) a fact of almost 
100 times faster strikes me that these real time ports of Linux onto PCs isn't 
what it's cracked up to be.   Otherwise the suggestion that it must be the 
other hardware seems iffy.  And if the hardware cannot be controlled to that 
extent because the drivers etc. are in the way then the solution is as the 
subject line suggests, a separate open source hardware/software platform 
running an RTOS that creates deterministic outputs.But that would also make 
products like yours dated and that's not my intention.

I'd certainly be up for having someone modify my HAL and INI files so that I 
can do the 50kHz step rates out the parallel port.  After all WIN-XP and MACH3 
can do it.But like I said, I have trouble understanding how a 2.4Ghz 
machine can't do what was done with smaller micros running much slower.

John Dammeyer



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Alan Condit]

Chris,

If I send 1 steps to a smart X-axis controller, how does it stay in sync 
with a smart
y-axis controller without someone controlling the synchronization between the 
two?

Alan

> From: Chris Albertson 
> Subject: Re: [Emc-users] Real-time OS for machine controllers
> Date: January 24, 2020 at 9:48:27 AM PST
> To: "Enhanced Machine Controller (EMC)" 
> 
> 
> If you can tolerate latency, then your "hub" does not need what we call
> "hard" real-time capability.  It only needs to keep up with the average
> workload, averaged over whatever latency you can tolerate.  Video streaming
> works this way.They can't reliably send video and the 60 Hz frame rate
> so they buffer a few seconds of video on your phone and the real-time
> viewer lives on the phone  not the server.
> 
> g-code could be the same way.   The penalty is that when you press the "go"
> button the milling machine would take a few seconds the start working while
> the data buffers into the low-level motor controllers. Today a
> step/direction controller has no memory so it must be fed steps in real
> time.  But if it has a 10,000 step memory you could just transfer blocks
> ever half second and the controller would work down the queue."Steps"
> are the wrong kind of data for this but "states" are what is used.
> 
> You are correct in that some real-time ability is needed at every level.
> But we could design things so the requirements are VEY loose at the highest
> level for 0.5-second latencies being acceptable.   One you need only that,
> then even an iPhone is a good enough platform.
> 
> On Thu, Jan 23, 2020 at 11:32 AM Peter C. Wallace  wrote:
> 
>> On Thu, 23 Jan 2020, Chris Albertson wrote:
>> 
>>> Date: Thu, 23 Jan 2020 10:17:44 -0800
>>> From: Chris Albertson 
>>> Reply-To: "Enhanced Machine Controller (EMC)"
>>>
>>> To: "Enhanced Machine Controller (EMC)" >> 
>>> Subject: Re: [Emc-users] Real-time OS for machine controllers
>>> 
>>> The trouble with the Mesa FPGA design is that it depends on a computer
>> with
>>> good real-time performance.   It can generate steps but I don't thing you
>>> can run a position or velocity PID control loop on the FPGA.
>> 
>> LinuxCNCs design paradigm requires realtime, this is a design decision
>> that is
>> supported by our Hostmot2 real time firmware. We have other firmware that
>> implements motion in the FPGA but this is not suited to LinuxCNCs model.
>> 
>> 
>> You might argue that its an old fashioned model but many high performance
>> CNC
>> systems and Robotics controllers use LinuxCNCs model of a capable real
>> time host
>> (real OS with file I/O loadable modules, unlimited memory, massive
>> floating
>> point performance etc etc) Some of these use Linux and others use real
>> time
>> windows varients often with Ethercat Peripherals. This makes for a
>> powerful
>> extensible realtime toolkit (like LinuxCNCs HAL) and complex realtime
>> responsive coordinated motion. Basically for this type of system you still
>> need a very capable real time controller hub even if the motor controllers
>> implement torque, velocity, or position loops
>> 
>> 
>> Peter Wallace
>> Mesa Electronics
>> 
>> 
>> 
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>> 
> 
> 
> -- 
> 
> Chris Albertson
> Redondo Beach, California


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[R C]

exactly


That is what is called inter process communication  (IPC)  in the 
computing world.  There are all kinds of systems to deal with that in 
large scale supercompters.   individual compute nodes have a means to 
communicate with other compute nodes


In this case it would mean,   "hey axis Y I am axis X and and I am at 
this position blabla,  what position are you at?"   That is not science 
fiction, it


has been around for a long while and exists and works very well.


Ron



On 1/24/20 9:27 PM, Alan Condit wrote:

Chris,

If I send 1 steps to a smart X-axis controller, how does it stay in sync 
with a smart
y-axis controller without someone controlling the synchronization between the 
two?

Alan


From: Chris Albertson 
Subject: Re: [Emc-users] Real-time OS for machine controllers
Date: January 24, 2020 at 9:48:27 AM PST
To: "Enhanced Machine Controller (EMC)" 


If you can tolerate latency, then your "hub" does not need what we call
"hard" real-time capability.  It only needs to keep up with the average
workload, averaged over whatever latency you can tolerate.  Video streaming
works this way.They can't reliably send video and the 60 Hz frame rate
so they buffer a few seconds of video on your phone and the real-time
viewer lives on the phone  not the server.

g-code could be the same way.   The penalty is that when you press the "go"
button the milling machine would take a few seconds the start working while
the data buffers into the low-level motor controllers. Today a
step/direction controller has no memory so it must be fed steps in real
time.  But if it has a 10,000 step memory you could just transfer blocks
ever half second and the controller would work down the queue."Steps"
are the wrong kind of data for this but "states" are what is used.

You are correct in that some real-time ability is needed at every level.
But we could design things so the requirements are VEY loose at the highest
level for 0.5-second latencies being acceptable.   One you need only that,
then even an iPhone is a good enough platform.

On Thu, Jan 23, 2020 at 11:32 AM Peter C. Wallace  wrote:


On Thu, 23 Jan 2020, Chris Albertson wrote:


Date: Thu, 23 Jan 2020 10:17:44 -0800
From: Chris Albertson 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "Enhanced Machine Controller (EMC)" 
with

good real-time performance.   It can generate steps but I don't thing you
can run a position or velocity PID control loop on the FPGA.

LinuxCNCs design paradigm requires realtime, this is a design decision
that is
supported by our Hostmot2 real time firmware. We have other firmware that
implements motion in the FPGA but this is not suited to LinuxCNCs model.


You might argue that its an old fashioned model but many high performance
CNC
systems and Robotics controllers use LinuxCNCs model of a capable real
time host
(real OS with file I/O loadable modules, unlimited memory, massive
floating
point performance etc etc) Some of these use Linux and others use real
time
windows varients often with Ethercat Peripherals. This makes for a
powerful
extensible realtime toolkit (like LinuxCNCs HAL) and complex realtime
responsive coordinated motion. Basically for this type of system you still
need a very capable real time controller hub even if the motor controllers
implement torque, velocity, or position loops


Peter Wallace
Mesa Electronics



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users



--

Chris Albertson
Redondo Beach, California


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Erik Christiansen]

On 24.01.20 20:27, Alan Condit wrote:
> Chris,
> 
> If I send 1 steps to a smart X-axis controller, how does it stay in sync 
> with a smart
> y-axis controller without someone controlling the synchronization between the 
> two?

One way could be for the host to pulse the x and y step pins in
synchronism at a suitable multiple of the steps needed for the longer
run. If we need a slope of 0.167, then tell one smart controller
to divide by 1, the other by 6.

Even pi can be approximated to 1 part in ten million by 355/113, so a
bit of smarts in the host could keep the axis controllers simple yet
flexible, I figure.

Motion commands could be sent on RS485 serial, before the primary step
sequence begins.

Erik
(Who hasn't read the whole thread, unfortunately. There's a 1 foot
diameter branch down in the front garden, and it needs to go before its
ute-load of eucalyptus leaves dries to a pyromaniac's dream.)


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[R C]

That makes perfect sense   if never anything goes wrong


what if one motor stalls, what if one signal needs to be re-transmitted?

If neither of that is corrected...  one axis is off "time shifted" 
relative to the other.


For precision sake, you would need feedback from one axis to the other.


On 1/24/20 10:14 PM, Erik Christiansen wrote:

On 24.01.20 20:27, Alan Condit wrote:

Chris,

If I send 1 steps to a smart X-axis controller, how does it stay in sync 
with a smart
y-axis controller without someone controlling the synchronization between the 
two?

One way could be for the host to pulse the x and y step pins in
synchronism at a suitable multiple of the steps needed for the longer
run. If we need a slope of 0.167, then tell one smart controller
to divide by 1, the other by 6.

Even pi can be approximated to 1 part in ten million by 355/113, so a
bit of smarts in the host could keep the axis controllers simple yet
flexible, I figure.

Motion commands could be sent on RS485 serial, before the primary step
sequence begins.

Erik
(Who hasn't read the whole thread, unfortunately. There's a 1 foot
diameter branch down in the front garden, and it needs to go before its
ute-load of eucalyptus leaves dries to a pyromaniac's dream.)


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Chris Albertson]

On Fri, Jan 24, 2020 at 8:29 PM Alan Condit  wrote:

> Chris,
>
> If I send 1 steps to a smart X-axis controller, how does it stay in
> sync with a smart
> y-axis controller without someone controlling the synchronization between
> the two?
>

As said, "steps" are the wrong thing to send.   What they do is send time,
tagged points.  Each point has a time tag on it.It is not hard to
synchronize clocks at the microsecond level.

What they send is a list of target points.Assuming the machine works in
(x, y, z) space each point, you have "time", (x, y, z) and (x', y', z') and
(x'', y'', z'').   A machine might have more or fewer axis with different
names, but same idea.   Each controller can handle up to some maximum
number of axis and it wold not be until you are over that limit that you'd
have to split things.  Doing six axis on one controller is reasonable.

The controller tries its best to hit the target points.  It can happen that
a target is impossible.  Also, some of ths data can be omitted.  Doing so
wuld free the controller to do what it "wants".  I think you always want
x,y,z but could maybe omit the prime (velocity) or double prime
(acceleration)  This kind of path planning is what LinuxCNC already does,
but today it is reasonable to push this down into a $5 chip.

LinuxCNC is originally written used the exact oposite aproach and move all
the "smarts" upstream into a PC.

The non-real-time part has to read the g-code or the conversational
interface or the hand pendant or video data and convert to a stream of
target points.

That said, "steps" could work if each one had a time tag.  But that pushes
the planning upstream and I think the better plan is to move as much
"smarts" as possible as close to the physical motor as possible.   So let
the motor driver figure out what rate to drive each otor so the targets are
reached.



Alan
>
> > From: Chris Albertson 
> > Subject: Re: [Emc-users] Real-time OS for machine controllers
> > Date: January 24, 2020 at 9:48:27 AM PST
> > To: "Enhanced Machine Controller (EMC)"  >
> >
> >
> > If you can tolerate latency, then your "hub" does not need what we call
> > "hard" real-time capability.  It only needs to keep up with the average
> > workload, averaged over whatever latency you can tolerate.  Video
> streaming
> > works this way.They can't reliably send video and the 60 Hz frame
> rate
> > so they buffer a few seconds of video on your phone and the real-time
> > viewer lives on the phone  not the server.
> >
> > g-code could be the same way.   The penalty is that when you press the
> "go"
> > button the milling machine would take a few seconds the start working
> while
> > the data buffers into the low-level motor controllers. Today a
> > step/direction controller has no memory so it must be fed steps in real
> > time.  But if it has a 10,000 step memory you could just transfer blocks
> > ever half second and the controller would work down the queue."Steps"
> > are the wrong kind of data for this but "states" are what is used.
> >
> > You are correct in that some real-time ability is needed at every level.
> > But we could design things so the requirements are VEY loose at the
> highest
> > level for 0.5-second latencies being acceptable.   One you need only
> that,
> > then even an iPhone is a good enough platform.
> >
> > On Thu, Jan 23, 2020 at 11:32 AM Peter C. Wallace 
> wrote:
> >
> >> On Thu, 23 Jan 2020, Chris Albertson wrote:
> >>
> >>> Date: Thu, 23 Jan 2020 10:17:44 -0800
> >>> From: Chris Albertson 
> >>> Reply-To: "Enhanced Machine Controller (EMC)"
> >>>
> >>> To: "Enhanced Machine Controller (EMC)" <
> emc-users@lists.sourceforge.net
> >>>
> >>> Subject: Re: [Emc-users] Real-time OS for machine controllers
> >>>
> >>> The trouble with the Mesa FPGA design is that it depends on a computer
> >> with
> >>> good real-time performance.   It can generate steps but I don't thing
> you
> >>> can run a position or velocity PID control loop on the FPGA.
> >>
> >> LinuxCNCs design paradigm requires realtime, this is a design decision
> >> that is
> >> supported by our Hostmot2 real time firmware. We have other firmware
> that
> >> implements motion in the FPGA but this is not suited to LinuxCNCs model.
> >>
> >>
> >> You might argue that its an old fashioned model but many h

Re: [Emc-users] Real-time OS for machine controllers

[Gene Heskett]

On Saturday 25 January 2020 00:56:18 Chris Albertson wrote:

> On Fri, Jan 24, 2020 at 8:29 PM Alan Condit  
wrote:
> > Chris,
> >
> > If I send 1 steps to a smart X-axis controller, how does it stay
> > in sync with a smart
> > y-axis controller without someone controlling the synchronization
> > between the two?
>
> As said, "steps" are the wrong thing to send.   What they do is send
> time, tagged points.  Each point has a time tag on it.It is not
> hard to synchronize clocks at the microsecond level.
>
> What they send is a list of target points.Assuming the machine
> works in (x, y, z) space each point, you have "time", (x, y, z) and
> (x', y', z') and (x'', y'', z'').   A machine might have more or fewer
> axis with different names, but same idea.   Each controller can
> handle up to some maximum number of axis and it wold not be until you
> are over that limit that you'd have to split things.  Doing six axis
> on one controller is reasonable.
>
> The controller tries its best to hit the target points.  It can happen
> that a target is impossible.  Also, some of ths data can be omitted. 
> Doing so wuld free the controller to do what it "wants".  I think you
> always want x,y,z but could maybe omit the prime (velocity) or double
> prime (acceleration)  This kind of path planning is what LinuxCNC
> already does, but today it is reasonable to push this down into a $5
> chip.
>
> LinuxCNC is originally written used the exact oposite aproach and move
> all the "smarts" upstream into a PC.
>
> The non-real-time part has to read the g-code or the conversational
> interface or the hand pendant or video data and convert to a stream of
> target points.
>
> That said, "steps" could work if each one had a time tag.  But that
> pushes the planning upstream and I think the better plan is to move as
> much "smarts" as possible as close to the physical motor as possible. 
>  So let the motor driver figure out what rate to drive each otor so
> the targets are reached.
>
> Alan

I like this idea. But the com path must be two way so the planner can 
know if that target was reached for each time point, and must know also 
each axis;s limits for accel and top speed so the it can issue 
attainable targets. But wait, isn't that what lcnc is doing now?

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[John Dammeyer]

 one packet every 40 
milliseconds is loafing for a 100MBPS Ethernet.  

If you've followed all this you can see that the intelligence is in the 
trajectory planner.  There is no need to replace that part of LinuxCNC into a 
dedicated stepping engine RTOS driven module.It's just a matter of 
configuring the results into a form that is interpreted by the hardware that 
talks to the motors.

I think I've said the same thing Chris did but from a different perspective.  

For my ELS I used the Bresenham algorithm 
https://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm
to move Z relative to the spindle for threading.   After all, a thread is 
really just a triangle wound around a cylinder.  Move Z relative to the spindle 
and you move along the hypotenuse of a triangle.   Each step pulse possibility 
examined a counter incremented by a constant based on spindle RPM and if it 
rolled over set the Z STEP pulse ON.  At the end of the routine the STEP was 
set off.  Based on the number of Z step pulses a similar calculation would set 
the X STEP pulse ON in order to do tapering.

John Dammeyer



> -Original Message-
> From: Chris Albertson [mailto:albertson.ch...@gmail.com]
> Sent: January-24-20 9:56 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Real-time OS for machine controllers
> 
> On Fri, Jan 24, 2020 at 8:29 PM Alan Condit  wrote:
> 
> > Chris,
> >
> > If I send 1 steps to a smart X-axis controller, how does it stay in
> > sync with a smart
> > y-axis controller without someone controlling the synchronization between
> > the two?
> >
> 
> As said, "steps" are the wrong thing to send.   What they do is send time,
> tagged points.  Each point has a time tag on it.It is not hard to
> synchronize clocks at the microsecond level.
> 
> What they send is a list of target points.Assuming the machine works in
> (x, y, z) space each point, you have "time", (x, y, z) and (x', y', z') and
> (x'', y'', z'').   A machine might have more or fewer axis with different
> names, but same idea.   Each controller can handle up to some maximum
> number of axis and it wold not be until you are over that limit that you'd
> have to split things.  Doing six axis on one controller is reasonable.
> 
> The controller tries its best to hit the target points.  It can happen that
> a target is impossible.  Also, some of ths data can be omitted.  Doing so
> wuld free the controller to do what it "wants".  I think you always want
> x,y,z but could maybe omit the prime (velocity) or double prime
> (acceleration)  This kind of path planning is what LinuxCNC already does,
> but today it is reasonable to push this down into a $5 chip.
> 
> LinuxCNC is originally written used the exact oposite aproach and move all
> the "smarts" upstream into a PC.
> 
> The non-real-time part has to read the g-code or the conversational
> interface or the hand pendant or video data and convert to a stream of
> target points.
> 
> That said, "steps" could work if each one had a time tag.  But that pushes
> the planning upstream and I think the better plan is to move as much
> "smarts" as possible as close to the physical motor as possible.   So let
> the motor driver figure out what rate to drive each otor so the targets are
> reached.
> 
> 
> 
> Alan
> >
> > > From: Chris Albertson 
> > > Subject: Re: [Emc-users] Real-time OS for machine controllers
> > > Date: January 24, 2020 at 9:48:27 AM PST
> > > To: "Enhanced Machine Controller (EMC)"  us...@lists.sourceforge.net
> > >
> > >
> > >
> > > If you can tolerate latency, then your "hub" does not need what we call
> > > "hard" real-time capability.  It only needs to keep up with the average
> > > workload, averaged over whatever latency you can tolerate.  Video
> > streaming
> > > works this way.They can't reliably send video and the 60 Hz frame
> > rate
> > > so they buffer a few seconds of video on your phone and the real-time
> > > viewer lives on the phone  not the server.
> > >
> > > g-code could be the same way.   The penalty is that when you press the
> > "go"
> > > button the milling machine would take a few seconds the start working
> > while
> > > the data buffers into the low-level motor controllers. Today a
> > > step/direction controller has no memory so it must be fed steps in real
> > > time.  But if it has a 10,000 step memory you could just transfer blocks
> > > ever half second and the control

Re: [Emc-users] Real-time OS for machine controllers

[Nicklas SB Karlsson]

Think it deserve to be mentioned since it is a standard available on many servo 
controllers. In CANopen devices can have a FIFO for set reference points, do 
not remember the details but could check if you or anyone else want to know?

In CANopen there is a special SYNC message to stay in SYNC. Do not know the 
accuracy but to make sure all devices use value for same time might be good 
enough or maybe more than good enough. Without syncronization time may start to 
diverge after a few minutes or hours due to clock drift.

To run continously without stop sending device will still be a hard real time 
task since otherwise receiving device may run out of values. If FIFO is 100 
values long periodicity of real time task is however 100 times longer so 
priority could be lowered. Guess there might be problem with GUI response time 
if FIFO is to long. Advantage with FIFO is values could be resent in case 
message is corrupted provided enough bandwidth and mechanism is available for 
this. FIFO will of course also be an advantage if header use a large portion of 
the messsage.


Regards Nicklas Karlsson

> Chris,
> 
> If I send 1 steps to a smart X-axis controller, how does it stay in sync 
> with a smart
> y-axis controller without someone controlling the synchronization between the 
> two?
> 
> Alan
> 
> > From: Chris Albertson 
> > Subject: Re: [Emc-users] Real-time OS for machine controllers
> > Date: January 24, 2020 at 9:48:27 AM PST
> > To: "Enhanced Machine Controller (EMC)" 
> > 
> > 
> > If you can tolerate latency, then your "hub" does not need what we call
> > "hard" real-time capability.  It only needs to keep up with the average
> > workload, averaged over whatever latency you can tolerate.  Video streaming
> > works this way.They can't reliably send video and the 60 Hz frame rate
> > so they buffer a few seconds of video on your phone and the real-time
> > viewer lives on the phone  not the server.
> > 
> > g-code could be the same way.   The penalty is that when you press the "go"
> > button the milling machine would take a few seconds the start working while
> > the data buffers into the low-level motor controllers. Today a
> > step/direction controller has no memory so it must be fed steps in real
> > time.  But if it has a 10,000 step memory you could just transfer blocks
> > ever half second and the controller would work down the queue."Steps"
> > are the wrong kind of data for this but "states" are what is used.
> > 
> > You are correct in that some real-time ability is needed at every level.
> > But we could design things so the requirements are VEY loose at the highest
> > level for 0.5-second latencies being acceptable.   One you need only that,
> > then even an iPhone is a good enough platform.
> > 
> > On Thu, Jan 23, 2020 at 11:32 AM Peter C. Wallace  wrote:
> > 
> >> On Thu, 23 Jan 2020, Chris Albertson wrote:
> >> 
> >>> Date: Thu, 23 Jan 2020 10:17:44 -0800
> >>> From: Chris Albertson 
> >>> Reply-To: "Enhanced Machine Controller (EMC)"
> >>>
> >>> To: "Enhanced Machine Controller (EMC)"  >>> 
> >>> Subject: Re: [Emc-users] Real-time OS for machine controllers
> >>> 
> >>> The trouble with the Mesa FPGA design is that it depends on a computer
> >> with
> >>> good real-time performance.   It can generate steps but I don't thing you
> >>> can run a position or velocity PID control loop on the FPGA.
> >> 
> >> LinuxCNCs design paradigm requires realtime, this is a design decision
> >> that is
> >> supported by our Hostmot2 real time firmware. We have other firmware that
> >> implements motion in the FPGA but this is not suited to LinuxCNCs model.
> >> 
> >> 
> >> You might argue that its an old fashioned model but many high performance
> >> CNC
> >> systems and Robotics controllers use LinuxCNCs model of a capable real
> >> time host
> >> (real OS with file I/O loadable modules, unlimited memory, massive
> >> floating
> >> point performance etc etc) Some of these use Linux and others use real
> >> time
> >> windows varients often with Ethercat Peripherals. This makes for a
> >> powerful
> >> extensible realtime toolkit (like LinuxCNCs HAL) and complex realtime
> >> responsive coordinated motion. Basically for this type of system you still
> >> need a very capable real time controller hub even if the motor controllers
> >> implement torque, ve

Re: [Emc-users] Real-time OS for machine controllers

[Jon Elson]

On 01/24/2020 11:21 PM, R C wrote:

That makes perfect sense   if never anything goes wrong


what if one motor stalls, what if one signal needs to be 
re-transmitted?


If neither of that is corrected...  one axis is off "time 
shifted" relative to the other.


For precision sake, you would need feedback from one axis 
to the other.



In an open-loop step/direction system, there is no way to 
know a stall happened, except to operator hitting the
E-stop button (if he is watching!)  And, after any E-stop, 
you need to rehome the machine.


But, if you have encoder feedback to the CNC control, then 
you can detect stalls and never lose the

axis alignment.

You can't just send 10,000 steps to totally independent 
motor drives, as they will almost certainly not arrive
at the endpoint at the same time (especially if one drive 
gets 10,000 steps and the other gets 4321 steps.)


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Jon Elson]

On 01/25/2020 01:38 AM, John Dammeyer wrote:

I agree there are all sorts of ways of doing this.  Only Peter at MESA or 
perhaps Jon could explain what they do but I don't know if it's proprietary to 
their hardware.
Well, it is not real proprietary.  I can only speak for the 
Pico Systems products.  Yes, as John says, the .ini file 
tells the
trajectory planner all it needs to know about max velocity 
and acceleration for each axis.  So, (assuming correct
configuration) it will never ask for moves the drives cannot 
do. Then, the TP feeds coordinated positions of all axes
to the PID component (or stepgen component for software 
stepping) at the servo thread rate.  Then, for all of my
boards, the encoder counter counts encoders (or with my 
stepper controller in open-loop mode it can count the steps 
issued)
and feeds this back to LinuxCNC at the servo rate.  PID 
calculates a velocity and sends that to the appropriate 
device (step generator, PWM generator or DAC) and the drive 
moves at the desired rate. Repeat every millisecond.


With encoder feedback, you can examine the real drive/axis 
performance with Halscope and find the actual limits of speed
and acceleration.  You can then decide how much to back off 
of these limits and set the MAX_VELOCITY and 
MAX_ACCELERATION ini file parameters accordingly.  This is 
harder to do in an open-loop system.


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[R C]

right,  that is what the situation is now, you would need encoders, 
however, these encoders


now are checked by the machine (linux-cnc) as the situation is now.

On 1/25/20 9:50 AM, Jon Elson wrote:

On 01/24/2020 11:21 PM, R C wrote:

That makes perfect sense   if never anything goes wrong


what if one motor stalls, what if one signal needs to be re-transmitted?

If neither of that is corrected...  one axis is off "time shifted" 
relative to the other.


For precision sake, you would need feedback from one axis to the other.


In an open-loop step/direction system, there is no way to know a stall 
happened, except to operator hitting the
E-stop button (if he is watching!)  And, after any E-stop, you need to 
rehome the machine.


But, if you have encoder feedback to the CNC control, then you can 
detect stalls and never lose the

axis alignment.

You can't just send 10,000 steps to totally independent motor drives, 
as they will almost certainly not arrive
at the endpoint at the same time (especially if one drive gets 10,000 
steps and the other gets 4321 steps.)


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Nicklas SB Karlsson]

> > ...
> In an open-loop step/direction system, there is no way to 
> know a stall happened, except to operator hitting the
> E-stop button (if he is watching!)  And, after any E-stop, 
> you need to rehome the machine.
> 
> But, if you have encoder feedback to the CNC control, then 
> you can detect stalls and never lose the
> axis alignment.
> 
> You can't just send 10,000 steps to totally independent 
> motor drives, as they will almost certainly not arrive
> at the endpoint at the same time (especially if one drive 
> gets 10,000 steps and the other gets 4321 steps.)
> 
> Jon

You need to synchronize them then you could send many points, in doubt 10,000 
steps is a good idea but maybe up to 20 to 50 fifty if sent is used at a rate 
of 1kHz and good response is needed in user interface. For response in user 
interface I assumed queue have to be used up before reaction will happen for 
example then jogging. If messages are sent over Ethernet it make sense to put 
several values in each message since header most probably is relatively large 
compared to values sent.

There should be no problem sending feedback using FIFO except delay though 
there might be a point reducing rate for feedback to message send frequency. 
Feedback with encoder should work but signal will be delayed which most likely 
will be a problem for feedback unless this is done locally in device. If 
following error is checked in Linuxcnc delay need to be added on compared 
signal but it may also be done locally in device. Using feedback in display 
sending at display update rate will obviously be preferred.


Regards Nicklas Karlsson


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Alan Condit]

Chris,

I am just trying to figure out your idea? Who parses the gcode file? The $5
chip?
If you are running everything but the user interface on the $5 chip, it
sounds like headless lcnc to me.

If you are running 6 axis on the $5 chip then you have all the wiring
complexities that we have now. The $5 chip needs to connect to a breakout
board something
like that to protect the chip and it (the $5 chip) needs to be located
someplace where it is convenient to wire all the axises from. So other than
the difference in cost what does this $5 chip buy you?

Alan


> From: Chris Albertson 
> To: "Enhanced Machine Controller (EMC)" 
> Cc:
> Bcc:
> Date: Fri, 24 Jan 2020 21:56:18 -0800
> Subject: Re: [Emc-users] Real-time OS for machine controllers
> On Fri, Jan 24, 2020 at 8:29 PM Alan Condit  wrote:
>
> > Chris,
> >
> > If I send 1 steps to a smart X-axis controller, how does it stay in
> > sync with a smart
> > y-axis controller without someone controlling the synchronization between
> > the two?
> >
>
> As said, "steps" are the wrong thing to send.   What they do is send time,
> tagged points.  Each point has a time tag on it.It is not hard to
> synchronize clocks at the microsecond level.
>
> What they send is a list of target points.Assuming the machine works in
> (x, y, z) space each point, you have "time", (x, y, z) and (x', y', z') and
> (x'', y'', z'').   A machine might have more or fewer axis with different
> names, but same idea.   Each controller can handle up to some maximum
> number of axis and it wold not be until you are over that limit that you'd
> have to split things.  Doing six axis on one controller is reasonable.
>
> The controller tries its best to hit the target points.  It can happen that
> a target is impossible.  Also, some of ths data can be omitted.  Doing so
> wuld free the controller to do what it "wants".  I think you always want
> x,y,z but could maybe omit the prime (velocity) or double prime
> (acceleration)  This kind of path planning is what LinuxCNC already does,
> but today it is reasonable to push this down into a $5 chip.
>
> LinuxCNC is originally written used the exact oposite aproach and move all
> the "smarts" upstream into a PC.
>
> The non-real-time part has to read the g-code or the conversational
> interface or the hand pendant or video data and convert to a stream of
> target points.
>
> That said, "steps" could work if each one had a time tag.  But that pushes
> the planning upstream and I think the better plan is to move as much
> "smarts" as possible as close to the physical motor as possible.   So let
> the motor driver figure out what rate to drive each otor so the targets are
> reached.
>
>
>
> Alan
>
>

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[John Dammeyer]

Let's see if I can sum up this discussion and then I'll be quiet about it.
1.  LinuxCNC runs on PC type hardware generally distributed with WIN-10 and is 
open source and free for download.
a) However there are also PC compatible boxes designed for embedded systems 
but still initially designed for WIN-10 that also work.
b) The Beagle Bone Black hardware is open source which is why the LinuxCNC 
port of MachineKit can run on this platform.
2. LinuxCNC does the user interface, display of tool path, loading of G-Code 
and trajectory planning.
3. LinuxCNC can issue simple step/dir motion at limited speeds on a Parallel 
port if it's included on the CPU motherboard. 
a) not all PC add on parallel port cards have drivers that make the card 
work with LinuxCNC even though they will work with WIN-7 and up.
b) not all PC add on Video cards (or motherboard video) work well with 
LinuxCNC resulting in a latency warning if step rates are too high.
4. LinuxCNC stops being an true open source solution the moment an aftermarket 
hardware step/servo interface board is required.
a) external boards all use different hardware/communication formats so 
there is no pluggable replacement for one compared to another.  
b) if an existing unit fails and the supplier has vanished a different 
incompatible unit is normally required with extensive wiring changes.

The above points suggest that for LinuxCNC to remain an true open source 
solution,  a redesign is required which describes an interface and 
communications format via Ethernet and a target module.  The target module 
would undoubtedly have a 32 bit processor running an RTOS and perhaps even an 
FPGA.  Or maybe a big FPGA with a processor core defined inside it.

But this module would have motor signalling and I/O on the output side with a 
clearly defined TCP/IP protocol on the input side.  Ideally a unit without an 
FPGA but with a 32 bit processor with full source code and schematics would be 
the minimum solution.  Essentially six axis where we have X,Y,Z and A,B plus 
Spindle.  Enough I/O for limit switch,  tool changer control and even an array 
of buttons and a simple display.  Also at a minimum one serial port with 
RS232/485 (jumperable for driver type) with MODbus support and one CAN port 
with CANopen support.  Such a unit could run the machine in a standalone local 
fashion without connection to a PC with simple motion actions.  

And once again this unit should be fully open source with both schematics and 
software.  Needless to say the LinuxCNC software driver would also be open 
source.

Oh and the CANopen side of things would allow it to either be the CANopen 
master running CANopen motors or as a CANopen slave controlled by a CANopen 
master for synchronizing motion over a larger number of systems.

At its simplest though, it would look like a MESA 7i92H looking like two PC 
Parallel ports but not require writing and programming the FPGA to do something 
as simple as switch between a PWM on parallel port pin 14 and a stepgen on pin 
14.

For example:
net spindle-pwm => remoteport.0.pin-14-out
net spindle-pwm <= pwmgen.0.pwm
or
net spindle-step  => remoteport.0.pin-14-out
net spindle-step  <= stepgen.5.step

At the moment with the MESA 7i92H we need:
net spindle-cw  =>  hm2_7i92.0.gpio.005.out
which is pin 14 on the P2 parallel port connection.   

Stepgen.5.step is on the P1 connector and can't be put on the P2 for a simple 
single Parallel Port implementation.  Not without going through the steps to 
reprogram the FPGA file and there is no off the shelf ready to go file that 
will do that.  So one has to learn about FPGAs and how to program them to set 
up one output to be step instead of PWM.  (the direction probably also has to 
be defined for the stepgen)

On MACH3 it's done with a checkbox regardless of whether the output is the 
parallel port on the PC motherboard or the Ethernet Smooth Stepper.   It should 
really be that simple for LinuxCNC.

IMHO
John Dammeyer








___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Stuart Stevenson]

Is Mach 3/4 open source?

On Sat, Jan 25, 2020, 4:56 PM John Dammeyer  wrote:

> Let's see if I can sum up this discussion and then I'll be quiet about it.
> 1.  LinuxCNC runs on PC type hardware generally distributed with WIN-10
> and is open source and free for download.
> a) However there are also PC compatible boxes designed for embedded
> systems but still initially designed for WIN-10 that also work.
> b) The Beagle Bone Black hardware is open source which is why the
> LinuxCNC port of MachineKit can run on this platform.
> 2. LinuxCNC does the user interface, display of tool path, loading of
> G-Code and trajectory planning.
> 3. LinuxCNC can issue simple step/dir motion at limited speeds on a
> Parallel port if it's included on the CPU motherboard.
> a) not all PC add on parallel port cards have drivers that make the
> card work with LinuxCNC even though they will work with WIN-7 and up.
> b) not all PC add on Video cards (or motherboard video) work well with
> LinuxCNC resulting in a latency warning if step rates are too high.
> 4. LinuxCNC stops being an true open source solution the moment an
> aftermarket hardware step/servo interface board is required.
> a) external boards all use different hardware/communication formats so
> there is no pluggable replacement for one compared to another.
> b) if an existing unit fails and the supplier has vanished a different
> incompatible unit is normally required with extensive wiring changes.
>
> The above points suggest that for LinuxCNC to remain an true open source
> solution,  a redesign is required which describes an interface and
> communications format via Ethernet and a target module.  The target module
> would undoubtedly have a 32 bit processor running an RTOS and perhaps even
> an FPGA.  Or maybe a big FPGA with a processor core defined inside it.
>
> But this module would have motor signalling and I/O on the output side
> with a clearly defined TCP/IP protocol on the input side.  Ideally a unit
> without an FPGA but with a 32 bit processor with full source code and
> schematics would be the minimum solution.  Essentially six axis where we
> have X,Y,Z and A,B plus Spindle.  Enough I/O for limit switch,  tool
> changer control and even an array of buttons and a simple display.  Also at
> a minimum one serial port with RS232/485 (jumperable for driver type) with
> MODbus support and one CAN port with CANopen support.  Such a unit could
> run the machine in a standalone local fashion without connection to a PC
> with simple motion actions.
>
> And once again this unit should be fully open source with both schematics
> and software.  Needless to say the LinuxCNC software driver would also be
> open source.
>
> Oh and the CANopen side of things would allow it to either be the CANopen
> master running CANopen motors or as a CANopen slave controlled by a CANopen
> master for synchronizing motion over a larger number of systems.
>
> At its simplest though, it would look like a MESA 7i92H looking like two
> PC Parallel ports but not require writing and programming the FPGA to do
> something as simple as switch between a PWM on parallel port pin 14 and a
> stepgen on pin 14.
>
> For example:
> net spindle-pwm => remoteport.0.pin-14-out
> net spindle-pwm <= pwmgen.0.pwm
> or
> net spindle-step  => remoteport.0.pin-14-out
> net spindle-step  <= stepgen.5.step
>
> At the moment with the MESA 7i92H we need:
> net spindle-cw  =>  hm2_7i92.0.gpio.005.out
> which is pin 14 on the P2 parallel port connection.
>
> Stepgen.5.step is on the P1 connector and can't be put on the P2 for a
> simple single Parallel Port implementation.  Not without going through the
> steps to reprogram the FPGA file and there is no off the shelf ready to go
> file that will do that.  So one has to learn about FPGAs and how to program
> them to set up one output to be step instead of PWM.  (the direction
> probably also has to be defined for the stepgen)
>
> On MACH3 it's done with a checkbox regardless of whether the output is the
> parallel port on the PC motherboard or the Ethernet Smooth Stepper.   It
> should really be that simple for LinuxCNC.
>
> IMHO
> John Dammeyer
>
>
>
>
>
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Dave Matthews]

No.  Commercial software.

On Sat, Jan 25, 2020, 22:41 Stuart Stevenson  wrote:

> Is Mach 3/4 open source?
>
>
>

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[bari]

On 1/25/20 4:41 PM, Alan Condit wrote:
> I am just trying to figure out your idea? Who parses the gcode file? The $5
> chip?
> If you are running everything but the user interface on the $5 chip, it
> sounds like headless lcnc to me.

Yes. But the GUI should not be X. I assume it should be some new modern
web interface that works on any device with a display that has network
connectivity.All the kids are doing it, don't be square  :).

http://wiki.linuxcnc.org/cgi-bin/wiki.pl?EMC_Components

I recall comments from the developers that NML was just a quick way at
the time to connect the GUI to Tasks, IO and Motion control in LinuxCNC.

https://www.nist.gov/publications/neutral-message-language-model-and-method-message-passing-heterogeneous-environments

https://www.nist.gov/system/files/documents/el/isd/cs/nml-tutorial.pdf

http://linuxcnc.org/docs/2.5/html/code/NML_Messages.html

Machinekit replaced NML with Machinetalk:

https://machinekoder.com/machinetalk-explained-part-1-introduction/

I think NML is what turns off new developers.

>
> If you are running 6 axis on the $5 chip then you have all the wiring
> complexities that we have now. The $5 chip needs to connect to a breakout
> board something
> like that to protect the chip and it (the $5 chip) needs to be located
> someplace where it is convenient to wire all the axises from. So other than
> the difference in cost what does this $5 chip buy you?

Yes if the chip was free it would still need lots more glue around it to
interface to the outside world with all its different voltage levels and
noise.


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Erik Christiansen]

On 25.01.20 14:41, Alan Condit wrote:
> If you are running 6 axis on the $5 chip then you have all the wiring
> complexities that we have now.

The $5 chip is ideally suited to a distributed implementation with
simplified wiring - power, high speed serial, and a synchronising clock
to keep axes aligned in time. Yes, the system is misconfigured if motors
can't keep up - reconfigure and fetch another workpiece.

There isn't much point yearning for a $5 chip if it handles more than
one axis, I figure. An additional $5 chip can run the path smarts,
including synchronised motion. Add one more for GUI, disc, and path data
retrieval. It is the only one which is not RT, and would run linux. The
others would run a small RTOS. 

With the serial bus and clock being the API, it could start off simple,
but soon someone would want to add capability negotiation, I guess.

Erik



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Chris Albertson]

Yes it could work that way.  There are Arduino based g-code interpreters.
I have one on my 3D printer.  A 3D printer is a four-axis stepper motor
based machine.  So it is certainly possible to run something like LinuxCNC
on a very low-end chip.  The Arduino uses a 16 Mhz 8-bit chip.

But that is not what I am suggesting.

I'm suggesting the microcontroller gets a set of points in 3D space and the
time to hit each point.   then the controller only has to move the motors
in a synchronized way so as to hit the points, each one at the specified
time. Because the points are time-tagged that can be sent in batches in
non-real time.

The machine that sends the points can read the g-code files or maybe some
other kind of file or maybe it is reading a hand help pendent.  But in
either case, the input is converted to a set of points to be hit at a
spec'd speed.  Because there are time tags on the data the machine that
reads g-code need not be real-time.  Or maybe we called it "very soft"
real-time where one-second latency is acceptable.   This process could run
on a PC or a Mac or maybe even a phone.

The goal is to push ALL, every bit of the hard real-time work onto a small
chip that runs a "real" RTOS.

I did not invent this.  Someone figured it out years ago that if the
commands are time-tagged and queued that the sender is no longer real-time
couped to the device that dequeues and executes the commands.   LinuxCNC
does not do this so we have RT requirements backed up all the way to nearly
every part of the system.




On Sat, Jan 25, 2020 at 2:43 PM Alan Condit  wrote:

> Chris,
>
> I am just trying to figure out your idea? Who parses the gcode file? The $5
> chip?
> If you are running everything but the user interface on the $5 chip, it
> sounds like headless lcnc to me.
>
> If you are running 6 axis on the $5 chip then you have all the wiring
> complexities that we have now. The $5 chip needs to connect to a breakout
> board something
> like that to protect the chip and it (the $5 chip) needs to be located
> someplace where it is convenient to wire all the axises from. So other than
> the difference in cost what does this $5 chip buy you?
>
> Alan
>
>
> > From: Chris Albertson 
> > To: "Enhanced Machine Controller (EMC)"  >
> > Cc:
> > Bcc:
> > Date: Fri, 24 Jan 2020 21:56:18 -0800
> > Subject: Re: [Emc-users] Real-time OS for machine controllers
> > On Fri, Jan 24, 2020 at 8:29 PM Alan Condit 
> wrote:
> >
> > > Chris,
> > >
> > > If I send 1 steps to a smart X-axis controller, how does it stay in
> > > sync with a smart
> > > y-axis controller without someone controlling the synchronization
> between
> > > the two?
> > >
> >
> > As said, "steps" are the wrong thing to send.   What they do is send
> time,
> > tagged points.  Each point has a time tag on it.It is not hard to
> > synchronize clocks at the microsecond level.
> >
> > What they send is a list of target points.Assuming the machine works
> in
> > (x, y, z) space each point, you have "time", (x, y, z) and (x', y', z')
> and
> > (x'', y'', z'').   A machine might have more or fewer axis with different
> > names, but same idea.   Each controller can handle up to some maximum
> > number of axis and it wold not be until you are over that limit that
> you'd
> > have to split things.  Doing six axis on one controller is reasonable.
> >
> > The controller tries its best to hit the target points.  It can happen
> that
> > a target is impossible.  Also, some of ths data can be omitted.  Doing so
> > wuld free the controller to do what it "wants".  I think you always want
> > x,y,z but could maybe omit the prime (velocity) or double prime
> > (acceleration)  This kind of path planning is what LinuxCNC already does,
> > but today it is reasonable to push this down into a $5 chip.
> >
> > LinuxCNC is originally written used the exact oposite aproach and move
> all
> > the "smarts" upstream into a PC.
> >
> > The non-real-time part has to read the g-code or the conversational
> > interface or the hand pendant or video data and convert to a stream of
> > target points.
> >
> > That said, "steps" could work if each one had a time tag.  But that
> pushes
> > the planning upstream and I think the better plan is to move as much
> > "smarts" as possible as close to the physical motor as possible.   So let
> > the motor driver figure out what rate to drive each otor so the targets
> are
> > reached.
> >
> >
> >
> > Alan
> >
> >
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


-- 

Chris Albertson
Redondo Beach, California

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[John Dammeyer]

> -Original Message-
> From: bari [mailto:bari00...@gmail.com]
> Sent: January-25-20 8:32 PM
> To: emc-users@lists.sourceforge.net
> Subject: Re: [Emc-users] Real-time OS for machine controllers
> 
> On 1/25/20 4:41 PM, Alan Condit wrote:
> > I am just trying to figure out your idea? Who parses the gcode file? The $5
> > chip?
> > If you are running everything but the user interface on the $5 chip, it
> > sounds like headless lcnc to me.
> 
> Yes. But the GUI should not be X. I assume it should be some new modern
> web interface that works on any device with a display that has network
> connectivity.All the kids are doing it, don't be square� :).
> 
> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?EMC_Components
> 
> I recall comments from the developers that NML was just a quick way at
> the time to connect the GUI to Tasks, IO and Motion control in LinuxCNC.
> 
> https://www.nist.gov/publications/neutral-message-language-model-and-
> method-message-passing-heterogeneous-environments
> 
> https://www.nist.gov/system/files/documents/el/isd/cs/nml-tutorial.pdf
> 
> http://linuxcnc.org/docs/2.5/html/code/NML_Messages.html
> 
> Machinekit replaced NML with Machinetalk:
> 
> https://machinekoder.com/machinetalk-explained-part-1-introduction/
> 
> I think NML is what turns off new developers.
> 
> >
> > If you are running 6 axis on the $5 chip then you have all the wiring
> > complexities that we have now. The $5 chip needs to connect to a breakout
> > board something
> > like that to protect the chip and it (the $5 chip) needs to be located
> > someplace where it is convenient to wire all the axises from. So other than
> > the difference in cost what does this $5 chip buy you?
> 
> Yes if the chip was free it would still need lots more glue around it to
> interface to the outside world with all its different voltage levels and
> noise.
> 

Looking at http://wiki.linuxcnc.org/uploads/EMCmsg_resize.png 
I see the trajectory planner is tightly coupled to the motion control.  I'd 
suggest that just like we see a Tool Module, Spindle Module etc.,  that the 
Motion Control be separated into a Motion Control and Motion Module.  The 
Trajectory Planner will still be in the real time side of LinuxCNC inside 
Motion Control but the status/command connection will be  to a Motion Module 
which then connects to the motors

The http://wiki.linuxcnc.org/uploads/EMC_Control_LG.gif shows where that break 
could happen inside EMCMOT.

And that will be something like what Chris Albertson suggested.  It certainly 
made sense with 80386 PCs and limited RAM along with unintelligent servo drives 
that the PID loop be closed inside the PC for motion verses encoder feedback.  
But now we have STMBLs among others that will flag a following error fault and 
stop the system in the same way a system that reads the encoder into the PC.  
We have closed loop stepper motors too.

Things have changed.   1GHz 32bit ARM processors with hardware quadrature 
encoder counters.  Running with massive amounts of memory.  So decisions made 
when the PCs were smaller and less power need to be re-examined.  Dedicated 
Gigabit Ethernet linkages can provide messaging far faster than the hardware 
can deal with.

And by moving that into a dedicated board manufactured by any number of 
suppliers, we have the ability to not run into these issues of latency or 
proprietary interfaces.

John Dammeyer



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Andy Pugh]

> On 26 Jan 2020, at 00:56, John Dammeyer  wrote:
> 
> . LinuxCNC stops being an true open source solution the moment an aftermarket 
> hardware step/servo interface board is required.

That rather depends on which board it is. 
The Mesa FPGA code is open-source, and some people have made their own Mesa 
style cards that work with the existing drivers. 
Also, the Mesa smart-serial protocol is open source, which allows the STMBL 
drive to appear as a smart serial peripheral to a host FPGA card. 

The situation with EtherCAT is more complicated. 

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Gene Heskett]

On Sunday 26 January 2020 02:57:28 Andy Pugh wrote:

> > On 26 Jan 2020, at 00:56, John Dammeyer 
> > wrote:
> >
> > . LinuxCNC stops being an true open source solution the moment an
> > aftermarket hardware step/servo interface board is required.
>
> That rather depends on which board it is.
> The Mesa FPGA code is open-source, and some people have made their own
> Mesa style cards that work with the existing drivers. Also, the Mesa
> smart-serial protocol is open source, which allows the STMBL drive to
> appear as a smart serial peripheral to a host FPGA card.
>
With all due respect Andy, smart serial is going to have to grow an error 
correction restart capability. I have had it fail and the only restart 
is a full, count to ten, powerdown on the whole machine, interface and 
computer system before it will recover. I've hit this several times. 

Peter cannot duplicate it but both of my 5i25/7i76D's systems are doing 
it. Seems to be associated with a 100 millisecond power bump from a 
substation voltage regulator or something along those lines. Not long 
enough to reboot any of the computers. I have a shoebox out in the shop 
building running TLM w/o a ups with a 150 day uptime right now. But it 
has only a 5i25 & bobs.

> The situation with EtherCAT is more complicated.

And I think proprietary?
> ___
> 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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[John Dammeyer]

HI Andy,

To be truthful I haven't investigated how open the MESA is.  When it comes to 
hardware I define open source as schematics and firmware.  I don't think PCB 
layouts need to be open.  And unfortunately often open source software is 
written in a way to obfuscate the code.

Probably because I also use Delphi to write Windows applications and it's so 
incredibly easy to create forms with check boxes etc. that command lines and 
complex make files are the hard way to do things.  

But in either case LinuxCNC with a MESA board or MACH with a Smooth Stepper is 
still far less expensive than these:

One can buy a CNC mill in Canada like this one for $27K
https://www.kbctools.com/itemdetail/6-265-006-G23

or the same one with 2 axis DRO for $10K
https://www.kbctools.com/itemdetail/6-265-006-N5

So there's about $15K for ball screws, motors, drivers, and the CNC control.  
The amount MESA charges is trivial relative to the overall costs.  

The ACU-RITE control is way more expensive than a LinuxCNC or MACH3 system.  
https://www.machinetoolproducts.com/acu-rite-millpwr-g2-cnc-console-upgrade-for-millpwr-ii-mp2-2003214-or-642650-01
This lists at $4799

But not to get distracted, let's just define a box that can be a 3 or 4 axis 
DRO, show spindle RPM, control spindle speed and direction along with jogging 
each axis either continuously or in increments.   With an MPG to simulate the 
original hand wheels.  No PC.  Just a display that looks remarkably like a DRO 
display.  And a switch for local remote.

Under remote an Ethernet connection LinuxCNC does the trajectory planning and 
motion commands. 

Under local, a group of buttons create a manual mill with power feed on each 
axis but with far more features like soft limits after homing but no automatic 
features other than perhaps peck drilling.  Power feed for tapping with an 
instant reverse at depth.  In some ways equivalent to a G-Code MACRO.

Most servo drives out there don't support smart serial so although an option 
other methods of control are required.

John Dammeyer.

> -Original Message-
> From: Andy Pugh [mailto:bodge...@gmail.com]
> Sent: January-25-20 11:57 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Real-time OS for machine controllers
> 
> 
> 
> > On 26 Jan 2020, at 00:56, John Dammeyer 
> wrote:
> >
> > . LinuxCNC stops being an true open source solution the moment an
> aftermarket hardware step/servo interface board is required.
> 
> That rather depends on which board it is.
> The Mesa FPGA code is open-source, and some people have made their own
> Mesa style cards that work with the existing drivers.
> Also, the Mesa smart-serial protocol is open source, which allows the STMBL
> drive to appear as a smart serial peripheral to a host FPGA card.
> 
> The situation with EtherCAT is more complicated.
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Peter C. Wallace]

On Sun, 26 Jan 2020, Gene Heskett wrote:


Date: Sun, 26 Jan 2020 03:33:29 -0500
From: Gene Heskett 
Reply-To: "Enhanced Machine Controller (EMC)"

To: emc-users@lists.sourceforge.net
Subject: Re: [Emc-users] Real-time OS for machine controllers

On Sunday 26 January 2020 02:57:28 Andy Pugh wrote:


On 26 Jan 2020, at 00:56, John Dammeyer 
wrote:

. LinuxCNC stops being an true open source solution the moment an
aftermarket hardware step/servo interface board is required.


That rather depends on which board it is.
The Mesa FPGA code is open-source, and some people have made their own
Mesa style cards that work with the existing drivers. Also, the Mesa
smart-serial protocol is open source, which allows the STMBL drive to
appear as a smart serial peripheral to a host FPGA card.


With all due respect Andy, smart serial is going to have to grow an error
correction restart capability. I have had it fail and the only restart
is a full, count to ten, powerdown on the whole machine, interface and
computer system before it will recover. I've hit this several times.

Peter cannot duplicate it but both of my 5i25/7i76D's systems are doing
it. Seems to be associated with a 100 millisecond power bump from a
substation voltage regulator or something along those lines. Not long
enough to reboot any of the computers. I have a shoebox out in the shop
building running TLM w/o a ups with a 150 day uptime right now. But it
has only a 5i25 & bobs.



With all due repect you seem to be the only one (in about 3500 7I76 systems) 
that has this sserial issue. I suspect you may have the 5V jumpering wrong or 
some other generic system issue.






The situation with EtherCAT is more complicated.


And I think proprietary?

___
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)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>


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



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[andy pugh]

On Sun, 26 Jan 2020 at 05:34, bari  wrote:

> I think NML is what turns off new developers.

Most will never need to touch it. I never have, and I have been pretty
deep inside LinuxCNC.

-- 
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, 1912


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Gene Heskett]

On Sunday 26 January 2020 08:36:03 Peter C. Wallace wrote:

> On Sun, 26 Jan 2020, Gene Heskett wrote:
> > Date: Sun, 26 Jan 2020 03:33:29 -0500
> > From: Gene Heskett 
> > Reply-To: "Enhanced Machine Controller (EMC)"
> > 
> > To: emc-users@lists.sourceforge.net
> > Subject: Re: [Emc-users] Real-time OS for machine controllers
> >
> > On Sunday 26 January 2020 02:57:28 Andy Pugh wrote:
> >>> On 26 Jan 2020, at 00:56, John Dammeyer 
> >>> wrote:
> >>>
> >>> . LinuxCNC stops being an true open source solution the moment an
> >>> aftermarket hardware step/servo interface board is required.
> >>
> >> That rather depends on which board it is.
> >> The Mesa FPGA code is open-source, and some people have made their
> >> own Mesa style cards that work with the existing drivers. Also, the
> >> Mesa smart-serial protocol is open source, which allows the STMBL
> >> drive to appear as a smart serial peripheral to a host FPGA card.
> >
> > With all due respect Andy, smart serial is going to have to grow an
> > error correction restart capability. I have had it fail and the only
> > restart is a full, count to ten, powerdown on the whole machine,
> > interface and computer system before it will recover. I've hit this
> > several times.
> >
> > Peter cannot duplicate it but both of my 5i25/7i76D's systems are
> > doing it. Seems to be associated with a 100 millisecond power bump
> > from a substation voltage regulator or something along those lines.
> > Not long enough to reboot any of the computers. I have a shoebox out
> > in the shop building running TLM w/o a ups with a 150 day uptime
> > right now. But it has only a 5i25 & bobs.
>
> With all due repect you seem to be the only one (in about 3500 7I76
> systems) that has this sserial issue. I suspect you may have the 5V
> jumpering wrong or some other generic system issue.

I think so too Peter. But being a CET, I'm in the waiting for the other 
shoe to drop mode. Need more clues than I have ATM.

Somehow, I'm leaning toward some theory that an incomplete powerdown when 
exiting linuxcnc itself is somehow related. Is shutting off the 5v from 
the 5i25 even possible short of moving its jumpers? p2's power is off of 
course as its a normal SainSmart bob and not equipt to take parport 
cable power so it has its own supply in the interface box, but 5i25-p3 
is on, thats been checked. But there could be a cross connection in the 
interface box between its 5 volts for the bob on p2, and the 5 volts to 
the 7i76D. Is there a jumper that might connect the 5 volts from the 12 
volt field power due to a misset jumper in the middle of the 7i76D, and 
thats preventing the reset? Unplugging the power to the interface box 
doesn't fix it.

IDK, but I'll certainly check the next time I have my hands on the 7i76 
docs. Right today I've spent the morning rebuilding my rpi4 stuff and 
posting it. Much smaller rt kernel as I turned off everything in the 
kernel config that not needed for a pi. Contemplating building a tarball 
via the install scripts and just publishing that as it would be 2% of 
the size of a built kernel image,  Rarely "nothing" to do here, even if 
its just bagging up the bed-pan from the Missus.


> >> The situation with EtherCAT is more complicated.
> >
> > And I think proprietary?
> >
> >> ___
> >> 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)
> > If we desire respect for the law, we must first make the law
> > respectable. - Louis D. Brandeis
> > Genes Web page <http://geneslinuxbox.net:6309/gene>
> >
> >
> > ___
> > 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.
>
>
>
> ___
> 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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Jon Elson]

On 01/26/2020 03:10 AM, John Dammeyer wrote:

One can buy a CNC mill in Canada like this one for $27K
https://www.kbctools.com/itemdetail/6-265-006-G23



Have you looked at Acorn CNC ?
https://www.centroidcnc.com/centroid_diy/acorn_cnc_controller.html

It is an amazingly inexpensive commercial controller based 
on the Beagle Bone.  I don't know
if they have a LinuxCNC/Machinekit port under the hood, but 
I kind of suspect it might be.


It is now $300, just add your own stepper drives.

Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Jon Elson]

On 01/26/2020 09:10 AM, andy pugh wrote:

On Sun, 26 Jan 2020 at 05:34, bari  wrote:


I think NML is what turns off new developers.

Most will never need to touch it. I never have, and I have been pretty
deep inside LinuxCNC.

NML has some inefficiencies, but does what is needed for 
single-node systems.  The place it breaks down,
and why the machinekit group worked to replace it, is that 
is becomes very resource-intensive when
you try to share the internal state of LinuxCNC across a 
network. This is because the system state is
a single unified chunk of memory.  The Machinekit folks used 
Zero MQ to make it possible for remote
processes to only receive the specific data structures they 
request, vastly reducing network overhead.
Their goal was to be able to make very complicated workcells 
with multiple robots passing through shared

3D spaces without interference.

But, for a single 3-5 axis machine running ordinary G-code, 
NML still works OK.


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[John Dammeyer]

> -Original Message-
> From: Jon Elson [mailto:el...@pico-systems.com]
> Sent: January-26-20 9:17 AM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Real-time OS for machine controllers
> 
> On 01/26/2020 03:10 AM, John Dammeyer wrote:
> > One can buy a CNC mill in Canada like this one for $27K
> > https://www.kbctools.com/itemdetail/6-265-006-G23
> >
> >
> Have you looked at Acorn CNC ?
> https://www.centroidcnc.com/centroid_diy/acorn_cnc_controller.html
> 
> It is an amazingly inexpensive commercial controller based
> on the Beagle Bone.  I don't know
> if they have a LinuxCNC/Machinekit port under the hood, but
> I kind of suspect it might be.
> 
> It is now $300, just add your own stepper drives.
> 
> Jon
Haven't look at that site in years.  Really quite nice what they provide as 
turnkey solutions.   The beagle bone can also be developed using the TI IDE and 
not even have Linux on it.  Given that the user interface runs on WIN-10 it's 
not likely to have LinuxCNC under the hood but the Beagle as a hardware 
platform that is fully open source makes for a nice $50 controller board with 
the two PRUs.  They are using the BB Green.  I forget off hand what the 
difference is with the BB Black.

The add on prices for software do look like you might eventually spend well 
over $1000.  OTOH, my Altium PCB design software cost more than that as does 
the Embarcadero RAD studio for Delphi and C++.  And AlibreCAD and AlibreCAM are 
now well over that too.  So the Centroid appears to be a good turnkey solution. 
 Probably better than MACH4 for a windows platform but also more expensive.  

And of course your stuff or Peters also end up costing far less.  And you don't 
have to use WIN-10 which is probably the best part.  The down side is you have 
to use Linux.  Ha ha.

John Dammeyer
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[N]

rtems could without doubt be worth a try but have only used FreeRTOS and it 
work.

FreerRTOS usually run scheduler at 1kHz and using one of the newer Micro 
controllers like Cortex-Mx which is a very common CPU in these with prioritized 
interrupts for higher priorities work really well. There is also support 
calling some of the functions from within interrupts but not all since they are 
not allowed to block.

It might be this prioritized interrupt controller may make FreeRTOS work really 
well since then interrupts could be assigned a priority so that they are 
correctly scheduled and guess this is not the case on an ordinary computer.


Guess NML would be a better choice for remote display.


> FreeRTOS sure is popular.  Have you compared it to other open source
> Posix standard real-time OS's such as NuttX and RTEMS?
> 
> http://www.nuttx.org/
> 
> http://rtems.com/
> 
> Any thoughts? I haven't worked with any real-time OS's much since the
> 80-90's.
> 
> 
> On 1/21/20 2:22 PM, Chris Albertson wrote:
> > Doing a fresh start in 2020, I'd pick a 32-bit microcontroller platform and
> > then a "hard" real-time OS that is portable over a wide rand of 32-bit
> > microcontrollers.   FreeRTOS would be a example of this.  See
> > https://en.wikipedia.org/wiki/FreeRTOS
> > These OSes are nothing at all like Linux.  They have no user interface and
> > are linked with the application.
> 
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[John Dammeyer]

Here's a copy of an email I received about the Open-Source Licensing Now 
Available for Micrium µC/ RTOS
I haven't used this one but maybe they were losing ground to the Free RTOS?

John


=
During the following weeks, Silicon Labs will transition the µC/ components to 
an open-source license model.  
By adopting permissive license terms for the µC/ components, we will make the 
benefits of this software available to the widest user base possible and give 
the embedded community a role in future development efforts.  
Please note: This licensing change does not affect our exclusive Micrium OS 
software available to developers through Simplicity Studio. Although it’s not 
open source, Micrium OS can be used commercially on Silicon Labs’ EFR32 
wireless SoCs and EFM32 microcontrollers (MCUs) with no licensing fees. 
We want to ensure a smooth transition to open-source terms for all licensees of 
the µC/ software. We will continue to provide technical support for customers 
with valid maintenance agreements. We are also working closely with partners 
who may offer similar support agreements in the near future.   
The new open-source license model will go into effect on February 28, 2020. 
Customers currently considering a license or maintenance renewal for any of the 
µC/ software components (µC/OS-II, µC/OS-III, µC/FS, µC/TCP-IP, µC/USB-Device, 
µC/USB-Host, µC/CAN, and µC/Modbus) have two options: 
1.  Submit a PO for the µC/ part numbers until February 7. Any purchases 
made during this period will include technical support through the end of 2020. 
  
2.  Once the new licensing terms for the µC/ components are in place, you 
may obtain the software at no cost for commercial use (without technical 
support from Silicon Labs)
==


> -Original Message-
> From: N [mailto:nicklas.karlsso...@gmail.com]
> Sent: January-28-20 11:55 AM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Real-time OS for machine controllers
> 
> rtems could without doubt be worth a try but have only used FreeRTOS and
> it work.
> 
> FreerRTOS usually run scheduler at 1kHz and using one of the newer Micro
> controllers like Cortex-Mx which is a very common CPU in these with
> prioritized interrupts for higher priorities work really well. There is also
> support calling some of the functions from within interrupts but not all since
> they are not allowed to block.
> 
> It might be this prioritized interrupt controller may make FreeRTOS work
> really well since then interrupts could be assigned a priority so that they 
> are
> correctly scheduled and guess this is not the case on an ordinary computer.
> 
> 
> Guess NML would be a better choice for remote display.
> 
> 
> > FreeRTOS sure is popular.  Have you compared it to other open source
> > Posix standard real-time OS's such as NuttX and RTEMS?
> >
> > http://www.nuttx.org/
> >
> > http://rtems.com/
> >
> > Any thoughts? I haven't worked with any real-time OS's much since the
> > 80-90's.
> >
> >
> > On 1/21/20 2:22 PM, Chris Albertson wrote:
> > > Doing a fresh start in 2020, I'd pick a 32-bit microcontroller platform 
> > > and
> > > then a "hard" real-time OS that is portable over a wide rand of 32-bit
> > > microcontrollers.   FreeRTOS would be a example of this.  See
> > > https://en.wikipedia.org/wiki/FreeRTOS
> > > These OSes are nothing at all like Linux.  They have no user interface and
> > > are linked with the application.
> >
> >
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[Chris Albertson]

 would not worry too much about who's RTOS you use.   The concepts are
universal.  First you come up with a high-level design and work out the
interfaces then you need to decide how wide of a range of hardware you need
to support.  Then do some prototyping.   You will very quickly have your
list down to a small handful.

People always get hung up on tools.That is not what matters.  What
matters is the high level system architecture and how you design the
interfaces between the parts.

You can't even choose a microcontroller until this is worked out.







On Tue, Jan 28, 2020 at 5:40 PM John Dammeyer 
wrote:

> Here's a copy of an email I received about the Open-Source Licensing Now
> Available for Micrium µC/ RTOS
> I haven't used this one but maybe they were losing ground to the Free RTOS?
>
> John
>
>
> =
> During the following weeks, Silicon Labs will transition the µC/
> components to an open-source license model.
> By adopting permissive license terms for the µC/ components, we will make
> the benefits of this software available to the widest user base possible
> and give the embedded community a role in future development efforts.
> Please note: This licensing change does not affect our exclusive Micrium
> OS software available to developers through Simplicity Studio. Although
> it’s not open source, Micrium OS can be used commercially on Silicon Labs’
> EFR32 wireless SoCs and EFM32 microcontrollers (MCUs) with no licensing
> fees.
> We want to ensure a smooth transition to open-source terms for all
> licensees of the µC/ software. We will continue to provide technical
> support for customers with valid maintenance agreements. We are also
> working closely with partners who may offer similar support agreements in
> the near future.
> The new open-source license model will go into effect on February 28,
> 2020. Customers currently considering a license or maintenance renewal for
> any of the µC/ software components (µC/OS-II, µC/OS-III, µC/FS, µC/TCP-IP,
> µC/USB-Device, µC/USB-Host, µC/CAN, and µC/Modbus) have two options:
> 1.  Submit a PO for the µC/ part numbers until February 7. Any
> purchases made during this period will include technical support through
> the end of 2020.
> 2.  Once the new licensing terms for the µC/ components are in place,
> you may obtain the software at no cost for commercial use (without
> technical support from Silicon Labs)
> ==
>
>
> > -Original Message-
> > From: N [mailto:nicklas.karlsso...@gmail.com]
> > Sent: January-28-20 11:55 AM
> > To: Enhanced Machine Controller (EMC)
> > Subject: Re: [Emc-users] Real-time OS for machine controllers
> >
> > rtems could without doubt be worth a try but have only used FreeRTOS and
> > it work.
> >
> > FreerRTOS usually run scheduler at 1kHz and using one of the newer Micro
> > controllers like Cortex-Mx which is a very common CPU in these with
> > prioritized interrupts for higher priorities work really well. There is
> also
> > support calling some of the functions from within interrupts but not all
> since
> > they are not allowed to block.
> >
> > It might be this prioritized interrupt controller may make FreeRTOS work
> > really well since then interrupts could be assigned a priority so that
> they are
> > correctly scheduled and guess this is not the case on an ordinary
> computer.
> >
> >
> > Guess NML would be a better choice for remote display.
> >
> >
> > > FreeRTOS sure is popular.  Have you compared it to other open source
> > > Posix standard real-time OS's such as NuttX and RTEMS?
> > >
> > > http://www.nuttx.org/
> > >
> > > http://rtems.com/
> > >
> > > Any thoughts? I haven't worked with any real-time OS's much since the
> > > 80-90's.
> > >
> > >
> > > On 1/21/20 2:22 PM, Chris Albertson wrote:
> > > > Doing a fresh start in 2020, I'd pick a 32-bit microcontroller
> platform and
> > > > then a "hard" real-time OS that is portable over a wide rand of
> 32-bit
> > > > microcontrollers.   FreeRTOS would be a example of this.  See
> > > > https://en.wikipedia.org/wiki/FreeRTOS
> > > > These OSes are nothing at all like Linux.  They have no user
> interface and
> > > > are linked with the application.
> > >
> > >
> > >
> > > ___
> > > Emc-users mailing list
> > > Emc-users@lists.sourcef

Re: [Emc-users] Real-time OS for machine controllers

[John Dammeyer]

Thought I'd maybe ask a question that I think is relevant to this discussion.

First some background.
I've been using both licensed Light-O-Rama and the free VIXEN light show 
software.  Back when I bought Light-O-Rama Vixen wasn't really available yet.  
Now it's pretty cool.

For those of you who don't light up their house at Christmas with lights that 
blink in time to music VIXEN is a software program that can send UDP messages 
over Ethernet to a controller that then pulls out 513 bytes and sends them out 
over an RS485 link.  The timing of the break character at the beginning of the 
string of bytes signals the devices out there that this is a new packet.  The 
first byte is the universe number and so multiple universes can co-exist.  Bit 
rate is exactly 250kbps.  Not a normal baud rate.

And the timing can be a bit critical.  Each byte or combination of bytes can 
consist of commands or data like a pan/tilt with a flood lamp.  The message 
data may contain position and lamp colour/intensity.  

Anyway, the software running on the PC broadcasts UDP.  I could just a easily 
be TCP/IP with guaranteed deliver and packet order.  The point is times have 
changed and the need to use some sort of HTML based scripting language isn't 
really as much as a requirement anymore.  The idea of write once, compiler 
anywhere with Lazarus Pascal (similar to Delphi 5) that allows the software 
user interface and trajectory planner to run on one machine and the actual 
motion control on an embedded system with an RTOS. 

Or alternatively if a commercial system was desired Embarcadero's RAD Studio 
with both C++ and Delphi can create amazing graphics centric programs and 
easily and dynamically along with any needed networking and database support.  
Not only that they can target PCs, Apples, Linux, Android and the various kinds 
of tablets just by selecting the target.  And not only the target system but 
with that target's look and feel.So a simple CAD program that can do the 
CAM part and then control a machine linked via Ethernet is entirely within the 
capabilities of what is now available in hardware.

The special driver interface to something like a MESA 7i92H which connects via 
Ethernet could run off this system.  In fact I'm not sure why the PC that I 
have beside the machine couldn't be located in another room other than not 
having physical control over it.  Ie. The loop between buttons attached to the 
7i92H needs to be closed as in the PC program must be running to jog an axis.

So we're back to my original suggestion that a simple machine controller which 
can react to buttons and an MPG for local control but no trajectory planning 
perhaps has an Ethernet connection, not to an HTML application but a dedicated 
application created with a write once compile or run anywhere application.

And a surplus tablet with touch screen that can sit by the machine for more 
sophisticated local control but can be set off line to allow that PC somewhere 
else to run the system lights out.

I'm going to suggest that the UDP or TCP/IP protocol is the heart of this sort 
of system.  Define it correctly to deal with the real time trajectories and 
control and that small embedded system can be tucked into the control cabinet 
while the real system can be anywhere.

John Dammeyer





___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers

[John Dammeyer]

Hi everyone,

https://tinyurl.com/rch38nk

The above link should take you here:

https://www.aliexpress.com/item/440345766.html?spm=a2g0o.detail.114.3.3c1678c9y97TcC&gps-id=pcDetailBottomMoreOtherSeller&scm=1007.13338.128125.0&scm_id=1007.13338.128125.0&scm-url=1007.13338.128125.0&pvid=a170f208-6d9b-4032-ba6d-ea633da3db7b&_t=gps-id:pcDetailBottomMoreOtherSeller,scm-url:1007.13338.128125.0,pvid:a170f208-6d9b-4032-ba6d-ea633da3db7b,tpp_buckets:668%230%23131923%2318_668%23808%234094%23160_668%23888%233325%2319



> So we're back to my original suggestion that a simple machine controller
> which can react to buttons and an MPG for local control but no trajectory
> planning perhaps has an Ethernet connection, not to an HTML application but
> a dedicated application created with a write once compile or run anywhere
> application.
> 
> John Dammeyer
> 

Going way back to this discussion.   I'm not suggesting the purchase of this 
since it's closed architecture.  And to build this here in North America would 
certainly be more than $350 for a 5 axis unit.  But aside from the fact that 
this module can also do G-Code, imagine an Ethernet connection to this that can 
treat this as something similar to one of the MESA (or others) Break Out I/O 
Interfaces and you end up with perhaps the best of both worlds.  A local 
machine controller that lets you work with the hardware in more of a manual 
mode.

But, flip a switch and LinuxCNC can take over with a full screen with graphical 
user interface and tool path.  I would, for example, also put a large 80mm 
diameter MPG knob on this pendant.  I'd go away from the membrane keypad to 
something that was more intuitive for working with the mill in a manual fashion 
- perhaps using two hands while holding onto it, one on the MPG and one for the 
buttons.   Maybe more like remote control boxes for airplanes and module cars.

In a way you could almost call it an intelligent BoB running an RTOS.  With the 
LinuxCNC control it just becomes exactly that.  An intelligent BoB where the 
buttons and knobs now become that pendant you normally plug into the USB port 
of the PC.

John Dammeyer




___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers (Jon Elson)

[Alan Condit]

Jon,

Machinekit has done some very nice things. Where they fall down is they seem to 
have no stable release model. It seems that anybody can change anything and 
there is no fallback to a stable release.

I tried to build Machinekit for the RockPro64 and I ran into changes several 
months old that had broken the system but were undiscovered. The “developers” 
were running on their own systems that compiled and ran without testing the 
current branch. But, there was no way I could find for someone else to check 
out a system that compiled and ran.

Eventually I was able to fix the problems and compile, but, it left me 
wondering about the whole system.

Alan

> From: Jon Elson 
> Subject: Re: [Emc-users] Real-time OS for machine controllers
> Date: January 26, 2020 at 9:22:35 AM PST
> To: "Enhanced Machine Controller (EMC)" 
> 
> 
> On 01/26/2020 09:10 AM, andy pugh wrote:
>> On Sun, 26 Jan 2020 at 05:34, bari  wrote:
>> 
>>> I think NML is what turns off new developers.
>> Most will never need to touch it. I never have, and I have been pretty
>> deep inside LinuxCNC.
>> 
> NML has some inefficiencies, but does what is needed for single-node systems. 
>  The place it breaks down,
> and why the machinekit group worked to replace it, is that is becomes very 
> resource-intensive when
> you try to share the internal state of LinuxCNC across a network. This is 
> because the system state is
> a single unified chunk of memory.  The Machinekit folks used Zero MQ to make 
> it possible for remote
> processes to only receive the specific data structures they request, vastly 
> reducing network overhead.
> Their goal was to be able to make very complicated workcells with multiple 
> robots passing through shared
> 3D spaces without interference.
> 
> But, for a single 3-5 axis machine running ordinary G-code, NML still works 
> OK.
> 
> Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers (Jon Elson)

[Jon Elson]

On 01/26/2020 06:14 PM, Alan Condit wrote:

Jon,

Machinekit has done some very nice things. Where they fall down is they seem to 
have no stable release model. It seems that anybody can change anything and 
there is no fallback to a stable release.

I tried to build Machinekit for the RockPro64 and I ran into changes several 
months old that had broken the system but were undiscovered. The “developers” 
were running on their own systems that compiled and ran without testing the 
current branch. But, there was no way I could find for someone else to check 
out a system that compiled and ran.

Eventually I was able to fix the problems and compile, but, it left me 
wondering about the whole system.


Yes, Machinekit seems to have collapsed.  There is a fully 
workable version from 2-3 years ago, but I can't tell that
there is still any work being done on it.  Which is too 
bad.  On the other hand, I think there is a distro for running
LinuxCNC on the Beagle Bone, and maybe that is the best way 
forward.


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers (Jon Elson)

[Robert Murphy]

I think with Machinekit they seem to be trying to add too much too soon.

From my Boof Head point of view, too many Bells & Whistles to keep the
"Maker Community" interested and the basics have seemed to be neglected.
TBH I could also be wrong on this point.

In saying that I did use Machinekit & a BeagleBone Black with a custom
cape. Tho I did jump to Linuxcnc with a couple Mesa boards as I found
LCNC Community support to be light years ahead of Machinekit.

The Machinekit google seems to be active, but no where near as active as
the various LCNC support channels.


Machinekit has done some very nice things. Where they fall down is
they seem to have no stable release model. It seems that anybody can
change anything and there is no fallback to a stable release.

I tried to build Machinekit for the RockPro64 and I ran into changes
several months old that had broken the system but were undiscovered.
The “developers” were running on their own systems that compiled and
ran without testing the current branch. But, there was no way I could
find for someone else to check out a system that compiled and ran.

Eventually I was able to fix the problems and compile, but, it left
me wondering about the whole system.



Yes, Machinekit seems to have collapsed.  There is a fully workable
version from 2-3 years ago, but I can't tell that
there is still any work being done on it.  Which is too bad.  On the
other hand, I think there is a distro for running
LinuxCNC on the Beagle Bone, and maybe that is the best way forward.

Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers (Jon Elson)

[John Dammeyer]

I set my BBB aside when the Xylotex cape I had forced normally open limit 
switches.  I was then going to use it with my lathe and got started with the 
quadrature encoder 3D printed holder but things stopped there.  

On the mill the surplus PC c/w parallel port was ultimately cheaper than the 
BBB and the cape.  I still needed a monitor, keyboard and mouse and for the BBB 
also a USB hub to connect those.  

And both the cape DB-25 or the PC DB-25 plugged into my break out board.  So 
since the cabinet for the DC Servo and stepper supply could also hold a PC I 
couldn't see a reason for going on with a system that had slow video and with 
the hub and all was kind of messy for wiring.

And there's the rub.  Other than as an experiment is the BBB worth it?  A big 
Bridgeport has the room for a full sized PC.  A small Sherline maybe is better 
with something like a Beagle.   I don't say this lightly.  I have 3 of them.  
Along with the Xylotex, a replicape for 3D printing , several display capes -- 
the manga screen was a total loss with really bad touch screen to make it 
worthless other than as a display, A CAN bus + RS232/485 cape.  Proto board 
capes.  Some of the display capes step on pins that would be used for the 
encoders.  

So for now my Beagles remain in the various boxes.  Perhaps, before the 
hardware is too old I might create that headless ELS for a mill.  One that 
serves as DRO and power feed control and links via Ethernet to a PC that does 
the actual G-Code translation.But for that an RTOS with the TI development 
environment may be more suitable.

John


> -Original Message-
> From: Robert Murphy [mailto:robert.mur...@gmx.com]
> Sent: January-26-20 5:19 PM
> To: emc-users@lists.sourceforge.net
> Subject: Re: [Emc-users] Real-time OS for machine controllers (Jon Elson)
> 
> I think with Machinekit they seem to be trying to add too much too soon.
> 
>  From my Boof Head point of view, too many Bells & Whistles to keep the
> "Maker Community" interested and the basics have seemed to be
> neglected.
> TBH I could also be wrong on this point.
> 
> In saying that I did use Machinekit & a BeagleBone Black with a custom
> cape. Tho I did jump to Linuxcnc with a couple Mesa boards as I found
> LCNC Community support to be light years ahead of Machinekit.
> 
> The Machinekit google seems to be active, but no where near as active as
> the various LCNC support channels.
> 
> >> Machinekit has done some very nice things. Where they fall down is
> >> they seem to have no stable release model. It seems that anybody can
> >> change anything and there is no fallback to a stable release.
> >>
> >> I tried to build Machinekit for the RockPro64 and I ran into changes
> >> several months old that had broken the system but were undiscovered.
> >> The �developers� were running on their own systems that compiled and
> >> ran without testing the current branch. But, there was no way I could
> >> find for someone else to check out a system that compiled and ran.
> >>
> >> Eventually I was able to fix the problems and compile, but, it left
> >> me wondering about the whole system.
> >>
> >>
> > Yes, Machinekit seems to have collapsed.� There is a fully workable
> > version from 2-3 years ago, but I can't tell that
> > there is still any work being done on it.� Which is too bad.� On the
> > other hand, I think there is a distro for running
> > LinuxCNC on the Beagle Bone, and maybe that is the best way forward.
> >
> > Jon
> >
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers (Jon Elson)

[Jon Elson]

On 01/26/2020 08:04 PM, John Dammeyer wrote:

I set my BBB aside when the Xylotex cape I had forced normally open limit 
switches.
The limit switch polarity can be set in software.  In the 
configs file directory, in file

CRAMPS.hal there is this :

# Adjust as needed for your switch polarity
setp bb_gpio.p8.in-08.invert 1
setp bb_gpio.p8.in-07.invert 1
setp bb_gpio.p8.in-10.invert 1
setp bb_gpio.p8.in-09.invert 1
setp bb_gpio.p9.in-11.invert 1
setp bb_gpio.p9.in-13.invert 1

If you change these lines to end in zero, it inverts the 
sensing of the switches.


Jon



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers (Jon Elson)

[Jon Elson]

On 01/26/2020 08:04 PM, John Dammeyer wrote:

Other than as an experiment is the BBB worth it?  A big Bridgeport has the room 
for a full sized PC.  A small Sherline maybe is better with something like a 
Beagle.
Also, there are mini-ITX X-86 motherboards that run LinuxCNC 
very well.  You can get 7" cube boxes for these
with fanless power supplies and an SSD, and they are just 
fine. When you assemble the whole works, though,
they are probably TWICE the price of the Beagle and CRAMPS 
boards.


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers (Jon Elson)

[John Dammeyer]

Hi Jon,

> -Original Message-
> From: Jon Elson [mailto:el...@pico-systems.com]
> Sent: January-26-20 6:14 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Real-time OS for machine controllers (Jon Elson)
> 
> On 01/26/2020 08:04 PM, John Dammeyer wrote:
> > I set my BBB aside when the Xylotex cape I had forced normally open limit
> switches.
> The limit switch polarity can be set in software.  In the
> configs file directory, in file
> CRAMPS.hal there is this :

Unfortunately not.  The signal was wired in hardware so the enable on the level 
translation devices was shut off when the switch was closed to ground.  So a NO 
switch would close signalling not only a limit condition but also shutting off 
all the drivers.  

A NC switch would never allow step pulses out.
John Dammeyer

> 
> # Adjust as needed for your switch polarity
> setp bb_gpio.p8.in-08.invert 1
> setp bb_gpio.p8.in-07.invert 1
> setp bb_gpio.p8.in-10.invert 1
> setp bb_gpio.p8.in-09.invert 1
> setp bb_gpio.p9.in-11.invert 1
> setp bb_gpio.p9.in-13.invert 1
> 
> If you change these lines to end in zero, it inverts the
> sensing of the switches.
> 
> Jon
> 
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers (Jon Elson)

[Jon Elson]

On 01/26/2020 11:09 PM, John Dammeyer wrote:

Hi Jon,


-Original Message-
From: Jon Elson [mailto:el...@pico-systems.com]
Sent: January-26-20 6:14 PM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Real-time OS for machine controllers (Jon Elson)

On 01/26/2020 08:04 PM, John Dammeyer wrote:

I set my BBB aside when the Xylotex cape I had forced normally open limit

switches.
The limit switch polarity can be set in software.  In the
configs file directory, in file
CRAMPS.hal there is this :

Unfortunately not.  The signal was wired in hardware so the enable on the level 
translation devices was shut off when the switch was closed to ground.  So a NO 
switch would close signalling not only a limit condition but also shutting off 
all the drivers.

A NC switch would never allow step pulses out.

Well, clearly this is a design defect in the breakout board, 
NOT a problem with LinuxCNC/Machinekit.

Also makes homing kind of funny.


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers (Jon Elson)

[John Dammeyer]

> >> On 01/26/2020 08:04 PM, John Dammeyer wrote:
> >>> I set my BBB aside when the Xylotex cape I had forced normally open
> limit
> >> switches.
> >> The limit switch polarity can be set in software.  In the
> >> configs file directory, in file
> >> CRAMPS.hal there is this :
> > Unfortunately not.  The signal was wired in hardware so the enable on the
> level translation devices was shut off when the switch was closed to ground.
> So a NO switch would close signalling not only a limit condition but also
> shutting off all the drivers.
> >
> > A NC switch would never allow step pulses out.
> >.
> Well, clearly this is a design defect in the breakout board,
> NOT a problem with LinuxCNC/Machinekit.
> Also makes homing kind of funny.
> 
> 
> Jon
> 
Which is why I went to BC Asset Recovery (Provincial Government Surplus) and 
bought two PCs for $75 each.  At that point it wasn't worth mucking around.  
And to be fair, although Xylotex wondered why I cared about NC or NO switches, 
the cape I have was discontinued and they now have one that is strictly I/O and 
probably way more suitable for MachineKit.  Available for $25 however their 
online ordering only supports US sales and I suspect shipping will cost more 
than the board.  Too bad it's not available through Amazon Prime.  Then I'd get 
it in a couple of days with free shipping.  Ah well...

http://xylotex.netfirms.com/OSCommerce/catalog/index.php?cPath=33&osCsid=399f6b4f8d069f3ae3d3569d71d7839c

And note, although it's still in the works, they are working on an FPGA board 
with 72 I/O

John Dammeyer



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers --> Micrium open source

[N]

Have been looking at Micrium suspect they might be really good.

Tried µC-probe, a really good idea and a really good software to have for real 
time applications but at least the GUI must have been written by a "modern" 
programmer with all newly invented programming paradigms or whatever it is 
called, looked very nice but slow like syrup and did not work well.


> Here's a copy of an email I received about the Open-Source Licensing Now 
> Available for Micrium µC/ RTOS
> I haven't used this one but maybe they were losing ground to the Free RTOS?
> 
> John
> 
> 
> =
> During the following weeks, Silicon Labs will transition the µC/ components 
> to an open-source license model.  
> By adopting permissive license terms for the µC/ components, we will make the 
> benefits of this software available to the widest user base possible and give 
> the embedded community a role in future development efforts.  
> Please note: This licensing change does not affect our exclusive Micrium OS 
> software available to developers through Simplicity Studio. Although it’s not 
> open source, Micrium OS can be used commercially on Silicon Labs’ EFR32 
> wireless SoCs and EFM32 microcontrollers (MCUs) with no licensing fees. 
> We want to ensure a smooth transition to open-source terms for all licensees 
> of the µC/ software. We will continue to provide technical support for 
> customers with valid maintenance agreements. We are also working closely with 
> partners who may offer similar support agreements in the near future.   
> The new open-source license model will go into effect on February 28, 2020. 
> Customers currently considering a license or maintenance renewal for any of 
> the µC/ software components (µC/OS-II, µC/OS-III, µC/FS, µC/TCP-IP, 
> µC/USB-Device, µC/USB-Host, µC/CAN, and µC/Modbus) have two options: 
> 1.Submit a PO for the µC/ part numbers until February 7. Any purchases 
> made during this period will include technical support through the end of 
> 2020.   
> 2.Once the new licensing terms for the µC/ components are in place, you 
> may obtain the software at no cost for commercial use (without technical 
> support from Silicon Labs)
> ==
> 
> 
> > -Original Message-
> > From: N [mailto:nicklas.karlsso...@gmail.com]
> > Sent: January-28-20 11:55 AM
> > To: Enhanced Machine Controller (EMC)
> > Subject: Re: [Emc-users] Real-time OS for machine controllers
> > 
> > rtems could without doubt be worth a try but have only used FreeRTOS and
> > it work.
> > 
> > FreerRTOS usually run scheduler at 1kHz and using one of the newer Micro
> > controllers like Cortex-Mx which is a very common CPU in these with
> > prioritized interrupts for higher priorities work really well. There is also
> > support calling some of the functions from within interrupts but not all 
> > since
> > they are not allowed to block.
> > 
> > It might be this prioritized interrupt controller may make FreeRTOS work
> > really well since then interrupts could be assigned a priority so that they 
> > are
> > correctly scheduled and guess this is not the case on an ordinary computer.
> > 
> > 
> > Guess NML would be a better choice for remote display.
> > 
> > 
> > > FreeRTOS sure is popular.  Have you compared it to other open source
> > > Posix standard real-time OS's such as NuttX and RTEMS?
> > >
> > > http://www.nuttx.org/
> > >
> > > http://rtems.com/
> > >
> > > Any thoughts? I haven't worked with any real-time OS's much since the
> > > 80-90's.
> > >
> > >
> > > On 1/21/20 2:22 PM, Chris Albertson wrote:
> > > > Doing a fresh start in 2020, I'd pick a 32-bit microcontroller platform 
> > > > and
> > > > then a "hard" real-time OS that is portable over a wide rand of 32-bit
> > > > microcontrollers.   FreeRTOS would be a example of this.  See
> > > > https://en.wikipedia.org/wiki/FreeRTOS
> > > > These OSes are nothing at all like Linux.  They have no user interface 
> > > > and
> > > > are linked with the application.


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Real-time OS for machine controllers (do not worry to much)

[N]

>  would not worry too much about who's RTOS you use.   The concepts are
> universal.  First you come up with a high-level design and work out the
> interfaces then you need to decide how wide of a range of hardware you need
> to support.  Then do some prototyping.   You will very quickly have your
> list down to a small handful.
> 
> People always get hung up on tools.That is not what matters.  What
> matters is the high level system architecture and how you design the
> interfaces between the parts.

Agree, what calculator is used does not matter if you do not understand the 
mathematics book in whatever form you happen to read it nowadays.


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users