Michael Aivaliotis

Ok, now your idea has 2 votes... 😀 Ya, I decided to delete them all manually, and also the Update Service installers, which are probably temporary packaged files for the update service.

I work with VMs and monitoring VM drive space is one issue I look at every now and then. The "C:\ProgramData\National Instruments" folder on one of my VMs is using 40GB. Does anyone know the proper way to clean up the NI crap? Using SpaceSniffer, it show the bulk of it is used by the Update Service and NI Package Manager. I'm sure it's just leftover installers that may be needed.

Don't forget cRIO has RT so you can implement a lot of programming on the RT side for various scenarios. As a master of the LabVIEW language and NI hardware. I would prefer a platform that allows me to use the language I already know and love. I can provide a PC application that implements anything the customer desires. then I can configure a cRIO and implement ECAT, serial, Devicenet, DAQ, DIO or whatever they want using the same language and skills. If NI does not support the desired hardware i need to talk to, they have many other options like DLL calls and other ways of interfacing that I still have not found a specific limitation that I was not able to workaround to get the job done and still make the customer happy. Yes, there are other languages and opportunities. Anyone who has worked with ECAT has heard of Beckhoff. They pretty much came up with the standard and are pushing it across the industrial world. It's just another communications standard. NI and LabVIEW are at a whole other level above and beyond that. Can NI improve the tools they provide for ECAT, DeviceNET and others? Yes! There are some features of ECAT that the NI tools simply cannot access or configure. A lot of what NI implements is the basics of the industry standard. They rarely go above and beyond unless customers push for it. They have a checklist of industry compatibilities they try to maintain so the marketing looks good. So they still can do better. Recently they started adopting TSN which is very powerful and allows synchronized DAQ across cRIOs and cDAQ chassis. Technology is constantly evolving and I commend NI for always trying to keep LabVIEW on the forefront by providing hardware that keeps up with todays requirements. So as you can obviously tell from this post, I am not going to convert to TwinCat any time soon. However competition is always healthy and keeps companies like NI on their toes to make sure they are always providing value to their customers so they don't start wandering off to other solutions.

What I would like to see is a way to minimize the map or set constant by double-clicking on it. Like you can do with cluster constants. Hand editing Maps is such a small use-case but useful for some I guess. You usually work with these things programmatically. Thanks for the tool.

i get it. Sometimes you gotta patch and move on. In parallel, though, I'd open a ticket with NI to get them to spend some resources on worrying about your problem too.

Can't you just add the numbers and divide?

I made a workaround. Instead of typdefing the entire Map, I just typedef the datatype inside the Map. This is probably the best way to do it anyway. Similar to typedefing an array element vs the entire array. Regardless, however, this is still a bug. Thanks for looking into it.

Ok this is so random how I found this, but I was able to reproduce it. I'm hoping others on here can reproduce it as well. If this is a known issue then please link to the source for reference. I've attached code that reproduces it. But basically in order to reproduce it: Place a Map datatype in the private class data of the class. Make the Map datatype a typedef. lava.zip

I'm noticing that when I probe LV class wires in LabVIEW 2019 SP1, it won't display any data on the probe. In fact it appears as if that part of the code never executed. I just can't figure out how to reproduce it. I'm wondering if anyone else has noticed this behavior. I can clearly see that I have multiple probes on one diagram and the probe attached to a class wired shows "Not Executed" in the probe watch window, even though "Retain Wire Values" is enabled. LabVIEW restart does not fix it. classprobe.mp4

It was not developed in a bubble. There was already a close relationship between the VIPM team and NI. So they knew the requirements and the need. It's been over 5 years since the release of NIPM, so not much movement however... That might have been the first step, but hardly the long-term plan. In reality, I think the main reason for lack of development on NIPM is that people got shuffled around and new management came in and the original development plans for NIPM got put on a shelf. I can tell you that NI had the goal of full VIPM replacement. There is much churn internally at NI on where to take NIPM next. They are back to wanting to add features to facilitate better reuse library installation for current LabVIEW (how to achieve this is not clear). For sure however, this is the clear case with NXG. I suggest you watch this video:

NI caused this problem themselves. NIPM should have provided all the features of VIPM from the start and then added GPM features. Lack of investment. Now they're playing catchup, but technology is moving on.

Well, it seems to be more of a back, than a front. GitHub is becoming the package repo. GitHub is not making a front end manager. Agree this would be hard or impossible to achieve. Ok, ya this is a more attainable goal and a possible path forward. But GPM is not widely adopted and has limitations. NIPM will win by default, because it is made and fully supported by NI. However, it has a long way to go to support all the features we (as developers) need. It's a dumb installer and has no smarts related to the LabVIEW environment. For example, you cannot target LabVIEW by version and cannot allow up compiling of code. NI is investing resources to make it better over time and we need to keep pushing them to add features we need. However, NI moves like a big company does, very slow. There are currently 3 package formats: VIPM, NIPM and GPM. It's a mess, and by reading this thread, it seems people are open to ditching packages all together.

I feel this is somehow related. GitHub supports packages as described here: https://help.github.com/en/github/managing-packages-with-github-packages Do you think this is something that we can utilize for LabVIEW package distribution?

GPM extracts code into your project, BTW. VIPM, NIPM and GPM provide built products of reusable code, among other things. I believe what you are saying is that you consider existing, cloud-based source code control tools such as GIT as a viable option for reusable code distribution. This shouldn't be limited to packaged stuff.

I agree. I don't store those type of file in the repo for a while now. My specific comment was about how to transition from one large files extension in Mercurial to Git. I use Bitbucket Downloads. However, I'm finding that different file sharing tools can be useful for different use-cases. There's really no one-size fits all.