VI Hierarchy - FPGA Simulation leftovers?

[Intaris]

I am working on a project where I regularly run some FPGA code in simulation mode.

Performance has gotten kind of sluggish on FPGA (nothing new there, right?).

I just switched to a different project to look at an issue in a certain VI and wanted to display the VI hierarchy and saw this:

It looks like these DLLs (There are about 40-50 of them at least) are left over from my last FPGA simulation operation.  Currently, no FPGA taqget is set to operate in simulation mode so should these DLLs not be disposed of somehow?  Could this be contributing to my slowness when editing VIs on FPGA targets?

Using LV 2015 SP1

[JacquesS]

Hi Itaris,

I don't see why running an FPGA VI in simulation mode would result in DLLs showing up in the VI hierarchy. Also, I doubt that this is related to the performance while editing the VIs.

- Do all these DLLs in the VI hierarchy point to the same location? Where should these DLLs be located?

- Could you check if a DLL gets added to the hierarchy if you execute it again in simulation mode?

- Could you please attach the project with the VI in question (ideally as ZIP), so I could have a look at it?

Regards,

[Intaris]

---

@JacquesS wrote:

Hi Itaris,

I don't see why running an FPGA VI in simulation mode would result in DLLs showing up in the VI hierarchy. Also, I doubt that this is related to the performance while editing the VIs.

- Do all these DLLs in the VI hierarchy point to the same location? Where should these DLLs be located?

- Could you check if a DLL gets added to the hierarchy if you execute it again in simulation mode?

- Could you please attach the project with the VI in question (ideally as ZIP), so I could have a look at it?

Regards,

---

I also don't see why the DLLS should be appearing at all.  Hence my post...   I'll check things out if I ever notice it happening again.

As to where the DLLs should be... I have no idea, they're not my DLLs.  They seem to be DLLs used in the background to assist FPGA cycle-exact simulation when one investigates the names of the DLL functions shown.

I can't really add the entire project as a ZIP, it's very large and I'm not sure we really want to pass on our entire product in one piece to NI......  Sorry.

[JacquesS]

Alright. I'm subscribed to this thread, so I'll be notified when you post an update.

At least I could not find any information about a similar issue that would explain why this happens.

I totally understand. If your company has an active SSP contract, I'd suggest to open a service request at your local branch. Another possibility would be to post a VI that does not contain any proprietary information but still shows the problem.

[Intaris]

It's not that important.  It has happened a total of once.

If it happens again, I'll try to open a service request.

I was more curious as to where the DLLs came from int he first place and why they were showing up in my hierarchy.  LabVIEW was continually stuck at 100% processor utilisation at the time (in idle).

[JÞB]

To aid in reproducing the issue (FPGA Not NEEDED) 

1. Open "Basic Functions.lvproj" A shipping example for the Unit Test Framwork
2. Run the Unit Tests
3. Close the project
4. Close LabVIEW (It won't close right)
5. Open a blank project (Look in dependancies, Items in memory)

Some Frameworks leave detrius behind when they hide their magic vi's in proxy callers.  (Working Hypothisis)  Sometimes this helps mitigate the time needed to reload a framework but leaves some junk laying around.  Once you see this the work-around is self evident (Reboot to release vis hidden in proxy callers)