Changing Pot based upon its own value

[Toma]

Hi,

Any attempt to change Pot using its current value
causes circular reference alarm, for example:

Pot1.reset = "Switch1"
Pot1.resetvalue = "Pot1*4"

Is this behavior correct?

Also, I often use expressions like "Pot1<>Pot.value"
to detect Pot or Switch changes. Is it safe to do so?

Kind regards,
Sergei

[andreoliveira 47]

Hi Sergei,

Yes the alarm message is expected,since you are making reference to the same object you are writing to, you should avoid this situation to keep consistency in your code.

Regarding your second question, are you trying to compare different pot objects or compare the pot implicity data member with its own values ?


Regards

Andre Oliveira

[Toma]

Hi Andre,


> Yes the alarm message is expected,since you are making reference to
> the same object you are writing to, you should avoid this situation to
> keep consistency in your code.

I see. On the other hand things become compicated when you need
to recaclulate pot based on its actual value.

> Regarding your second question, are you trying to compare different
> pot objects or compare the pot implicity data member with its own
> values ?


Sorry for mistake in my example.

I compare Pot or Switch objects with their own data members like
Pot1<>Pot1.value or
Switch1<> Switch1.value.

It's simple and works fine, but I'm not quite sure its safe to use
such expressions. Do you think this behavior will remain the same in future
Lookout
releases?

Best regards,
Ser
gei Modebadze

[Roli]

Sergei - I've forwarded your questions to a Lookout developer at NI (Mark D.) and he answers:
"For his first question, Lookout is not able to set an object's value base on itself. The problem comes from that we cannot control how many times we transfer a signal between the source and the destination, which causes an endless transfer in a circular reference.

For the expression "pot1<>pot1.value", it goes high whenever pot changes it value, because the pot1 and pot1.value has different route number. But we cannot promise Lookout will keep the same behavior in the future."

Hope this insight helps
Roland

[Toma]

Roland,

Many thanks for your very detailed information.

I'll bear in mind that expressions of "pot1<>pot1.value"
type may change behavior in the future.

Kind regards,
Sergei

> Sergei - I've forwarded your questions to a Lookout developer at NI
> (Mark D.) and he answers:
> "For his first question, Lookout is not able to set an object's value
> base on itself. The problem comes from that we cannot control how
> many times we transfer a signal between the source and the
> destination, which causes an endless transfer in a circular reference.
>
> For the expression "pot1<>pot1.value", it goes high whenever pot
> changes it value, because the pot1 and pot1.value has different route
> number. But we cannot promise Lookout will keep the same behavior in
> the futur
e."
>
> Hope this insight helps
> Roland











> (Mark D.) and he answers:
> "For his first question, Lookout is not able to set an object's value
> base on itself. The problem comes from that we cannot control how
> many times we transfer a signal between the source and the
> destination, which causes an endless transfer in a circular reference.
>
> For the expression "pot1<>pot1.value", it goes high whenever pot
> changes it value, because the pot1 and pot1.value has different route
> number. But we cannot promise Lookout will keep the same behavior in
> the future."
>
> Hope this insight helps
> Roland