Stopped passing input parameters

[AlexF3449]

Hi all,

My code was working as intended in 3/4 cases of this switch. I made some changes to the not working case, and verified the other working cases remained functional, then I ran the last, non working case, and now no cases in this program or previous versions of it before the change work. the error code is -200003, "the input values must be > 0". After a little probing and testing, It looks like the problem is that when I pass my array of input parameters into the function, none make it through, they are all read as 0 inside the static reference VI. This results in f(X, a) = NaN for some cases, causing the error in the Lev-Mar function. How would I fix this? Attached are some screenshots of the call for the Lev-Mar function and the probes. Values passed into the function should be between 0 and 6 but some values can be as precise as 10^-4. The last value in the array passed in is the vertacle shift which tends to be between -50 and 50.

Thanks

[wiebe@CARYA]

A VI would be helpful...

[altenbach]

Yes, we need the actual VI.

Even on a picture, there are plenty of things wrong. Why are you sending the "data" as variant attributes instead of just a variant containing an array of two values? Why are they DBL but you are reading them as integers? Why are there so many local variables? Are you sure all terminal have received data before you are reading the local? Why not use wires instead? You are doing "fitting", not "optimization".

[AlexF3449]

the local variables are all variables in the function. I've passed the data in like that because that's how it first occurred to me to do it, and probing shows I am getting the right values for d1 and d2 to pass through. I have fixed the issue where I was reading the dbl as an integer. Some of my other debugging seems to have fixed the issue. Thanks for your help.

[johntrich1971]

---

@AlexF3449 wrote:

the local variables are all variables in the function. 

---

I don't understand what you're saying here, but the local variables look like a race condition waiting to happen. You're code looks like spaghetti and will be extremely hard to maintain. I recommend that you go through the training materials at the top of this board. 

---

@AlexF3449 wrote:

Some of my other debugging seems to have fixed the issue. Thanks for your help.

---

What debugging fixed the issue? If you don't know how you fixed the issue then there's nothing to say that it won't break again. As far as that goes it could be a race condition which can sometimes give erratic behavior.

[billko]

---

@johntrich1971 wrote:

---

@AlexF3449 wrote:

the local variables are all variables in the function. 

---

I don't understand what you're saying here, but the local variables look like a race condition waiting to happen. You're code looks like spaghetti and will be extremely hard to maintain. I recommend that you go through the training materials at the top of this board. 

---

@AlexF3449 wrote:

Some of my other debugging seems to have fixed the issue. Thanks for your help.

---

What debugging fixed the issue? If you don't know how you fixed the issue then there's nothing to say that it won't break again. As far as that goes it could be a race condition which can sometimes give erratic behavior.

---

I have to agree.  From looking at that picture, it seems to be a disaster waiting to happen.  You could be reading stale data and not even know it.  The probes tell you nothing about that because you don't know when it arrived at the probe relative to when the value was set.  If you don't know how you fixed something, it's probably not fixed.  Maybe you rolled the dice and with this recompile, it worked.  Who knows what happens the next time the VI gets recompiled?

[AlexF3449]

Switching from a bounded to an unbounded nonlinear fitting function has allowed me to run the program without any errors interrupting the run; however I now have a very inaccurate fit in this particular case. I'm reviewing the materials like you suggested, and have attached the vi and the static reference VI. the Vi with main in the title is the main one, the other is the static reference vi. I cannot attach a typical data set because the excel spreadsheets tend to have thousands of rows, so the file size is far too large. the case which does not work as expected is case one, I have provided a screenshot of the actual data (green) the model with the initial parameters (red) and the fitted model (white) to try to show what is happening. The code looks very messy because I am doing the cross product of several matrices, and while there is a cross product function in labview, storing the 1d array entering the static reference vi in matricies and taking their cross product results in a dbl and the information leaving the static reference VI should be a 1d array. I have found it easier to write out the matrix multiplication than to convert to matricies, take a cross product, and then try to rebuild the array in a loop before passing it out, especially because I am only taking 2 cross products, which I was able to write out relativley quickly and with less critical thinking than making some loop.

[AlexF3449]

I forgot to include this in previous comments, but additional testing with a very high tolerance (10,000) and low iteration (1) does not result in a graph that is essentially identical to the input parameters. When I run the program under normal tolerance and iteration, the resulting "best fit" parameters do fit the data relatively well, but the graph does not match the best fit parameters I get back. I have checked the portions of my code related to graphing the best fit, and they are error free.