Bryan

I would hope that if an employer were to say that they were switching to something else, opportunities (and funding) for proper training would also be offered and utilized. Though I know that's not always the case. I've seen first hand (though maintenance and update of LabVIEW code with my current employer) the effects of mandating a new programming language and people learning on their own without training (taken or offered).

When I said at least one, I meant whichever one that I feel would be more beneficial to my own career ambitions, be it Python, Rust, etc. I didn't (mean to) infer that they were generic and interchangeable, (I know better than that). For me though, my introduction and programming experience has primarily been in LabVIEW. Changing my mental process to go from a graphical to a text based language feels like it would be more difficult for me than switching between text-based languages. As I said though, I realize that there are differences ranging from simply syntax to the more drastic.

I've had similar thoughts over the past few years. My introduction to the programming world was LabVIEW. I've dabbled in a few text-based languages, but not enough to become anywhere near proficient. Perhaps I should choose at least one and begin attempting to become proficient as I'm also looking in the 20-something year range until retirement.

Looks like homework to me. You'll never learn how to use LabVIEW if you try to cheat and get others to do your work for you.

I sometimes create my own using Paint or GIMP. More often than not, it's some web searches for icons or graphics that I can use. Of course, most of my graphics are for programs that are used internal to my organization. If it were to be also output as a deliverable product, I'd have to ensure that I'm not violating any creative rights/licensing.

I may be dating myself a bit here, but I remembered that from the original Simpson's episode. I don't recall if the meme or the episode would be older. Would that still check out? LOL!

"In Soviet Russia, moon hit you!"

I had meant to put that in there and had forgotten (I was in a rush). Thanks for catching that.

Is the 1606 1015 24 the hex values that would be shown in a string control/indicator when displayed in "Hex Display" mode (in "\ Codes" display it would be "\16\06\10\15$")? If so, see below:

Property nodes, such as the linked ones that I have shown in my screenshots above, are linked to the controls/indicators within that particular VI/scope, which is what I thought you were wanting to do. I didn't know that you were wanting to involve moving control and manipulation of them into subVIs. In different VI (i.e. subVI), you're in a completely different scope, and the control reference(s) will have to be passed to that new VI from the calling VI(s). LabVIEW tried to do that for you automatically, and you'll have to create references for the control(s) that you want to handle in your subVI. This can begin to get messy if you're new to using (unlinked) property/invoke nodes. I recommend spending some time learning about them before going too much further in your coding. Screenshots of your code will help us provide better assistance, but right now I'm not 100% sure exactly what you're trying to accomplish as the context of the original post seems to be evolving.

Sure, you could read the "Text.Text" property from ComboBox1 and write it to a "Text.Text" property for ComboBox2. The caveats would be that your "Items" would have to be named exactly the same, and that you'd have to pay attention to the order of execution. Best way to force order of exec is using property nodes even for the values. Others may have better approaches than I can suggest, but I've never had to do this before, so I'm mocking up quick examples for you. Below is an example where I use lowercase values for the 2nd combo box.

It appears that the decimal "6" is being provided as a 32 bit integer based on your description. You'll need to convert it to an 8 bit integer before type casting. Without seeing your code, I made an assumption and created the example below, which returns the hex value "6" for the month of June:

If you're familiar with Property Nodes, you can use the "Strings and Values []" property for access to both the "Items" and "Values" defined in the combo box. Additionally, you can use the "Text.Text" property to get the displayed text (i.e. "Items"), while the value will always be that from the "Values" defined.

Have you tried searching NI or the Rohde & Schwarz websites for LabVIEW drivers?

I've been playing with this a little more and I believe a simpler way may be to have a string indicator that can show/hide a list box on "Mouse Enter/Leave". Here's a little example I whipped up quickly. Again, probably not a preferred or the best way, but doable. Note - I found that ensuring that the hidden/visible items list needs to have key focus if it's going to need to "appear" over another control or indicator, at least in my limited testing of it. Hover Menu Example.vi

Someone else may know a better way to do it, but I was curious, so I did a quick google search and found this on the NI forums. I downloaded the "Menu_demo2_vi" and made a couple of modifications to the event structure - adding some "Mouse Enter" and "Mouse Leave" events to the event case that toggles visibility. I don't consider this to be a very streamlined solution and would opt for something better if available. But, it's at least proof that the behavior can be emulated in LabVIEW somehow. (Attached file is in LabVIEW 2020) Menu_demo3..vi

I agree, the LabVIEW Advanced Virtual Architects Forums need more of this type of informative and riveting content. Thank you @ensegre for saving me from wasting a full 16:49 of my life watching the video. I watched approximately 20 seconds (cumulatively, while mostly skipping around), which was enough for me to confirm that there was nothing to pique my interest before exiting the video. I found the music too annoying for me to tolerate more than that.

I never necessarily had a defined depth limit in my mind of how many levels I would deem too be overkill. For my uses, 1-3 just always seemed to be where it ended for me.

It almost sounds like you work at the same place I do. I have a few of those users that at least make an effort, but they're few and far between.

I'm in a manufacturing environment where the production operators are my end users. Even your "rather have" example would be ignored by 90% of the end users that I serve. They would just come to me and say "The red box keeps popping up.". I would ask what it said and they would tell me that they didn't read it. It appears that if they see lotsa text, they don't even attempt to read it. What I've had to end up doing is to capture the error message codes and transpose them into something the operators will understand. Then and present them with a shortly worded and flashy dialog with large text. In the background however, I'm logging the error message verbatim to an error log file that I, and other LabVIEW programmers in my company can reference for further information and debugging. To do this, I basically have a configuration file where the error codes are my keys, and the values are plain language error/failure/resolutions that will be presented to the operator.

You are creating an array of objects, then trying to wire that array into a scalar input in your class methods. An array of objects needs to be handled similar to any other array - you will need to index each object from your array in order to use/operate on them.

Done!

Just like politicians.

TL;DR - Download the Linux Community Edition 2021 SP1 ISO and extract it. In the "INSTALL" and "utils/install_helpers.sh" scripts in the extracted files, replace all instances of "ubuntu" with "ubuntu|zorin". For those who don't mind a little bit of reading (I can be long winded): I don't know if anyone has tried this yet, but I figured I would post it for archival purposes and future LAVA searches. For those who don't already know, LabVIEW 2021 SP1 supports Ubuntu 18 and 20. It's worth noting, however that the VI Analyzer Toolkit is not supported on Ubuntu according to the "README.html" file that's included with the installation media. For grins, I tried installing it on Zorin 16 simply by running the normal "sudo ./INSTALL" command, but was met with "Sorry, LabVIEW is not currently available for this O/S and architecture...." In order to get LabVIEW 2021 SP1 to install on Zorin 16, just open the "INSTALL" and "utils/install_helpers.sh" scripts with root privileges, and search and replace all instances of "ubuntu" with "ubuntu|zorin", then run the "INSTALL" script as usual. My assumption is that this may work for all distributions based on Ubuntu Bionic or Focal by adding the conditional for what is returned with the following commands. In the example below "zorin" was returned: $ . /etc/os-release $ echo ${ID} zorin Disclaimer: Because ZorinOS isn't listed as an officially supported distribution, assume that it is not supported by NI.

It sounds to me like the error is being generated by the Python script and isn't necessarily the SystemExec VI if it claims to be missing args. As Rolf said, if you pass it a FALSE for Wait until Completion, LabVIEW will send the command and return immediately - not waiting for the python script to return. Some things to remember, if your "script.py" or "file_name.hex" is a path or filename that has any spaces in it, you'll have to put the entire path or filename in quotes as I believe arguments are parsed by Python using spaces (Please correct me if I'm wrong, I don't know much about Python.): python.exe "C:\path\to\script.py" --port com3 --adr 2 "C:\path\to\file_name.hex" Alternatively, you could try passing the command switch to execute and then terminate: cmd /C python.exe "C:\path\to\script.py" --port com3 --adr 2 "C:\path\to\file_name.hex" If your python script is waiting for a response before returning to the command prompt, then SystemExec will hang forever waiting for a response. In that case you'll have to pass a value to STDIN. We had an instance of executing an EXE via SystemExec that would wait for a "Press any key to continue" if it had an error and would hang forever waiting for a key press. Our solution was to pass it a "space" constant for STDIN so that it would return. Interestingly, it wouldn't return the error via STDERR and did so via STDOUT.