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.
This can all take place in one servo cycle.
However, what happens if the components are added (addf) in the order:
Component C, component B, Component A.
In that case:
(cycle 1): Component C reads Sb (no value stored there yet) and produces
Sc-1.
Component B reads Sa (no value stored there yet) and
produces Sb-1.
Component A reads hardware and produces Sa-1. It reads Sc-1
and writes the hardware.
(cycle 2): Component C reads Sb-1 and produces Sc-2
Component B reads Sa-1 and produces Sb-2
Component A reads hardware and produces Sa-2. It read Sc-1
and writes the hardware.
(cycle 3): Component C reads Sb-2 and produces Sc-3
Component B reads Sa-2 and produces Sb-3
Component A reads hardware and produces Sa-3. It reads Sc-2
and writes the hardware.
Look at where the value written to the hardware came from. Sc-2 was
generated in cycle 2 from Sb-1.
Sb-1 was generated in cycle 1 from no value store there, but call it cycle
0.
So the value that is output in cycle 3 is essentially three cycles old.
If instead, the components were addf'd in the order A, B, C, the delay
would be
determined strictly by the processing time.
I first saw this problem in the 1960s in the context of generating a PERT
chart. I later found out that solving it requires doing a topological sort.
There's a slight complication in that topological sorts are done in DAGs
(directed acyclic graphs) and our graph has cycles where a single component
can be both an input and an output. A straightforward solution might be to
arbitrarily break those components into two parts.
At any rate, Gene brings up a real problem should be solvable with a simple
tool.
Ken
On Tue, Oct 23, 2018 at 12:52 AM Nicklas Karlsson <
nicklas.karlsso...@gmail.com> wrote:
> > ...
> > 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 jitter at
> > the start of the thread, which is typically less than 10
> > us. (Much less on a machine with good latency jitter numbers.)
> >
> > Jon
>
> Even though there are jitter on servo thread this jitter make no
> difference, anywhere within period is equally good because signals are
> latched/updated by hardware at period.
>
> Ideally in a good real time operating system there should be a list of all
> real time processes and worst case execution time. Then these exuction
> times and worst case execution of a new thread is known it is possible to
> calculate if enough execution time will be available. It might be hard to
> get an exact number but an upper bound is enough.
>
>
> Nicklas Karlsson
>
>
> _______________________________________________
> 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
