Am 10.11.2010 18:51, Anders Blomdell wrote:
> On 2010-11-10 18.23, Vinzenz Bargsten wrote:
>> Hi,
>>
>> can someone provide (more) information on how to run a RTnet
>> in combination with in this case one non-Linux/non-RTnet, i.e. windows 
>> machines?
>>
>> The windows machine (robot controller), which runs some proprietary 
>> real-time 
>> software,
>> sends a UDP packet with XML strings every 12ms to the Linux machine.
>> The Linux machine receives and processes the data (<1ms) and has to answer 
>> in 
>> less than 12 ms.
>>
>> At the moment,the setup on the Linux machine is:
>> kernel 2.6.32-7 x86_64 with xenomai 2.5.1, RTL8139 NIC
>> The data processing is done in/via OROCOS in a real time task.
>> There is no other machine on this network.
>>
>> However, the problem is that the real time requirement is not met,
>> i.e. the answer from the linux machine sometimes takes more than 12ms.
>> Using wireshark we found out, that normally the answer is sent after (packet 
>> receive time) + ~0.5ms,
>> but after some time (minute(s)), it takes >40ms and several/the missing 
>> packets 
>> are sent at once.
> Could it be that you are running a SMP machine? Then this might be of 
> interest:
> 
> https://mail.gna.org/public/xenomai-core/2010-11/msg00053.html
> 
> later kernel, but the bug might exist in earlier versions (Jan can you comment
> on this)?

No, this particular issue was introduced with 2.5.5.

> 
>>
>> This is a big problem, as the packets, which are sent from the Linux machine 
>> contain position data,
>> which should be commanded to a robot.
>> If the packets are delayed, the robot will stop/hold its position for this 
>> time,
>> which results in an non-smooth/impulsive movement, making the measurement 
>> useless.
>>
>> So, what is the correct procedure to make the network interface working in 
>> real 
>> time mode with a non-TDMA capable remote station?
>> Is it possible with RTnet, does it make sense?
>> As the communication is already working with a definite rhythm, I think the 
>> TDMA 
>> functionality is not necessarily required. Is this true?

Yep, the setup sounds valid. There is something delaying the packet
processing, and that needs to be found.

The usual questions are:
 - any suspicious kernel logs?
 - what are the result of Xenomai latency tests (to evaluate the
   hardware)?
 - already tried a recent Xenomai & I-pipe combination?

If that doesn't help, tracing is the next step.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a 
Billion" shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users

Reply via email to