02-27-2024 08:44 AM - edited 02-27-2024 08:57 AM
Hey folks,
I'm trying to set a communication with my signal generator (Siglent 6032x), and I need to generate an arbitrary signal (concatenated sinusoidal functions) and send it to the device. At first, I tried to use Labview, where Siglent had already provided some interfaces and examples. Long story short, they have failed to create arbitrary functions over Labview. It always sets negative values to zero and rounds the floating numbers to integers.
Anyway, I used the phyton interface for this specific purpose and built a code that solved my problem and worked perfectly well. My idea was to call this phyton code in Labview, let it do its mission, and continue with the next steps in my VI. My problem is now that Labview can call and execute the code; however, it does not build communication with the signal generator and send the functions, whereas the same code works without a problem in VScode/Python. By the way, Labview does not give me any errors. So, there is no compatibility problem; I also tried the dummy algebra function, which worked properly.
Any help would be appreciated. I have attached my both files '.py' and '.vi' for reference.
All the best,
Akif
I have attached the files for Python and Labview. I would be really happy if someone could help me in this regard.
All the best,
Akif
Solved! Go to Solution.
02-27-2024 11:20 AM
@muyendizako wrote:
...
My problem is now that Labview can call and execute the code; however, it does not build communication with the signal generator and send the functions, whereas the same code works without a problem in VScode/Python.
So why are you using LabVIEW as a wrapper for Python code? Just write the code in Python and save yourself the headache.
02-27-2024 11:35 AM
Thanks for the advice but this feature will be a part of a more complex code already written in LabView. Although python gives flexibility, LabView has great benefits of GUI, integration, and communication.
All the best.
02-27-2024 12:14 PM
@muyendizako wrote:
Thanks for the advice but this feature will be a part of a more complex code already written in LabView. Although python gives flexibility, LabView has great benefits of GUI, integration, and communication.
All the best.
And don't forget all the fun that comes with integrating two code bases written in different languages. I'm on the fence if the Python node was a good idea or not. The best way to call python is directly from the system exec VI then establish IPC between the two processes. If the Python node is not working it's darn hard to debug because LabVIEW is running its own Python interpreter somewhere that you don't have easy access to so how are you going to debug that?
02-27-2024 12:30 PM
@muyendizako wrote:
I looked over the code and have determined that I was wrong on my first statement about just implementing this in Python. I thought you were importing a library from Siglent in the python code. The only library you are using that is not part of the standard Python library is PyVISA which is a huge red flag. Certainly in this 88 lines of Python code should just be implemented in LabVIEW if you are making it part of a larger LabVIEW code base.
But if you insist on using the Python node you need to fix a few things,
1) the way the call is set up in labview is wrong, you call main and pass args but main does not take args.
2) the way main is defined is wrong in the python code, if you are trying to call the module it will never work the way it is written.
02-27-2024 12:39 PM
see these previous labivew -> python posts:
and
https://forums.ni.com/t5/LabVIEW/Leveraging-python-in-labview-programs/td-p/4225103
and
https://forums.ni.com/t5/LabVIEW/Python-object-refnum/td-p/4292776
02-29-2024 09:04 AM
Hey Jay,
thank you for the guidance, I learned a lot from the discussions you raised and shared even I followed another way to solve the problem. I had two changings, one is as you suggested I made the python code more easy and relax (I deleted the wrıte and read parts). Secondly, I updated the LabVIEW version from 2018 to 2024 which I assume the interpreter works better. I understood it from the errors that LabVIEW share with me. I used those clues to shape/debug my code as LabVIEW liked.
I'm attaching the final file if someone would like look at them.
All the best,