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
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
