From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

passing control reference to subVI crashes labview

Hi,

using a image control (as indicator) provided by imaq Vision, I tried to pass the reference of the control to a subVI. On a computer it works and on a other (same labview version, same vision version, same os, same hardware and hardware drivers!), this crashes labview. I tried to close the control refnum at the end of the subVI, but that changed nothing to the issue. Now I use the reference as a global variable and it seems to work...nevertheless, I would like to understand what the issue and if I should remove any passing to subVI of control ref because this can potentially triggers an error. My correlated question is if this global passing is a "fake" workaround or have real chance of improving (this before going through the whole code for changing all passing of reference to subVI)
thanks a lot

0 Kudos
Message 1 of 3
(2,422 Views)
There's nothing inherently wrong with passing a reference to a front-panel control down to a subVI ( or sub-subVI, etc.)

I tried to close the control refnum at the end of the subVI, but that changed nothing

It shouldn't, except for speed and (if you call it thousands of times) memory usage.

How do you know it's this issue which causes the crash?

What LabVIEW version?

My correlated question is if this global passing is a "fake" workaround or have real chance of improving

Given that one computer works OK, and another crashes, I would say that you are seeing the effect of something else, not the cause. If passing a control ref via terminals was fatal, it would be fatal all the time.

You have some other sort of issue, perhaps timing of the different machines triggers the bug, perhaps running out of memory, perhaps LabVIEW is corrupted on one machine.... But I don't think changing all your code to use globals would solve the real problem.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

Message 2 of 3
(2,413 Views)
Hi,

thank
CoastalMaineBird for your answer

How do you know it's this issue which causes the crash?

When I remove this parameter from and the only property node in the subVi that write to it, I have no longer any problem. Moreover, to ensure that's really the "passing", and made a global variable containing the reference to this control and use my original SubVi that do access the control through its reference number
, and it works! In this last exemple, the only change is the way of transmitting the reference

What LabVIEW version?

8.0.1
up to date according Measurement & Automation update tool

Given that one computer works OK, and another crashes, I would say that you are seeing the effect of something else, not the cause. If passing a control ref via terminals was fatal, it would be fatal all the time.

You have some other sort of issue, perhaps timing of the different machines triggers the bug, perhaps running out of memory, perhaps LabVIEW is corrupted on one machine.... But I don't think changing all your code to use globals would solve the real problem.

Actually, saying that I wonder about problem of synchronisation. I know from Visual C++ that this kind of error happens if two process try to access the same control at the same time. This is typically an error changing from a computer to an other, and mutex or semaphore are the way to deal nicely with that. But does labview contains already such a securisation? If so, the global variable point on a single object and can "fell" the semaphore/mutex. But passing make a copy that will likely have two different semaphore/mutex but will point to a single control! Do someone know if I'm wrong in this idea or not?

Thanks
0 Kudos
Message 3 of 3
(2,402 Views)