Slow LabVIEW 2019 Development Environment

[Niatross]

I am working on a project in LabVIEW 2019 SP1 and suddenly it has started to become very slow. I am referring to the development environment not my code execution. Opening/saving VI's and placing block diagram items takes minutes. Once items are placed wiring isn't too bad, but is a little sluggish. It's the opening and closing that is ridiculous. Whilst LabVIEW is doing whatever it is doing it will max out one CPU core and the entire development environment will freeze

My project has code for both a computer and CRio target. There is quite a lot of interlinking between them, in other words I am using typedefs or VI's which are located in the computer target in the CRio target so they show up as dependencies in the CRio. All my code is split into modules in their own libraries.

The problem goes away if I remove all of the CRio code from the project. Obviously this will not be conducive to continuing the project though... I can't currently work out exaclty what part of the CRio code is causing the problem.

I have updated my display drivers and experimented with display settings as described in this KB article but to no avail.

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P8dWSAS&l=en-GB 

Does anyone have any ideas as to what might be cause the IDE to freeze like this?

[Niatross]

I have also tried clearing compiled object cache and then mass compiling again. This highlighted a VI with insane objects which I have fixed. Not sure whether that has any potential relevance 

[Niatross]

Bump as this problem is still haunting me and is causing my development on this project to grind to a halt.

My current leading theory is that it is being caused by me using code located in the My Computer target in my CRio target as well. This is causing the entire library that code is in to be listed as a dependency along with any other dependencies of that library.

I think this because some of libraries are showing as locked. When I click why is this locked I get a message saying that it has edits in another application, this is going to be the CRio target.

I have been going to through removing stuff trying to locate the source of the problem but to no avail. Occasionally I will remove something and the libraries will unlock and everything will work fine. Close and reopen LabVIEW and it is slow again though.

I am currently going through trying to extract any files which are used on both My Computer and CRio targets and store them outside of a library in order to stop LV. This is a painful process though.

If anyone has any thoughts not just on what might be causing this but also how I can go about debugging this I would appreciate it.

(Unfortunately I can't post the entire project here and I also can't replicate it on a smaller project, mainly because I don't have a clue what is causing it at the moment)

[Yamaeda]

Shut down the project and use only the Libraries. Something seems to go into a spin in projects, but i have no idea what. Unfortunately you'll lost much of Quick drop this way. 😕

[Niatross]

That doesn't feel like a permanent solution. Are you saying don't use a project at all, just libraries?

If nothing else I need a project sooner or later in order generate a build spec for CRio and FPGA deployment

I suppose I could separate the CRio and HMI sides of the code into separate projects, that might help.

[Yamaeda]

Basically only use the project when building, if this starts to happen

[JÞB]

It sounds like this project grew beyond your customary workflow.  And you are most likely using libraries poorly.   So let me give you some advice. 

Let's start with a library.   EVERY library should be developed in an owning project.  For a simple example I'll use "File  I_O" because it is common.  File I_O.lvproj would contain:

• File I_O Example.vi
• File I_O Docunentation.txt|docx|etc. Something human readable
• File I_O tests\ <folder>
• File I_O.lvlib
• Optionally, a build specification for File I_O.lvlibp (recommended)

File I_O.lvlib will contain at a minimum:

• Public folder "API" with Open File.vi Close File.vi, Write File.vi and Read File.vi.  you might have create, delete, copy, etc... but we're keeping the example simple.
• Maybe a public folder Utilities with e.g. Set / Get Datetime String.vis
• Private folder that does stuff the API.vi callers don't have to play with.   Maybe a Core Action Engine. Perhaps that Global variable Datetime Format String,. And Utilities for converting to csv, ini, XML. Whatever..

Now let's look at what that did to the user project "Thornby Super Controler.lvproj"  the TSC.lvproj does, among other things,  File I_O dependencies contain only the lvlibp and since those are read only or under separate SCC silly cosmetic edits can't lock your library.  The debug features can be removed (we tested in File I_O.lvproj) and we could even have shell code so multiple developers can work in parallel. 

[Niatross]

I don't think I disagree with anything you have said, unless I have misunderstood...although I don't develop each library in its own project. I have also trialled packaging my libraries in packed libraries but I didn't like that they are then available to the end user because you can't package them into an executable. It is only a minor thing but you never know when that might expose something you don't want exposing.

The thing that is killing me I think is I define some typedefs in my library, lets stick with your File IO example and say I have created a type deffed cluster defining data being streamed from the cRIO.

I use this type def within the library on the My Computer target and in the cRIO target. This causes the entire library to show as a dependency in my cRIO. I also have a library of reuse code (Which you may disapprove of but it has worked so far for me because I don't develop my libraries in isolation) which my library uses and therefore then gets listed as a dependency in my cRIO.

From your description of how you suggest to use libraries it sounds like you would also define the typedef in your library and expose it through your public API. Defining it elsewhere would mean you library is no longer a self-contained module. Also defining it in both the cRIO library and the My Computer library seems totally wrong as they should never be different.

I have started moving these typedefs out of their libraries and into a virtual folder in the project and this appears to have fixed my problem, although I have had false hope in the past where I thought I had fixed it only for it to reappear. It has been fine all day which is good. I also haven't pinpointed which typedef was causing the problem.

[JÞB]

Very close. Except for the exe build

Stick the lvlibp IN TSC.lvproj Not Dependencies,  and it builds into the exe. 

For typedef I HAVE TO expose ( and some would argue that that could violate data hiding and say use a class instead)  again, drag the lvlib(p) out of dependencies into the TSC.LVPROJ and make the typedef Protected rather than public.  From reading between the lines... I don't think that I would pack a lvlib that I would Reuse in development of multiple lvproj BUT I'd most assuredly have a lvproj with examples documents and test cases for every lvlib I use this way!  If for no other reason, because I could set up a development Environment with a specific lvlib version from SCC!  Packing in this case only really benefits your when later versions of the RTE are used to execute the library without forcing you to fork the source code as a copies for 2017, 2018, 2019, 2020...I still have nightmares.