Any change in code causes data to change from good to bad

[bomluuk]

I have a vi that receives its data from a UDP stream.  A C# created dll is used as a stream file (order of data, and size (char, short, Long, and Double))

The issue is this: if I change any part of the code and then run the vi, the data that used to show good (ex 28 volts) becomes bad (ex 15154898762 volts).

I have played around with rebuilding the .dll, but I can't get a solid way to remedy this problem.  It seems to have worked sometimes, and not others, but I have been stuck with the bad data version for the past 2 hours.

I am not able to post my code.

I have searched and have not come across any situation like this.

I am new to posting here so please forgive me if I have omitted any helpful data.

Thanks.

[billko]

---

@bomluuk wrote:

I have a vi that receives its data from a UDP stream.  A C# created dll is used as a stream file (order of data, and size (char, short, Long, and Double))

The issue is this: if I change any part of the code and then run the vi, the data that used to show good (ex 28 volts) becomes bad (ex 15154898762 volts).

I have played around with rebuilding the .dll, but I can't get a solid way to remedy this problem.  It seems to have worked sometimes, and not others, but I have been stuck with the bad data version for the past 2 hours.

I am not able to post my code.

I have searched and have not come across any situation like this.

I am new to posting here so please forgive me if I have omitted any helpful data.

Thanks.

---

I'm guessing you have serious race issues with your VI and every time it recompiles, you roll the dice and maybe it works, maybe it doesn't.

[JÞB]

OK, First, why are you using a C# DLL to write a file?  LabVIEW writes files very well.

Without your code we can only guess (As Bill has demonstrated)  Guessing without the 8-Ball in my cube does not often solve issues.

So, What did you change to make the data bad?  Cluster Order? a coersion?  any example code to help us reproduce this would help us help you.

What is the data type of "28"?

[bomluuk]

---

I'm guessing you have serious race issues with your VI and every time it recompiles, you roll the dice and maybe it works, maybe it doesn't.

---

Ok.  I'll look into that.

[bomluuk]

---

OK, First, why are you using a C# DLL to write a file?  LabVIEW writes files very well.

Without your code we can only guess (As Bill has demonstrated)  Guessing without the 8-Ball in my cube does not often solve issues.

So, What did you change to make the data bad?  Cluster Order? a coersion?  any example code to help us reproduce this would help us help you.

What is the data type of "28"?

---

The C# DLL is created before hand.  It is what creates the Property node (i think that's the correct term) that has the list of parameters.  It is read from, not written to.

One example of  a code change I made that made the data bad: Added an addition operator icon to the block diagram, then immediately deleted it from the block diagram.  I did not touch anything else, nor connect any wires to the addition icon.  That is what I meant by any change in code.

The data type of 28 is a double in LabVIEW.  I think it's a 4 bit long in the dll.  I'll have to check when I get to work tomorrow.

[GerdW]

Hi bomluuk,

The data type of 28 is a double in LabVIEW.  I think it's a 4 bit long in the dll.

Facts:

- a DBL takes 8 byte of memory.

- a "4 bit long" number is a nibble or half of a byte

- a SGL takes 4 bytes

- you can convert a SGL to a DBL…