LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Error code 1 when Remote Debugging property nodes

Hi,

 

I'm hoping someone has seen this issue before, because it's really frustrating (not that I'd wish that on anybody)!

 

I have a project that I developed in LabView 2011.  Recently I upgraded to LabView 2014, and since then I've had problems remote debugging the code.

 

LabView EXE:  works fine, no errors

LabView Development Environment:  works fine, no errors

Remote Debugging LabView EXE:  all property nodes fail and report Error 1.

 

YesError.gif  NoError.gif

 

The button in this example is set to "Switch On Pressed," not "latch," and I know that boolean values are not valid for latching buttons so I originally thought that maybe the debugger was misinterpretting the button type.  I've since confirmed that property nodes for non-buttons give the same error, however.

 

I can create new code in a new project, and I won't see this behavior.  When I add a new button to the original project, however, it produces the same error while remote debugging.

 

I'm on a Windows 7 machine, with LabView 14.0.1f3.  Is there something that I missed while upgrading?  Have I lost my mind?

 

I'm grateful for any help you can give me.

 

Thanks!

Jason

0 Kudos
Message 1 of 7
(3,138 Views)

Hello savinkoff,

 

Are you able to run your executable on a separate computer without issue?

 

Also, what property nodes are you using?

Matt G.
Product Manager
National Instruments
0 Kudos
Message 2 of 7
(3,082 Views)
Hi Griffindor, Thanks for responding. The executable runs fine on all computers I've tried, but the remote debugging issue remains on each as well. I'm using property nodes to control certain aspects of my main GUI controls - usually values and enable/disable properties of buttons and list boxes. I've come across a note in the LabView 2015 Bug Fixes that is related to this, so I'm going to try to upgrade to 2015 and see if that fixes it. Jason
0 Kudos
Message 3 of 7
(3,072 Views)

Great! Let us know here in the forum if the upgrade works!

Matt G.
Product Manager
National Instruments
0 Kudos
Message 4 of 7
(3,040 Views)

So I'm not saying this is the solution, but I noticed you are closing that control reference.  This is like a no-op and isn't needed.  You are asking LabVIEW to close a control reference, when the VI that owns it is still open, so LabVIEW will do nothing.  Which is why I think removing it should not change it's behavior but you never know, maybe LabVIEW is closing it when it shouldn't, which would make that This reference in valid?  Probably not.

 

The general rule is if you didn't do any explicit open call to create a reference, then you don't need to close it.  This isn't always true but works the majority of the time.

 

Oh and in this case can't you just use a local variable instead?

0 Kudos
Message 5 of 7
(3,030 Views)

Hooovah, good point about the Close Reference vi. It's a habit that I picked up years ago based on someone's recommendation, and I haven't thought much about it since. I'm not surprised to hear that it effectively does nothing!

 

Regardless, I did try with and without the Close vi, and it did not solve the problem.

 

Yes, in this case I could have used a local variable, but there are other property nodes in the code that give this error. In those cases, I need to set properties and not values.

0 Kudos
Message 6 of 7
(2,999 Views)

So, it appears that LabView 2015 has addressed and fixed this issue.  Once I upgraded, everything seems to work fine.

 

I did discover that the problem in LV2014 seems to be related to my homemade classes.  My experiment was to create a new vi in LV2014 with just a button and a property node behind it.  This worked fine when remote debugging.  However, as soon as I dropped an instance of one of my classes in the diagram (just free-floating and not wired to anything) the button property node threw the Error 1 while remote debugging again.

 

It seemed to only happen with classes that I created in LabView 2011.  In other words, when I created a simple class in LV2014 and tried the same experiment, it didn't cause a problem.

 

So all of that may explain why this wasn't more of a widespread issue for LV2014.  Anyways, I'm just glad they fixed it.

 

Cheers!

Jason

0 Kudos
Message 7 of 7
(2,986 Views)