04-21-2011 12:37 PM
Well, with a diagram that large, you're bound to have trouble debugging.
In any case, I don't see the problem. I boiled it down to simple cases and got this:
And, LV gets the right answer.
So, my guess is that that array is empty (size 0) when it shouldn't be.
Blog for (mostly LabVIEW) programmers: Tips And Tricks
04-21-2011 12:58 PM
I agree with Steve.
You should consider using a State Machine make the code more readable.
Or some other architecture that would render the code readable.
On the surface, you should get the array size (let's say 4) - 3 = value (let's say 1).
Unless you get an empty array.
For us to see more with your existing code, I would recommend that you run it and then set all values to default, save it and post it. That way, we get to see what is in that last array before the strange calculation. If the array is empty, then we know what's wrong..
04-21-2011 03:17 PM
In order to have a helpful dialogue, lets assume that LabVIEW can still add and subtract, so we should look for where there is a problem in your code. What I can suggest doing since you removed the subVIs (I am sure with good reason) is to put a breakpoint on the wire where your probe 2 is in your image error.jpg. Then see if it adding correctly or not, my guess is that the code stopped at some point where the 4-3 subtraction had not yet happened. From that point on hit Ctrl-R to run to that breakpoint repeatedly, you should be able to catch where things go wonky this way.
I agree with everybody else, this code is extremely unruly. For your own sanity, you need to convert it into a state machine or make subVIs of your major loops, whatever makes more sense to you. I am guessing you are a domain expert rather than a LabVIEW artist by trade so I am sure you're not offended by these types of comments...
best,
C
04-21-2011 03:33 PM
well thanks everyone. i really appreciate your help. i know that if it was an empty array the result would be -3, but in the screenshots i posted you can see that the array size (in one case if i remember right) was 4 not 0, so it would have to give me 3.
i know it is not that readable yet, im currently just developing. and after it is working i clean it up. i know what a state machine is but i dont think it would apply here... no really sure, but a lot of subVIs would help clean it up. it basically has 3 steps but i dont want to get into detail. right now i make it work but i dont like the way i did it. instead of a subtract with a 3 constant i put 3 decrement operators in a row. and it works that way. but i just think it is plain stupid to have to put 3 decrements in a row for it to work. but oh well. what you are saying about the probe and the breakpoint, i did it that way. except thati put the breakpoiont before and hit the step botton until the operation was done and then screenshoted the diagram and probe values. so i hope that after a clean up the compiling sorts it out. maybe so much code is confussing the compiler.
04-21-2011 04:03 PM
Try dragging just that particular subract primitive into a new VI and see if it still fails in a super simple context. If it does, it MUST be a faked primitive as Altenbach surmised. There is no way LV2010 could have basic arithmetic bugs that have gone unoticed until now...
I Hope!
04-21-2011 04:05 PM
Try dragging just that particular subract primitive into a new VI and see if it still fails in a super simple context.
That's exactly what I did in the above ScreenShot.
the subtract operation is extracted from his VI.
It's genuine, not a forgery.
Blog for (mostly LabVIEW) programmers: Tips And Tricks
04-21-2011 04:10 PM
Oh yes, he posted the top-level code. I guess I should have tried it myself as I have LV2010.
Thanks Steve.
04-21-2011 04:13 PM
Superjugy wrote: what you are saying about the probe and the breakpoint, i did it that way. except thati put the breakpoiont before and hit the step botton until the operation was done and then screenshoted the diagram and probe values. so i hope that after a clean up the compiling sorts it out. maybe so much code is confussing the compiler.
humor me, try it the way I suggest, it might be different. Especially running to that stop multiple times and looking at the probes each time. Another way which would create a record would be to wire those as outputs to the edge of the loop, autoindexing, then attach an indicator to the outside edges (you'll have two array indicators), see what really was going in. If in fact there is a math bug that only becomes apparent when there is a lot of code, I think NI would and should be very interested.
04-21-2011 06:05 PM
there is a problem though, the next part in the for loop is a while loop that im trying to debug and it is currently getting infiniteiterations so i can't do the breakpoint thing you want me to do... sorry, for the time being i'll stick with the 3 consecutive decrements. thanks.
04-26-2011 08:05 AM
Hi,
If you want to exit the while at the iteration # 3 you might be able to compare a 2 with the terminal i and whenever it is true you might be able to exit the loop.