subtract function error

[Phatin]

Maybe it's a basic math error on my part, but I'm pretty sure that 9 minus 2 is 7, and not -2.

Seriously though, has anyone come across an instance where the subtract function messes up like this (see portion of screen capture)?  I've tried replacing the subtract function multiple times, and it can't be that the values are just changing so fast that I'm not seeing the true values being passed to the function, because the values shown are the retained wire values after I've stopped the program.  And if I start from a blank VI and just put in 9-2 it outputs 7 like it's supposed to, so it's not a problem with the machine. 

I have found ways of getting around this issue of course.  For instance, if I replace the subtract function with a compound arithmetic add function, and put in a -2 for the constant it works properly.  (Note: replacing with the simple add function and using a constant -2 does not work.)  Also, if I convert the variable value (represented by probe #38 in the image) to a double representation, instead of the I32 that it is, it also works.

Anyway, I'm just curious as to whether I'm the only one experiencing this bug, or if someone maybe knows why this bug is happening?

[RavensFan]

What version of LabVIEW are you using?

Can you post a VI that demonstrates this so we can try it out?

Were you using execution highlighting?  Just wonder why there are several seconds between the timestamps of those probels.

[Ben]

I have seen errors like that in the probes or exe-highlighting but not the data.

Ben

[Phatin]

I just recently upgraded to 2010.

Unfortunately, I don't think I can post this VI.  If I can create a simpler, stand-alone VI to duplicate this issue I may be able to provide that, but at this time I'm just going with one of the work arounds and moving on.

The difference in timestamps simply come as a result of when I created the probes.  As I mentioned, these are the retained wire values after I had stopped the program.  So the last update is simply when I create the probes.  In other words, if I wait ten seconds between creating the first and the second probe, that's the difference in time that will be shown.  Monitoring the timestamps while running does update the time nearly identically.

[RavensFan]

---

@Phatin wrote:

The difference in timestamps simply come as a result of when I created the probes.  As I mentioned, these are the retained wire values after I had stopped the program.  So the last update is simply when I create the probes.  In other words, if I wait ten seconds between creating the first and the second probe, that's the difference in time that will be shown.  Monitoring the timestamps while running does update the time nearly identically.

---

Retained values.  That is probably an important clue!  I'm sure Ben will have some ideas how that might work.  But it might be something along the lines of a buffer being changed after that wire.  Perhaps the wire for probe 38 since we can't see where that is coming from.  If the wire comes from the shift register, then the retained value you are seeing is probably the last value into the shift register at the end of execution.

How do the probe values look when you are actively running?  Or drop in temporary indicators on those wires.

[Ben]

---

@Ravens Fan wrote:

...  Or drop in temporary indicators on those wires.

---

Those always work (God willing!).

The probes are helpful when they work but if they fail it is hard to duplicate and even if you do, they are low-priority since they are not show-stoppers.

I do not use the "retain" setting since performance is is highly desirable and I have never had a chance to benchmark if they impact performance.

Ben

[Phatin]

  I did drop in some temporary indicators.  I also went ahead and expanded the screen capture to show a bit more of the local VI so you can see that the results being fed to the subtract function should not be changing, and that because of the error, it essentially locks up the VI since it won't read any more values with the read VI.  Anyway, it can still be seen that the subtract function is still errs.

  I've never really noticed a lag in performance with the retain value feature turned on; however, I did for the heck of it turn it off.  And to my extreme astonishment, the subtract function begins to operate correctly.  Because as I understand the feature, it should not be influencing the results of the program in any way; it should just be recording the results for later viewing.  And it doesn't interfere if I try it in a simpler VI.  So unfortunately I'm still at a loss as to why the error is occuring, but at least that helps to narrow down the issue, and it's one more option for working around it.

[RavensFan · Accepted solution]

It's possible you have found a bug in the behavior of the retain values system.  Since LV 2010 had some changes in the way code is compiled, it's possible it was introduced there.  If you have the means, try running your VI back in LV 2009 and see if it has the same behavior with retain values on and off.

If someone from NI sees this thread and jumps in, they may ask for a copy of your code that you could send to them privately for them to try out and figure out what is going on.

[Ben]

agreed!

TO determine bug or not, NI is going to have to duplicate it since timing can make the difference big-time. In the above image, if the "x" was zero on a previous iteration adn it has not bee updated, then "-2" is correct.

Ben

[RavensFan]

---

@Ben wrote:

agreed!

TO determine bug or not, NI is going to have to duplicate it since timing can make the difference big-time. In the above image, if the "x" was zero on a previous iteration adn it has not bee updated, then "-2" is correct.

Ben

---

"Timing ... difference big time" in a thread about subtraction.  That's funny.