LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

.net refnum calling problem

Solved!
Go to solution

Hi,

 

I am working for calling .net dll to control Radar RTS with Labview. when I calling .net dll first time , it worked well, then program stoped, but when i calling it again, it failed.  finally , i fund that it did not worked because of the .net dll refnum changed in the shift register has changed. so,i am wondering about it: why the .net dll refnum in the shift register could changed without any written operations?

 

 

thanks

Jieqiang

Download All
0 Kudos
Message 1 of 11
(213 Views)

First, if you need to post screenshots, could you take them using the PC and not by taking a cell phone picture of the PC screen?  It can be very hard to read a cell phone picture.

 

Second, if you could post your actual VIs that would also be very helpful.

 

That said, if you look at the "Refnum (in hex)" value it's staying the same, meaning it's not a problem with LabVIEW directly losing the reference or resetting it to default because if that was it, the refnum would likely change to 0x00000000.  What's probably happening is that the reference is being closed somewhere.  It could be in another case of your case structure (that we can't see because you didn't post a VI).  It could also be a problem where if your program stops then starts again it doesn't re-run the code that initializes the reference (which we also can't see because you didn't post a VI).

 

Also, as a side note, you really ought to connect those error wires between your .NET nodes.  You're both not getting any error information if there is a problem, and also all 4 of your nodes could be running in any order because they don't have dataflow dependencies.

0 Kudos
Message 2 of 11
(180 Views)

Make sure you are closing the .Net refnum before your code ends.

One of my favorite ways of crashing the LabVIEW IDE is forgetting to close a .Net refnum when some unhandled error occurs earlier in a VI and I stop it.

LabVIEW will sometimes crash the next time you run the VI

0 Kudos
Message 3 of 11
(170 Views)

Thanks for your help. I had uploaded my code.  As you said, if LabVIEW directly losing the reference or resetting it to default, the refnum would likely change to 0x00000000, but it did not. When I start code with "Initialize", it works well, and it can be running in cycle until I stopped it. then I started code with "GetRTS" , errors happened, and the refnum had changed, but refnum (in hex) is still the same value.

 

Thanks

Jieqiang

Download All
0 Kudos
Message 4 of 11
(153 Views)

 

I fund another phenomenon, during running "GetRTS" case, the cycle time was about 1s(the delay I given was 100ms), and it seems the code should not running with so long time(1s). and when I given 1s delay, the cycle time could be about 2s(1s+delays). So It seems the "Wait (ms)Vi" did not running in parallel with other code? 

0 Kudos
Message 5 of 11
(148 Views)

I had fund once I select the .net class just like "4.PNG", Labview would be crashed right now. And when I select with Browse button, then elect the .net dll, Labview  worked well.  so I'm wondering is any problems between this .net dll I called and Labview?

 

thanks 

Jieqiang

0 Kudos
Message 6 of 11
(134 Views)
Solution
Accepted by topic author JieQiang

@JieQiang wrote:

. so,i am wondering about it: why the .net dll refnum in the shift register could changed without any written operations?


It cannot and will not change.

 

However, if you run a VI that creates the reference, and then calls your sub VI, and then stops, when running just the sub VI, the reference won't be alive anymore.

 

The reference will have a value, but the value won't be valid anymore.

 

References in LabVIEW are tight to the top level VI's data space. So if this top level VI stops running, all references created in it's execution hierarchy are closed.

 

It's hard to see from a partial image...

0 Kudos
Message 7 of 11
(120 Views)

@JieQiang wrote:

Thanks for your help. I had uploaded my code. 


No, you uploaded part of the code.

 

This is just a sub VI.

 

Again, if you run your main, and stop it, the reference will become invalid when you run just this sub VI (even though the value will be there).

0 Kudos
Message 8 of 11
(118 Views)

@JieQiang wrote:

 

I fund another phenomenon, during running "GetRTS" case, the cycle time was about 1s(the delay I given was 100ms), and it seems the code should not running with so long time(1s). and when I given 1s delay, the cycle time could be about 2s(1s+delays). So It seems the "Wait (ms)Vi" did not running in parallel with other code? 


 

Putting .NET nodes in parallel, doesn't make them execute in parallel. Each one probably blocks execution of the others.

 

It seems to be like the 100 ms is running in parallel. I don't see any other evidence for the opposite.

0 Kudos
Message 9 of 11
(115 Views)

@JieQiang wrote:

I had fund once I select the .net class just like "4.PNG", Labview would be crashed right now. And when I select with Browse button, then elect the .net dll, Labview  worked well.  so I'm wondering is any problems between this .net dll I called and Labview?


Yes. Don't do that.

 

Selecting a class from that menu to change either a constant, constructor, method or property crashes LabVIEW.

 

This is standard behavior. It is not specific to your assembly or VI.

 

 

0 Kudos
Message 10 of 11
(109 Views)