Re: [Emc-users] Hardware emcmot? Real time delay

[Chris Albertson]

>
> On an STM32 it will probably be less than 4850ns on the highest priority
> interrupt. Others however depends on threads with higher priority. Ideally
> all threads should be known and have an upper bound on execution time then
> it might under correct conditions be possible to calculate beforehand all
> dead lines will be met.t
>

THis is why it can be nearly perfect on the small system, because you CAN
know EVERY thread.   The chip only runs one program.  So you can control
the amount of time you keep interrups disabled.

But then how good is good enough?  What is actualy required?  I think you'd
have to work backwards from machine accuracy requirements.  Let's say "plus
or minus 0.0002 inches is more than good enough then convert that to time.
  So it just might turn out we don't need to care about microseconds.

My first use of Real-Time Linux has to build a digital camera.   We used
software to stabilize the image on the CCD chip by moving the charge on the
chip so as to keep it under the optical image and then to read out the
charge, digitize it and record the data to a file. Needless say we DID
care about microseconds and even nanoseconds.   All the code ran in one
giant loadable kernal module.   So the timing can be VERY good if you
structure the software for that purpose.

On the other hand, it would be cool to see MK run on a $12 device that
connects by USB to any kind of PC runnig whatever OS.   No reason it can't
be done except for some one finding the time.





> ___
> 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] Hardware emcmot? Real time delay

[bari]

Please don't paint yourself into a corner like GRBL and the *duino crowd
with not being able to support closed loop for servos, rigid tapping, 4+
axis, >30fps HD GUI's, etc etc.

On 4/13/19 5:04 PM, Danny Miller wrote:
>
> On 4/13/2019 3:46 PM, Nicklas SB Karlsson wrote:
>>> Even th D-525-MW motherboard? I can latency-test for an hour or 2 on
>>> this
>>> machine I'm building up right now, and not show any worse than 5.1
>>> microseconds for base thread latency, and If I run without that thread,
>>> which I don't use anyway, and the worst case latency is 4850ns.  Thats
>>> right alongside the figures I've seen quoted for the STM-32.
>> On an STM32 it will probably be less than 4850ns on the highest
>> priority interrupt. Others however depends on threads with higher
>> priority. Ideally all threads should be known and have an upper bound
>> on execution time then it might under correct conditions be possible
>> to calculate beforehand all dead lines will be met.
>>
>> Then I last checked real time seems to run really well on ordinary
>> linux with real time kernel. Do anybody know if it is possible to
>> list running real time threads in linux?
>
> I did a calc and got *10ns* latency on a Cortex m7 400MHz, with only
> 2ns of that as actual jitter, which would be avoidable.
>
> Danny
>
>
>
> ___
> 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] Hardware emcmot? Real time delay

[Danny Miller]

On 4/13/2019 3:46 PM, Nicklas SB Karlsson wrote:

Even th D-525-MW motherboard? I can latency-test for an hour or 2 on this
machine I'm building up right now, and not show any worse than 5.1
microseconds for base thread latency, and If I run without that thread,
which I don't use anyway, and the worst case latency is 4850ns.  Thats
right alongside the figures I've seen quoted for the STM-32.

On an STM32 it will probably be less than 4850ns on the highest priority 
interrupt. Others however depends on threads with higher priority. Ideally all 
threads should be known and have an upper bound on execution time then it might 
under correct conditions be possible to calculate beforehand all dead lines 
will be met.

Then I last checked real time seems to run really well on ordinary linux with 
real time kernel. Do anybody know if it is possible to list running real time 
threads in linux?


I did a calc and got *10ns* latency on a Cortex m7 400MHz, with only 2ns 
of that as actual jitter, which would be avoidable.


Danny



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

Re: [Emc-users] Hardware emcmot?

[Nicklas SB Karlsson]

> But any OS needs to disable interrupts to access shared memmory or maybe
> for some IO drivers.

I use to get by without disabling interrupts. Then exchanging data most usually 
the methodI use is to write data in shared memory and use a variable written to 
zero or one to indicate new data is avaiable as this only change one bit 
without reading I expect it to be an atomic operation.

> But if writing motion control on a uP you would not use software to make
> pulses

Correct. Usually there is a builtin in PWM timer with shadow registers updated 
at top and/or bottom of timer at the same time as interrupt is triggered. With 
prioritized interrupt as is available in the Cortex-M-* CPU this should if I 
did not miss anything fulfill the requirements for Rate-monotonic scheduling so 
that it is possible to calculate if all dead lines will be met.


Regards Nicklas Karlsson


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

Re: [Emc-users] Hardware emcmot? Real time delay

[Nicklas SB Karlsson]

> Even th D-525-MW motherboard? I can latency-test for an hour or 2 on this 
> machine I'm building up right now, and not show any worse than 5.1 
> microseconds for base thread latency, and If I run without that thread, 
> which I don't use anyway, and the worst case latency is 4850ns.  Thats 
> right alongside the figures I've seen quoted for the STM-32.

On an STM32 it will probably be less than 4850ns on the highest priority 
interrupt. Others however depends on threads with higher priority. Ideally all 
threads should be known and have an upper bound on execution time then it might 
under correct conditions be possible to calculate beforehand all dead lines 
will be met.

Then I last checked real time seems to run really well on ordinary linux with 
real time kernel. Do anybody know if it is possible to list running real time 
threads in linux?


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

Re: [Emc-users] Hardware emcmot?

[Chris Albertson]

>
>
>
> Even th D-525-MW motherboard? I can latency-test for an hour or 2 on this
> machine I'm building up right now, and not show any worse than 5.1
> microseconds for base thread latency, and If I run without that thread,
> which I don't use anyway, and the worst case latency is 4850ns.  Thats
> right alongside the figures I've seen quoted for the STM-32.
>

I think we might be looking at different numbers.The interrupt latancy
on the uP
is  12 to 17 cycles depending on the chip.Let's assume we run at
100MHz, so
a cycle 10ns.  so that is 120 to 170ns.But I doubt this is what the tool
you are using measures. I think it measure maximum uncertainly
or "jitter" of a loop period. So what it really measures is the time
where the
OS has interrupts disabled.

If you were to run a thread on a timmer-based interrupt on the uP with
no OS loaded the "jitter" would be effectily zero,  Some picoseconds I'd
guess.
But any OS needs to disable interrupts to access shared memmory or maybe
for some IO drivers.

But if writing motion control on a uP you would not use software to make
pulses
so the jitter in the loop is not jitter in the pulses.   the uP (unlike the
Intel x86)
has a"ton" on external, programmable hardware so you can make pulses using
that hardware and have near perfect hardware generated waveforms

Windows security can be "bullet proof". Someone who is very concerned about
someone hacking their CNC miling machine could run their Windows 10
Machine on LAN that is firewalled or even "air gapped" from the Internet.
Or
they could run Windows in a VM. Or they could run Linux or MacOS. or IOS.



>
> > There is nothing special about Linux other than it provided a cheap
> > and easy to get RT OS.
>
> And security. Windows may be improving, but connected directly to the
> net, how long before its owned. I went from amiga to linux in 1998, and
> have not been touched since. That of course includes using another linux
> product, dd-wrt, between my local network, and the network at large on
> the other side of my cable modem.
>
-- 

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] Hardware emcmot?

[Jon Elson]

On 04/12/2019 05:39 AM, Nicklas Karlsson wrote:

I have been thinking in similar paths, there is NML communication between
parts. Then trying to separate I got the impression maybe real time part
work but axis did not work properly. I also get the impression real time
performance have gotten better for ordinary Linux run on ordinary computer
which would make separating less useful but still good.


As far as I know, splitting the mostly-RT part of LinuxCNC 
from the display/interpreter part has been possible since 
the early days of EMC2 with HAL.  But, the NML system in 
LinuxCNC sends a LOT of data back and forth when it may not 
be necessary.  Machinekit changed most of this over to 0mq, 
which creates a global state, and then allows various 
"subscribers" to tell it what specific info they need.  0mq 
then sends ONLY that required info to each subscriber. My 
understanding is the move to 0mq has not been totally 
finished (as of the last I heard) but it did allow much 
greater separation of the many pieces of LinuxCNC onto 
separate computer nodes.  Part of their impetus on this was 
to enable multiple machines in a workcell to be coordinated 
by a central process.


On the other hand, Machinekit works pretty well on a Beagle 
Bone. Yes, the screen and keyboard can sometimes be just a 
little bit laggy, but it seems to be usable.  And, it works 
fine on relatively cheap mini-ITX PC motherboards.


Jon


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

Re: [Emc-users] Hardware emcmot?

[Nicklas Karlsson]

I have been thinking in similar paths, there is NML communication between
parts. Then trying to separate I got the impression maybe real time part
work but axis did not work properly. I also get the impression real time
performance have gotten better for ordinary Linux run on ordinary computer
which would make separating less useful but still good.

Den fre 12 apr. 2019 kl 02:48 skrev bari :

> My dream would be "broadcon" going out of business ending all the Rpi crap.
>
> A big bag of cash falling from the sky over all the LCNC devs homes.
>
> Someone putting effort into 4+ axis open source CAM or other useful
> software.
>
> On 4/11/19 7:42 PM, Danny Miller wrote:
> > Well, what I would ideally picture is a realtime hardware motion
> > controlled coupled to a Raspberry PI running Linux non-RT, the PI is
> > hooked to a PC and has an embedded http server.  At that point you
> > access it via browser and load and control control your job from the
> > PC interface.  estop etc is still on the hardware.  At that point it
> > does not matter if you use Windows or Linux.
> >
> > Danny
> >
> > On 4/11/2019 7:19 PM, bari wrote:
> >> I disagree. The problem is making the machine configuration easy. If
> >> LCNC ran on Winders or Androids, many would still complain about how
> >> difficult it is to configure. Active High vs Low for Limit switches,
> >> Home switches, Step and Dir signals, encoder pulses per rev. etc etc is
> >> far to challenging for many to deal with.
> >>
> >> On 4/11/19 2:41 PM, Chris Albertson wrote:
> >>> If the machine controler could run on a me=aintstream OS (like
> >>> Windows 10)
> >>> and on a normal notebook PC it would be orders of magnitude more
> >>> popular
> >>> and widly used
> >>
> >>
> >> ___
> >> 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
>

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

Re: [Emc-users] Hardware emcmot?

[bari]

My dream would be "broadcon" going out of business ending all the Rpi crap.

A big bag of cash falling from the sky over all the LCNC devs homes.

Someone putting effort into 4+ axis open source CAM or other useful
software.

On 4/11/19 7:42 PM, Danny Miller wrote:
> Well, what I would ideally picture is a realtime hardware motion
> controlled coupled to a Raspberry PI running Linux non-RT, the PI is
> hooked to a PC and has an embedded http server.  At that point you
> access it via browser and load and control control your job from the
> PC interface.  estop etc is still on the hardware.  At that point it
> does not matter if you use Windows or Linux.
>
> Danny
>
> On 4/11/2019 7:19 PM, bari wrote:
>> I disagree. The problem is making the machine configuration easy. If
>> LCNC ran on Winders or Androids, many would still complain about how
>> difficult it is to configure. Active High vs Low for Limit switches,
>> Home switches, Step and Dir signals, encoder pulses per rev. etc etc is
>> far to challenging for many to deal with.
>>
>> On 4/11/19 2:41 PM, Chris Albertson wrote:
>>> If the machine controler could run on a me=aintstream OS (like
>>> Windows 10)
>>> and on a normal notebook PC it would be orders of magnitude more
>>> popular
>>> and widly used
>>
>>
>> ___
>> 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] Hardware emcmot?

[Danny Miller]

Well, what I would ideally picture is a realtime hardware motion 
controlled coupled to a Raspberry PI running Linux non-RT, the PI is 
hooked to a PC and has an embedded http server.  At that point you 
access it via browser and load and control control your job from the PC 
interface.  estop etc is still on the hardware.  At that point it does 
not matter if you use Windows or Linux.


Danny

On 4/11/2019 7:19 PM, bari wrote:

I disagree. The problem is making the machine configuration easy. If
LCNC ran on Winders or Androids, many would still complain about how
difficult it is to configure. Active High vs Low for Limit switches,
Home switches, Step and Dir signals, encoder pulses per rev. etc etc is
far to challenging for many to deal with.

On 4/11/19 2:41 PM, Chris Albertson wrote:

If the machine controler could run on a me=aintstream OS (like Windows 10)
and on a normal notebook PC it would be orders of magnitude more popular
and widly used



___
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] Hardware emcmot?

[bari]

I have been designing with x86 since the early 80's, ARM since the early
90's and several other architectures (Mips, Sparc, Alpha etc) over the
years. I just don't get the recent attraction to moving the realtime out
of the PC and onto ARM. It's lots of work for what actual benefit? This
idea has come up a lot without anyone really putting any effort into it
besides machinekit. But they picked a SOC without a GPU powerful enough
to run a GUI in HD. Does/did one of them work for TI or something?

On 4/10/19 2:01 PM, Sam Sokolik wrote:
> I don't understand the want to move the realtime stuff out of the
> computer.  What shortcoming are you wanting to solve?  I have not had a
> problem with computer hardware performing the real time parts.  Now that
> rt_preempt is getting mainlined into the kernel - it can only get better.
> I have even had quite a few laptops now that perform quite well.  The
> amount of work that would be required to duplicate the flexibility/ease of
> use of motion/hal in hardware would be a ton.
>
> sam
>
> On Wed, Apr 10, 2019 at 1:48 PM andy pugh  wrote:
>
>> On Wed, 10 Apr 2019 at 19:43,  wrote:
>>
>>> Actually I *don't* want to run a form of Linux. Since it's
>> dedicated
>>> HW, the tasks can be hardcoded for bare metal
>> I wonder if the Mesa "SoftDMC" would do what you want?
>>
>>
>> http://store.mesanet.com/index.php?route=product/product=65_id=163
>>
>>
>> --
>> atp
>> "A motorcycle is a bicycle with a pandemonium attachment and is
>> designed for the especial use of mechanical geniuses, daredevils and
>> lunatics."
>> — George Fitch, Atlanta Constitution Newspaper, 1916
>>
>>
>> ___
>> 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] Hardware emcmot?

[bari]

I disagree. The problem is making the machine configuration easy. If
LCNC ran on Winders or Androids, many would still complain about how
difficult it is to configure. Active High vs Low for Limit switches,
Home switches, Step and Dir signals, encoder pulses per rev. etc etc is
far to challenging for many to deal with.

On 4/11/19 2:41 PM, Chris Albertson wrote:
> If the machine controler could run on a me=aintstream OS (like Windows 10)
> and on a normal notebook PC it would be orders of magnitude more popular
> and widly used



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

Re: [Emc-users] Hardware emcmot?

[Gene Heskett]

On Thursday 11 April 2019 15:41:15 Chris Albertson wrote:

> I have to agree,   The entire point of moving al real time functions
> to hardware is so that a real-time OS is no longer required.
>
> The only reason Linux is even needed is that it is an easy way to get
> a real-time OS.   If not for the RT requirement you could use a Mac or
> Windows or even an iPad or any cell phone.
>
> If the machine controler could run on a me=aintstream OS (like Windows
> 10) and on a normal notebook PC it would be orders of magnitude more
> popular and widly used
>
> "EMC" as it was called (then later Linux CNC and then MK) was a great
> idea: Use existing, low cost off the shelf hardware to control a CNC
> machine. This is still a good a very idea but today the existing
> low-cost hardware looks like an STM32 chip and cost about $5.   These
> chips have "compute power" roughly the same as the old PCs EMC was
> developed with.  These little chips are nice to use not just because
> of the price but because there typically come with an RT operating
> system (based on CMSIS)  that has much better RT performance than any
> RT-Linux.
>
Even th D-525-MW motherboard? I can latency-test for an hour or 2 on this 
machine I'm building up right now, and not show any worse than 5.1 
microseconds for base thread latency, and If I run without that thread, 
which I don't use anyway, and the worst case latency is 4850ns.  Thats 
right alongside the figures I've seen quoted for the STM-32.

> There is nothing special about Linux other than it provided a cheap
> and easy to get RT OS.

And security. Windows may be improving, but connected directly to the 
net, how long before its owned. I went from amiga to linux in 1998, and 
have not been touched since. That of course includes using another linux 
product, dd-wrt, between my local network, and the network at large on 
the other side of my cable modem.

> The CMSIS based RTOSes on STM32 are better.   
> I have some experience with both ways and believe by moving to the
> smaller RT system is nearly Arduino-like simplicity and ease of use.  
> I'm using it for robotic motion control now.
>
> On Thu, Apr 11, 2019 at 3:32 AM Les Newell 
>
> wrote:
> > >   Actually I *don't* want to run a form of Linux.
> >
> > I suggested running a Linux variant because it would simplify
> > porting code. Most HAL code only uses a few system calls so you
> > could emulate those calls. IMHO rewriting everything to run on
> > dedicated hardware is a bad idea. Not having compatibility with the
> > main LinuxCNC code base will mean you have to maintain all of the
> > code by yourself. That is a lot of work.
> >
> > > Since it's dedicated
> > > HW, the tasks can be hardcoded for bare metal and stored in flash
> > > and directly load the STEP/DIR pins with SPI data which does
> > > precise, synchronized step-outs.. This is leaner, simpler, more
> > > reliable and the latency can be very low and consistent (although
> > > LinuxCNC on Preempt-RT is already all of that for my machine).
> >
> > If you are just concerned with accurate steps then just move step
> > generation to external hardware. The trajectory planning etc is done
> > at a relatively low speed (usually 1ms intervals) and even a few
> > hundred microseconds of jitter isn't a big deal so there is nothing
> > much to gain in moving this to dedicated hardware. The Ethernet Mesa
> > boards work this way. They use hardware step generation that is
> > updated every 1ms over Ethernet.
> >
> > > This would require somewhat extensive modification of code.
> > > Microcontrollers typically use C and cannot handle C++'s OOP nor
> > > dynamic memory allocation.
> >
> > This is a myth. Even the lowly 8 bit ATMEGA series is fine running
> > OOP C++. Look at Arduino. The majority of that code is C++. Several
> > years ago I wrote a preemptive+cooperative multi tasking real time
> > OS in C++ and it ran well on an ATMEGA. On more memory restricted
> > parts you need to be careful with dynamic memory allocation but it
> > still works as long as you don't go overboard. If you're considering
> > moving emcmot etc to another processor you're gonna need something
> > with considerably more grunt than an ATMEGA anyway.
> >
> > 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)
Genes Web page 



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

Re: [Emc-users] Hardware emcmot?

[Chris Albertson]

I have to agree,   The entire point of moving al real time functions to
hardware is so that a real-time OS is no longer required.

The only reason Linux is even needed is that it is an easy way to get a
real-time OS.   If not for the RT requirement you could use a Mac or
Windows or even an iPad or any cell phone.

If the machine controler could run on a me=aintstream OS (like Windows 10)
and on a normal notebook PC it would be orders of magnitude more popular
and widly used

"EMC" as it was called (then later Linux CNC and then MK) was a great idea:
 Use existing, low cost off the shelf hardware to control a CNC machine.
This is still a good a very idea but today the existing low-cost hardware
looks like an STM32 chip and cost about $5.   These chips have "compute
power" roughly the same as the old PCs EMC was developed with.  These
little chips are nice to use not just because of the price but because
there typically come with an RT operating system (based on CMSIS)  that has
much better RT performance than any RT-Linux.

There is nothing special about Linux other than it provided a cheap and
easy to get RT OS.   The CMSIS based RTOSes on STM32 are better.   I have
some experience with both ways and believe by moving to the smaller RT
system is nearly Arduino-like simplicity and ease of use.   I'm using it
for robotic motion control now.

On Thu, Apr 11, 2019 at 3:32 AM Les Newell 
wrote:

>
> >   Actually I *don't* want to run a form of Linux.
>
> I suggested running a Linux variant because it would simplify porting
> code. Most HAL code only uses a few system calls so you could emulate
> those calls. IMHO rewriting everything to run on dedicated hardware is a
> bad idea. Not having compatibility with the main LinuxCNC code base will
> mean you have to maintain all of the code by yourself. That is a lot of
> work.
>
> > Since it's dedicated
> > HW, the tasks can be hardcoded for bare metal and stored in flash and
> > directly load the STEP/DIR pins with SPI data which does precise,
> > synchronized step-outs.. This is leaner, simpler, more reliable and
> > the latency can be very low and consistent (although LinuxCNC on
> > Preempt-RT is already all of that for my machine).
>
> If you are just concerned with accurate steps then just move step
> generation to external hardware. The trajectory planning etc is done at
> a relatively low speed (usually 1ms intervals) and even a few hundred
> microseconds of jitter isn't a big deal so there is nothing much to gain
> in moving this to dedicated hardware. The Ethernet Mesa boards work this
> way. They use hardware step generation that is updated every 1ms over
> Ethernet.
>
> > This would require somewhat extensive modification of code.
> > Microcontrollers typically use C and cannot handle C++'s OOP nor
> > dynamic memory allocation.
>
> This is a myth. Even the lowly 8 bit ATMEGA series is fine running OOP
> C++. Look at Arduino. The majority of that code is C++. Several years
> ago I wrote a preemptive+cooperative multi tasking real time OS in C++
> and it ran well on an ATMEGA. On more memory restricted parts you need
> to be careful with dynamic memory allocation but it still works as long
> as you don't go overboard. If you're considering moving emcmot etc to
> another processor you're gonna need something with considerably more
> grunt than an ATMEGA anyway.
>
> 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] Hardware emcmot?

[Peter C. Wallace]

On Wed, 10 Apr 2019, dan...@austin.rr.com wrote:


Date: Wed, 10 Apr 2019 20:39:06 +
From: dan...@austin.rr.com
Reply-To: "Enhanced Machine Controller (EMC)"

To: "'Enhanced Machine Controller (EMC)'" 
Cc: "'Enhanced Machine Controller (EMC)'" 
Subject: Re: [Emc-users] Hardware emcmot?

From: "andy pugh"
To: "Enhanced Machine Controller (EMC)"
Cc:
Sent: Wednesday April 10 2019 1:46:17PM
Subject: Re: [Emc-users] Hardware emcmot?

On Wed, 10 Apr 2019 at 19:43,  wrote:

> Actually I *don't* want to run a form of Linux. Since it's
dedicated
> HW, the tasks can be hardcoded for bare metal

I wonder if the Mesa "SoftDMC" would do what you want?

-

Hmm maybe so!

Although it is key to modulate beam power at ~5KHz scaled with the
reciprocal of the instantaneous velocity and an accompanying motion
command param. Not the motion command target feedrate but the
instantaneous velocity after acceleration curves are applied. This
prevents burning more energy per inch than specified during accel
periods.

The vector sum is easy to sum squares, but then you have reciprocal
of the square root to create. You know, it doesn't have to be perfect,
I wonder if a polynomial for reciprocal-of-square-root would suffice?
Much faster esp since multiplying 32 bit numbers could in theory
overflow a 32 bit reg (although the velocity to do that seems
unreasonable).

The same is true of any solution, except the bulk 98% of the base
requirement tasks are already there. No nontrapezoidal accel.

There seems to be a lack of arc blending though, and I've seem the
result of poor trajectory planning on certain laser-cut files. Ones
that have like 1000 linear motion commands per inch (that number might
be hyperbole) and poor path smoothing, I think due to pixellation
causing irrelevant right-angle turns for only a few thousandth of an
inch. It ran *really* slow on something that was actually not a whole
lot of exceptionally high detail. Some of that could be path smoothing
approximated in the CAM stage.

Danny

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




I notice that you ordered a copy of SoftDMC from our webstore. I suspect This 
is not the best way to accomplish laser modulation with LinuxCNC


If you use our hardware, I think the best way would be to use our DataPainter
module for Hostmot2. Unfortunately this does not have a driver yet but could 
be accessed via raw register access in a real time hal component


This implements a FIFOed data stream (bitstream or PWM) that can be "position 
locked" to a motion axis or a multi-axis length vector for arbitrary path 
painting. In addition it has front-end (realtime) scaling of the PWM so that
PWM duty cycle is the product of FIFO PWM data times real time (probably 
scaled/lincurved velocity) data.


The 1 KHz or so servo thread update rate is not a real limitation here since 
the data painting interpolates between motions (possibly scale) waypoints


Its addition it has start and stop position registers to allow gating the data 
stream at position breakpoints



This will support modulation rates to the hundreds of KHz


Misssing bits in LinuxCNC are some standard scheme to include position
synchronized data either embedded in the gcode or via external files



Peter Wallace
Mesa Electronics


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

Re: [Emc-users] Hardware emcmot?

[Les Newell]

Actually I *don't* want to run a form of Linux.


I suggested running a Linux variant because it would simplify porting 
code. Most HAL code only uses a few system calls so you could emulate 
those calls. IMHO rewriting everything to run on dedicated hardware is a 
bad idea. Not having compatibility with the main LinuxCNC code base will 
mean you have to maintain all of the code by yourself. That is a lot of 
work.



Since it's dedicated
HW, the tasks can be hardcoded for bare metal and stored in flash and
directly load the STEP/DIR pins with SPI data which does precise,
synchronized step-outs.. This is leaner, simpler, more reliable and
the latency can be very low and consistent (although LinuxCNC on
Preempt-RT is already all of that for my machine).


If you are just concerned with accurate steps then just move step 
generation to external hardware. The trajectory planning etc is done at 
a relatively low speed (usually 1ms intervals) and even a few hundred 
microseconds of jitter isn't a big deal so there is nothing much to gain 
in moving this to dedicated hardware. The Ethernet Mesa boards work this 
way. They use hardware step generation that is updated every 1ms over 
Ethernet.



This would require somewhat extensive modification of code.
Microcontrollers typically use C and cannot handle C++'s OOP nor
dynamic memory allocation.


This is a myth. Even the lowly 8 bit ATMEGA series is fine running OOP 
C++. Look at Arduino. The majority of that code is C++. Several years 
ago I wrote a preemptive+cooperative multi tasking real time OS in C++ 
and it ran well on an ATMEGA. On more memory restricted parts you need 
to be careful with dynamic memory allocation but it still works as long 
as you don't go overboard. If you're considering moving emcmot etc to 
another processor you're gonna need something with considerably more 
grunt than an ATMEGA anyway.


Les


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

Re: [Emc-users] Hardware emcmot?

[dannym]

From: "andy pugh" 
To: "Enhanced Machine Controller (EMC)"
Cc: 
Sent: Wednesday April 10 2019 1:46:17PM
Subject: Re: [Emc-users] Hardware emcmot?

On Wed, 10 Apr 2019 at 19:43,  wrote:

 > Actually I *don't* want to run a form of Linux. Since it's
dedicated
 > HW, the tasks can be hardcoded for bare metal

 I wonder if the Mesa "SoftDMC" would do what you want?

-

Hmm maybe so!

Although it is key to modulate beam power at ~5KHz scaled with the
reciprocal of the instantaneous velocity and an accompanying motion
command param. Not the motion command target feedrate but the
instantaneous velocity after acceleration curves are applied. This
prevents burning more energy per inch than specified during accel
periods. 

The vector sum is easy to sum squares, but then you have reciprocal
of the square root to create. You know, it doesn't have to be perfect,
I wonder if a polynomial for reciprocal-of-square-root would suffice?
Much faster esp since multiplying 32 bit numbers could in theory
overflow a 32 bit reg (although the velocity to do that seems
unreasonable).

The same is true of any solution, except the bulk 98% of the base
requirement tasks are already there. No nontrapezoidal accel.

There seems to be a lack of arc blending though, and I've seem the
result of poor trajectory planning on certain laser-cut files. Ones
that have like 1000 linear motion commands per inch (that number might
be hyperbole) and poor path smoothing, I think due to pixellation
causing irrelevant right-angle turns for only a few thousandth of an
inch. It ran *really* slow on something that was actually not a whole
lot of exceptionally high detail. Some of that could be path smoothing
approximated in the CAM stage.

Danny

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

Re: [Emc-users] Hardware emcmot?

[Ralph Stirling]

That is the direction the Machinekit fork of Linuxcnc has
been going.  They have successfully created a machinekit-hal
system and a machinekit-cnc that communicates with it.
Haven't used it much in a few years, but do read their email
list.

-- Ralph

From: Danny Miller [dan...@austin.rr.com]
Sent: Wednesday, April 10, 2019 9:10 AM
To: emc-users@lists.sourceforge.net
Subject: [Emc-users] Hardware emcmot?

I have been wondering- can emcmot be separated from the HAl and emctask
and become a true dedicated realtime stage to control the joints?

The shared memory FIFOs could be replaced with like an ethernet link to
the hardware RAM.  You'd probably load a DMA buffer and just let it
flow, there's some minor latency but there's not a realtime requirement.

There are cheap high freq MCUs with single-cycle hardware double
multiply/add and gobs of memory.  It would have to be coded in non-OOP C
and I greatly prefer hardware interrupt-driven strategies over RTOS.

Danny






___
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] Hardware emcmot?

[Sam Sokolik]

I don't understand the want to move the realtime stuff out of the
computer.  What shortcoming are you wanting to solve?  I have not had a
problem with computer hardware performing the real time parts.  Now that
rt_preempt is getting mainlined into the kernel - it can only get better.
I have even had quite a few laptops now that perform quite well.  The
amount of work that would be required to duplicate the flexibility/ease of
use of motion/hal in hardware would be a ton.

sam

On Wed, Apr 10, 2019 at 1:48 PM andy pugh  wrote:

> On Wed, 10 Apr 2019 at 19:43,  wrote:
>
> > Actually I *don't* want to run a form of Linux. Since it's
> dedicated
> > HW, the tasks can be hardcoded for bare metal
>
> I wonder if the Mesa "SoftDMC" would do what you want?
>
>
> http://store.mesanet.com/index.php?route=product/product=65_id=163
>
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1916
>
>
> ___
> 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] Hardware emcmot?

[andy pugh]

On Wed, 10 Apr 2019 at 19:43,  wrote:

> Actually I *don't* want to run a form of Linux. Since it's dedicated
> HW, the tasks can be hardcoded for bare metal

I wonder if the Mesa "SoftDMC" would do what you want?

http://store.mesanet.com/index.php?route=product/product=65_id=163


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


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

Re: [Emc-users] Hardware emcmot?

[dannym]

From: dan...@austin.rr.com
To: "Les Newell"
Cc: 
Sent: Wednesday April 10 2019 1:33:31PM
Subject: Re: [Emc-users] Hardware emcmot?

From: "Les Newell" 
To: "Danny Miller"
Cc: 
Sent: Wednesday April 10 2019 12:55:14PM
Subject: Re: [Emc-users] Hardware emcmot?

Moving just emcmot is not really practical but moving the whole
realtime 
 side to another processor shouldn't be too hard. If I remember
correctly 
 the CMS/NML communication subsystem already has network
functionality. 
 Of course in that case you'd probably need your external processor to
be 
 running some sort of Linux.

 Les

 On 10/04/2019 17:10, Danny Miller wrote:
 > I have been wondering- can emcmot be separated from the HAl and 
 > emctask and become a true dedicated realtime stage to control the
joints?
 >
 > The shared memory FIFOs could be replaced with like an ethernet
link 
 > to the hardware RAM. You'd probably load a DMA buffer and just let
it 
 > flow, there's some minor latency but there's not a realtime
requirement.
 >
 > There are cheap high freq MCUs with single-cycle hardware double 
 > multiply/add and gobs of memory. It would have to be coded in
non-OOP 
 > C and I greatly prefer hardware interrupt-driven strategies over
RTOS.
 >
 > Danny 

-

Actually I *don't* want to run a form of Linux. Since it's dedicated
HW, the tasks can be hardcoded for bare metal and stored in flash and
directly load the STEP/DIR pins with SPI data which does precise,
synchronized step-outs.. This is leaner, simpler, more reliable and
the latency can be very low and consistent (although LinuxCNC on
Preempt-RT is already all of that for my machine).

This would require somewhat extensive modification of code.
Microcontrollers typically use C and cannot handle C++'s OOP nor
dynamic memory allocation. However, static mem allocation should be
fine and, like I say, faster and lower latency. Converting objects to
non-OOP code is usually pretty straightforward.

Danny



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

Re: [Emc-users] Hardware emcmot?

[dannym]

From: "andy pugh" 
To: "Enhanced Machine Controller (EMC)"
Cc: 
Sent: Wednesday April 10 2019 1:12:04PM
Subject: Re: [Emc-users] Hardware emcmot?

On Wed, 10 Apr 2019 at 18:19, Danny Miller  wrote:

 > http://wiki.linuxcnc.org/cgi-bin/wiki.pl?EMC_Components
 /> >
 > Shows EMCMOT as a discrete module, and emcmot.c and emcmot.h are
 > supposed to be discrete files. The motor PWMs and switch IO is
under
 > the realtime veil, which is easy to integrate into hw.

 Note that that page was last edited 12 years ago, and is based on an
 earlier page describing EMC1.
 The information there actually dates back to before there was a
HAL

 As far as I can tell motion is made up of all the files in the motion
folder.
 motion.c mainly creates hal pins and exports that hal function that
is
 called periodically by realtime:

 But I might be misunderstanding what you want to do. If you want to
 move motion into a different CPU then it probably could be done, by
 making a HAL interface that duplicates the HAL interface of motmod.
 (the pin names would not have to be the same)
 The Mesa and Pico cards already do this. HAL pins are given values,
 and those values are sent to an FPGA, by various methods (PCI, EPP,
 Ethernet, SPI)

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

 ___
 Emc-users mailing list
 Emc-users@lists.sourceforge.net


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

Re: [Emc-users] Hardware emcmot?

[andy pugh]

On Wed, 10 Apr 2019 at 18:19, Danny Miller  wrote:

> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?EMC_Components
>
> Shows EMCMOT as a discrete module, and emcmot.c and emcmot.h are
> supposed to be discrete files.  The motor PWMs and switch IO is under
> the realtime veil, which is easy to integrate into hw.

Note  that that page was last edited 12 years ago, and is based on an
earlier page describing EMC1.
The information there actually dates back to before there was a HAL

As far as I can tell motion is made up of all the files in the motion folder.
motion.c mainly creates hal pins and exports that hal function that is
called periodically by realtime:
https://github.com/LinuxCNC/linuxcnc/blob/f36ddbe0e0cc43adf379aa430114f67ee26efa30/src/emc/motion/motion.c


But I might be misunderstanding what you want to do. If you want to
move motion into a different CPU then it probably could be done, by
making a HAL interface that duplicates the HAL interface of motmod.
(the pin names would not have to be the same)
The Mesa and Pico cards already do this. HAL pins are given values,
and those values are sent to an FPGA, by various methods (PCI, EPP,
Ethernet, SPI)

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


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

Re: [Emc-users] Hardware emcmot?

[Danny Miller]

On 4/10/2019 11:31 AM, andy pugh wrote:

On Wed, 10 Apr 2019 at 17:12, Danny Miller  wrote:


I have been wondering- can emcmot be separated from the HAl and emctask
and become a true dedicated realtime stage to control the joints?

I suspect not as it stands. This is based on the observation that
motmod is a HAL module.


?

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

Shows EMCMOT as a discrete module, and emcmot.c and emcmot.h are 
supposed to be discrete files.  The motor PWMs and switch IO is under 
the realtime veil, which is easy to integrate into hw.


I see the shared memory (inherently fast) with EMCTASK, but I doubt 
ethernet latency would be a dealbreaker.  Correct me if I'm wrong.


I also have this diagram:

https://www.researchgate.net/figure/EMCMOT-Structure_fig2_265199849

which depicts the HAL with servo feedback (not essential as we use 
steppers) and fault/limit switches going to EMCMOT on a separate port.  
That seems functionally identical just a different artistic style.


I'd like to be able to integrate 2.8's circular arc blending trajectory 
planning into laser cutter and 3d printer control HW. This might 
eventually mean EMCTASK is also on hardware and Windows machines or 
anything else with whatever bastard config they happen to have installed 
can keep it fed with G-code.  The subset of common g-codes may be 
preferable, you don't need G73 high speed peck drills or G74 left-hand 
tapping cycle for 3D printers or laser cutters.  I don't think any of 
the CAM pkgs would even generate subroutines which is best to leave 
unsupported as it's nonlinear.


Ideally, a bit ambitious, and not entirely within G-code, but I'd like 
to take a stab at nontrapezoidal acceleration profiles and multiple 
acceleration models.  This would be useful- in transitioning from the 
end of a laser cut path into a rapid, it's "as fast as the machine can 
go" once the beam is off, whereas in starting a cut you may want a 
smoother stop because of belt stretch causing some oscillation that 
would persist briefly as the beam turns on.  With lasers you typically 
want to fullstop briefly at the start and end of every cut, but then why 
slam it to a rushed G0 stop only to do a 
G0-to-cold-dwell-then-powerup-dwell-then-go.




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

Re: [Emc-users] Hardware emcmot?

[andy pugh]

On Wed, 10 Apr 2019 at 17:12, Danny Miller  wrote:

> I have been wondering- can emcmot be separated from the HAl and emctask
> and become a true dedicated realtime stage to control the joints?

I suspect not as it stands. This is based on the observation that
motmod is a HAL module.


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


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

[Emc-users] Hardware emcmot?

[Danny Miller]

I have been wondering- can emcmot be separated from the HAl and emctask 
and become a true dedicated realtime stage to control the joints?


The shared memory FIFOs could be replaced with like an ethernet link to 
the hardware RAM.  You'd probably load a DMA buffer and just let it 
flow, there's some minor latency but there's not a realtime requirement.


There are cheap high freq MCUs with single-cycle hardware double 
multiply/add and gobs of memory.  It would have to be coded in non-OOP C 
and I greatly prefer hardware interrupt-driven strategies over RTOS.


Danny






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