Preallocated clone subvi appears to be intermittently nonresponsive. What's wrong?

[matteci]

Rather than look long and hard for what would be an elegant vi I made my own. I don't understand why it's periodically not working:

I have a situation where I want to delay the change of an integer value by a specific time. This is within a deterministic loop and cannot be blocking. OK, so I made the attached "Delay Integer Change" vi, which worked great at first.

After other code changes and multiple deployments to a crio 9068, this VI suddently became nonresponsive. While running interactively, the owning VI appears to work fine, debug indicators on wires leading to this vi display correct data, but this VI does not update its FP to correspond with the values wired to its terminals. If I run it by itself on the target and play with the front panel it works as expected/designed.

I am of the impression that I can use a while loop and shift registers and NOT have it behave as a FGV (i.e. can be used in different places for unrelated purposes) as long as it's reentrant. This problem occured while configured for preallocated clone reentrance.

What am I doing wrong? I'm hoping that this will be part of a reliable embedded application and would love to learn from a mistake within.... I will humbly accept any and all suggestions on how to do this better/smarter/easier.

Thanks in advance.

[Joel-I]

Hi matteci,

When you deploy a Real-Time Executable, front panel objects are disconnected.  If you want to have a user interface with an executable running on your target, you'll have to create a VI on your Host side that communicates with the RT target to update a front panel.

Regards,

[matteci]

Hi Joel,

Thanks for the response. I must have mis-spoken; I am running the toplevel VI interactively by using the run arrow. So I guess that it's not technically 'deployed' while I've been experiencing this issue. Other front panels still work, and I had previously experienced this front panel working correctly...

Any other possibilities?

[drjdpowell · Accepted solution]

You only change the integer if you happen to check when the time is EQUAL to the scheduled change time.  If you fail to check it during that one millisecond then it wont change until the MS timer wraps around in 4294967295 ms, which is rather unresponsive.  Normally for timeout calculations I would subtract old time from new time and check if it is greater than or equal to the timeout.

[matteci]

D'oh! I should've known better. Yeah, it would be good to write code that reacts sometime this month. Thank you for pointing this out. I got so comfortable with comparing iterations that I forgot I could still miss something.

As a newbie, I think I should ask:

---

@drjdpowell wrote:

 Normally for timeout calculations I would subtract old time from new time and check if it is greater than or equal to the timeout.

---

Is there a specific reason why this is preferable to, say, adding the timeout period to the old time, and then checking to see if that is less than or equal to the new time?

Is there less overhead on the comparison of smaller numbers, even if they are of the same representation?

Again, thanks, anything beyond your answer above is gravy.

[nathand]

It's an issue of handling roll-over properly. To make the math easier, let's say your timer is only 8 bits. The current time is 100, and you want to wait 60. So you add 100+60, and you wait until the new timer is greater than or equal to 160. Sounds right. But now you do this again and the current time is 200. You add 200+60, which exceeds the maximum value of an 8-bit integer so the value rolls over and the result is 4. Now your loop checks if the current time is greater than or equal to 4, which is true immediately.

Let's say instead you do as drjdpowell suggests, and subtract the new time from the old time. Due to the magic of 2's complement math, the subtraction continues to produce the correct difference in time, even if the current time is 2 and the old time was 200. 2's complement math means that subtraction produces the same pattern of bits regardless of whether the inputs are signed or unsigned. 2-200 = -198, which has the same bit pattern as +58, which is the correct difference in time.

The same math applies with a 32-bit counter, of course. If you aren't familiar with 2's complement math, spend a few minutes reading about it, it's an important and clever computing concept.

[matteci]

I'll have to work on digesting that. Thanks for the insight, I'm poking through the wiki on it.

You LabView nuts are awesome!