LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Special LabVIEW Considerations when creating a DLL?

I have created an app that works without issue.  Takes a file, parses the file, and creates a new file.  Depending on the file it is fed, it may call a different parser (there are 2 parsers internally, potential for more).  But, it works without issue in Dev Env.

 

What does "work without issue mean?"  Well, I'll tell you.  As a VI in LabVIEW environment, I feed it all the different files and they are correctly parsed and the correct file is created.  As a built executable, I feed it all the different files and they are correctly parsed and the correct file is created.  As a DLL called by Python, 1 of the parsers work... the other just freezes.

 

The issue does NOT lie with Python as it's just feeding it the filepath and getting the finished filepath as a return.  Why is this not the issue? Cuz it makes no sense for that to work for 1 and not the other.  Again, all files have been tested against the executable version and the VI version.

 

There's something LabVIEW to DLL that Windows, or RTE, or something doesn't like.  Are there any special considerations that need to be kept in mind when building a VI that will be eventually made into a DLL?  Like FPGA? You can't use the entire pallet when making FPGA.

 

Things I am using: Data Value References, Queues, FGVs. But both parsers use these. The only significantly different thing about the parsers, one parser runs two loops asynchronously.

0 Kudos
Message 1 of 19
(197 Views)

In your dll build specification there is something related to parallel execution.  Make sure it is enabled.

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.
0 Kudos
Message 2 of 19
(192 Views)

@billko wrote:

In your dll build specification there is something related to parallel execution.  Make sure it is enabled.


I'm digging through all the build properties, but not seeing anything related to parallel execution.  You might need to spoon feed me on this one.

0 Kudos
Message 3 of 19
(182 Views)

In my LV 2020 it's in advanced --> Execute VIs in a private execution system.

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.
0 Kudos
Message 4 of 19
(170 Views)

@billko wrote:

In my LV 2020 it's in advanced --> Execute VIs in a private execution system.


2020 as well.  I have this checked.  I do see in the header file: void __cdecl SetExecuteVIsInPrivateExecutionSystem(Bool32 value);

 

Is there something in Python (or other language) that needs to make sure it enables it?  Actually feed it a true?

0 Kudos
Message 5 of 19
(166 Views)

Just off the top of my head.... does EXACTLY one of the file parsers depend on DOMUserDefRef.dll?  W3C has never released a threadsafe version of that library (and since it does file reads and writes from disk hardware would not permit multiple concurrent disk IO anyway)

 

That's not saying that the DLL you build shouldn't work the same as a compiled LVObject...just food for thought in understanding what went wrong.   Try Unchecking the use private execution system option. 


"Should be" isn't "Is" -Jay
0 Kudos
Message 6 of 19
(160 Views)

@JÞB wrote:

Just off the top of my head.... does EXACTLY one of the file parsers depend on DOMUserDefRef.dll?  W3C has never released a threadsafe version of that library (and since it does file reads and writes from disk hardware would not permit multiple concurrent disk IO anyway)

 

That's not saying that the DLL you build shouldn't work the same as a compiled LVObject...just food for thought in understanding what went wrong.   Try Unchecking the use private execution system option. 


Okay, so this is interesting.  To answer your immediate question, I have no idea.  But based on context, the parser that does work actually does simultaneous R/W.  The parser that is not working actually does wait for the file to be read before writing back to disk.

0 Kudos
Message 7 of 19
(131 Views)

I tried it Unchecked.  No change to results.  One parser works, the other does not.

 

I noticed, though, the header file does not change.

 

void __cdecl SetExecuteVIsInPrivateExecutionSystem(Bool32 value);

0 Kudos
Message 8 of 19
(127 Views)

@LuminaryKnight wrote:

@JÞB wrote:

Just off the top of my head.... does EXACTLY one of the file parsers depend on DOMUserDefRef.dll?  W3C has never released a threadsafe version of that library (and since it does file reads and writes from disk hardware would not permit multiple concurrent disk IO anyway)

 

That's not saying that the DLL you build shouldn't work the same as a compiled LVObject...just food for thought in understanding what went wrong.   Try Unchecking the use private execution system option. 


Okay, so this is interesting.  To answer your immediate question, I have no idea.  But based on context, the parser that does work actually does simultaneous R/W.  The parser that is not working actually does wait for the file to be read before writing back to disk.


What file types does the working parser work on? Ditto the problem parser.   What is different about the files?  Is DOMUSERDEFREF.DLL in dependencies?


"Should be" isn't "Is" -Jay
0 Kudos
Message 9 of 19
(106 Views)

Let's get to more basic things first.

 

What is the entire header file created from LabVIEW when you build the DLL?

What is the Python ctypes definition for the import of the relevant functions?

Rolf Kalbermatter
My Blog
0 Kudos
Message 10 of 19
(100 Views)