>
> 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
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
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
> 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
> 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
>
>
>
>
> 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
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
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
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
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
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
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
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
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
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: R
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
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,
: 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
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
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
--
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?
Mo
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
/> >
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
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
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
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
26 matches
Mail list logo
