Without providing any code it sounds to me like you have a Race Condition.
In short, a Race Condition is a Computer Science term used to describe when two threads (concurrent computer programming segments) access the same element "at the same time". When I say "at the same time" i mean they "try" to access the same element at the same time. As a result, you have a "race' where the output is different depending on who gets to access the data first.
A simple example:
You have $5 in the bank that you and your wife share. Your wife calls you and tells you to put more money in the account so she can buy shoes. Unfortunately, your wife is impatient.
At "roughly" the same time:
1. You try to deposit $10 before your wife gets out money for the shoes.
2. Your wife tries to buy the shoes with a check (that is electronically/instantly cashed).
You have a few outcomes:
1. You deposit the money just before she buys her shoes. This is the desired outcome.
2. Your wife tries to buy the shoes with the check just before you deposit the money. Your check bounces and now you have an unhappy wife, an unhappy bank, and an unhappy store.
This is probably what is happening in your program. For instance (in C)
int x = 0;
Program A:
x = x + 5;
Program B:
x = x + 5;
If you tell it to run program A and then B on two different threads, you have a couple of outcomes:
1. Program A goes first and adds 5 to x. (x = 5 now). Then Program B goes and adds 5 to x. (x = 10 now)
2. Program B goes first and adds 5 to x (x = 5 now). Then Program A goes and adds 5 to x (x = 10 now).
3. Program A and B go at the same time (approximately -- the computer functionality is being abstracted here) and both see that X = 0. So they take 0 and add 5 to get (x = 5). Both programs store "5" in "x". (x = 5 now).
This causes problems since you cannot guarantee your output. This is likely what is happening to you.
Why is this happening and how to fix it?
Well, there are really two ways. First, you could edit the .dll (if you wrote it) and add Mutual Exclusion via Semaphores. (Complex computer elements that ensure shared resources between threads don't cause Race Conditions). This is likely not your answer unless you wrote the library.
The second option is a LabVIEW issue that you can control. By linking the dataflow to these two calls in parallel, LabVIEW will automatically run them on seperate threads (to try to do twice the work at once to decrease overall execution time). To prevent this, ensure that one runs before the other by wiring the errors in serial. (One before the other).
**Note: It is also possible this isn't your issue, but you described a common Race Condition issue so I am assuming the above should apply to you. If not, it is good to know nonetheless 😄
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Edit:
Upon second reading it could also be a memory allocation/garbage collection issue. If you did not allocate or deallocate memory in the "dll" appropriately, it is possible that your pointers are overlapping one another and reading garbage off the stack in one instance.
Without your code or a more actual description of the problem (using technical terminology), I can do nothing more than suggest "possible" problems.
Edit2:
I also presume the "dll" was created using a C language. They have multiple uses of the word "static". Read here for more info on which type you are using. (This is another instance in which attaching actual code would help clarify your problem.)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If someone helped you out, please select their post as the solution and/or give them Kudos!
