PseudoInverse Matrix Glitch

[aanthis]

I have a VI that uses PseudoInverse Matrix.vi and am having some problems with it. For instance, if you plug in x = 0.0001 and y = 0.00016 into my code, the pseudoinverse of my A matrix blows up. But if you use y = 0.00014 or y = 0.00019 it works fine and matches with the result I calculate using MATLAB. There seems to be no rhyme or reason to what values cause it to blow up. Has anyone had trouble with pseudo inverse before?

See attached code.

Thanks

[altenbach]

As a first step you need to eliminate the glaring race condition. (Your local variable will potentially get read way before its indicator gets updated with new values. Use a wire and eliminate the local!)

I don't know your definition of "blows up", but all three y values given work just fine for me. Can you elaborate what you are seeing?

[aanthis]

Thanks for your reply. I eliminated the local variable and wire the matrix directly now but still have the same problem. When I type in X=0.0001 and Y = 0.00016, every value in my pinv(A) matrix becomes -3.158x10^17 which is nowhere near correct. In contrast, if I use, Y = 0.00015 or Y = 0.00017, the numbers in pinv(A) exactly match the number I find using the PseudoInverse command in MATLAB (nothing larger than 10^4). This happens for many seemingly random combinations of numbers.

[aanthis]

Update: If I run this code from my computer, then it works fine. It is only when I deploy it and run it on my PXIe-8135 controller that this glitch happens. So perhaps there is some sort of bug in the way that my DAQ device handles the pseudo inverse command? Here is my hardware setup:
PXIe-1082 Chassis

PXIe-8135 Controller

PXIe-6363 AI

PXIe-6739 AO

PXIe-6368 AI

Software: LabVIEW 2020

[altenbach]

---

@aanthis wrote:

Update: If I run this code from my computer, then it works fine. It is only when I deploy it and run it on my PXIe-8135 controller that this glitch happens.

---

Curious. Sorry, I have no experice with that. Let me ask around. What OS  is running on the controller? Is this plain LabVIEW or LabVIEW RT? I assume you have  more than just LabVIEW base. Do you know if Intel MKL libraries are available?

[aanthis]

This picture shows the software that is running on my PXIe setup. I am using LabVIEW RT 20.0.0

[Bob_Schor]

---

@aanthis wrote:

Update: If I run this code from my computer, then it works fine. It is only when I deploy it and run it on my PXIe-8135 controller that this glitch happens.

---

I think you just pin-pointed the problem -- you are trying to run "Host" software, developed for Windows, on a RT-Controller running NI's version of Linux-RT.  Are you using the Controller as part of an RT Project?  I notice you have Network Streams installed, so you certainly could run a Host/Target RT Project, with the File I/O and heavy-duty computation being done on the (Windows) Host, where the Pseudoinverse VI works, and the time-critical RT Acquisition and Control code done on the PXI-based system running LabVIEW-RT under Linux-RT.

Bob Schor

[altenbach]

Well, math is math and it should work correctly on both systems.

Let's quickly recap (please correct me if I am wrong!):

On the RT system (linux?), the pseudoinverse works for most inputs, but fails for some specific values of Y. Is this correct?

• x=0.0001, y=0.00016 (does not work!)
• x=0.0001, y=0.00014 (works!)
• x=0.0001, y=0.00019 (works!)

In contrast, on the desktop system, All three parameter sets give valid results.

If this is all true, something seems wrong with the way the calculation is done on the RT system. What is the error output in all six scenarios above? Can we assume that the output of the formula node is identical between the two systems?

[aanthis · Accepted solution]

Hi everyone,

Thanks for all of the help. I ended up circumnavigating the issue by building a pseudo-inverse for the matrix myself rather than using the VI. In order to do that, I am now using the SVD VI. See updated code attached. I never figured out the bug but I am not going to pursue it any further. 

Thanks again,

Austin

[altenbach]

---

@aanthis wrote:

I ended up circumnavigating the issue by building a pseudo-inverse for the matrix myself rather than using the VI. I

---

Great that you found a workaround, but if there is a inherent bug in the code, NI should fix it. I'll try to make sure they are aware of this.

(Your homegrown "pinv" seems a big kludgy. Let me see if I can simplify it a bit (for example the sequence structure serves no purpose!))