hooovahh

I can talk a little about VLAs since I have them, but I can't say how they will be effected by this change because we haven't had to renew yet. In the VLA you have a system where you have a bucket of licenses that can be assigned to users, or computers. I think NI wants this system to be automated, and maybe for larger companies it is. But in every case I've seen a VLA done licenses are assigned or revoked manually. At my last company we had something like 4 professional licenses, and 2 base licenses. Every once in a while someone would create a goal for themselves to learn LabVIEW, and we would go into the VLA, and assign a base license to them and let them take online training. We'd often make a disconnected license, which was a license type that works without needing network connections to the server running the VLA. This is because IT, and VPNs, and internet stuff caused problems. It was just easier to make a disconnected license, then email them a file, with instructions on how to add it to the NI License Manager running on their machine. For these people learning LabVIEW we'd often make the license PC based meaning any user on that PC can use LabVIEW. But developers that worked on multiple computers could have the license be user based. This meant they could log into any PC on the network with their user name, and active LabVIEW with the same license. This user name also doesn't care about if the user is a local Windows one, or a domain controlled one. When you create a disconnected license you can give it an expiration date. This by default is the date that the next renewal takes place on. However you can create a disconnected license, for a user or PC, that is permanent. This license can be used on a PC without the internet, and can activate that version of LabVIEW or older. Again this can be based on a single PC, or a user name. When a new version of LabVIEW comes out, the VLA gets updated, and a new disconnected license can be created. I've been making permanent disconnected licenses for myself and I think that means LabVIEW 2021 SP1 will be accessible even after this change. After that I'm unsure if a disconnected permanent license can even be created.

Sorry I have to play devil's advocate. But is it growing slower than other programming languages?

Ugh that sounds terrible. All of this on top of the typical stress of preparing for the exam. You likely already know this, but NI has a program for recertifying by participating in NI events. These accumulate points, and if you have enough points you don't have to take another test to recertify. I've done this once, and hope to do this for as long as NI allows me to. It used to be much easier to get enough points. I'd participate in a beta two years in a row for 30 points, and attend NI week for 15 and, then attend a user event for 5 giving the 50 I needed. Also presenting at NI Week is 30, which is over half way there. Unfortunately I haven't had much time to participate in betas, and NI Week and the CLA Summit hasn't happened in a while. Luckily there are still user groups where presenting gets you 10. I got a couple years before mine expires but I'll need to make sure I do enough. Passing the CLA wasn't easy.

Agreed. I did use WebVIs when they were part of NXG. And I did get a UI that had a decent amount dynamic UI stuff. But it was primarily done with many duplicate controls, inside transparent tabs, so I could show and had data, while making it look like things were moving around. Of course at the time this wasn't straight forward, not sure if it has gotten better. It got so bad that the IDE just chugged to a crawl. I contacted support at NI and showed them the several hundred controls I needed to make it look normal. NI's original reaction was "Why would you need so many controls?" and then after explaining the UI/UX I was trying to make their reaction was "Yeah I guess that is the only way to get what you want". Luckily once built into HTML it ran just fine. I've found a couple times when these limitations are arbitrary, or just based on incomplete testing. A few times a VI will return an error when on a platform that it wasn't intended for. If you look at the block diagram it is a conditional structure just set to generate an error. In a couple cases when I removed the structure the code ran just fine.

Sorry. I suspect part of the issue is that once NI announced WebVIs and porting the runtime engine to JAVA script, companies probably thought there isn't much sense in trying to have a 3rd party tool compete with NI's. And either froze development, abandoned the project, or rolled it into other tools. Still I do use MediaMongrel's WebSocket API, and I've used the Front Panel Publisher on a program or two but nothing active right now. I've wanted to update it to add support for more data types, and clean up the examples, but without a program that uses it, and with very little Java experience, I don't think anything will happen to it.

I like to reference this thread occasionally when people ask about web and LabVIEW solutions. Since it has been a few years lets see if I can give another summary of the options. I haven't used all these but just wanted a list of NI and non-NI ones that were available. These are not all equal, and the intention is that here is a landing page where people can find tools and do their own research on what meets their needs, while providing a little history. Solutions From NI: G Web Development - Came from WebVIs in NXG's Web Module. Paid toolkit. Web Service - Great for simple request response, but the UI needs to be made somewhere else. Included with LabVIEW Full/Professional Web Publishing Tool - Simple to use, works on RT, but uses Silverlight and no modern browser supports it, just IE. Included with LabVIEW Data Dashboard - Tool for displaying Network Published Shared Variables on tablet devices. No longer supported. Web UI Builder - Pre NXG no longer supported with download links missing. Linked to the 2009 Keynote. 3rd Party Solutions: Front Panel Publisher - Open source originally used Web Service but now uses Web Sockets. MQTT WebSockets Connection - Open source. UI needs to be built by another tool. WebSockets API by MediaMongrels - Free toolkit, MIT License. UI needs to be built by another tool. LabSockets - Paid toolkit with trial. Wezarp - Paid toolkit with trial. Encryption Compendium for LabVIEW - Websocket API included among other tools. Paid toolkit. UI needs to be built by another tool. WebPager - Not sure never used it. The original site seems down. VIRemote - Appears to be a paid toolkit but has a free demo. WebPanels - Hosting site seems down, LAVA thread linked. Remote Witness - I think it was a paid tool but the site doesn't have much.

Sorry I haven't had experience with HyperV and Linux RT VM. I've stuck with Virtual Box and with the instructions posted on the idea exchange and didn't have any issues.

You can, but it would probably be best to just paste in your issues and any example code that demonstrate the issue in the report. That way the issue can be tracked more easily by NI.

Thanks for the info. LabVIEW Linux doesn't get much love. Combined with the large variation in Linux environments can mean issues like these. Can you post this on the dark side? Is there a Linux desktop sub forum? If not sending these to NI as a service request would also help.

Sounds like there is a common denominator here.

For the second question I said other. What I wanted to say is there is very little if any, unused code in the project. If I make a VI to do some purpose, and then that VI is superseded, or the functionality is replaced, I delete the VI from the project and SCC. Obviously it is still in the revision history so it can be restored. There are a few cases when a VI isn't used, but still valuable, and in those cases I'll either move it to a sandbox folder for the project, or copy it to the reuse library candidates, where it might be polished and added to a reuse library. With classes I might end up with several small VIs that don't do much, but accessor like VIs are usually scripted through the class as needed and don't take much effort to make. And for me almost all of my classes belong to reuse libraries, where you'll access them from the palette anyway. So it might have unused VIs, but it isn't like you are aware of them in the project, or where they might be on disk.

I messaged the site admin.

Yes I do have some issues with flattening a cluster to a string for logging. I already have a set of code in this package for reading and writing cluster data to a TDMS file. It just doesn't support the various TDMS Classes I made, it works on the TDMS reference alone. But the code in this package has a ton of overhead. It flattens the string to a string, with human readable decimals, and tab delimiters. I posted an update on the dark side here which works much better but by writing the array of bytes as a string, with padding used on the bytes that need escape characters. It also supports different methods of compression. (some of this is in the VIPM.IO package too) This works much better but I found a bug in regards to how the extended ASCII table is used. If you write a cluster to a TDMS file, then FTP that file over to a Linux RT target, it won't be able to read the bytes where the 8th bit is used. I believe this to be a bug that NI hasn't confirmed. In any case extra escaping characters can be used for these cases too. Anyway this is all just to say that at the moment the reading and writing of cluster data needs some attention before being updated in this package.

Oh that is better than renaming EXEs and copying them. A native solution from NI would be even better but I'm guessing they don't get this kind of request often. Still if the embedded target has some desktop like functionality it isn't crazy to be able to run arbitrary LabVIEW binaries.

So combining the script to stop and start the NI service, with a couple of file copies or moves, you could get something that works but is pretty clunky. When the user tries to switch programs, it will need to copy over the other rtexe, replacing the current one, then have it call a script to stop and start the NI service. That might bring up the new rtexe, but will have issues if you restart the controller as it will run the now new rtexe instead of the older one. It might be possible to on start up, copy over the first rtexe back before the NI service starts. All very clunky, and probably not what you want but possible. Other developers would probably suggest trying to just make a single LabVIEW project that combines the code from both into a single application.

I'll take it! Also a Texas Tea is like a long island tea but with tequila instead of gin. I like gin, and don't usually like tequila but man when I'm at NI week, those are amazing. Thank you @Mark Balla.

Okay here is a quick first update to the Write VIM that has special code if you are writing an analog waveform, or an array of analog waveforms. It will write the waveform properties and then flush the file, then write the 1D array of doubles for a scalar, or a 2D array for a 1D array of waveforms. On the next write it will see the property for the waveform exists, and not write it again, but the dT between the write must match. If it doesn't it generates an error. This is still using just the normal TDMS write. So if you are having memory issues, this doesn't use the advanced stuff, and might not fix it. Partially because don't have experience with advanced TDMS stuff, and also because I don't fully understand the original issue. Write Tremendous TDMS - Waveform.vimSet Waveform Properties.vi Also I noticed that there is a disabled structure that has a partially implemented cluster write. I should probably finish and test that.

Never meet your heroes. Unless it's me and you're planning on buying me a Texas Tea at the piano bar. In that case you should definitely meet your heroes.

So I'm still reading the thread, but I don't fully understand the issue, or the solution. I get that you are saying there is some issue with the normal TDMS Write, and this issue is most commonly seen when writing waveform data. And I get that waveform data really is just a 1D array of doubles, with a bunch of special properties. So I can absolutely update the write function to instead of writing a waveform, write the properties and the doubles differently. But I don't have much experience with the advanced primitives, and I'm not sure how they come into play. Is it possible to attach a VI that demonstrates this uncontrollable memory leaking/growing problem?

I get what you are saying, and agree with some of your comparisons. I've seen on the forums a few times when an inexperience LabVIEW developer is like "I know nothing about programming but was able to make a spectrum analyzer using Express VIs." And half the replies will be from people like me saying "You're doing it wrong" and they will replay with "Well yeah maybe, but it sure got the job done without much work." That's sorta how I feel here. Your criticism of Network Steams are valid. And better solutions can be made. I'm just glad that I was able to make a synchronous network transport mechanism that uses VIMs, has status, automatic reconnection, and can target applications running on different platforms and different operating systems. All of this with no networking experience, and the amount of effort needed to make this was pretty minimal. I forgot to update this thread, but I did present this to the user group here, and uploaded the package to VIPM.IO here.

Around there, if I had to guess I'd say 8.0 or 8.20.

Okay I may have a solution, but I don't know if it will work in your use case or not. If you wire a cluster to an Add, it will work if all elements in the cluster support the Add function individually. So you could have a VIM that has a Type Specialized structure, and perform a type cast if all elements in the cluster support the Add. Oddly enough in my test I used a Timestamp Constant, and that makes a pink wire, but supports the Add, and is a fixed size. But I'm not sure I understand what you want done into the byte array. If you are just trying to get a byte representation of a cluster, and you want to use a fixed string for those cluster elements, it probably would just be best to iterate over element in the cluster with while loop recursion. What I think you what can still be done with a VIM, using the Type Cast in one type specialized case, and then if that fails, then to iterate over all elements.

Thanks I appreciate the feedback and I'll change it, but not push out a new version of the package for a change like this. Also your comment does at least help me know that someone does use it on a cRIO and finds it useful. Edit: Actually looking at the newest version of the package here, and the newest version of the package on VIPM.IO, the front panel looks like this. And actually I think I always put defaults in parenthesis and not brackets, and I don't think I would bold a front panel label. Are you sure someone didn't edit that?

I mean it is a programming technique for making code more portable, by including small external dependencies. But I agree that having embedded programs AND having Run When Open is concerning. I mean other than the Abort All VIs from AQ, I can't think of a good reason a file downloaded would be set to run when opened. I did see in a controlled environment, Run When Opened was being used in place of making an EXE. Operators would just double click the Main.vi shortcut, it would open it in LabVIEW because they had the full IDE, and then it would run. It wasn't a good practice to have and I advised against it. But those are the only two cases I can think of where it could be used. Edit: I do remember embedding a VI as a block diagram constant too. In my LabVIEW Tray Launcher there is an Abort All VIs, which needs to be saved in the oldest version of LabVIEW supported. If the VI was a static reference the application builder would resave it, but then I couldn't do an Open VI Reference on other versions of LabVIEW. So I saved it as a constant, then when needed it would get saved to a temp location and ran. But again this wasn't a Run When Open situation.