On Thursday 25 October 2018 22:56:33 Jon Elson wrote:
> On 10/25/2018 05:59 PM, andy pugh wrote:
> > On Thu, 25 Oct 2018 at 20:48, Kenneth Lerman
wrote:
> >> At any rate, Gene brings up a real problem should be solvable with
> >> a simple tool.
> >
> > One fly in the ointment is that I don't
On 10/25/2018 05:59 PM, andy pugh wrote:
On Thu, 25 Oct 2018 at 20:48, Kenneth Lerman wrote:
At any rate, Gene brings up a real problem should be solvable with a simple
tool.
One fly in the ointment is that I don't think anything knows which
function reads inputs and which writes outputs for
On Thursday 25 October 2018 18:59:36 andy pugh wrote:
> On Thu, 25 Oct 2018 at 20:48, Kenneth Lerman
wrote:
> > At any rate, Gene brings up a real problem should be solvable with a
> > simple tool.
>
> One fly in the ointment is that I don't think anything knows which
> function reads inputs
On Thu, 25 Oct 2018 at 20:48, Kenneth Lerman wrote:
> At any rate, Gene brings up a real problem should be solvable with a simple
> tool.
One fly in the ointment is that I don't think anything knows which
function reads inputs and which writes outputs for each component.
--
atp
"A motorcycle
On Thursday 25 October 2018 15:45:37 Kenneth Lerman wrote:
> I believe that issue Gene thinks needs addressing is the following:
> Consider component A (say Jon's board) reads the hardware and produces
> a signal Sa.
> Component B reads Sa and produces Sb
> Component C reads Sb and produces Sc
>
I believe that issue Gene thinks needs addressing is the following:
Consider component A (say Jon's board) reads the hardware and produces a
signal Sa.
Component B reads Sa and produces Sb
Component C reads Sb and produces Sc
Component A (Jon's board again) reads Sc and writes to the hardware.
> ...
> 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
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
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.
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
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
> 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
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
> 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
> 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
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,
> ...
> 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
>
Greetings all;
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 a database of total delays so that
18 matches
Mail list logo
