Bryan

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.

That link should have been posted with a disclosure. After clicking on the link and attempting to read the page, my brain BSOD'd.

I agree, a dedicated location for things like this would be a good idea.

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.

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.

Cross Post: https://forums.ni.com/t5/LabVIEW/How-to-edit-the-element-value-of-the-2d-array-of-string/m-p/4207337

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.

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

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.

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.

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.

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.

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):

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.

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)?

Not everything was "free", but I did get a good deal on some things. - Expensive set of industrial environment cooling fans used in destructive environmental testing of a DoD product that still worked perfectly fine after testing was completed. Was able to get permission to take them home. They ended up as attic fans in my old house. - Expensive soldering iron for $1 at a company auction. - May possibly be getting a high horsepower server that we built for our department that was in a recent flood that will be scrapped. Only the bottom of the server tower was in the water, so the power supply would be the only thing that needs replaced. Nothing else except one of the HDs was submerged. - $200 office chair from company auction for $10.

Thank you for posting this. It's very helpful and informative. I was noticing icon font issues in LabVIEW 2020 Community Edition for Linux, so it doesn't look like NI has fixed (or knew about) the issue in LV 2020 for Linux either.

This process worked for me (though not verbatim) in order to install LabVIEW 2020 Community Edition on Zorin 16 Linux. Thank you @Yaw Mensah. The .deb package names varied slightly for me and I had to install alien on zorin and dpkg manually before starting above: sudo apt-get install alien dpkg-dev As of writing this post, I haven't messed with LabVIEW enough on Zorin to say whether everything is working 100%, but I was able to at least launch LabVIEW. I did have to go into /usr/local/natinst/LabVIEW-2020-64 and create a symbolic link to the executable to launch with using the Zorin "start menu" entry: cd /usr/local/natinst/LabVIEW-2020-64/ sudo ln -s labviewprofull labview

That's a lot of participation awards... I'm surprised an Admin hasn't chimed in yet to let us in on the new hotness.

Would you be willing to post what the solution was?

Welcome @LVmigrant! If your company isn't willing to pay for LabVIEW training, but uses LabVIEW - it sounds like a great recipe for major headaches in the future. Speaking as someone who has inherited some really bad LV code over the years, a company's up front investment in training for their employees will save them a lot in the future as far as maintenance, refactoring, and many other things. The bad code I inherited was from programmers who didn't take any training nor took the time to learn from other more seasoned programmers. This is a great community with some of the most knowledgeable LabVIEW programmers I've ever met. Even though I've been using LabVIEW on and off since 1999 - I don't hold a candle to the knowledge contained within some of the the members of this forum. That being said - many of the users in here have contributed to the LabVIEW Wiki, which has a LOT of useful information.

I was never involved with it, where I used to work I supported a software group that wrote code for an automated military application. I can't speak for other DoD contracting companies, but I know that they went through iteration after iteration of software testing, regression testing and debugging over the course of several months to a couple of years with testing "events" that would go around the clock for a couple of days at a time. My role was not with programming for that application, but I was responsible for maintenance and troubleshooting of the simulation testbed that they used to develop their software. If they found undesirable behavior from their code, I worked with them to determine whether it was actually a bug or something wrong with the testbed.

Well - Finding a CLA may be more difficult than finding a CLD. Some people may (like myself) have gone the path up to feeling qualified to take the CLA Exam, but never pulled the trigger for one reason or another (mostly $$ reasons). I never did it because - working for a company - a CLx never benefited me in any way nor did it benefit my company. They were willing to foot the bill for the exams, some of the time, but I never went through the process and let my certification expire long ago after only one renewal. You could specify CLA-Level of experience without necessarily making them have an active or expired credential. However, you'd still have to determine somehow by evaluation or by faith that they have the level of experience they claim to have. Hey! I (likely) resemble that remark!

I would start with having a CLD (recent or in the past) as being helpful, but not necessarily a requirement. Ask them if they've taken any LabVIEW courses and what they were. This should give a baseline of their expected knowledge/experience. Quiz them on what they SHOULD know having taken them. Quiz them on the commonly used LabVIEW frameworks (or commonly used in YOUR job) to get a feel for their grasp on the concepts (e.g. QDMH, DVRs, OOP, etc. LIB MR DUCKS). A courses, a degree, or CLD doesn't necessarily equal competence (but I agree, it gives more of a 'warm-n-fuzzy' feeling) - I've seen it several times in my career. Some of the most competent people I've worked with have no official degree, but lots of experience. Some people can have loads of LabVIEW experience, but never went for a CLD/CLA because the certification wasn't required for their job or field. If they can (and it's not always able to be done because of intellectual property constraints), ask them to provide sample code for you to review. I'm sure others will have more (and much better) insights than I do, since I haven't taken part in many candidate interviews for LabVIEW positions. (Although I will be here in the near future).