Re: Simulink RTAI-LAB multiple rates in multi-cpu systems

Let me find a bit of time for a check, I've gathered a bit of rust in my head relation to RTAI-LAB.
I let you know. Paolo.
________________________________________
From: Rtai [[email protected]] on behalf of Virgili-Llop, Josep FORNATL, SP [[email protected]]
Sent: Tuesday, December 1, 2015 8:36 PM
To: [email protected]
Cc: Zappulla, Richard (CIV)
Subject: [Rtai] Simulink RTAI-LAB multiple rates in multi-cpu systems

Dear all,

We have encountered an error while using RTAI and we have implemented a fix but we don’t know if the error occurs because we are doing something wrong.

We use Ubuntu 14.04 32-bit Server Version and install RTAI using the procedure described at http://www.rtaixml.net/realtime-suite.

We then use another machine with MATLAB/Simulink to generate and compile code for that target. We are currently using Ubuntu 14.04 64-bit and install the RTAI required libraries via apt-get install librtai-dev:i386. Using the RTAI-LAB Matlab extension of RTAI 4.1 and slightly modifying the rtai.tmf file (include paths and adding -m32 flags) we are able to generate and compile code from our Simulink models.

Everything seems to work fine when the target machine has only one CPU. On multi-cpu machines we have encountered an error that prevents the initialization of multiple sub-rates.

In the RTAI-LAB rtmain.c lines 386-427 is where these sub-rates are initialized.

Is my understanding that the for loop on line 396-399 looks for unique names which don’t have an address assigned (looking for names that are free). In a multi-cpu architecture it appears that the all names are free as this code is executed in parallel? (collect all the rates first and then assign them to the available CPUs?)
At least all the for loops when the name assignment is done for all the sub-rates are executed before the call to rt_task_init_schmod is executed (so all names appear to be free). This observed behavior results in all rates being assigned the same name and thus the rt_task_init_schmod fails when it tries to initialize the second sub-rate (as it finds that name has been already been taken).

We were able to fix this by changing the manner in which the names are assigned. If we use the sample rate number (which is unique for every execution) then the rates can be initialized. We modified line 397 from

sprintf(myname, "TSR%d", i);



to

sprintf(myname, "%dSR%d", sample, i);

Is that a real bug or is there something we are inadvertently doing wrong?

Best,
Dr. Josep Virgili-Llop
NRC Research Associate
Spacecraft Robotics Laboratory
Naval Postgraduate School. Monterey, CA

_______________________________________________
Rtai mailing list
[email protected]
https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai