9 replies to this topic

[CannonFodder]

I've used LabVIEW for many years (starting 3.1), and have been doing RT programming for about the past 6 years. I am considering taking the plunge to OOP, but I had some questions of a general nature.

1) are there special performance considerations designing OOP code for an RT platform? even a small platform like old cFP's?
2) how does memory allocation and management work with LVOOP in RT?
3) hardest to answer, are there specific limitations or weaknesses using OOP in general that I should know about?

It seems that if I have a design using dynamically launched VI templates and named single-element queues, it is begging for OOP. However, not knowing the limitations I don't want to start coding myself into a corner.

I know, I am late to the party. I resisted the auto-tool too, at first. My tab key had the letters rubbed off.

Thanks,
Jeremy

[Aristos Queue]

The online help that ships with LabVIEW discusses this topic. Take a look at that and see if that answers your questions.

Edited by Aristos Queue, 07 February 2012 - 07:24 AM.

[Götz Becker]

I have seen a medical application switched back from LVOOP to normal clusters because of a much longer startup time on cRIO (LV2009) with LVOOP. Other than that it did work very nice with LVOOP.

[CannonFodder]

Aristos Queue, on 07 February 2012 - 07:23 AM, said:

The online help that ships with LabVIEW discusses this topic. Take a look at that and see if that answers your questions.

I have searched and found only how-to articles in the LV Help. Can you point me to the article you are thinking of?
Thanks

Götz Becker, on 07 February 2012 - 09:11 AM, said:

I have seen a medical application switched back from LVOOP to normal clusters because of a much longer startup time on cRIO (LV2009) with LVOOP. Other than that it did work very nice with LVOOP.

That's good to know, I will keep that in mind, thanks!

[Paul_at_Lowell]

We have deployed quite a few Object-Oriented applications on RT on cRIOs now. We did encounter some serious issues early on (see below for what I can remember off the top of my head) but now that we know how to work around these our applications work great (and within the confines of what we do working with objects on RT is very easy to do).
Relevant problems and solutions:
1) Performance issue accessing objects within another object. We had a set of individual objects to do specific things and added these objects as attributes inside a larger collection class, using accessor methods to pull off each of these, and then performing operations as appropriate. (That is, one object was a collection of other objects.) Our tests showed that in this circumstance (lots of objects within another object) the execution time to access an object in the collection was prohibitively lengthy for our RT applications. We improved performance (and the API was easier anyway) by putting the objects inside a cluster instead, which is OK since this was strictly a collection and had no behavior itself. (Note that accessor methods otherwise seem to work just fine.) [This is an issue in LabVIEW 2010. We haven't tested it in LabVIEW 2011. I do not know what the root cause of this issue is.]
2) Also in LabVIEW 2010, we encountered many issues with builds. The build times were extraordinarily lengthy and more often than not failed (meaning it would complete on the same code maybe one out of five times). National Instruments helped us around this issue (thanks, NI!) in a couple ways, but most importantly we learned that we could avoid these issues by minimizing source interdependencies in our code. We began implementing interfaces (OK, not Java-style interfaces but our own version of interfaces), which dramatically reduced interdependencies between different sections of our code. This had a huge impact and we haven't had a problem with a build in many months now. (The use of interfaces results in a better application design in any case!)
3) For the record, we also encountered issues with debugging in the earliest release on RT (stepping into a dynamic dispatch VI didn't always work correctly) but we haven't seen this in LabVIEW 2010.
4) Also for the record, the RTETT traces do not show which dynamic dispatch VI is running (as of LabVIEW 2010). This hasn't been a big problem for us in practice.

Now that we have "conquered" these issues, working with objects in RT is typically a quite pleasant experience for us. So, go for it, but use interfaces!

[I remembered that I had started a similar topic very nearly two years ago here: http://lavag.org/top...__fromsearch__1, The only comment there is my initial comment.]

[CannonFodder]

Paul_at_Lowell, on 07 February 2012 - 05:20 PM, said:

We have deployed quite a few Object-Oriented applications on RT...

Great post, thanks for sharing that. That is just the type of response I was looking for.

I am still evaluating what you mean by "implementing interfaces" to reduce "source interdependencies." Do you mean interfaces between code modules? user interfaces? interfaces between FPGA and RT? Were the build problems related to FPGA or RT in particular?
Build problems are especially alarming since they are typically discovered near the end of the project.

[Paul_at_Lowell]

I discuss interfaces in this context carefully in Appendix I to the paper linked in this thread:
http://lavag.org/top...__fromsearch__1

I hope you find it helpful.

[Aristos Queue]

Paul_at_Lowell, on 07 February 2012 - 05:20 PM, said:

4) Also for the record, the RTETT traces do not show which dynamic dispatch VI is running (as of LabVIEW 2010). This hasn't been a big problem for us in practice.

This was not a known issue. I have filled CAR 337019. Do you know if it affects the Desktop Execution Trace Toolkit as well? (I told them to check both, but if you know off the top of your head, I'll add that to the CAR.)

Edited by Aristos Queue, 08 February 2012 - 03:22 PM.

[Paul_at_Lowell]

Thanks for creating a CAR! (I have mentioned this to NI Support before but I guess it was always adjunct to a more pressing issue.) I don't have the Desktop Execution Trace Toolkit in the currently installed version of LabVIEW (2010) so I'm afraid I don't know if this applies there or not. Thanks again!

[MarkCG]

I have wondered about this too. I use compact fieldpoints (mostly 2120s) and am rather uneasy about using LVOOP on them. I've encountered a number of problems working with LV2011 and cFPs.... i.e. extremely slow deploy times, confirmed by NI, LV crashing when importing cFP .iak files through project explorer, etc. . This makes me that the cFPs are not getting the love they need from NI.

I have a particular component that I've implemented using traditional techniques, but would be well suited for refactoring to OO style. I'll use it to test out how LVOOP works with compact fieldpoints