Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by Bryan

  1. 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.

  2. 5 hours ago, hooovahh said:

    I'm convinced most of the users of my software are illiterate.  The good users of my software know the common troubleshooting techniques, and will blindly run through turning it off and on again before telling me.  Then if "The red screen" comes up again they'll tell me, or take a picture with their phone.  Honestly I prefer this over the "I don't know what it said".

    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. 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}

    Disclaimer: Because ZorinOS isn't listed as an officially supported distribution, assume that it is not supported by NI.

    • Like 1
  5. 8 hours ago, Daniel Bochen said:

    ...Error is that the script is missing args. If wait until completion? is FALSE, then script work just fine...

    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.


  6. 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.

  7. 50 minutes ago, Rolf Kalbermatter said:

    Not so interesting! Both Elena and Omer have so far only posted to boost about the TVI framework. Omer supposedly as an employee of the company that sells TVI and with Elena I'm not so sure, but it could be also from their marketing department. 😀

    While technically related it is bordering spam based on the repeated marketing style postings.

    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. 

  8. 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.

  9. On 12/27/2021 at 2:05 PM, FixedWire said:

    So folks...what about a Plan B?

    Python may have become a "fav" in some circles but having to dig for plugins is a pain at best and a disaster in the making if the code is anywhere near a regulated environment. Rolf nailed it with far too much code that just works but lacks architecture or isn't hardened. Choosing that one plugin could derail a project so fast if it needs to be rewritten.  In the real world we need tools that we can rely on.

    Has anyone looked into Uno Platform or Avalonia? You'd think at this point and time one could build out projects that could easily port between Windows, Mac & Linux. Uno works off of C# & the .NET and thus caught my attention.

    Just re-reading the above pains me for all this superb community does. So many sharp minds here, something good will evolve!


    The majority of my own career has been based upon LabVIEW. I was exposed to it in college for a semester in 1999 and have loved using it ever since.  Unfortunately, my dream of working for an NI Alliance partner in order to really develop my LabVIEW skills, (like many of you lucky bums) never became reality (I was normally the sole LabVIEW guy.  Now I'm part of a very small group with varying levels of proficiency).

    I've dabbled a little in various text based programming over the years, but never really spent enough time to be as proficient like I have been able to in LabVIEW.  Therefore, I need to start thinking about a "Plan B" myself in the event that my company, for whatever reason, declares that "...henceforth, shalt thou NOT use LabVIEW and TestStand...".  If that ends up being the case, I may have to seek alternative employment unless they are willing to send me to classes to properly learn the new programming language du jour.

    19 hours ago, ShaunR said:

    Codetyphon (WISIWIG IDE)

    This piqued my interest and I downloaded it to give it a look.  The majority of what I currently do in LabVIEW involves user interfaces, so WISIWIG looks ideal.  From the screenshots I saw, it reminded me of the days when I dabbled in VB6.

  10. 13 hours ago, Rolf Kalbermatter said:

    An interesting corner case would be to create tutorials for your youtobe channel. If that youtobe channel ends up being watched a lot and earning you more than a few (as in some two digits, just a number I came up with but I'm sure is about what NI would consider still valid) bucks per year, you are violating the Community Edition license conditions.

    That is an interesting case, but based on the piddly amount of compensation that most average Joe's get for their channels, I would expect NI to overlook that case based on the fact that you are essentially giving them free advertising and potentially drumming up interest for their products.  

    Many channels are sent free products by companies in the hopes that the channel will shill their product, or at least give them some free exposure.  I wouldn't think that NI would be any different, but I could most definitely be wrong.

  11. 1 hour ago, ShaunR said:

    Yikes. Software as a service?

    I was wondering when NI would go this route - seems like every entity that used to produce software as a product is going this way. 

    I like to minimize dependencies as much as possible in everything I do.  Software as a service is one additional dependency that I am not looking forward to dealing with.  

    Since my license is provided via VLA (for which I'm not the administrator as I was at my previous company), I guess it's more of the same.

    Wouldn't surprise me if sometime in the future, some sort of NI subscription is required to use the RTE in order to run executables.  The day that happens is the day that I move to another programming language as my primary. 

    National Microsoft... err... Microsoft Instruments... I mean... National Instruments is becoming more like Microsoft each year and I'm not liking it. 

  12. Okay, I understand now.  

    Once you've opened a file reference, you can keep it open for the duration of the program's use without much in the way of a resource concern.  Unless you're creating a MONSTER of a program (I've seen some, they exist) or have memory leaks somewhere, modern computers should have plenty of resources. 

    That being said, Opening/reading/closing a file repeatedly is harder on resources than simply keeping a reference open, but depending on the scale, it may be a non-issue.  Using the function in your example to read the file does this, but for your purposes (as I understand them), this should be fine.  If you were constantly reading/writing/streaming to a file several times a second, then using that VI wouldn't be recommended.

    So, yes - I would say that you could open/read the file to populate the combo box, then later open/read the file again to search for the desired values.  My guess is that these two actions aren't going to be occurring at a fast/high enough rate to be of any concern with regard to resource usage. 

  13. I'm not sure if I'm missing something, but I don't believe that the code is going to work reliably or as intended, unless I'm not understanding how this SubVI is to be used.

    Updating combo box items/values in a subVI doesn't really make sense (unless you're passing a reference to a front panel control into it).  Even then, you'd have to update the combo box items/values before the they're selected by the  user - then use the user's selection to search for and return the Density/Refractive index values.  

    I have a lot going on right now, so I'm unable to provide an example at the moment.


  14. There are many ways to "skin that cat", but these are the routes I would probably use myself:

    Using a Text Ring instead of a Combo Box (The RingText.Text property outputs the string of the selected item):



    If you're set on using a combo box method, here would be my approach (the Text.Text property outputs the string value of the selected item):


  15. TestStand has its place.  Yes, it can be a very powerful tool, but where I work, TestStand was someone's hammer and every test solution was a nail.  We have several instances where TestStand was grossly overkill, where a more lightweight test executive would have been a better fit. 

    I could write a short novel on all the hassle we've had with our TestStand based testers and the poor planning, development and implementation of it where I work, but I will refrain. (In fact, I did, but deleted it as it went on a long rant). 

    I'll just simply say that I've inherited those @%$#@ machines and they've been nothing but a 4-year headache and I'm slowly replacing each one with a LabVIEW-Only solution.  The ones I've done so far perform much better/faster/stronger, are more robust and the operators gripe much less about them if at all.  In fact a "notoriously gripey" operator said that they "absolutely loved the new tester" after I had completely reworked it to eliminate TestStand.

    • Like 1
  16. Sie sollten ein LabVIEW 2009-VI in LabVIEW 2019 öffnen können. Einige Abhängigkeiten werden möglicherweise nicht richtig übersetzt.

    Wollen Sie damit sagen, dass Sie es überhaupt nicht öffnen können - was bedeutet, dass Sie beim Versuch, es zu öffnen, eine Fehlermeldung erhalten, oder dass Sie das VI einfach nicht ausführen können (gebrochener Ausführungspfeil)?

  • Create New...

Important Information

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