[Xenomai-help] OT. A question about constraints in realtime

[Xenomai-help] OT. A question about constraints in realtime

[Leopold Palomo Avellaneda]

[-- Attachment #1: Type: text/plain, Size: 2368 bytes --]

Dear people,

first of all this is an Off topic, so please don't be angry with me. If you 
don't want to answer, move this message to /dev/null. But I have a problem 
with a device and maybe some people in this list could give me some idea.

I'm working in a robotics lab and we have a device (a haptic from Sensable) 
that it's connected to the parallel port. Of course that the Sensable company 
doesn't not publish open source drivers, etc. By now it's an sterile 
discussion.

Anyway, they provide a driver that it's a lib (.so). Also there's some library 
that can act with the device using that driver. Excepting the driver, for the 
other parts I have some source code.

I have had several problems with this driver. Firstly, the driver only can 
works if the parport module detects the EPP mode. Sadly, the linux parport 
module is more or less unmaintained and fails in many boxes to detect the EPP 
mode, although the bios is configured to.

After that, you can read encoders of the device (using the driver) but when 
you send forces to the engines, it suffers some kind of chattering and the 
driver disable the force because the loop of control expend too much time. 

Asking in some forum I have arrived to the conclusion that the driver has some 
kind of timer and if it doesn't not receive any order in 1ms, then the force 
is disabled.

So, my question are:
- Why the windows driver works so well? the scheduler in Windows do that if a 
task need to have a constraint of 1ms they give it the control and that's 
all?
- Why a linux driver doesn't not work? the load of the box is quiet normal. 
I'm not compiling or solving eigen systems. Or is possible that some device 
is breaking some access to the parport, or whatever?
- I have tried to use the realtime kernel -rt but same result. 
- Can I do something with xenomai to avoid it?

The sensable people claims that their driver works with some versions of Linux 
(till fedora 4 and some suse) but I'm not be able to run it in a debian etch. 
I don't know if the distros provide a kernel with some kind of modifications 
that solve it, but I don't think so.


Well, thanks in advance and I'm sorry for the noise. Really, the realtime 
stuff is something not obvious...

Best regards,

Leo


-- 
--
Linux User 152692
PGP: 0xF944807E
Catalonia

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [Xenomai-help] OT. A question about constraints in realtime

[Gilles Chanteperdrix]

Leopold Palomo Avellaneda wrote:
> The sensable people claims that their driver works with some versions of Linux 
> (till fedora 4 and some suse) but I'm not be able to run it in a debian etch. 
> I don't know if the distros provide a kernel with some kind of modifications 
> that solve it, but I don't think so.
> 
> 
> Well, thanks in advance and I'm sorry for the noise. Really, the realtime 
> stuff is something not obvious...

The first thing to do is to get statistics about the scheduling latency
of your driver. This means measuring the difference between the date
when the driver (kernel-code) wakes up the task and the date when the
task effectively runs. The bad news is that it will be hard with a
binary-only driver. If the driver has some compilable glue, then you can
hook into this glue, otherwise, you will have to resort to ugly hacks in
the kernel code.

If this latency is really the problem, then before resorting to xenomai,
you have linux-only solutions, like using a real-time priority for the
task using the driver.

-- 
                                                 Gilles.

Re: [Xenomai-help] OT. A question about constraints in realtime

[Leopold Palomo Avellaneda]

[-- Attachment #1: Type: text/plain, Size: 1732 bytes --]

A Dilluns 28 Juliol 2008, Gilles Chanteperdrix va escriure:
> Leopold Palomo Avellaneda wrote:
> > The sensable people claims that their driver works with some versions of
> > Linux (till fedora 4 and some suse) but I'm not be able to run it in a
> > debian etch. I don't know if the distros provide a kernel with some kind
> > of modifications that solve it, but I don't think so.
> >
> >
> > Well, thanks in advance and I'm sorry for the noise. Really, the realtime
> > stuff is something not obvious...

First of all thanks for the answer. 

> The first thing to do is to get statistics about the scheduling latency
> of your driver. This means measuring the difference between the date
> when the driver (kernel-code) wakes up the task and the date when the
> task effectively runs. The bad news is that it will be hard with a
> binary-only driver. If the driver has some compilable glue, then you can
> hook into this glue, otherwise, you will have to resort to ugly hacks in
> the kernel code.

Well, I cannot (or it's too difficult to do it with a _only_ binary driver. 
This driver is a lib (.so) and the user use some functions of that lib. 

> If this latency is really the problem, then before resorting to xenomai,
> you have linux-only solutions, like using a real-time priority for the
> task using the driver.

Well, I guess that it's the latency. They have a loop that control each 
engine, and if the driver doesn't receive any signal in some time, it 
disconnects the engine (some rele acts) . They works well with devices with 3 
motors but the 6DOF model fails.

I have to think how to solve it ...

Regards,

Leo


-- 
--
Linux User 152692
PGP: 0xF944807E
Catalonia

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [Xenomai-help] OT. A question about constraints in realtime

[Gilles Chanteperdrix]

Leopold Palomo Avellaneda wrote:
> A Dilluns 28 Juliol 2008, Gilles Chanteperdrix va escriure:
>> Leopold Palomo Avellaneda wrote:
>>> The sensable people claims that their driver works with some versions of
>>> Linux (till fedora 4 and some suse) but I'm not be able to run it in a
>>> debian etch. I don't know if the distros provide a kernel with some kind
>>> of modifications that solve it, but I don't think so.
>>>
>>>
>>> Well, thanks in advance and I'm sorry for the noise. Really, the realtime
>>> stuff is something not obvious...
> 
> First of all thanks for the answer. 
> 
>> The first thing to do is to get statistics about the scheduling latency
>> of your driver. This means measuring the difference between the date
>> when the driver (kernel-code) wakes up the task and the date when the
>> task effectively runs. The bad news is that it will be hard with a
>> binary-only driver. If the driver has some compilable glue, then you can
>> hook into this glue, otherwise, you will have to resort to ugly hacks in
>> the kernel code.
> 
> Well, I cannot (or it's too difficult to do it with a _only_ binary driver. 
> This driver is a lib (.so) and the user use some functions of that lib. 

It is hard, but not impossible. You can hook into the sys_open function,
detect that you are opening the driver (using either the device path, or
 current->comm), and in this case, replace the file operation pointer in
the file descriptor with your own file operations pointers which does
some tracing then calls the original file operation pointer. So, it is
not impossible.

-- 


					    Gilles.

Re: [Xenomai-help] OT. A question about constraints in realtime

[Leopold Palomo Avellaneda]

[-- Attachment #1: Type: text/plain, Size: 2257 bytes --]

A Dimecres 30 Juliol 2008, Gilles Chanteperdrix va escriure:
> Leopold Palomo Avellaneda wrote:
> > A Dilluns 28 Juliol 2008, Gilles Chanteperdrix va escriure:
> >> Leopold Palomo Avellaneda wrote:
> >>> The sensable people claims that their driver works with some versions
> >>> of Linux (till fedora 4 and some suse) but I'm not be able to run it in
> >>> a debian etch. I don't know if the distros provide a kernel with some
> >>> kind of modifications that solve it, but I don't think so.
> >>>
> >>>
> >>> Well, thanks in advance and I'm sorry for the noise. Really, the
> >>> realtime stuff is something not obvious...
> >
> > First of all thanks for the answer.
> >
> >> The first thing to do is to get statistics about the scheduling latency
> >> of your driver. This means measuring the difference between the date
> >> when the driver (kernel-code) wakes up the task and the date when the
> >> task effectively runs. The bad news is that it will be hard with a
> >> binary-only driver. If the driver has some compilable glue, then you can
> >> hook into this glue, otherwise, you will have to resort to ugly hacks in
> >> the kernel code.
> >
> > Well, I cannot (or it's too difficult to do it with a _only_ binary
> > driver. This driver is a lib (.so) and the user use some functions of
> > that lib.
>
> It is hard, but not impossible. 

Sure, but the afford and the skill are not insignificant.

> You can hook into the sys_open function, 
> detect that you are opening the driver (using either the device path, or
>  current->comm), and in this case, replace the file operation pointer in
> the file descriptor with your own file operations pointers which does
> some tracing then calls the original file operation pointer. So, it is
> not impossible.

Well, the driver is for a device that uses the parallel port. It's a library 
that has implemented some kind of loop function and make the transformation 
from the values to send to the device and read the device. 

I guess that they have a very bad implementation in linux. But, really to me 
the question that intrigue me is why it works well in Windows and not in 
linux.

Leo



-- 
--
Linux User 152692
PGP: 0xF944807E
Catalonia

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]