trigger real time thread from external interrupt

[jmelson]

I'd like to ask about making it possible to trigger a real time thread from an external interrupt. The Pico Systems boards all can latch encoder count and generate regular interrupts through the parallel port. This would reduce position sampling jitter down to the jitter of the quartz oscillator on the board. As long as the real time thread is completed before the next tick of the clock, RT jitter would cease to exist.

This would require the loadrt emcmot command line to accept the interrupt number instead of a thread period.

[rene-dev]

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

[andypugh]

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.

[zultron]

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.

[rmu75]

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

[pcw-mesa]

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.

[rene-dev]

is there any advantage in doing this?

[pcw-mesa]

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)

[jmelson]

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

[rmu75]

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.

[jmelson]

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

[zultron]

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