LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Bug/enhancement: Representation of Fixed Constants (Scripting)

For some reason, Fixed Constants (such as Pi etc) do not have the "Representation" property - presumably because not all such constants are numeric.

FixedConstantRepresentation.png

However, these constants can have their Representation changed by right-clicking on the constant.  It would be useful (though to very few people I'm sure) to have this property available for scripting uses.  I was unsure whether this was a bug, or a request for a new idea, so am happy to repost in the Idea Exchange if it fits there better.

0 Kudos
Message 1 of 12
(2,471 Views)

Hi GregS,

 

I'm not familiar with these functions.  Are you using a 3rd party package or addon?  Perhaps OpenG?

 

Have a great day,

 

Chris V

Applications Engineer
National Instruments
0 Kudos
Message 2 of 12
(2,451 Views)

@Chris V wrote:

Hi GregS,

 

I'm not familiar with these functions.  Are you using a 3rd party package or addon?  Perhaps OpenG?

 

Have a great day,

 

Chris V


Greg has Scripting turned on, though the LabVIEW ini file. Having done that, he has these functions under Application Control > VI Scripting Palette. Several Property Nodes & Invoke Nodes come along for the ride as well, and are colored blue.

Richard






0 Kudos
Message 3 of 12
(2,444 Views)

@GregSands wrote:

For some reason, Fixed Constants (such as Pi etc) do not have the "Representation" property - {...}


Same is true with a plain old "Constant" as well, right? Whether Fixed or not, a constant can be (for example) a string, where Representation would not apply.

Richard






0 Kudos
Message 4 of 12
(2,440 Views)

Possible Workaround:

 

  1. Use Change to Control method on FixCnst.
  2. Coerce control reference to Numeric control type.
  3. Use Representation property on numeric control to change the representation.
  4. Get the Terminal of the numeric.
  5. Convert to a constant.

ChangeFixCnstRepresentation.png

 

Full Disclosure - I did not run this to ensure it works.  It also needs to close a lot of open references.

0 Kudos
Message 5 of 12
(2,432 Views)

I hope this gets considered a bug since scripting-related ideas are not exactly Kudos magnets.

 

My typical workaround when I have something that is easy to code but hard to script is to use a subVI.

 

1) Create a subVI which only contains a SGL precision Pi constant

2) Use New VI object with SubVI Class specifier and path pointing to your subVI

3) Call the Inline method of this created subVI

 

I have a utility which will automate this process for me.  I will actually use the sequence structure option of the inline method, get the AllObjs[] of the first Diagram, then remove the sequence structure.  This will give me the reference(s) to the object(s) which I dropped using this method.

 

I haven't tried DFGray's method, but it will give you a 'normal' constant and not the fixed variety. Probably good enough, but still a risk of later editing.

0 Kudos
Message 6 of 12
(2,421 Views)

I have not convinced myself this is a bug.  As stated previously, not all fixed constants are numeric.  The allowed values of representation vary with the type of fixed constant, so adding a representation property at this level does not necessarily make a lot of sense, as it would be very easy to create errors.  To fix this properly would require subclasses of the fixed constant class (e.g. string, float, etc.).

 

Opinions?  It is probably worth posting to the idea exchange.

 

Darin, it may be faster to put the sequence frame explicitly around your code in your subVI, do a Move of the sequence onto the target diagram (which will move all your code), then remove the sequence.  This gives you much better contol of placement, as well.  You can do an explicit Make Space at the target location, if needed.

0 Kudos
Message 7 of 12
(2,414 Views)

I think the "bug" is that the numeric FixedConstant nodes (those in the <Numeric\Math & Scientific Constants> menu) should be a subclass of NumericConstant, (say NumericFixedConstant!) and therefore inherit the appropriate Methods/Properties.  Instead, they're lumped together with all other FixedConstants as merely a subclass of Constant.  I'd probably suggest that the FixedConstant object class disappears altogether, and is replaced with NumericFixedConstant, StringFixedConstant for the strings, PathFixedConstant for paths, and whatever else is needed to mop up any remaining constants - is it possible to determine what others there are?

 

In the meantime, Darin's solution is reasonably elegant, and given his superb Math Node he should know something about it all!  But I won't mark it as a solution in case it prevents someone considering this as a bug!

 

0 Kudos
Message 8 of 12
(2,399 Views)

One more thing - it took a while for me to determine which class the "Pi" constant belonged to, or at least it wasn't immediately obvious.  I presume there is a one-to-one mapping between "Style" and "vi object class" - is that published or available anywhere?

0 Kudos
Message 9 of 12
(2,392 Views)

Style is a modifier of object class.  As such, there is a many to one correspondence between style and object class.  For example, a FixedConstant can be π, +∞, -∞, NaN, etc.  Controls are another good example.  And, unfortunately, there is no good way to determine the style of an object from its reference.

0 Kudos
Message 10 of 12
(2,378 Views)