Shared Variables (LV 8.20) problem

[i2dx]

Hi folks,

I encountered the following unexpected behaviour, when using Shared Variables with LV 8.20:

I created a new Shared Variable (Single Process Type) with a custom control, which is typedef'ed. I thought, that, if I change the typedef, the type of the Shared Variable would change automatically, too. Instead, it sticks to the old type, which results in many broken wires.

Is this a bug? Am I making a mistake? What's wrong?

I'd like to file a product suggestion at ni.com, with the request, that Shared Variables, which are created with a typedef'ed custom type, auto-update from that typedef. But before I bother them, I'd like to be sure, that there's a "bug" ...

cheers,

CB

[Ton Plomp]

Hi i2dx,

It appears that a shared variable only holds the flattened data and not the type-def control...

See here

Ton

[i2dx]

Hi i2dx,

It appears that a shared variable only holds the flattened data and not the type-def control...

See here

Ton

thanks a lot!

=> product suggestion filed

[bsvingen]

The same problem exists when using call by reference nodes. Broken wires are afterall OK, because then it is much easier to find the problem. But when these red dots appear, it is very hard to track down. The solution is also awquard because it involves a deletion of the reference node and insert a new one - after the cause of the red dot has ben found (it seems that the by reference node remembers the last type and will not change it unless there is a broken wire).

[i2dx]

The same problem exists when using call by reference nodes. Broken wires are afterall OK, because then it is much easier to find the problem. But when these red dots appear, it is very hard to track down. The solution is also awquard because it involves a deletion of the reference node and insert a new one - after the cause of the red dot has ben found (it seems that the by reference node remembers the last type and will not change it unless there is a broken wire).

your're right. I first thought you could find coercion dots, if you enable "Show warnings in error list dialog by default", but the are not mentioned. Maybe that would be an other feature to request? "Find Coercion dots"?

[Ton Plomp]

your're right. I first thought you could find coercion dots, if you enable "Show warnings in error list dialog by default", but the are not mentioned. Maybe that would be an other feature to request? "Find Coercion dots"?

VI analyzer?

Here is some code is scratched, it uses for VI Analyzer, and allows you to browse to the coercion dots!

Beware, you need VI Analyzer to run this!

Ton

Download File:post-2399-1161183893.zip

[i2dx]

VI analyzer?

Here is some code is scratched, it uses for VI Analyzer, and allows you to browse to the coercion dots!

Beware, you need VI Analyzer to run this!

yes, but shouldn't that feature allready exist in the BASE Package, due it's importance? What do others think about that?

[Mellroth]

yes, but shouldn't that feature allready exist in the BASE Package, due it's importance? What do others think about that?

I agree, it could be next to the "Show buffer allocations.." tool.

/J

[Ton Plomp]

yes, but shouldn't that feature allready exist in the BASE Package, due it's importance? What do others think about that?

I agree, it could be next to the "Show buffer allocations.." tool.

I don't agree, this issue (coercion dots) are more something for the advanced users, I agree that you should try to minimize them, but I don't take great effort to remove them.

Ton

[Guillaume Lessard]

I don't agree, this issue (coercion dots) are more something for the advanced users, I agree that you should try to minimize them, but I don't take great effort to remove them.

In general, they're not a big deal, but in id2x's case finding the coercion dots is necessary to fix code broken by shared variables! This is *not* an advanced user issue, it's basic functionality.

[Mellroth]

...I don't agree, this issue (coercion dots) are more something for the advanced users...

I haven't teached LabVIEW for some time now, but if I remember correcty, coercion dots is introduced in BasicsI (or II). If it still is something that NI teach new LabVIEW programmers they should avoid, there should also be a tool that helps you find them.

/J

[dthomson]

CB,

I brought this up with NI during the 8.20 beta. If I recall correctly, this is on their radar for possible improvement in a future version. (Though I love Shared Variables, I think there is ample room for improving them in a number of regards...)

Dave

Hi folks,

I encountered the following unexpected behaviour, when using Shared Variables with LV 8.20:

I created a new Shared Variable (Single Process Type) with a custom control, which is typedef'ed. I thought, that, if I change the typedef, the type of the Shared Variable would change automatically, too. Instead, it sticks to the old type, which results in many broken wires.

Is this a bug? Am I making a mistake? What's wrong?

I'd like to file a product suggestion at ni.com, with the request, that Shared Variables, which are created with a typedef'ed custom type, auto-update from that typedef. But before I bother them, I'd like to be sure, that there's a "bug" ...

[crelf]

...coercion dots are more something for the advanced users...

I totally disagree - coercion of data is one of the very first things that should be taught in programming as the dangers of implicit coercion can be both devestating and difficult to track down for new users.

[Louis Manfredi]

I don't generally do "me too" posts, but I've got to chime in here & agree with Crelf-- Ignoring coercion dots can cause all kinds of problems ranging from mere slow performance to out & out mysterious program failures!

Louis

[Ton Plomp]

OK, I get the point

Louis could you describe what kind of failures you mention?

But a more serious issue (which I think is very very serious) is that a convert to U* from a I* doesn't convert the value but typecasts it:

This goes for U8,U16,U32,U64

It shows no coercion dots, this issue will be quite hard to deal with...

Ton

[Mellroth]

This goes for U8,U16,U32,U64

It shows no coercion dots, this issue will be quite hard to deal with...

This is the same as if you just skipped the conversion node, except that you would see a coercion dot on the U8 terminal, eventhough the value is typecasted.

Actually, this is a good example of when you could run into trouble if you perform any actions on the coerced U8 value. If you see a coercion dot on the U8 terminal, you have to deal with the I8 number so that you get the conversion that you want. In this case, you should add a range check to remove negative numbers.

/J

[i2dx]

But a more serious issue (which I think is very very serious) is that a convert to U* from a I* doesn't convert the value but typecasts it:

[Ton Plomp]

[crelf]

Convert (IMHO) means that the value will be adapted into the new data format, it is normal behaviour when converting from float to int that overflow is limited to the maximum value of the int, not a typecast.

I'm just speculating here (I'd test it more thoroughly, but am a little strapped for time at the moment) - is it possible that the coercion function converts the input down to a array of bits (that's all that numbers are anyway, right?) and then up from there to the new type? Your're right - that's typecasting, and I'd have expected conercion not to do that... Anyone from NI care to chime in with their :2cents: ?

[Kevin P]

Convert (IMHO) means that the value will be adapted into the new data format, it is normal behaviour when converting from float to int that overflow is limited to the maximum value of the int, not a typecast. That's what happens here!

I think a 'negative' UINT should be zero! I'd expected an 'inrange and coerce action' when converting.

If I wanted a typecast I'd used that one

Ya know, I never sat & thought hard about it before -- I just observed that I32<-->U32 "conversions" would leave all the bits alone and simply reinterpret them, typecast style. It's probably more proper to use the typecast function, but it's more of a pain to navigate to and requires more steps to implement, and uses more space.

So I think I agree with you philosophically, but I happen to rely on that typecast-like behavior very extensively in a lot of my counter data acq apps. For example, I normally take encoder data as big arrays of U32 counts which get slung around my apps through queues or whatever. I very often want a signed position count value though, so I just throw in a "to I32" conversion function knowing that no new array is allocated and the array elements don't even need to be individually manipulated. It's a CPU freebie that's become S.O.P. for me.

It'd be nice if there were a more prominent native way to get "in range and coerce" behavior out of nodes as simple and small as the convert functions, provided that the existing ones maintain their current behavior...

-Kevin P.

[JDave]

Convert (IMHO) means that the value will be adapted into the new data format, it is normal behaviour when converting from float to int that overflow is limited to the maximum value of the int, not a typecast. That's what happens here!

I think a 'negative' UINT should be zero! I'd expected an 'inrange and coerce action' when converting.

I have felt the same way and since it came up in my programming again since reading this post, I thought I might chime in that I DO NOT like it. I would classify it as a bug, because it does not fulfill it stated functionality.

To Unsigned Long Integer - Converts a number to a 32-bit unsigned integer in the range 0 to (2^32)

[EJW]

I'd expected an 'inrange and coerce action' when converting.

Ton

Something like this then ---

Something like this then ---

[Ton Plomp]

Something like this then ---

Yep, and have false as the default (so it will be backwards compatible)

Now the creepy thing: why do you quote yourself? :laugh:

Ton

[EJW]

Yep, and have false as the default (so it will be backwards compatible)

Now the creepy thing: why do you quote yourself? :laugh:

Ton

I really have no idea why I quoted myself.

"I really have no idea why i quoted myself."

[Aristos Queue]

All the numeric conversions are either simple bit reinterpretations or IEEE standards for floating point behaviors. I cannot name any programming language that treats type coercion differently. In C, for example, assigning an unsigned int to a signed int will give a compiler warning (equivalent of the coercion dot) but will simply assign the bits without modification. High bit of the unsigned integer becomes the sign bit of the signed integer.

None of the behavior is wrong. It is right, by definition, as long as it is consistent.