Select represetation for Feedback Node and Shift register.

[JÞB]

I noticed an odd (undesired) behavior where my SR/FB node acted oddly.

First I created a simple !32FB node

Next I added a +1 primitive to make it a counter....

-  and  my data type changed!  This behavior was undesired and looking through the node RCM and Properties I could not select representation

In fact I had to add a conversion. Simillarlly the same thing occured with a USR

I propose adding the ability to select representation to the RCM and Properties pages of SRs and FBNs

SR RCM                                        FBN Property browser

[RavensFan]

This seems to actually be a bug.

See this thread.  http://forums.ni.com/t5/LabVIEW/Unexpected-coercion-in-LabVIEW-8-6/m-p/775337?jump=true

[JÞB]

Well then, exposing the "Adapt to entered data" and "Representation" properties via RCM and Property browser may be a good fix for CAR 125834

I bet I get a quick "Declined-moved to CAR database" and maybe free a NI resource to work on it

[G-Money]

Moved to CAR database. CAR#125834

[G-Money]

You are correct on the Declined-moved to CAR database response  That free resource was helpful because I just tested this out in the LabVIEW 2011 Beta and this behavior has been fixed. No more datatype changes just for adding the Increment.

[SteenSchmidt]

Until LV 2011 a fix is to rewire any of the connections on the feedback node. That'll change the type back to I32.

I don't think the problem lies in the feedback node, but instead in the instance picker when you drop a polymorphic function. The correct instance should be chosen before the poly is dropped into the block diagram forcing the compiler to do type propagation.

Cheers,

Steen