hooovahh

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.

This looks similar to the issue I mentioned earlier with SSE instructions. The guess at the time was that the translation layer of Windows for ARM for running x86 applications, didn't fully support all the instructions. This is why in my experimentation with LabVIEW on Windows 10 on a Pi, I had to go with LabVIEW 2016. With 2016 there is settings in the application builder that can turn SSE optimizations off. Since VIPM is built using LabVIEW using those SSE instructions, it can't run. MAX corrupting Windows is a new one.

I'm not sure how to change this either, I'll contact the site admin.

I agree that people have been asking for unicode support in LabVIEW for a while. But there's a good chance NXG development definitely started more than 10 years ago. The first alpha available for people outside of NI was around 2013. And the Web UI Builder was showcased at NI Week 2010, which has some core components of what NXG would become.

By the way LabVIEW 2021 now warn you about VIs that are set to run when opened. Years ago I made a LabVIEW Tray Launcher that takes over the file extension, and allowed to select what version to open a file in. I added a feature there that would also open it without running it. I haven't updated it in a while so no idea if it still works right.

I've met Eric and Omid. I can't vouch for their intentions, or background. I can say they were friendly energetic guys and on the surface seemed to have good intentions for NI as a whole. Didn't know Eric was worth $14 Million. Also didn't know Jeff K. is worth $112 Million. Anecdotally I've always thought that those at the very bottom, and very top of an organization generally do good things for the company. I've generally seen the corruption, cheating, stealing, and short sited poor decision making happen at the middle management level.

It is still free (as in beer of course) for all non-commercial use. It might only be licensed for one year at a time, and it is linked to your NI account. It does make the SAS model a bit easier to swallow, along with the 3 year locked in price. As an individual I can still keep up with LabVIEW and use it for all the stuff I want.

I'm not so sure, I saw this on multiple machines. And it still behaves this way in 20.0.1 on the one machine I have access to. Edit: This is for the original issue with dragging within the project.

If you go to NI.com/support then click "Manage your active service requests" you should see all the times you contacted NI along with the case number and issue details. Hopefully the CAR or bug number is in there. It is a bit slow at loading things.

As far as I know built applications use the run-time engine which requires no license, just a EULA for installing it. If you are talking about things like FPGA and the Real-Time module then I'm not sure but I suspect they too will use an annual license strategy.

Good point. I wonder if people are going to go out and buy a perpetual 2021 license while they can. I currently get my license from a VLA that we renew each year. Depending on the options we may just renew like normal. I do suspect the price will go up compared to what we currently pay but we'd get access to lots of other software we currently don't.

Today NI announced a new subscription model for all NI software, with special exceptions for perpetual licenses for things such as debug and deployment licenses. https://www.ni.com/en-us/landing/subscription-software.html I don't really have a whole lot to contribute to the discussion just yet, but I just thought I'd make the community aware of it in a separate post so people can discuss it if they'd like.

https://www.ni.com/en-us/landing/subscription-software.html Edit: I made a new thread regarding this topic.

So I'm not sure I fully understand your issue, but I believe it might be related to the fact that you are changing the XScale Offset, but you don't specify which is your Active X Scale. I think by default it will probably pick the last X Scale as the active one, but if you want to specify the first one, you need to write a 0 to the property Active X Scale, before performing the offset, then if you want to change the second one you write a 1, followed by the new offset. Remember property nodes are executed from top down, so you can try doing stuff like this.

That thread looks promising. I experimented with Windows 10 ARM by putting it on a Raspberry pi, then trying to run LabVIEW programs. At the time the x86 emulation built into Windows 10 didn't support several SSE extended CPU instructions, and LabVIEW EXEs wouldn't run. After rolling back to LabVIEW 2016 I was able to disable those instructions, make a build, and run the EXE. I didn't attempt to run the IDE because even installing the runtime was difficult with various MSI installers needing to be manually installed.

Vision Builder AI does have a button that was something like "Generate VIs" which would create the VIs that would do the functions that Vision Builder AI did for you. This was a one way street and wouldn't let you make changes and convert it back. But still being able to drag functions and test things out, then see the VIs that would do that work for you would make for an easy development process. Again no idea if this is what OP is talking about.