LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Invalid object reference

Solved!
Go to solution

Hello everybody,

 

I am trying to show/hide two boolean controls on the front panel when another boolean is activated/deactivated, i.e. if the user clicks on "MUX ON/OFF" button "SAVE THE DELAY VALUES" and "Number of Channels" controls should disappear and on the next click appear again (see the attached VI).

 

I managed to do it with just "Number of Channels" control by using a reference of this control and the Visibility property nodes in both states (MUX ON & MUX OFF). So when the programm is in the MUX ON state the "Number of Channels" control is hided because i wired a FALSE to the visibility property node. The reference is handed over to the MUX OFF state via a shift register so when the programm is in the MUX OFF state the "Number of Channels" control is showed on the front panel again. Everything fine till here. When I try to do the exact same thing with the other control "SAVE THE DELAY VALUES" I get an error:

 

Error 1055 occurred at Property Node in GUI_Emirali_final_DFA_WE.vi

Possible reason(s):

LabVIEW: Object reference is invalid.

 

I don't why the reference is not valid since I think I am doing the same thing with the other control i.e passing the reference to the relevant states via shift registers, not forgetting to do Linked Input Tunnel -> Create&Wire Unwired Cases and then going from the left register to the property nodes reference input. Can somebody see my mistake?

 

LabView Version:17.0.1f3 (64-Bit)

 

Any help would be highly appreciated.

Best regards,

Ecafer

0 Kudos
Message 1 of 8
(5,314 Views)

Your problem is your task tunnels being set to "Use Default if Unwired" here:

Spoiler
FireFist-Redhawk_0-1599504753189.png

 

I'm not the type to tell people all the things wrong with their code. I usually just answer the specific question asked and go about my day. But man, you need some serious cleanup. Multiple error shift registers and multiple task shift registers too? Wires going under structures, nothing has labels telling why you did anything this way, all of your shift registers are uninitialized which could lead to other issues down the road. I'm not trying to be harsh, just want to encourage you to learn best practices and use them.

Spoiler
FireFist-Redhawk_1-1599504982458.png

 

Redhawk
Test Engineer at Moog Inc.

Saying "Thanks that fixed it" or "Thanks that answers my question" and not giving a Kudo or Marked Solution, is like telling your waiter they did a great job and not leaving a tip. Please, tip your waiters.

0 Kudos
Message 2 of 8
(5,304 Views)
Solution
Accepted by topic author ecafer

You have two reference wires that are all travelling through a shift register.  The shift register is uninitialized.  If you go to an state that uses that wire before you ever had a chance to put a valid reference on that wire, you will get the error you are seeing.

 

Why are you using those shift registers and explicit property nodes?

 

The only times explicit property nodes are needed are if you need to programmatically determine which of many controls you are trying to set the properties of, or if you need to set the property of a code that is in a different VI (e.g.  set visibility of a chart on a main VI from within a subVI.)

 

I can't tell if you are trying to do either of those things.

 

Run your VI with highlight execution with probes on the reference wires and your state machine wire.  I think you'll find that the states execute in an order where you try to use a reference wire before you ever established a reference to a particular control.

 

Look at eliminating those reference wires and shift registers.  From what I can tell, you just need to set those property nodes to implicit.  (Right Click, Link To)

Message 3 of 8
(5,303 Views)

Ugh, can't edit my comment for some reason. The first thing I mentioned isn't the reason for the error you were having, but those default tunnels will likely end up being a problem for you. The reason for the property node error is most likely the uninitialized control reference shift registers, as myself and RavensFan point out.

Redhawk
Test Engineer at Moog Inc.

Saying "Thanks that fixed it" or "Thanks that answers my question" and not giving a Kudo or Marked Solution, is like telling your waiter they did a great job and not leaving a tip. Please, tip your waiters.

Message 4 of 8
(5,265 Views)

I take it as a constructive feedback. I am new on LabView so I am here to learn.


@FireFist-Redhawk wrote:

Multiple error shift registers and multiple task shift registers too?


Don't understand what you mean with shift and task registers.

The labels and prettieng the wires come at the end. Thanks for the help.

0 Kudos
Message 5 of 8
(5,232 Views)

Why are you using those shift registers and explicit property nodes?

Look at eliminating those reference wires and shift registers.  From what I can tell, you just need to set those property nodes to implicit.  (Right Click, Link To).


I saw the reference approach on an online VI that's why I used it. Your suggestion worked. I deleted all the references and wires+shift registers for this purpose and just linked every Visibility Property Node to the desired control. Thank you very much for your help.

0 Kudos
Message 6 of 8
(5,230 Views)

I'm talking about this:

Spoiler
FireFist-Redhawk_1-1599504982458.png

Redhawk
Test Engineer at Moog Inc.

Saying "Thanks that fixed it" or "Thanks that answers my question" and not giving a Kudo or Marked Solution, is like telling your waiter they did a great job and not leaving a tip. Please, tip your waiters.

0 Kudos
Message 7 of 8
(5,198 Views)

@ecafer wrote:

I take it as a constructive feedback. I am new on LabView so I am here to learn.


@FireFist-Redhawk wrote:

Multiple error shift registers and multiple task shift registers too?


Don't understand what you mean with shift and task registers.

The labels and prettieng the wires come at the end. Thanks for the help.


In my experience, if you don't "pretty up" as you go along, it becomes such a mess that you are discouraged from doing it at the end.  (That, and you've usually run out of time and need to deliver on schedule.)

 

Plus it makes it much easier to troubleshoot if it's already somewhat organized.

 

Developers always underestimate the significance of "neat" code.  As I've mentioned countless times, creating messy LabVIEW code is like creating C code with random indents.  In each case, the compiler doesn't care, but if an angry developer who is charged with modifying - or even just understanding - your code comes to me looking for the perp, I'm just going to point to your cubicle, put on my headphones and turn the volume all the way so I can just shrug my shoulders when someone asks me what happened at the crime scene.

 

Habits are easily formed, hard to break.  Make sure the habits you form are good ones.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 8 of 8
(5,192 Views)