Add "error in" connector to local variables

[oenk]

Sometimes you want to use local variables and sometimes these were accessed in one state twice (e.g. read it and after that reset it).

To follow the data flow paradigm one can:

a) create a new state called "reset XY variable"

b) place a sequence around it and wire an error code through it

c) use the new error in connector at the local variable

where:

(a) is not always IMHO good style as the state machine gets bigger and bigger

(b) is not always good to read

(c) may be nice...no error handling is needed so "error in" may be enough

[altenbach]

You can use a "single process shared variables" if you want the error I/O. (value properties also have error in/out but are not equivalent because of performance reasons)

Also note that your idea is insufficient, because it would definitely need an error out. The way you are currently branching the error wire at the bottom image does not fully enforce dataflow: It will delay the local write until the node on the left has executed, but it will not delay nodes to the right on the error wire (not shown) until the local is written. In probably 50%+ of the use cases it is important to ensure that the local write happens before something else. So, both "error IN" AND "error OUT" would be needed.

Still, I don't think we need any of that.....

[oenk]

OK, I see...

I didn't think this through...I was looking at it like I'm using those locals. Most of the times I do those resets at an exit of a state. So in that case I won't need an error out, because no more code is executed in the actual state. But you are right of course, to be consequent an error out is needed.

I still think it would be neat to have something like that but as an option with default disabled

[tst]

Like Altenbach said, you can use the Value property, which offers the functionality you want. It's true that its performance characteristics are different from the local, but I doubt this would make a difference in your case.

[oenk]

Thanks for your suggestion. But I don't like it very much. Not because of performance reasons but because of readability. With the new design of the locals these look very nice and display nicely on the FP. If you have to use more than one of the property node it's not as good to read as with the locals.

But after all: that's just my opinion....I just thought it would be nice to use locals with error clusters. Not always but sometimes...

[AristosQueue (NI)]

> With the new design of the locals

Since you have to have error in and error out, adding those terminals will change the height of the node, destroying the aspect you probably like most about the new design -- that it fits in a standard height.

[smercurio_fc]

---

@oenk wrote:
Thanks for your suggestion. But I don't like it very much. Not because of performance reasons but because of readability.

---

I guess I don't understand what you mean by this in terms of "readability". Readability of what? What's unclear about the word "Value"?

[oenk]

I see, I was a little unclear....my written English is a little bit rusty I guess.

Anyways, I will try to describe it better.

I don't like it how the code looks with property nodes when only setting the value. A local variable looks much better and is in my opinion easier to read. But that's just my feeling...

[smercurio_fc]

---

@oenk wrote:
I don't like it how the code looks with property nodes when only setting the value. A local variable looks much better and is in my opinion easier to read. But that's just my feeling...

---

Yeah, sorry, but that's a good selling point to me. I'm not saying you're wrong, but I don't agree. If anything, I think the property node is more readable than the local variable. It's just too bad about the performance hit.

[Darren]

Any idea that has received less than 4 kudos within 4 years after posting will be automatically declined.