Managing Errors Labview Python

[Dariush_Hampai]

Hi Guys,

in thepast I used he xraylib module (https://github.com/tschoonj/xraylib/wiki) for Fluorescence analysis.

However, new versions of Labview (starting from 2018/2019...) has some bugs on wizard import shared libraries. I already opened a ticket and this was the answer:

"I can confirm that this is a limitation of the shared library import wizard and there are no plans to improve it.
As discussed, the next best option is to use the python version of the dll."

Now, I included the python subvis, but if the python code has a problem, the labview code will crash (I have to close manually in task manager the python.exe application to stop the vi)

The python code is

def CsB_FL_K_loop(Z,Shell,Lin,En_array,Int_array):
   param=0
   En_abs=float(xraylib.EdgeEnergy(Z,Shell))
   kk=1
   for i in range(len(En_array)):
     if En_abs>0.15:
     if En_array[i]>En_abs:
     param+=(xraylib.CSb_FluorLine_Kissel(Z,Lin,En_array[i]))*Int_array[i]
     kk=kk+1
     CsB_exit=np.array([kk, param])
   return CsB_exit

and, in particular conditions (due to the parameters that I want to evaluate) I receive this error (on terminal), error that freeze labview code:

python functions.py
Cs Total per Z= 3 : 28.13123088429663
CsB per Z= 3 : [1 0]
CsB per Z= 3 : [1 0]
CsB per Z= 3 : [1 0]
Cs Total per Z= 4 : 223.36705900712207
CsB per Z= 4 : [1 0]
CsB per Z= 4 : [1 0]
CsB per Z= 4 : [1 0]
Cs Total per Z= 5 : 558.7210110603571
CsB per Z= 5 : [404. 5.54212806]
Traceback (most recent call last):
File "C:\Software\XRF Analysis\vi.support\python_to_labview\functions.py", line 64, in <module>
print("CsB per Z= {}".format(ZZ), ": {}".format(CsB_FL_K_loop(ZZ, 0, 1, x, y)))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Software\XRF Analysis\vi.support\python_to_labview\functions.py", line 46, in CsB_FL_K_loop
param+=(xraylib.CSb_FluorLine_Kissel(Z,Lin,En_array[i]))*Int_array[i]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\laphampai\AppData\Local\Programs\Python\Python312\Lib\site-packages\xraylib.py", line 4351, in CSb_FluorLine_Kissel
return _xraylib.CSb_FluorLine_Kissel(Z, line, E)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: Invalid line for this atomic number

Now, how can I skip the evaluation with labview when I receive this error?

Thank you in advance

[rolfk]

---

@Dariush_Hampai wrote:

Hi Guys,

in thepast I used he xraylib module (https://github.com/tschoonj/xraylib/wiki) for Fluorescence analysis.

However, new versions of Labview (starting from 2018/2019...) has some bugs on wizard import shared libraries.

---

That's definitely a misrepresentation of the problem. The library API is in no way suited to be imported by the shared library wizard. Never was and never will be. It may have worked by accident for specific functions that have a simple interface, but never could have imported the entire API except maybe older API versions that used a different and simpler API interface. I read in the documentation that several of the bindings they talk about and are not maintained by themselves will "LIKELY" not work with the 4.0.0 API, so may guess is that your problem has much more to do with the change of the API version, which got more complex and advanced, than with any "bug" in the Import Shared Library Wizard.

The Import Library Wizard is a tool that does try to create a LabVIEW wrapper based on very limited information from a C header file. This information is enough to often determine the correct data type (but by far not always since the C syntax can be very ambiguous about that too) but there is absolutely no way to correctly guess the memory management requirements of a particular API. And that is the crux when calling C functions, because that makes all the difference between well performing code and a memory leak or crash generator.

That all said, it is still possible to call external C code libraries that the shared library wizard can't handle. You just have to do all the leg work yourself and not just click on a magic button "Import" and hope all is well. There are some limitations even there, if your API for instance requires callback pointers, things are simply not feasible to do directly through the Call Library Node since LabVIEW does not provide anything that can easily be translated to that. Otherwise it can be usually done but it often requires someone who very well understands:

1) The API in question

2) How this API should be called from a C program

3) How a C compiler does certain things in memory

4) How these things translate to the LabVIEW Call Library Node

4) gets almost self explanatory if you have a sound understanding of the first 3 points.

In many cases it is actually easier to create an intermediate library in C and compile it into a shared library (.so;.dll) to translate between the actual C API and a more LabVIEW Call Library Node friendly API. It does require a fairly similar skill set as above (you need to understand the C API you try to call and how to actually call it from C code) but you can let the C compiler deal with the nitty gritty details about memory alignment and similar things.

Basically if you have a reasonably complex API and couldn't write some C code to correctly call such an API, the Import Library Wizard is NOT your savior but your Nemesis.

They do seem to provide a .Net interface too. Since you try to do this on Windows, that may be actually an easier path than trying to get a Python interface (that still seems to have crash problems itself) to work. .Net formalizes many things about memory handling and also incorporates a very extensive API interface description in each assembly.  The LabVIEW .Net nodes can make use of that interface description to automatically create a much more functional translation stub that translates between the LabVIEW managed memory model and the .Net managed memory model.

DLL interfaces have no standardized management contract. Each library can (and quite often also does) use whatever the programmer fancied as most efficient, easy, or sometimes simply crazy. Therefore LabVIEW and the import shared library wizard can't try to adhere to a certain management contract, since there is simply none. Whoever is calling such a library has to read and understand the library documentation, often study the individual code examples, and just as often do a lot of trial and error, to find out how a specific API needs to be handled. Not something any automated tool could ever try to even attempt.

[Dariush_Hampai]

Hi Rolf

thank you for your reply. This discussion is not how to import dll libraries (even if up to labview 2018 I can do...).

I skip this problem simply using a quite similar solution that you suggest: passing through python.

Now, following what I wrote, as the funtion that I called fails, the python callnode is blocked as python.exe didn't exit... How can I resolve the problem?

Thanl you in advance

Dariush

[rolfk]

---

@Dariush_Hampai wrote:

Hi Rolf

thank you for your reply. This discussion is not how to import dll libraries (even if up to labview 2018 I can do...).

I skip this problem simply using a quite similar solution that you suggest: passing through python.

Now, following what I wrote, as the funtion that I called fails, the python callnode is blocked as python.exe didn't exit... How can I resolve the problem?

---

The only way to fix that is to not make Python crash/hang. LabVIEW has no control over the Python environment once it passes execution flow to it. If it doesn't return, the only way to fix that is to kill the entire process. You can't kill an external component, like what Python is when it is called through the LabVIEW Python Node, and still hope to maintain memory and process integrity.