We are writing a control system that will run at 1 kHz. Since we need to
synchronize our loop's phase with that of the EtherCAT DC clock, we cannot
just use a periodic activity, so we are repeatedly arming and firing a
RTT::os::Timer to control our loop timing.
However, this Timer is consistently overshooting by about 60 us, which is
quite significant. There is low jitter, and we have isolated this task to a
core that is not otherwise utilized, but it's still there.
What could cause this issue?
Thank You,
Johnathan Van Why
Dynamic Robotics Laboratory
Oregon State University
Timer overshooting consistently.
On Wed, Jul 25, 2012 at 08:59:18AM -0700, Johnathan Van Why wrote:
> We are writing a control system that will run at 1 kHz. Since we need to
> synchronize our loop's phase with that of the EtherCAT DC clock, we cannot just
> use a periodic activity, so we are repeatedly arming and firing a
> RTT::os::Timer to control our loop timing.
>
> However, this Timer is consistently overshooting by about 60 us, which is quite
> significant. There is low jitter, and we have isolated this task to a core that
> is not otherwise utilized, but it's still there.
>
> What could cause this issue?
Are you running on Xenomai or RT_PREEMPT and setting real-time
priorities? If yes, I would try to directly use POSIX clock_nanosleep
with CLOCK_MONOTONIC and sleep to an absolute time. If that solves the
problem, it's something to do with RTT::os::Timer...
Markus
Timer overshooting consistently.
On Wed, 25 Jul 2012, Johnathan Van Why wrote:
> We are writing a control system that will run at 1 kHz. Since we need to synchronize our loop's
> phase with that of the EtherCAT DC clock, we cannot just use a periodic activity, so we are
> repeatedly arming and firing a RTT::os::Timer to control our loop timing.
Isn't it an option to let the EtherCAT component trigger your control loop
as a slave? Or, even better if you want minimal delays: to implement your
controller as a pure function, and call it from inside your EtherCAT
component?
> However, this Timer is consistently overshooting by about 60 us, which is quite significant.
> There is low jitter, and we have isolated this task to a core that is not otherwise utilized,
> but it's still there.
>
> What could cause this issue?
Maybe the cause is all the context switches involved in putting all
functionalities in different TaskContexts (inlcuding the timer component),
and the delays in the Communication?
TaskContexts are nice to guarantee data consistency and deadlock-free
systems, but you pay a performance price; especially if you want to
synchronize different components indirectly via an external clock/timer
component.
Of course, there might be other reasons, such as motherboard issues.
> Thank You,
> Johnathan Van Why
> Dynamic Robotics Laboratory
> Oregon State University
Herman
Timer overshooting consistently.
> Isn't it an option to let the EtherCAT component trigger your control loop
> as a slave? Or, even better if you want minimal delays: to implement your
> controller as a pure function, and call it from inside your EtherCAT
> component?
We're not using the Orocos SOEM component. In this case, the EtherCAT
isn't an issue in and of itself...
here is pseudocode of our timing function (I can provide the whole
class if necessary):
void ECatComm::timeout(TimerID timer_id) {
RTT::os::TimeService::nsecs overshoot =
RTT::os::TimeService::Instance()->getNSecs() - targetTime;
// overshoot is approximately 60000 ns here... an oscilloscope on
EtherCAT transmit line and DC line confirms
// this measurement
< run EtherCAT and control loop >
cur_time = getNSecs();
sleepTime = <calculation for time remaining until next cycle>
targetTime = sleepTime + cur_time;
arm(timer_id, ((double) sleepTime) / ((double) 1000000000.0));
}
> Maybe the cause is all the context switches involved in putting all
> functionalities in different TaskContexts (inlcuding the timer component),
> and the delays in the Communication?
There is only one TaskContext involved here... and this is not a slow machine.
Thank you for responding,
Johnathan Van Why
Dynamic Robotics Laboratory
Oregon State University