> ...
> We need something that can give us a text list in just a minute or so.
> Ideally it would give us a list of module delays, sorted by addf order
> in one column, and a second column of all the delays that signal
> encounters from the hal read operation, collecting the machines instant
>
On Tue, 4 Sep 2018 at 09:26, Gene Heskett wrote:
> Laying awake thinking about this lathe, and its hal configuration, it
> seems like it would be at least as handy as sliced bread, to have a
> utility that could collect all the processing delays and sort them
> according to the addf order, giving
All PCI/e LPT cards work for software stepping with RTAI if the
mainboard and CPU have low enough latency. This most often limited by a
bad/broken BIOS that doesn't let the user kill power management, speed
stepping, etc..
The PCI/e LPT cards that you have to watch out for are those that have
brok
> Rockhopper can give a graphic that can display the path and carefull
> analisis of that artwork can be informative, but it doesn't really show
> where the signal delays are.
I think most blocks/functions are calculate in an instant in sort of. There is
delay because input signal is sampled pe
> On Tue, 4 Sep 2018 at 09:26, Gene Heskett wrote:
>
> > Laying awake thinking about this lathe, and its hal configuration, it
> > seems like it would be at least as handy as sliced bread, to have a
> > utility that could collect all the processing delays and sort them
> > according to the addf o
On Mon, 22 Oct 2018 at 20:31, Nicklas Karlsson
wrote:
> It depends on hardware but to simultaneously sample inputs and actuate
> outputs is a good method. Then computations could happen anywhere within
> period and it also agree with theories for real time scheduling.
I don't think that any Li
> On Mon, 22 Oct 2018 at 20:31, Nicklas Karlsson
> wrote:
>
> > It depends on hardware but to simultaneously sample inputs and actuate
> > outputs is a good method. Then computations could happen anywhere within
> > period and it also agree with theories for real time scheduling.
>
> I don't t
On Monday 22 October 2018 14:01:35 Nicklas Karlsson wrote:
> > ...
> > We need something that can give us a text list in just a minute or
> > so. Ideally it would give us a list of module delays, sorted by addf
> > order in one column, and a second column of all the delays that
> > signal encounte
On Monday 22 October 2018 14:13:00 andy pugh wrote:
> On Tue, 4 Sep 2018 at 09:26, Gene Heskett wrote:
> > Laying awake thinking about this lathe, and its hal configuration,
> > it seems like it would be at least as handy as sliced bread, to have
> > a utility that could collect all the processin
On Mon, 22 Oct 2018 at 21:54, Gene Heskett wrote:
> > Basically, by the time any HAL component reads its inputs all the
> > upstream components have updated their outputs.
> This is the ideal addf order, but we need a tool to yell at us when we
> are out of order.
Maybe I used the wrong word. B
You know those little things that finally do your head in?
When I choose to Open a file in LinuxCNC, it uses an inconvenient path name, so
I always have to go up a couple of levels and select the directory I need. I
can't find where the path name is stored, in LinuxCNC or in Axis.
Where should I
On Monday 22 October 2018 17:48:04 Marcus Bowman wrote:
> You know those little things that finally do your head in?
>
> When I choose to Open a file in LinuxCNC, it uses an inconvenient path
> name, so I always have to go up a couple of levels and select the
> directory I need. I can't find where
Gene,
I think you forgot to mention which file to edit to change that
PROGRAM_PREFIX.
John
> Theres an editor called nano that can fix that, what you probably want
> is:
>
> PROGRAM_PREFIX = /home/marcus/linuxcnc/nc_files
>
___
Emc-users mailing li
On Monday 22 October 2018 18:39:12 John Dammeyer wrote:
> Gene,
> I think you forgot to mention which file to edit to change that
> PROGRAM_PREFIX.
> John
Oops & Right, I didn't because I don't know what you have called your
machine.
It's whatever you have called your .ini file. Often but not a
On 10/22/2018 03:17 PM, andy pugh wrote:
On Mon, 22 Oct 2018 at 20:31, Nicklas Karlsson
wrote:
It depends on hardware but to simultaneously sample inputs and actuate outputs
is a good method. Then computations could happen anywhere within period and it
also agree with theories for real time
> ...
> So, this makes sure that the encoders for ALL axes are
> sampled simultaneously, and then the DACs are updated
> simultaneously on the next servo cycle. Thus, there is no
> variable delay between encoder sampling and DAC update, it
> is always equal to the servo thread period +/- the j
16 matches
Mail list logo
