LabVIEW MathScript computation speed improvement

[runningquig]

I am using a MathScript node to make calculations on an sbRIO FPGA module and the speed of these computations is critical.  What are some ways to improve the speed of calculations and is there a faster way to do matrix calculations than MathScript?  If I make the MathScript portion into a subVI will it improve the speed of calculations?

Thanks for any ideas

[Rishi_Gosalia]

Is it possible to share the specific .m code that you are trying to optimize? 

Thanks

Rishi Gosalia

Senior Software Engineer

National Instruments

[runningquig]

if j == 1
if i == 1
ESO1 = SpO2;
ESO2 = 0;
xhat1=SpO2;
xhat2 = .02;
xhat3 = 3;
Pkp1 = 10;
Pkp2 = 10;
Pkp3 = 10;
end
end
Sp_d = 0;
ess = 0.06; %adjust? originally 0.05 (ess=error steady state)
HH = [1 0 0];
MM = 1;
RR = 2; %can be adjusted:
QQ = 0.001; %can be adjusted
Ts = .1; dt = .1;
beta = exp(-300*Ts);
Lp = [1-beta^2; ((1-beta)^2)*(1/Ts)];

A = [-xhat2 xhat3*xhat2 ; 0 0]; B = [xhat3*xhat2;0];
C = [1 0 ]; D = 0;
E = [ 0 1];

STM = eye(2) + A*Ts;
Gam = (eye(2)*Ts+.5*A*(Ts^2))*B;
J = 0;
Lc = inv(STM)*Lp;

u_ESO = [Uhat ; SpO2];
xhat_ESO = [ESO1; ESO2];
xhat_ESO = (STM-Lp*C)*xhat_ESO+ [Gam-Lp*J Lp]*u_ESO;
yd = (eye(2)-Lc*C)*xhat_ESO + [-Lc*J Lc]*u_ESO;

if yd(2) > 0
U_EKF = Uhat;
else
U_EKF = Uhat+yd(2);
end
%got this far - why is there random number generator?
q = sqrt(QQ)*randn;
wp1 = sqrt(QQ)*randn;
wp2 = sqrt(QQ)*randn;
Pkp = [Pkp1 0 0;0 Pkp2 0 ; 0 0 Pkp3];

LL = [q*dt 0 0; 0 dt*xhat2^2 0 ;0 0 dt];
FF = [1+dt*-xhat2 dt*(-xhat1+xhat3*U_EKF) dt*xhat2*U_EKF;0 1-2*dt*xhat2*wp1 0; 0 0 1];
Pkm = FF*Pkp*FF' + LL*QQ*LL';
KK = Pkm*HH'*inv(HH*Pkm*HH' + MM*RR*MM');
xkm = [xhat1+dt*(-xhat1*xhat2+xhat3*xhat2*U_EKF); xhat2+dt*(wp1*xhat2^2); xhat3+dt*wp2];
xkp = xkm + KK*(SpO2 - HH*xkm);
Pkp = (eye(3,3) - KK*HH)*Pkm;

if yd(2) > 0
U_dist = 0;
else
U_dist = 0.1*-yd(2);
end
xhat1 = xkp(1);
xhat2 = xkp(2)
xhat3 = xkp(3)

Pkp1 = Pkp(1,1);
Pkp2 = Pkp(2,2);
Pkp3 = Pkp(3,3);
dhat = yd(2);
ESO1 = xhat_ESO(1);
ESO2 = xhat_ESO(2);

% Control
err = Sp_d - SpO2;
Kp = ((1/ess)-1)/xhat3;
U_prop = Kp*err;

Control_Signal = U_prop + U_dist;

if Control_Signal<0
Control_Signal=0
end

[timtamslam]

Hey Runningquig,

I just want to clarify with one point as well, you mentioned "I am using a MathScript node to make calculations on an sbRIO FPGA module"

Are you looking to program the FPGA directly or develop for the sbRIO's real-time processor?

You also mentioned, "speed of these computations is critical", what kind of performance are you looking to achieve (loop speed, allowable max jitter, etc)?

[Rishi_Gosalia]

I noticed that your .m code requires two inputs, SpO2 and Uhat. What are the expected data types for these variables. Is it possible for you to put the .m code in a MathScript node with the two inputs with some test data and post the VI?

Thanks

Rishi

[runningquig]

I put in some dummy data so you can see how it is intended to work.  When you run it on your computer it will calculate very quickly.  The problem is I am running this in a VI that calls the FPGA.VI and when I run this code it takes about 10-15 seconds for the loop to calculate 50 iterations.  I need these same 50 iterations to be calculated under 5 seconds, hence the speed of calculation question.

I'm durrently trying to convert the mathscript code provided into more basic Labview functions which is very tedious and is taking awhile.

Thanks for any help

[Rishi_Gosalia]

I understand the problem. I suggest you wait for me to take a look. If need be, I'll be happy to convert the VI to G for you. 

Rishi

[Rishi_Gosalia · Accepted solution]

Please look at the attached VI. It has your original .m code, my modifications to your .m code, and the G code equivalent to the modified .m code. First, let me describe to you the numbers I saw on a cRIO 9012 for each of the three approaches.

I ran each of the three approaches for hundred iterations, ignored the first 30 iterations to allow for memory allocations (which caused a huge spike in run-time performance on RT), and then took the average run-time for each loop iteration for the remaining iterations

Original M: 485 msec/iteration

Modified M: 276 msec/iteration

G: 166 msec/iteration

The modifications I made to your .m code are the following:

(1) Added ; to end of each line to suppress output (used for debugging)

(2) Moved the random code generation out - used whitenoise (seems like that's what you were doing)

(3) Switch on the data type highlighting feature. Noticed that majority of the data was casted to complex, although didn't seem like you needed the complex domain. The source was sqrt function. Modified it to using real(sqrt(...))

This improved performance by over 40%. I believe more can be squeezed if you follow the documentation - Writing MathScript for Real-Time Applications. 

Then, I took the MathScript you had and wrote equivalent G leaving the algorithm as is. This gave us performance improvement of another 40% over the modified G. This is a known issue that on slow controllers MathScript adds a 2x penalty to equivalent G. We are currently investigating this issue and may be able to fix it in a future release.

If you profile the G code, you will notice that most of the time is spent in matrix multiplication. Unless you rethink your algorithm, I doubt this can improve further.

Let me know if you have questions

Regards,

Rishi Gosalia

[runningquig]

Thank you Rishi_Gosalia!  This was a very thorough response and I really appreciate the time you spent to re-work the code in 2 different ways as well as explain what was going on in each case.  This was extremely helpful!

One last thing:  Could you possibly save those files as a labview 2010 VI?  I have version 2010 and cannot open a 2012 VI.

[Rishi_Gosalia]

Attached are VIs saved in LV 2010.

- Rishi