Anyone else having DVR/In-place-element structure bug (error 1556) in LabVIEW 2023

[Darren]

Circular dependencies in your code are the most common cause of long mass compiles, and possibly mass compile hangs. They also cause long build times.

I've never used this tool, but I've heard its helpful for identifying circular dependencies: Tools - LabVIEW Craft (labviewcraftsmen.com)

[Kyle97330]

For those interested:

The tool Darren linked creates graphs like this one that are opened in a web browser (I've removed the names from the classes, but they're present on the diagram).  When you mouse over a class, it highlights only connections to that class:

A connection that is wide one one end and skinny on the other is a 1-way dependency.  If it's wide on both ends, then it's a circular dependency.  In this example I am highlighting the class in the upper right, showing that it has 7 classes it depends on, 1 of which is circular (the grey one at the top), and 1 class that depends on it.

It's not amazingly useful in finding circular dependencies, as it produces a visual graph rather than a list you could filter to show you just the circular dependencies, nor is it particularly great at helping you resolve them as it doesn't isolate the cause of the dependency either.

[sdusing]

---

@Darren wrote:

This problem is likely related to Bug 2411021, which requires a recompile of the code to fix the issue. Note that this should have happened transparently, but could potentially be an issue if some of the code (but not all) has been compiled in LV 2023 Q3.

@sdusing, can you mass compile your entire codebase and confirm that that the issue no longer occurs?

---

It's going to be a longer exercise to find and remove all circular dependencies and then get a mass compile to work. I'm going to mark your comment as the solution since that is most likely accurate.  Is there anywhere we can find more information on Bug 2411021? I'm not seeing it online or in the known list of issues for LV2023 Q3, but I might not know the right place to look.  I'm mostly interested in being able to track when NI resolves this.

[Darren]

Bug 2411021 was introduced by another change in LabVIEW related to eliminating some reference leaks with DVRs. To clarify, Bug 2411021 was actually fixed in LabVIEW 2023 Q3, but requires a recompile of your code. Normally this should happen transparently, but if you have some code that has recompiled and other code that has not, you'll see the issue that you encountered. A mass compile is the most dependable way to ensure all your code is compiled in the latest version and is able to take advantage of the fixes included in the latest version. NI recommends that you mass compile your code when upgrading to a new LabVIEW version.

[sdusing]

I have waited until LabVIEW 2024 came out, in the hopes that going to a new year version of LabVIEW would resolve this problem. However, I'm faced with the same issue. I'm getting random 1556 errors in code that I KNOW works in LabVIEW 2023 Q1. Any thoughts on how to resolve?

I have tried a mass compile on my project folder. which did complete, but did not resolve the issue.

[Darren · Accepted solution]

---

@sdusing wrote:

I have tried a mass compile on my project folder. which did complete, but did not resolve the issue.

---

I would expect a mass compile to fix it, but if it's not, then another thing to try would be to open any top-level VI(s) from your application and Ctrl-Shift-Click the Run Arrow of those VIs, which will force recompile the entire hierarchy of the application. This will take a while, but whenever it's done, all of your VIs should be recompiled in the current LabVIEW version, and you can do a Save All, run your code, and see if the problem still occurs.

[sdusing]

So the mass compile did fix the issue when I run my code from my project. However, I'm trying to run my code from the main application instance instead. My top level vi (in the project app instance) calls another vi that is set to run in the default application instance. (Unnecessary detail - but I'm doing this to run in the same application instance as TestStand).

My code behaves fine when I just call the code directly in the project app instance. However, it still gives error 1556 when trying to use the DVRs if I run in the default application instance.

Is there anything I should be aware of related to how LabVIEW handles compilation for different application instances that could help me resolve the issue I'm seeing?

For reference, here is my top level code. I have already tried force recompiling (Ctrl-Shift-Click the Run Arrow) this vi as well as the "Top Level - Build.vi" that this calls.

[Darren]

I've asked LV R&D if they have any ideas of what might be going on here. I'll keep you posted. Any chance you can share code with me that reproduces the issue?

[sdusing]

I've shared the code with NI just now. Darren - I assume you have access to it there?  If not, let me know and I can send a direct link. I would like to avoid providing my code directly on the forum since it does contain a number of our reuse library dependencies that we consider IP.

[Darren]

If you want to send me a forums DM with the service request number you used to submit the code (I assume that's how you shared it?), I can take a look.