Re: [Emc-users] need something like rockhopper, but faster

[Gene Heskett]

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 think anything knows which
> > function reads inputs and which writes outputs for each component.
>
> MOST hal components do it all in one shot.  Generally, only
> the ones related to complicated I/O devices like Pico
> Systems and Mesa boards have a separate read and write
> functions that require TWO ADDF lines.  (The software
> encoder has two functions that are typically run in separate
> THREADS, that's another whole complication.)  At least for
> the Pico PPMC devices, you do the read function as the VERY
> first thing in the thread, and the write as the last.
>
> Jon

And that is how I've composed the hal files here, even for the one simple 
software stepper running the teeny hf mill. But do I have all the 
intermediary stuff in the correct order? I think I do, but no way to 
certify that I have.  And that may be impinging on the speed I can move, 
or on following errors.

The hf mill has no spindle encoder, so I can't thread on it, and its 200 
watt motor doesn't have the power anyway. Where it really stars is doing 
edm, Its done several parts for the Sheldon doing edm to cut slots for 
compression fittings. Works well but really dirty using k2 for 
dielectric fluid but actually works well using distilled water too, 
cutting faster with the water I believe. I have a 400 watt motor that 
came off TLM when I put the 1hp motor on it, and someday I'll strip that 
box off the top, and make a 3 speed belt drive using the 400 watt motor, 
which will make room for an encoder. Someday. Need to find my round tuit 
again. :) I did order a 1x2 foot sheet of .500 thick alu, ostensibly to 
make a new apron for the Sheldon, moving the Z nut an inch to the right 
and relocating new gain pushbuttons for the jog dials to make them more 
comfortable to push. That will make good stock for a 3 speed belt 
shifting drive.

But I'm still waiting for the new master-rt with the fixed function 
keys. ??? Andy said the buildbot was done 10 minutes after my previous 
post on that most of a week ago, but synaptic hasn't offered it as an 
update to the x86 machines yet. The pi & Sheldon, with a slightly older 
version, works well.

Thanks all.

-- 
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] need something like rockhopper, but faster

[Jon Elson]

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 each component.

MOST hal components do it all in one shot.  Generally, only 
the ones related to complicated I/O devices like Pico 
Systems and Mesa boards have a separate read and write 
functions that require TWO ADDF lines.  (The software 
encoder has two functions that are typically run in separate 
THREADS, that's another whole complication.)  At least for 
the Pico PPMC devices, you do the read function as the VERY 
first thing in the thread, and the write as the last.


Jon


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

Re: [Emc-users] need something like rockhopper, but faster

[Gene Heskett]

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 and which writes outputs for each component.

Could that be borrowed from rockhopper? Or is this something different?

Thanks Andy.

-- 
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] need something like rockhopper, but faster

[andy pugh]

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 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] need something like rockhopper, but faster

[Gene Heskett]

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
> 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
>

I'm not so sure I'd call it simple, Ken, but we definitely do need such a 
tool. I don't think it would be fast, at least not on a hal file with 
100 lines of addf's or more, and 2, maybe 3 threads. My Sheldon, running 
from a pi, has two threads, servo and jog, with jog running at only 200 
hertz. I need to move all the slow threads to the bottom of the list, 
then re-sort each list to firmly achieve the correct, it all falls thru 
in one thread cycle order, and if it was carefully analyzed, theres 
likely a few items/modules that could be moved to the slower thread. The 
G0704 is all running on the 1KHz servo thread, but thats a much faster 
Intel dual core cpu, which isn't showing its overworked, yet...  Its 
about to get independent homing switches which will add a few lines to 
the hal file as soon as I get good eyesight back. 2, maybe 3 weeks yet 
to new glasses.

Now getting into the killing frost time of the year, snow by the foot or 
so, so some of this will slow down.  The garage is very well insulated, 
heats all winter with a 1500 watt heater. but the shop only has a layer 
of T-111 between the weather and occupants like me. Been thinking of 
tearing it down and making a bigger one that can be insulated as its 
built, now that a damaged back in 2010 50 foot pine has been taken down 
at the other end of the yard. All I have to do is last long enough to do 
it. ;-)

Thanks Ken.

-- 
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] need something like rockhopper, but faster

[Kenneth Lerman]

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

Re: [Emc-users] need something like rockhopper, but faster

[Nicklas Karlsson]

> ...
> 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

Re: [Emc-users] need something like rockhopper, but faster

[Jon Elson]

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 scheduling.

I don't think that any LinuxCNC hardware driver does this, and none of
the sample HAL files are written this way. LinuxCNC typically uses a
read-process-write scheme.

(then waits 1mS for the next cycle)

Well, the Pico Systems PPMC boards for analog servo 
interface does this.  At the beginning of the thread, you 
latch all the encoder counts, and then read them in.  
Various components execute, especially PID, and then outputs 
are sent to the velocity command DACs.  But, these DACs hold 
the new setting in a digital memory, and do not update the 
analog output immediately.  At the beginning of the NEXT 
servo thread, when the encoders are latched, the DACs update 
the analog output.


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


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

Re: [Emc-users] need something like rockhopper, but faster

[andy pugh]

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. By "Upstream" I meant "earlier in the addf order"

But this has nothing to do with "delays" or execution times.

So, yes, I think that a tool could be written to optimise addf
ordering, but it need not be anything like Rockhopper.

-- 
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] need something like rockhopper, but faster

[Gene Heskett]

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 processing delays and sort them
> > according to the addf order, giving a database of total delays so
> > that one could more easily see where a signal processing step was
> > out of order, causing a 1 or more total thread processing delay in a
> > given signals path thru all the modules.
>
> I don't think that HAL does any parallel processing, so my first guess
> is that this is non-issue.
> (My second guess is that I have misunderstood the question)
>
> 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.

-- 
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] need something like rockhopper, but faster

[Gene Heskett]

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 encounters from the hal read operation, collecting the
> > machines instant status, doing all the additional time to the final
> > hal write back to the interface, in a format that would show the
> > extra delay in that signals path caused by out of order module
> > execution.
>
> Linuxcnc confguration is essentially a netlist with one signal driving
> each net. I think the method is to calculate a "call graph" for each
> output. Delay obviously have to be known for each
> block/function/component.
>
> Algorithm probably is:
>   1. Check so that each net there output is used is driven by exactly
> one net. 2. For each output calculate the call graph.
>   3. Scan the call graphs and calculate delay.
>
> I started backend in gschem although did not yet finnish it and as far
> as I understand rockhopper work in other which is great sometimes.
>
Rockhopper works well with two exceptions. A net with no load isn't 
shown, and the labor involved in producing a readable printout, taking 
up to 6 tabloid pages to print it out.  That takes much of a day to do.

What we need is something that tells us in easy to see form, when we have 
modules out of order, which extends the read data, action on data, write 
data, by one servo threads delay for every out of sequence module. And 
yells at us by way of adding the extra delays to the offending module. 

OTOH, I have used that delay on purpose as a filter to reduce the 
quantization noise of a poor resolution optical encoder by averaging the 
last 4 samples (edges) from the encoder.

Thats a tall order, but it sure would be helpfull.
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



-- 
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] need something like rockhopper, but faster

[Nicklas Karlsson]

> 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 LinuxCNC hardware driver does this, and none of
> the sample HAL files are written this way. LinuxCNC typically uses a
> read-process-write scheme.

The read and write process send all signals in one message for each direction?


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

Re: [Emc-users] need something like rockhopper, but faster

[andy pugh]

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 LinuxCNC hardware driver does this, and none of
the sample HAL files are written this way. LinuxCNC typically uses a
read-process-write scheme.

(then waits 1mS for the next cycle)

-- 
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] need something like rockhopper, but faster

[Nicklas Karlsson]

> 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 a database of total delays so that
> > one could more easily see where a signal processing step was out of
> > order, causing a 1 or more total thread processing delay in a given
> > signals path thru all the modules.
> 
> I don't think that HAL does any parallel processing, so my first guess
> is that this is non-issue.

Then calculations are done within same quanta/period it does not matter if they 
are executed in a sequence after each other or in parallel by several CPUs.

> (My second guess is that I have misunderstood the question)
> 
> Basically, by the time any HAL component reads its inputs all the
> upstream components have updated their outputs.

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.


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

Re: [Emc-users] need something like rockhopper, but faster --> control loop delay

[Nicklas Karlsson]

> 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 periodically and output signal usually is 
a PWM signal which with an average over the period. Then it depends a little 
bit on hardware but in most cases it will probably be at least a few periods, 
PWM timers in micro controllers usually have a shadow register so that software 
calculations could be done anywhere within period while update is done exactly 
at period usually at timer overflow or at top and/or bottom.

I can not put a number on the delay but it is somewhere within the period. If I 
think correct delay is distributed within period with this kind of square 
shaped probability distribution there any number within period is equally 
likely to happen but I can't remember the name on it.

Then designing a control loop maximum delay need to be at largest what phase 
margin allow. For higher frequencies phase angle will be more negative because 
delay stay the same while period decreases with period. T=1/f, where T is 
period in second and f is frequency in Hz, phase in degree is delay/T*360 if I 
got everything correct.


In practice many signals if not all have at least some kind of filtering and 
other smaller or larger random variations. Variations will also add some 
variations to phase margin.


Regards, Nicklas Karlsson


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

Re: [Emc-users] need something like rockhopper, but faster

[andy pugh]

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 a database of total delays so that
> one could more easily see where a signal processing step was out of
> order, causing a 1 or more total thread processing delay in a given
> signals path thru all the modules.

I don't think that HAL does any parallel processing, so my first guess
is that this is non-issue.
(My second guess is that I have misunderstood the question)

Basically, by the time any HAL component reads its inputs all the
upstream components have updated their outputs.

-- 
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] need something like rockhopper, but faster

[Nicklas Karlsson]

> ...
> 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 
> status, doing all the additional time to the final hal write back to the 
> interface, in a format that would show the extra delay in that signals 
> path caused by out of order module execution.

Linuxcnc confguration is essentially a netlist with one signal driving each 
net. I think the method is to calculate a "call graph" for each output. Delay 
obviously have to be known for each block/function/component.

Algorithm probably is:
  1. Check so that each net there output is used is driven by exactly one net.
  2. For each output calculate the call graph.
  3. Scan the call graphs and calculate delay.

I started backend in gschem although did not yet finnish it and as far as I 
understand rockhopper work in other which is great sometimes.


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

[Emc-users] need something like rockhopper, but faster

[Gene Heskett]

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 
one could more easily see where a signal processing step was out of 
order, causing a 1 or more total thread processing delay in a given 
signals path thru all the modules.

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.

Obtaining a copy from rockhopper, poster-izing it to an 8 to 12 sheets of 
paper format, and printing it out, cutting it up because your printer 
has borders, then taping it up to make up a chart that might occupy half 
a sheet of 1/8" paneling is an all day job by the time its been made 
into usable data.

A huge, where do I store it in a crowded shop result that might be 
completely in error 5 minutes later after the first "fix" has been 
applied 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 
status, doing all the additional time to the final hal write back to the 
interface, in a format that would show the extra delay in that signals 
path caused by out of order module execution.

Do we have such a utility to do this and I've just not become aware of 
it?

Thanks all.

-- 
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 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users