Distributing LVOOP/FPGA-based application over several projects possible?

[dlanger]

SITUATION: I am developing a rather large project that is heavily based on LVOOP: I encapsulated hardware-interaction and functionality into LV classes that are loaded at run-time. I have different types of plug-ins that are interacting with each other in the top-level VI. Those plug-in types are realised as more generic classes defining their interfaces that are used by the top-level VI. The classes of actual plug-ins instantiated at run-time are child-classes of the corresponding more generic classes (dynamic dispatch).

PROBLEM: The Labview project file is now rather large and takes ages to load/save. Also, I regularly get crashes or other very strange behaviour of Labview itself. For example, Labview stalles when loading the project file, except when it is loaded via the "recentlly opened projects" list in the Labview start-up menu.

POTENTIAL SOLUTION: I would like to make an individual Labview project file for each actual plug-in. That would have the additional advantage that they could be developed indivually by different developers without provoking versioning conflicts.

PROBLEM WITH THAT SOLUTION: First tests show that this would indeed work for plug-ins that do not use FPGA targets. However, several of my plug-ins use FPGA VIs, which again are characteristic for certain plug-ins (i.e., some plug-ins might use one FPGA VI, whereas others would use another FPGA VI: only one FPGA VI will be executed at a time, however). For this reason, I would like to put those FPGA VIs in the Labview project of the corresponding plug-in only, but not in the top-level Labview project. Because otherwise, I would have to update the top-level project each time somebody wrote/edited a plug-in that uses an FPGA VI.

 Unfortunately, Labview throws an error when in the top-level VI a method of a plug-in class that uses an FPGA VI is executed: "Error 1498 occurred at Get LV Class Default Value.vi. Possible reason(s): LabVIEW:  Library has errors. Fix the errors before attempting this operation. Complete call chain: Get LV Class Default Value.vi top_level_vi.vi"

Actually, it does not even help to add to the top-level LV project the FPGA target including the FPGA VI that will be called: the error message stays the same.

QUESTIONS:

- Is there any way to distribute LV classes over different projects with some of those projects having their own dedicated FPGA VI/resources.

- Or is there a completely different solution to avoid a huge LV project file with the associated problems?

Thanks in advance for any help! 

[dlanger]

I just realised that no error is thrown if the FPGA target incl. FPGA VI is added to the top-level LV project and the FPGA VI is SEPARATELY COMPILED for the top-level LV project.

This leaves the question open if/how one could get it running with having the FPGA resources present only in the plug-in LV project, but not in the top-level LV project.

Message Edited by dlanger on 01-28-2009 06:21 AM

Message Edited by dlanger on 01-28-2009 06:22 AM

[DianaS]

Hi dlanger,

 

I think a better solution would be to write a class which provides functions to communicate with FPGA.

All other classes communicate with this FPGA class.

[dlanger · Accepted solution]

I found out that one can access an FPGA VI without adding all the FPGA resources (such as FIFOs, I/Os etc.) to the respective project by obtaining the FPGA VI reference via the VI's bitfile (in contrast to obtaining it via the VI's path). That's exactly what I needed. I now have one project containing the FPGA resources and the FPGA VIs. And in all other projects I can make use of the FPGA VIs without adding the FPGA resources, just by opening the bitfile-bound FPGA VI references.

The idea of encapsulating the FPGA VI in an own LabVIEW class is also very useful. In combination with obtaining the FPGA VI reference via the bitfile it allows me to flexibly load different FPGA VIs at run time (depending on settings specified in configuration files), again without having to add all combinations of FPGA resources to the project. 

Problem solved. Thanks!