LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Conditional disable structures and dlls

I had a look in the forums but was unable to find a match for this problem.

 

In LabVIEW 8.6 (don't know about others), when building a shared library (DLL) from a VI containing a conditional disable structure, the resultant dll is incorrect in the sense that the exported function will do nothing regardless of the value of the conditional disable symbols.

 

Taking the same code and compiling to an EXE works as expected, but a DLL version does not. I find it hard to believe that no one has come across such behaviour before so I may be doing something stupid, but I can't figure out what.

I have attached a project and code to demonstrate the issue.

 

The project has a conditional disable symbol (CDSV1) defined and two build specifications one for an EXE and one for a DLL. In cdstest.vi we have a conditional disable structure which tests CDSV1 and returns a string indicating the value of the symbol. The cdstestcall.vi has a Call Library Function node to call the DLL version and set a string with the output of the DLL. If you compile the DLL version and run cdstestcall from the labview environment the output from the DLL will be the same as the input, i.e. the DLL wont change the string.

 

 

0 Kudos
Message 1 of 10
(2,966 Views)

A further note, if you enable debugging on the DLL build spec, then the DLL function will do something, but not what the conditional disable symbol indicates, i.e. the DLL will have been compiled with the default action in the conditional disable structure, regardless of the actual symbol value.

0 Kudos
Message 2 of 10
(2,963 Views)

Could someone please confirm what I'm seeing or help me understand what I've messed up?

If it's a known bug with 8.6 then perhaps it has been fixed in a later release, if someone could someone let me know whether it is fixed in the latest version that would be great.

 

Thanks.

0 Kudos
Message 3 of 10
(2,938 Views)

Is there anybody ... out there?

 

I know there must be, because even the guy who asked how to build a scientific calculator got some responses, if only to admonish him for the quality of his question.

0 Kudos
Message 4 of 10
(2,919 Views)

I don't have 8.6, but in LabVIEW 2009 it works exactly as expected.  Built your DLL, provided the path to the compiled cdstest.dll and ran cdstestcall.vi.  Result was "Value = A".

 

EDIT: I can't get the EXE to run, though; I get a Microsoft Visual C++ Run-Time Library Run-Time Error, and I don't have time to investigate why.

Message 5 of 10
(2,910 Views)

Thanks, at least I know a labview upgrade will fix my problem.

It also suggests that this is really a labview 8.6 bug since I haven't messed up the project settings etc.

I'm puzzled as to why the EXE wouldn't work though - the code is so ridiculously simple.

Anyway thanks again for giving it a go.

 

0 Kudos
Message 6 of 10
(2,907 Views)

Well, for whatever it's worth, in LabVIEW 2011 on my home machine both the DLL and executable are fine.

0 Kudos
Message 7 of 10
(2,896 Views)

I tried it both in 8.6 and 2010 and it just works as expected in both cases! Not sure what is different here, except that I'm using 8.6.1f1 and 2010SP1.

Rolf Kalbermatter
My Blog
0 Kudos
Message 8 of 10
(2,889 Views)

Sorry about my previous message. 8.6.1 seems to have a problem somehow but it doesn't necessarily seem to be in the DLL itself. If I call the DLL created in 8.6.1 in the test VI in LabVIEW 2010 it works fine. If I call the 2010 DLL from a VI in LabVIEW 8.6.1 it works too. The only combination that doesn't seem to work is an 8.6.1 DLL called from 8.6.1 VI.

 

But it's not executing the default condition either since I always see AAAAAAAAAAAAA when it doesn't work. So the DLL somehow isn't called properly and the default input data is just passed out again, eventhought the Call Library Node doesn't indicate any error in its error cluster.

Rolf Kalbermatter
My Blog
0 Kudos
Message 9 of 10
(2,884 Views)

Hi Rolf,

 

Yes that's precisely what I see too. Now interestingly if you enable debugging in the build spec for the dll, rebuild and re-run the test the behaviour will be different, but still incorrect.

 

Thanks

0 Kudos
Message 10 of 10
(2,877 Views)