LV compiler error while trying to open vi

[StewieRupert]

I have a source controlled LV library that's not under a LV project. It was working fine yesterday but today it is throwing a compiler error as in the attachment

                                                      .  

[ikaiser]

Hello StewieRupert,

Can you give some more information about what your library is? If it's public, can you please also provide a link? It's almost impossible to give useful advice without knowing what your project is doing.

Are you using this library in an application? If so, what is the bigger picture of your application/library? How big is it, how many VIs are in it, what is its structure?

I have seen this error only once, in an application with 2500+ VIs. That ran into a Windows Limitation regarding the number of allowed GDI Objects (simplified: "things shown on the UI"). Increasing that number helped in this specific case. However I'd only give it a 5% chance this will solve your issue as well.

Edit: The limit is typically around 10000 objects per application, you can see the current amount used in Windows' Task Manager: Overview of Performance Monitoring

Which version(s) of LabVIEW are you using?

[StewieRupert]

I am not allowed to share it publicly. But it's a Hardware Abstraction Layer library implemented with OOP and works in conjunction with Teststand. The library is still in its initial stage and the number of VIs is around 280. 

My older version still works. Could a programming error cause this?

[ikaiser]

---

@StewieRupert wrote:

I am not allowed to share it publicly. But it's a Hardware Abstraction Layer library implemented with OOP and works in conjunction with Teststand. The library is still in its initial stage and the number of VIs is around 280. 

---

So this is your own development, not a 3rd-party library you downloaded somewhere. Got that. Do you have the possibility to try to open/compile this on a different computer? Maybe it's OS or installation related.

In case you can share your code with NI and think it would be beneficial, be aware that you can also contact NI's support department directly. Either via web (http://www.ni.com/en-gb/support.html, scroll down to Service Request Manager), or calling and asking for support.

---

@StewieRupert wrote:

 My older version still works. Could a programming error cause this?

---

Surely. What have you changed since the last version?

Did you check about the GDI limitation?

[StewieRupert]

Yeah we are doing it in-house. I ran the recent version of the library in my colleague's computer and it worked fine with no crash. The problem is just on my computer i suppose.

I added a serial communication class as a component of Device class and then made NiDMM class use the communication class object to commicate with the hardware. There's no edit-time or run-time error.

I had a look at the GDI limitation. It was at default of 10K and I changed it to 30K. Anyway that does not help.

[ikaiser]

Creating a MAX Technical Report to Document Configuration Information

---

@StewieRupert wrote:

I ran the recent version of the library in my colleague's computer and it worked fine with no crash. The problem is just on my computer i suppose.

---

I would assume this as well. Without knowing anything about your setup, I'd check if there is any difference in NI software/driver installed on both machines. You can use NI MAX for that: Determine the Version of the NI Software Installed on My Computer. You can also create MAX technical reports (Creating a MAX Technical Report to Document Configuration Information) on both machines and compare them. The report is a zip file, which has an html file inside.

In case there are all the same versions and packages installed, you might want to re-install everything: Force Reinstall Non-Working or Corrupt NI Software

[JÞB]

Now for some questions to clarify what may have happened. 

Source controlled library not in a project.

Elaborate on that.   Llb, lvlib, lvlibp, dll?  What SCC? is the compiled code in SCC or separated?  Do all developers follow your groups rule on this or could a component have been created and committed with the wrong setting (note, if you had it in a lvproj with the project properties set you would never run into this question.. get it in a lvproj  today)

How is Teststand calling it...through what exact context.  You can really corrupt library components with mixing absolute and relative paths and mixing contexts by calling through a project and not.  Again,  the lvproj and using it in teststand prevents this.

Did you clear your object cache if the source is separated?  Without a owning lvproj you'll have to check every single file in SCC.

And yes, I strongly suspect that TestStand held onto a vi copy in a proxy caller that got created by a bad step setting...

Update and release your library.  Then change implementation in TestStand.  Mixing the two processes can lead to unexpected consequences....but, you know that from recent experience don't you?