hooovahh

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.

Seems like there are several VIs missing. Some are on the Desktop under RS CAN Communication. Still I'm not sure how RS485 is used. Regardless I'd put another device on the CAN bus, and listen to the traffic to isolate where the issue could be coming from. Is the device not sending it properly? are you not reading it properly? This might be more obvious with another device on the bus listening.

Great question and one I don't think people think about often enough. So yes lets say you stick with LabVIEW 2021 for 5 to 7 years. What kinds of complications will you have? Well LabVIEW itself won't just stop working. If you stay on the same OS, the same LabVIEW version, and use the same hardware you have today nothing will suddenly stop working. So on the surface you shouldn't need to worry at all. But in practice there are some things that might cause you to have issues. Here is a compatibility chart for LabVIEW and Windows version. This might matter because what if Windows isn't supported anymore? Well right now 2021 supports Windows 10, but it is unclear if it will officially support Windows 11. I suspect it will get support for it with the service pack in a few months. If that happens then 2021 will be an even better choice since Windows 10 at the moment will lose support support in 2025. But even if NI doesn't support LabVIEW 2021 in Windows 11, there is a good chance it will just work. People are very successful with running older LabVIEW versions on newer Windows, NI just doesn't validate it for that platform. Lets say you stick with 2021, and Windows 10. In 4 years you will either be on an unsupported OS, or need to hope Windows 11 will work with LabVIEW 2021. If the upgrade works, great. But you aren't out of the woods yet. You might have hardware compatibility issues. Lets say some hardware you use isn't supported anymore. This would only be likely if the hardware you are using is a couple generations old, or listed as deprecated, or legacy by NI today. Then you might find that NI stops supporting the hardware in the drivers. If the hardware dies, you may need to buy new hardware. This new hardware might functionally replace it, but support might only exist in the newer driver versions. And LabVIEW 2021 might not be supported. As an example, lets say you needed to buy a PXIe-4497 to replace some legacy hardware. This card just got support in DAQmx 21.3. This means you can't use this card with LabVIEW 2017 because DAQmx 21.3 only supports 2018 and newer according to this table. If the PC dies you'll have issues too. I worked at a place that started to see an uptick in support calls from older systems running Windows 3.x or 95 and it was due to the hard drives just dying. We couldn't replace it with a such and old machine so we updated to XP at the time. This big change was difficult for several reasons. For us we updated the computer, OS, LabVIEW, Drivers, and code. From one year to the next, the number of hardware support being dropped is pretty minimal. And the OS support doesn't change too often either. But if you compile all of these changes over 5 to 10 years then the difference can be quite large. For us the cost of yearly support, is less worth it to not have these stations be unsupported, or the risk in having to drop everything and spend weeks getting it going if something happens to them. My gut feeling is 2021 should be fine for at least 5 years. After that I can't say.

Yeah a lot of the decisions made there seem pretty dumb looking at it now. But it was a personal project and really just needed something that could tell me if a string pulled from a webpage, had a similar enough string to a file name on disk. Good luck.