Odd subtraction behavior

[arcranda]

I'm using Tick Count (ms) to calculate the delay between two events (see attached VI), but for some reason the subtract function doesn't want to compute the correct difference.  

It the attached screenshot, both events occured at tick count 25145544. But for some reason 25145544-25145544 = -849.

Thoughts? 

[crossrulz]

Do you get these results repeatably?

This is a total shot in the dark, but what if you didn't convert to I32 first?  Nothing else is screaming at me.  But there's probably something obvious in there.

[arcranda]

The error does happen repeatably.  Although, the answer changes (but never to the correct one).  Error persists regardless of what I convert to.  Long word is Tick Count (ms)' native output and it gives me the wrong answer.  Long int gives me the wrong answer. DBL gives me the wrong answer.  

[nathand]

I can't see any obvious error either.  What happens if you also check for equality between the two tick counts?  Does it report that they're equal?

[arcranda]

When I check for equality it reports that two obviously equal quantities are not equal. 

[ErnieH]

Try this. It will synchronize your front panel terminals so they display on the same iteration.

[Ben]

If you just left them as "U32" what happens?

Ben

[arcranda]

Ben - error still persists even if the tick counts are U32s. 

Ernie - you might be on to something.  

I placed indicators for (what should be) the same value inside and outside of a sequence structure.  I also included some boolean comparisons.  What I noticed is that one of values inside of the sequence structure was inheriting the value of its counterpart outside of the sequence structure from the previous iteration.  I don't have an explanation for that behavior.  And while indicators claimed some quantities were equal, boolean comparisons claimed they were not equal.  And vice versa.  SR initialized.png has some screen shots of the front panel for 3 iterations. 

Then I tried uninitializing the shift register on the top while loop. This eliminated some of the anomalies, but not all of them.  In iteration 1 (see SR not initialized.png) the indicators claim DTR Ticks does not equal Stamp Ticks or Synched DTR Ticks, but the booleans claim they are equal.  Also, the indicators claim the difference should be 1, but the indicator from the subtract function says the difference is 0. 

Any idea why a shift register would effect the performance of the subtract and boolean comparison functions?  Any thoughts on where the remaining bugs are? 

[ErnieH]

The reason I put the sequence structure in was so the terminals would all be synced to the data on the same cycle. Without it, you would be displaying new and old data until the last loop finishes, causing it to look like and error. When the loop runs again, one of the Ticks could  update immediately  while it waits for the other loop to finish. It could go so fast you do not see it.

[altenbach]

---

@arcranda wrote:

BThen I tried uninitializing the shift register on the top while loop. This eliminated some of the anomalies, but not all of them.  In iteration 1 (see SR not initialized.png) the indicators claim DTR Ticks does not equal Stamp Ticks or Synched DTR Ticks, but the booleans claim they are equal.  Also, the indicators claim the difference should be 1, but the indicator from the subtract function says the difference is 0. 

---

This description is way too confusing for me. You have three while loops, so at least the word "iteration" is ambiguous. What is the point of the lower inner while loop?

Can you run your VI until all indicators have typical data, make the current values the default, then attach the VI again?

I don't see how you can ever reliably have the same tick count from two different while loops running asynchronously in parallel.

There is only a problem if values from the same wire differ along the data path. Do they?