Inconsistent output values in project. Possible race condition.

[dosinski]

I have a large project and many VIs. I've recently made a few changes to the topmost VI (can't remember what the changes were though)  which has lead to very odd test results, some of the time. I have a sub VI that grabs the model number off the DUT and outputs an enum. If the subVI outputs a 2, is should read as a 2 at the topVI. About 20% of the time, it outputs as a 0. In the top level, the output of the subVI connects to a typedef cluster which contains the typedef enum.

[Taki1999]

We'd need code to debug this. Sounds like you're correct in your assessment of a race condition.

[mikeporter]

At least post a screen shot of the top level. That will give some insight into what sort of clean up is needed.

Mike.

[dosinski · Accepted solution]

I figured it out. Turns out it was not a race condition. Because of where i placed my probes and where i set breakpoints, it looked like the data the subIV was outputting and the data in the top VI did not match up. Turns out the DUT has a firmware that returns incorrect data sometimes. 

[Bob_Schor]

---

@dosinski wrote:

I have a large project and many VIs. I've recently made a few changes to the topmost VI (can't remember what the changes were though) 

---

This is why many of us would never dream of writing serious LabVIEW code without some form of Version Control System in place (what Fabiola de la Cueva calls "A Time Machine").

Bob Schor