hooovahh

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.

I do have a very quick and dirty solution that I wrote many years ago without consulting the internet or what would be the right way to do this. That being said I just ran it on the Stack Overflow test and for: Robert, and Amy Robertson my code had a 44% match, and for Robert and Richard it had a 0% match. That being said if you can come up with anything better or more standard that would probably be better than this. Compare String Confidence.vi

If the snap does work, but returns the exact same image, you might be able to detect a locked up camera by comparing the last two images and seeing that they are exactly the same. At that point I don't know if closing all references, and re-initing would help or not. I've had some success with this, depending on what caused the lock up. I've had other cameras that really seem defective and the only fix was to power off and on the camera. For that something like a relay could be used to kill the power and turn it back on. But in general I suggest using high quality ethernet based cameras because of some of these issues that I've seen in the past. Still ethernet cameras aren't without issues. I've seen firewall or antivirus software cause camera images to not acquire properly.

I know this is quite old, but I recently sent a link to this when answering a question, and I realized I have added a couple of opcodes over the years that people might be interested in. Also Jing as a video recorder is old and I've been moving my videos away from it and hosting on Youtube instead. I've downloaded the two videos Norm and rehosted them there. Image Move.zip

Is there a good reason that this is password protected? Other than it probably is a single call library node to some internal function?

Historically support is something I've said NI and Microsoft both have been done well. Lately I'm having a harder time lately singing NI's praises for support. NI used to have all new hires work support first before going to other departments. This in general made support a bit green, and you'd need to escalate a couple of times before getting what you needed. My career started as a co-op and so being thrown into the deep end of the pool certainly helped me learn quickly. And I liked the idea of NI people all starting out having to quickly get familiar with NI's offerings, and being close to the customer issues. I suspect NI has gotten feedback over the years that this model for support didn't work well and I heard NI was changing this policy.

Oh sorry, here is a VI I made a while ago for generating a GUID. It might need to be modified for the pattern you need. Generate GUID.vi

Yes I too am only familiar with reading these file types but not writing. NI has the ECU Measurement and Calibration Toolkit which is a CAN toolkit for performing XCP and CCP functions. One of which is flashing new software to an ECU over CAN. In there is the start of some code that reads SREC and HEX files. Some of the file types were had poor performance and I made an attempt at improving them. This code can be found in the CAN File IO package here. But I admit that is a whole lot of code to install for some simple file reading stuff so I've attached the important bits here. This appears to support S0 through S9 types, and some kind of HEX files that start with a ":". Looking at the code I still see some room for improvement. Hooovahh SREC and HEX.zip