Why does my val(Sgnl) property node have a coercion dot?

[benv]

Hello all,

I have a state machine with a typedef state variable.  I want to have the state machine set this variable using a signaling value property node so that another loop can detect a particular value in an event structure and act on it.  I create the property node by right-clicking the indicator (which doesn't have a coercion dot insdie the state machine), and when I replace the indicator with the property node, I get a coercion dot, and context help on the property node shows it only as (unsigned word [16-bit integer] enum{ init, stateA, etc...}), whereas the wire and the indicator show (typedef'StateVariable.ctl'[non-strict]) (unsigned word [16-bit integer] enum{ init, stateA, etc...}). 

Any ideas as to why a property node created from an typedef indicator isn't a typedef, or whether this is something I should let concern me at all.... I hate having those little dots hangin around.

I can't post my code, but I could post a mockup perhaps.

thanks for any insight!

Ben

[MikeS81]

Hi Ben,

i see the same behavior. You can use a typecast to remove the coercion dot, but i´m not sure if it is good performance.

Mike

[benv]

Thanks for confirming, Mike. 

So am I correct in assuming this is ok, or could I run into problems later if I add or remove values from the typedef?

[JeffOverton]

I may be totally wrong on this, but my guess would be that since an unassigned property node uses variants for all its inputs, an assigned node that takes actual values for its inputs considers them variants that have been cast to a more specific datatype.  This would mean the internals of how property nodes work can't handle typedefs because there's no primitive way to cast that data type.

edit - As to future issues, I don't think you'll have a problem.  Your typdef input will be cast to U16 or U32 in the property node, then cast back to your typedef in the indicator.  Since the typedef input (secretly a U16/32) can't be outside the range of the indicator (also secretly a U16/32), the cast-recast won't be an issue.

Message Edited by JeffOverton on 09-11-2008 11:41 AM

[benv]

That's what I'm thinking too. 

 I just was worried that there was a reason I've never seen anyone else with this particular architecture.  It allows me to have a loop (state machine) running, doing what it does, and another loop running asynchronously, handling emergency power off button events, etc, and still have a somewhat elegent way of stopping this second loop and its event structure when the first one enters its clean-up state without a bunch of event notifiers and associated wires or checking for it using the event timeout.  Seems pretty clean.

thanks.