Error 1055 occurred at Property Node, only the FIRST TIME I run the VI

[yoz'st]

hi !

I'm managing some object properties with 2 subVIs,

so I send to the first one a number and a cluster which contains the objects references, so that it controls the "visible" property depending on the number,

and I send to the second one the previous cluster and an other cluster which contain the objects data, so that it controls the data depending on some parameters.

VI is better than explaination, so find it attached !

at the first time you'll run it, the error occurs, so click "stop" button, and run it again, no error, and you'll understand the way it works.

To fond the error again, just close it completely and re-open it.

(I built an example VI as close as possible to my real VI, and I get the same error, so I attached only the example)

hope you'll understand (if no I can explain better)

thanks a lot.

[yoz'st]

I found a mistale in my precedent VI, so here is a new version, with more comments as well...

[Wart]

Your problem comes from using local variables.  If you'll wire the data cluster and reference cluster directly to your subVIs rather than using locals then it will work.

What happens is that the local variable is read before you write to it.  So when it is passed to the subVI it's blank and that's what the subVI tries to use.  Blank references aren't valid.

[yoz'st]

thanks it works !

but in my real VI I'm using those clusters a lot, that's why I chose to use local variables, if I wire the clusters directly to the subVIs I'll get wires every where...

Is there a way to "initialise" local variable ?

[smercurio_fc]

You have to write to the control/indicator the local variable points to.

Local variables should be used with extreme caution. LabVIEW programming is not like C-programming. Local variables are the #1 reason for race conditions, which is what you had. Read more here:

http://forums.ni.com/t5/BreakPoint/Why-some-people-say-Local-Variables-are-bad/td-p/711239

[Wart]

A lot of local variables can be eliminated with a proper design and layout.  Make sure you're using state machines and producer consumer loops where appropriate.

Once you've done all of that - if you still need a variable the simplest implementation would be an action engine or functional global variable.  See this famous post by Ben: http://forums.ni.com/t5/LabVIEW/Community-Nugget-4-08-2007-Action-Engines/td-p/503801

[yoz'st]

---

smercurio_fc a écrit :

You have to write to the control/indicator the local variable points to.

---

sorry but I don't really understand this... (I'm french).

I tried to use globals, but the same error occurs...

[smercurio_fc]

---

@yoz'st wrote:

---

smercurio_fc a écrit :

You have to write to the control/indicator the local variable points to.

---

sorry but I don't really understand this... (I'm french).

---

A local variable points to a control or indicator. To "initialize" it you have to write a value to it. Or, you can set the value of the control/indicator to a default value.

---

I tried to use globals, but the same error occurs...

---

Of course it will. Because you're not understanding that you have a race condition. http://en.wikipedia.org/wiki/Race_condition

[yoz'st]

ok I understand the idea of race condition...

I found a solution :

I tried to move the initialisation of the clusters away from the "while sequence", this way initialisations are done first, and there is no issues with local variables. It works, but the data of the objects doesn't react when I change them (logical). So I moved back into the "while sequence" only the initialisation of the data cluster, and it works fine !

Indeed It was references which were causing trouble, and by the way they are always the same, so it doesn't need to be inside the while loop, but the data cluster needs to be updated.

tanks a lot for help, in the furur I'll try to be more carefull.