Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Bryan last won the day on February 25

Bryan had the most liked content!

Profile Information

  • Location
    Land of Confusion
  • Interests
    Stuff and things.

LabVIEW Information

  • Version
    LabVIEW 2018
  • Since

Recent Profile Visitors

5,492 profile views

Bryan's Achievements


Apprentice (3/14)

  • Conversation Starter Rare
  • Dedicated Rare
  • Reacting Well Rare
  • First Post Rare
  • Collaborator Rare

Recent Badges



  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. Just a thought, but I think that many younger/new developers aren't necessarily searching for online forums anymore. My guess is that newer generations of programmers may view online forums as "social media for old timers'". If they have questions, they may look on platforms such as Reddit, et. al. If they want to contribute, they may create videos on YouTube or other platforms where the rewards for contributing could be financial, notoriety or "influencer"-like status with a larger potential audience. This may be more appealing for newbies than reputation badges on a small, concentrated community. I'm not implying that the motives are all so superficial for all "young pups" entering or participating in the world of LabVIEW. However, there are more "shiny" alternatives to a single online forum from which assistance can be gained and contributions made. I guess, being an "old timer" myself, I still prefer the concentrated and focused community of smaller online forums, where one's questions and contributions don't get lost in the noise associated with larger platforms. This is why I almost exclusively stick to LAVA and rarely visit the dark side for any information.
  8. That link should have been posted with a disclosure. After clicking on the link and attempting to read the page, my brain BSOD'd.
  9. I agree, a dedicated location for things like this would be a good idea.
  10. I agree. I had originally written a pretty lengthy and fairly mean post because I have such personal distain for such things, but after I finished my first cup of coffee for the morning I calmed down and made it more civil. Personally, this type of thing actually deters me and people like me from patronizing such products/companies/organizations.
  11. It's interesting that you just joined the forum yesterday, and all of the posts for your account so far have been with regard to TVI. Additionally, the OP was asking about tools to automate testing of LabVIEW itself, not a TestStand/Test Sequencer alternative.
  12. Cross Post: https://forums.ni.com/t5/LabVIEW/How-to-edit-the-element-value-of-the-2d-array-of-string/m-p/4207337
  13. In my current role, I've inherited a LOT of bad code with who-knows-what inside. This usually ends up in complete refactoring of the code wherever possible and removing unused VIs, unless they're part of a library or collection of VIs that are or could be relevant to the application in the future. VIs that are obviously reference/example/testbeds, I will leave in for future reference. We keep all of our code in SCC, so if we remove VIs that we consider to be unused/junk, they're never really permanently deleted. If the application is not in SCC, we add it in it's current state as a "snapshot" so that we can always revert or retrieve VIs if they end up being needed later.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.