classes sans frontières

[Intaris]

Classes without borders.  No this is not a plea for cosmetic changes.

For the last six months I have been immersing myself (for the first time) in RT and FPGA applications.  We have a program whose functionality spans Host, RT and FPGA.

I would like to investigate the use cases for LVOOP in this situation since it is officially supported (with limitations and caveats of course) on each of these three targets.

My problem is that I rather naively tried to implement a single class with functionality for all three levels (static calls for FPGA and so on).  The problem is when I try to add this class to my project, where do I put it.  If I put it int he project as a Host component, the RT anf FPGA parts cause a broken arrow.  If I put in ont he RT tatget, the Host and FPGA parts cause a broken arrow and so on.

How do I go about designing a class which spans the boundary of more than one target.  Of course I am aware that I will actually have three objects running independently of each toher and I need to take care of synchronisation myself but I would at least like to be able to make sure that the CODE on each level is what I want it to be.

I)'m assuming that composite objects are the key but how to go about this?

Shane.

[Dragis]

I'm glad to hear you are giving classes across the platforms a try.

I'm not sure I understand your issue. There is no problem with running a class on different targets at the same time. However, there is a long-standing issue with editing classes across multiple targets or contexts. For instance, if you open a VI within the class on the host and then again on the FPGA target (even if they are different VIs), the library will be locked from editing.

The only practical way I've found of sucessfully dealing with this is to have all my target specific code in separate strategy classes that I can feed to or derive from my main, target-agnostic class. I tend to like composition over inheritance, so I do a lot of nesting which I find LabVIEW is better at dealing with. You always edit the target-agnostic class from one context, usually the host for me. You can edit the target-specific classes from their respective contexts.

[T-REX$]

Another solution that I commonly use is to have a Conditional Disable structure that keys off of the TARGET_TYPE symbol so that only code specific to the current target gets loaded. Of course this isn't specific to classes in any way, just a trick that I use when I'm testing FPGA code on Windows and need to avoid particular functions.

During development, the lower left-hand corner of the VI window is great for switching between contexts manually without moving the code around in the project.

[Intaris]

My problem is only partly the usage of the class.

My main confusion  is where in the project to have the class show up.  If I try to put a mixed-target class under my RT target, it will complain about PC or FPGA functions not being executable.  If I try to put it on the Host, the same problem.

Where do I store my class?

Shane.

[T-REX$]

Well, my thought was to keep it under "My Computer", and use the Conditional Disable to prevent it from complaining when it's opened in different contexts. That's how I would go about it I think. Let me try to develop a cross-platform class and get back to you 

[Intaris]

Ah, right.

I get it now.

A Conditional disable IN THE CLASS VIs.  Gotcha.  Cool, that would work of course with all common VIs being without Conditional disable.

The lightbulb goes on so to speak.

Shane.

[Dragis]

Although I do use the conditional disable frequently, I would suggest having target-specific subclasses that override or add functionality to a generic implementation in the majority of cases. In my experience, this helps maintain a stronger separation between the target specific code and makes you think through how they interact up front. It is also nice because you can edit the various target specific classes in parallel on different targets at the same time. Either way, let us know how things go.

[Intaris]

I have been thinking along these lines.

I reckon a base class with common functionality (supported on all targets) with individual classes for the different target functionality will have to do it.

Shane

[Intaris]

---

@T-REX$ wrote:

Well, my thought was to keep it under "My Computer", and use the Conditional Disable to prevent it from complaining when it's opened in different contexts. That's how I would go about it I think. Let me try to develop a cross-platform class and get back to you 

---

Any chance of an update regarding this idea.

I was just trying out womthing today and I got immediately bogged down by the "reserved for execution in another application instance" when trying to work with a class spanning more than one target.  This obviously makes editing such classes a MAJOR PITA.

Any ideas on how to get around this?  It reminds me of XControls and LVOOP, and not in a good way.

Shane.

[T-REX$]

I started off with a Math class that had different implementations for functions based on where they were executing. It was pretty straight-forward to design, but if I wasn't careful to hit the  (save all instances) before switching contexts then I would lose code. As you put it, I would consider this a "major PITA" as well. Once I got it coded up though, it worked fine. I added it to both an FPGA target and Host computer, then compared the values returned.

It also makes it difficult to use the FPGA_EMULATION=TRUE conditional disable structure that I like so much, as something about nested conditional disable structures rubs me the wrong way.

Anyway, as long as I hit [ctrl + s] after I did anything, I didn't run into any issues with this method. What did you do to run into the "reserved for execution in another application instance" issue?