[LinuxCNC/linuxcnc Issue#213] trigger real time thread from external interrupt

#1 – rene-dev 于 2018-11-10

you can have a pll that syncs the thread to some external clock.
ethercat does this: https://github.com/sittner/linuxcnc-ethercat/blob/master/patches/add-task-pll-functions.patch

#2 – andypugh 于 2018-11-10

There are DPLLs in the Mesa firmware too.
http://linuxcnc.org/docs/2.7/html/man/man9/hostmot2.9.html#dpll (anchor goes to a point below the title). I think this is intended to do much the same thing.
It does appear, though, that it is possible to trigger interrupts in Linux via the parallel port: https://www.oreilly.com/library/view/linux-device-drivers/0596005903/ch10.html
Then the question becomes whether this gives behaviour that is any more realtime than the RTAPI timers.

#3 – zultron 于 2018-11-15

IIRC there was discussion about this topic on the emc-developers list several years ago. This was at least on the roadmap for Machinekit, but I don’t think it was ever implemented.

The link to @sittner’s code, pasted by @rene-dev above (and merged in Machinekit), is the only implementation I’ve actually seen of RT thread timing following external hardware rather than the internal clock. It should be an instructive example for developing this feature.

#4 – rmu75 于 2018-11-15

It should be possibly to wake up the thread “near” the anticipated interrupt, early enough, and then busy-wait on the pin (with some timeout of course).

#5 – pcw-mesa 于 2018-11-15

Machinekit has a way of using Mesa PCI interrupts to trigger the RT thread (I think Charles S worked on this) They use the DPLL rate generator as a master rather than a slave in this case.

#6 – rene-dev 于 2018-11-15

is there any advantage in doing this?

#7 – pcw-mesa 于 2018-11-15

I guess you get somewhat lower jitter at the expense of having to incorporate interrupt code in the driver
I think a possible disadvantage of using a hardware device as the main timing source is that you likely cannot use it as an absolute time reference (which should be possible with LinuxCNCs TOD synced threads)

#8 – jmelson 于 2018-11-16

On 11/15/2018 02:07 PM, Rene Hopf wrote:
>
> is there any advantage in doing this?
>
>
Well, in a real servo system, there is a time jitter in
sampling the position of the axes, if it is triggered by
software. My Pico Systems motion controllers, for instance,
have a feature where the position can be sampled by a
hardware timer in the board, and then the CNC controller
could be interrupted, and have the whole servo period to
pick up the position and compute a new velocity to send
out. That would reduce sampling jitter to sub-ns levels.
But, I haven’t dived into the software to do it, as it looks
to be a non-trivial amount of change. One issue is I only
provided 4 servo rates in the hardware (1, 2, 5 and 10 KHz).

Jon

#9 – rmu75 于 2018-11-16

In this case (“a real servo system”) jitter of the host clock should not matter that much, because the HW could sample the encoder and latch new velocities at it’s own clock ticks. The host just has to do the calculations anytime between these two clock ticks, using the timestamps of the HW.

Even if you delivered interrupts into linux to wake up the servo thread, i suspect that latency or jitter won’t improve much, because whatever causes the jitter in the first place probably will interfere with waking the thread, regardless from the event that caused it. At least in the case of RT Preempt.

#10 – jmelson 于 2018-11-16

On 11/16/2018 03:49 AM, Robert Schöftner wrote:
>
> In this case (“a real servo system”) jitter of the host
> clock should not matter that much, because the HW could
> sample the encoder and latch new velocities at it’s own
> clock ticks. The host just has to do the calculations
> anytime between these two clock ticks, using the
> timestamps of the HW.
>
The way many systems work with LinuxCNC is the software
determines when the position is sampled.
Mesa has a scheme where a phase-locked loop generates the
sampling clock. Without some way for the hardware to stay
roughly synched to the software thread, you would make
things quite a bit worse.

> Even if you delivered interrupts into linux to wake up the
> servo thread, i suspect that latency or jitter won’t
> improve much, because whatever causes the jitter in the
> first place probably will interfere with waking the
> thread, regardless from the event that caused it. At least
> in the case of RT Preempt.
>
>
Yes, ONLY IF the software was still causing the position to
be sampled. That would be pointless. If the position
sampling is triggered WITHIN the hardware, which at least
the Pico Systems devices CAN do, then the sampling jitter
will be in the sub-ns range. Then, the servo thread just
has to process it before the next interrupt, and as long as
that is satisfied, timing doesn’t matter.

The idea is that the hardware timer samples the encoder
position, and then triggers the servo thread to process the
precisely sampled position. But, it doesn’t work that way
now, just due to the software.

Jon

#11 – zultron 于 2018-11-19

> Machinekit has a way of using Mesa PCI interrupts to trigger the RT thread (I think Charles S worked on this) They use the DPLL rate generator as a master rather than a slave in this case.

@cdsteinkuehler