anton.lindner

X-Post to the NI LabVIEW discussion forum.

Hi LAVAs, I try to solve a system of linear equations AX = Y with LV 7.1. I played around with the "Solve Linear Equations.vi" (SLE) and the "Inverse Matrix.vi" (IM) from the linear algebra palette and found some strange behaviour: I expected the SLE-vi to be much faster than the IM-vi. A small test (see attachment) shows that this is not the case. LabVIEW help tells us that the SLE-vi uses LU-decomposition for NxN-matrices. In the SLE-vi a function named CxEqsSetBySVDDri_head in lvanlys.dll-library is called. I think the SVD in the function name means singular value decomposition. This would be the right algorithm for solving rectangular matrices but not for square matrices. This would also explain why the function is so tedious slow compared to the IM-vi. I found the function CxEqsSetByLUDri_head in lvanlys.dll (LU-decomposition) which, I think, should be used for NxN-matrices. In the attached vi I used the modified SLE calling CxEqsSetByLUDri_head to check the speed against the IM-vi. Using a 10x10 Matrix for A and a 10x2 for Y, the modified SLE-vi with LU-decomposition should be 10/2=5 times faster then the IM-vi which has to invert (10/10 = 1) the whole matrix. Unfortunately it is only slightly faster (factor 1.5 to 2) than the matrix inversion. Either the matrix inversion algorithm is so fast that it can almost beat the (modified) SLE or the performance of the CxEqsSetByLUDri_head-function was such a flaw that it was intentionally not used My problem is, that I have to solve small linear equation systems of the size in the example, as fast as possible. Has anybody an idea to speed the things up? Thanks, Toni P.S. Would be nice to know, if this behaviour has changed in LabVIEW 8.5. I only have 7.1 availible.

Hi, there are different vis for FFT, IFFT, Hilbert-, Wavlettransformations etc. in the signal processing section of all LabView-versions except the base package. Could you explain a little bit more, what you want to do exactly? Toni

- stupid comment; deleted -

Hi Jeff, hi Jean-Pierre, thanks for your suggestions. @Jeff: Thanks for bringing Lua into my scope; I wasn't ware of it. I will still try using G if possible because I have the feeling that I should get more comfortable to the possibilities of LabView unless I try something else. @Jean-Pierre: I wanted to try different cost-functions but you are right I will start with least-square. I will reply if I figured out more. Toni

I am sorry, my description of the problem was mistakable. I attached a picture to better illustrate my problem. In the upper half the "Conjugate Gradient nD.vi" is used as described in the examples that ship with LabView and works just fine. In the lower half of the picture I outlined what I would like to realize. Basically I want to do a curve fitting of a model to measurement values. So I would start a simulation with a rough guess of the variables which are fed into the simulation vi. After calculating the response of the model, the measured values care compared with the simulated ones and a cost function is caluclated. This cost function should be minimized by the "Conjugate Gradient nD.vi". The minimum output is fed into the simulatin vi again and after a few iterations the simulated values hopefully fit the measured values. I cannot use the curve-fit vis that ship with LabView because I need a specialized model that I have to fit.

I had a similar problem with a data socket (OPC) connection to a OPC-server. Some integer-variables had to be sent as I8. Sending them as I16 or I32 caused the OPC-server to stop responding and it seemed as if the handle had been destroyed. But it had nothing to do with the remote OPC-item name or the handle, it was just the data-type of the variable that caused the trouble. Greetings, Toni

Hi all, is it possible to call a (sub)-vi from the formula node? Motivation: I would like to minimize a pretty complicated function that I have already coded in G. I thought about using the "Conjugate Gradient nD.vi" which should be well suited for this problem. Unfortunately the vi needs a formula-string as input. My (already coded) function is full of matrix operations with complex numbers and I can't easily re-write it in the formula-string-style :-( So it would be a great benfit if I could call my sub-vi from the formula-string. Are there any other solutions than calling Matlab (which I don't have availible) from LabView? Have a nice day, Toni X-Post to NI-LabView-Forum Download File:post-2-1156834705.zip

mballa, thank you. In fact it was exactly as you described. I found the non-typedef enum while I was reprogramming.... Greetings, Toni

Hi Randy, thanks for your fast answer. Although the original problem still exists I couldn't reproduce this behaviour with a new vi. Seems like a one-time issue. Curious..... So I will re-programm the vi and see what happens. Toni, the surprised

Hi all, I use an enum at the case selector input of a case structure to build a small state machine. The enum is defined as a type def, so that I can add states easily without editing all enums by hand. If I connect a case structure to the enum, the first time, the case structure labels are generated from the enum labels. Unfortunately if I add a state to the enum, the case structure labels are set to the pre-defined labels e.g. 0 (default), 1, 2, .... Changing case structure to sequence and back didn't work, adding cases also didn't work. Has anybody an idea how to get the labels back to the case structure? Greetings, Toni