Re: [Xenomai-help] [Ethercatmaster-users] EML conflict with RTCAN? low_level_input framebuilding failed.

[Jan Kiszka <jan.kiszka@domain.hid>]

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

Roland Tollenaar wrote:
> Hi,
> 
>> How many threads do you have sending process data, and what are there
>> priorities? (/proc/xenomai/sched IIRC)
> I have 3 rt tasks running. Only one sends and receives process data. The 
> priorities are:
> rt_task1 99

Check the /proc output again, there should be also RTnet's stack manager
at prio 98. Maybe that is too low for your scenario and causes prio
inversions (note: every incoming Ethernet frame goes through its hands).
Try lowering the prio of your rt_task1 beneath 98.

> rt_task2 75
> rt_task3 1
> 
> Period times are
> 1ms
> 3ms
> indefinite(holds a blocking rt_can recv call to catch any incoming CAN 
> messages)
> 
> 
>>> EC_Telegram::index_check() : index not the same,
>>> low_level_input() :  framebuilding failed.
>>>
>>> Or something pretty closely to that effect.
>>>
>>> Despite EML warning that the frame could not be built, the inputs (which
>>> rely on the framebuilding being succesful pretty stringently) seem to
>>> function perfectly. It seems as though EML is emitting a false warning.
>> What do you mean with "inputs functioning perfectly"?
> 
> The digital inputs are packed into the frame as are the digital outputs 
> and analog output process data. The outputs function as they should but 
> the warning complains mainly about the retrieving part of the ethercat 
> cycle. Hence my comment that the digital inputs also function as they 
> should that is to say the data arrives correctly and uncorrupted. AFAI 
> understand from ETG the index is not changed by the ESC's so I would 
> expect the check always return true. But even if it does not what does 
> that mean? Can it mean that EML is losing some frames that have been 
> transmitted? I.e. the index is incremented with every transmit and the 
> message with the same index is expected on the next read but instead it 
> is only getting one later? If so, what could cause this?

If the problem persists (or your _really_ want to understand what
happens), you could try to put an xntrace_user_freeze(0, 1) before the
line which emits that EML warning, turn on the I-pipe tracer, set a
large back_trace_points value (a few thousand), enable verbose mode, and
grab what /proc/ipipe/trace/frozen reports after the hick-up. See [1]
for more howtos.

If you post the dump, we may be able to analyse what the system is doing
before the problem report, if there are long delays due to high-prio
tasks e.g.

Jan

[1] http://www.xenomai.org/index.php/I-pipe:Tracer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]