My First LVOOP Project

[Omar Mussa]

I just finished the first phase of a project where I'm using 15 different LVOOP classes and I thought I'd share some of what I learned. I've been using LV 8.20 and NOT upgraded to LV 8.2.1 yet, so hopefully Tomi has helped AQ figure out most of the issues that have come up for me - in fact I don't intend to write about the bugs in LVOOP here at all. (I do plan on upgrading to 8.2.1 right away to see what happens now that I've reached my milestone.)

Here are five things that you should consider when starting a LVOOP project (not necessarily in order of importance).

1) Source Code Control

Don't even THINK about starting a LVOOP project without it. Unlike in LabVIEW where it is possible (albeit risky) to plug along and not think about SCC too much, it is ESSENTIAL for LVOOP because it is possible for classes to get corrupted and without SCC, you're screwed because you can't do anything to the class file directly. Hopefully 8.2.1 fixes many of the issues that cause corruptions, but at the core, I firmly stand by the statement that if you don't have an SCC process in place, don't use LVOOP.

2) Project Environment

I'm not a huge fan of the LV Project environment but you need to get familiar with it if you start working with LVOOP. The biggest challenge right now with the project environment is that it becomes very difficult to organize and find VIs in the hierarchy window (there isn't any support for sorting VIs in the project by name, etc). To get around this, it is best to create a VI Tree for each LVOOP class so that you can easily organize the members in a way that makes sense to you.

3) Context sensitivity

One thing to keep in mind, class VIs are loaded into memory differently depending on the context in which you load them. For example, if you start from just LV being open and launch a class member VI, the entire class will be loaded into memory. If you then open a .lvproj file containing the class, you will find the class is locked because it is open in 2 contexts. I recommend creating a VI Tree that contains all of your class VI Trees so that you can open everything in your project in one context outside of the .lvproj in case your .lvproj gets corrupted.

4) Don't use dynamic dispatching on every VI

Dynamic dispatching is great, but at the price (for 8.20 at least) of not being able to find your VIs using the 'Find all instances'. So, instead of making every VI in your class dynamically dispatched, use it judiciously in places where you truly want to have over-ridable functions. Where you don't intend to over-ride the function, make the class connection 'Required'. You can always change the connection to 'Dynamic Dispatching' if you decide to over-ride the function later.

5) Be prepared to iterate

The one thing I found I had to iterate on the most was abstracting class data from child classes and putting the code into the parent class. Sometimes, even with careful design, you'll find patterns emerging as you develop. If you keep in mind that one good goal is to minimize the amount of code you create, you'll find that you need to move 'generic' functions into parent classes. Remember that a child function that over-rides the parent can call the parent function - so utilize that behavior to reduce duplication of code and then extend that functionality in the child class - or, if a very special implementation is required, skip calling the parent method - whatever option keeps the code tighter and easier to understand.

Finally Understand OOP concepts

Don't dive in and assume you'll figure it out. Get some OOP books and check out the shipping examples and blogs like Tomi's Expressionflow. Try to create a scale model of your project before implementing details.

[Tomi Maila]

Hi Omar,

I'm happy that you have joined to the group of few who have really used LabVOOP for something serious. Excellent advices from you, I must say. I join your views. Thanks for recommending my blog EXPRESSIONFLOW. Although I try to conver LabVIEW Object-Oriented Programming related issues in my blog, the blog will not replace a good text book. I recommend reading one of Brian Eckel's Thinking in... books. Perhaps Thinking in Java would suite best for LabVIEW programmers. It's available as a traditional book as well as free electronic form.

Omar, I'm interested in your experiences on LabVOOP together with source code control system. Until now I've been developing so that I make manual backups of my whole project. It's not the most elegant solution. I've been thinking of moving to SCC but the lack of experience on SCC together with LabVOOP has prevented me from the transition. I guess now you have this valuable experience. I'd appreciate if you would share the details with us. Would you like to write an article on the subject to Expressionflow? I can create you an author level account there... The SCC issues I'm especially interested in are

1. LabVIEW requires all the files to be renamed or moved in LabVIEW so that links between files don’t get meshed up. This is especially important when using LabVOOP. On the other hand I think subversion requires files to be renamed or moved in subversion so that the revision history doesn’t get meshed up. How
   
2. LabVOOP requires often recompiling the whole project. As a result each file in the project, even the files you didn’t edit, gets changed. How does this affect the usage of version control software.
   

Regards,

Tomi

[Omar Mussa]

Hi Tomi,

I'd be happy to write an article on using SCC and LVOOP for your blog, we can work that out offline.

QUOTE(Tomi Maila @ Apr 24 2007, 09:55 AM)

The SCC issues I'm especially interested in are

1. LabVIEW requires all the files to be renamed or moved in LabVIEW so that links between files don't get meshed up. This is especially important when using LabVOOP. On the other hand I think subversion requires files to be renamed or moved in subversion so that the revision history doesn't get meshed up. How
   
2. LabVOOP requires often recompiling the whole project. As a result each file in the project, even the files you didn't edit, gets changed. How does this affect the usage of version control software.

1) Yes, you have to be careful when renaming a file and using SCC. I'm using SVN so I use SVN Rename (which basically drops the old file and adds the new file to the repository). I'm not using SCC integration with LabVIEW - I use SVN outside of LabVIEW via TortoiseSVN in Explorer.

2) LVOOP does recompile the whole project on occasion. I just check in everything at that point and add a comment to the commit so that I know what happened. Its better to commit often and be able to revert later than not commit and then get stuck! The only cost is disk space, which is cheap relative to time spent programming!

Omar

[TG]

A good thread.

Thanks for sharing. I am interested in any tips on how to work with LVOOP "as it is today" with 8.2 or 8.21.

Your tips are hard learned (I am sure) and are appreciated.

[Tomi Maila]

QUOTE(Omar Mussa @ Apr 24 2007, 08:08 PM)

Hi Tomi,

I'd be happy to write an article on using SCC and LVOOP for your blog, we can work that out offline.

Nice

Tomi

[dannyt]

Hi Tomi,

Though I am not using LVOOP at presents (Still running Labview 7.0), I have been reading your Blog's with interest.

QUOTE(Tomi Maila @ Apr 24 2007, 05:55 PM)

LabVOOP requires often recompiling the whole project. As a result each file in the project, even the files you didn't edit, gets changed. How does this affect the usage of version control software.Regards,

Tomi

This issue is one I find really annoying as somebody relatively new to LabView, the fact that VI's are in effect both the source code and the object and I am often surprised by some of the things that can cause other VI's to have to change . I use ClearCase as our source control system and I have just come to terms (well almost ... one day) with the fact that I often have to 'Checkout' save a 'Checkin' a number of VI's other than the one I was really interested in.

However ...... One of the big benefits I would have hope for, and expected, with moving to a LVOOP Class based architecture, would be a significant reduction in this particular problem by decoupling large amounts of the code. I was sort of hoping that if the public interface VI's of the class are left alone (as much as possible) the recompiles of VI's in the private implementation part of the class, would be limited to a greater extent to with-in the class. I wonder if this was your experience. It may well be I do not full or correctly understand the extent of the recompile issues.

cheers

Dannyt

[Tomi Maila]

QUOTE(dannyt @ Apr 25 2007, 03:30 PM)

I was sort of hoping that if the public interface VI's of the class are left alone (as much as possible) the recompiles of VI's in the private implementation part of the class, would be limited to a greater extent to with-in the class. I wonder if this was your experience. It may well be I do not full or correctly understand the extent of the recompile issues.

I'm afraid Danny, that what really happens is that every single VI in your project needs recompiling quite often. My experience is that if you for example change the private data cluster of your class, then all the VIs using this class need to be recompiled. This on the other hand may require changes on other classes and so on. Often the whole project needs to be manually recompiled by pressing Ctrl+Shift+Run as there are still some bugs in the LabVOOP compilation project. So the project recompilation is far from being limited to public interface VI changes only. As a result the number of VIs you need to check-in and check-out in LabVOOP projects is going to increase rather than decrease.

Tomi

[Omar Mussa]

QUOTE(Tomi Maila @ Apr 25 2007, 05:45 AM)

As a result the number of VIs you need to check-in and check-out in LabVOOP projects is going to increase rather than decrease.

Tomi

I agree with Tomi. You'll have to checkin more code more often.

I've found that the biggest cross-your-fingers action you can make is to change the class data, especially if you have a type-definition within the class data and you've modified it. There is a cascade of changes that LabVIEW makes when you save the class that is very 'sensitive' and often you end up with crashing LabVIEW completely (especially in 8.20, still not sure about 8.2.1). I've found that the two things I have to do to help mitigate this problem is 1) ALWAYS use the 'Apply Changes' menu option before closing a type def you've changed and 2) checking in the code often so that you won't have too much pain if you have to go backwards. I've noticed that a lot of issues come up when you try to save-all on the project, I think the save-all has some order of operation issues - for example I think it tries to save the class members first, then the class, then the project (which is good) - however I don't think it always starts with the right class (am sketchy about this myself) - and this results in the class that is being saved to crash during the save operation (because it refers to data in a class that has not been saved). This results in a crash and when you re-open the project, VIs will be missing (from both classes and the project itself) and your classes might not recompile. The best way to get around this problem is to open a VI Tree containing your class VIs outside of the project environment and then save-all. Then open the class and save it. Then close the class and open the project. Whew! If that kind of pain intimidates you, you might want to avoid LVOOP for now

[Mark Balla]

QUOTE(Omar Mussa @ Apr 24 2007, 10:38 AM)

I just finished the first phase of a project where I'm using 15 different LVOOP classes and I thought I'd share some of what I learned. I've been using LV 8.20 and NOT upgraded to LV 8.2.1 yet, so hopefully Tomi has helped AQ figure out most of the issues that have come up for me - in fact I don't intend to write about the bugs in LVOOP here at all. (I do plan on upgrading to 8.2.1 right away to see what happens now that I've reached my milestone.)

Hey Omar,

Great thread,

Can you elaborate on methods or patters you found useful? I’m curious if you were able to keep your OOP as a by value paradigm or were you forced to wrap them in a queue in order to protect and pass the data between loops.

One of the biggest drawbacks that I find with OOP is the difficulty of testing public Vis. Because the object data is not visible or settable it becomes difficult to inject data and see the results. Were you able to come up with an alternative way to test Publics.

Thanks

Mark

[dannyt]

QUOTE(Tomi Maila @ Apr 25 2007, 01:45 PM)

As a result the number of VIs you need to check-in and check-out in LabVOOP projects is going to increase rather than decrease.

Tomi

Thank you for that information, I find that very very disappointing. I am now not so sure that I am as keen in trying to persuade people here to move to LabView 8.2.1 and try out the LVOOP way of doing things (though 8.21 would still be generally a good thing). I suspect I would just get a lot of grief from my co-workers. I do hope this is something that will change as LVOOP develops. For now I suspect this is a more play with at home option. Dannyt

[Tomi Maila]

QUOTE(dannyt @ Apr 26 2007, 11:11 AM)

I do hope this is something that will change as LVOOP develops. For now I suspect this is a more play with at home option. Dannyt

I don't think that this actually can change. Object-oriented programming allows to hide implementation on source level but there is no way the implementation can be hidden on the binary level. As long as LabVIEW embeds all the binary code to the same files as contain the source code there is now way to prevent these files from changing when the classes they rely on change.

I'd like to see source files and binary files to be distinguished in the future so that by default the VIs would be archive files (ZIP) that contain a XML source code and a separate binary. For novice users this would appear as if there was no change compared to what VIs are at present. However there should be a project level option to save the source part of the VI into a parallel file hierarchy with extension .vis (VI source). The binary files would still also include the source files but the separate source files would only contain a URI of the binary file.

<example>

My Documents\My Project\My Project.lvprj (XML where each item links to both .vis and .vi)

My Documents\My Project\source\A.vis (XML file with VI source only)

My Documents\My Project\source\B.vis (XML file with VI source only)

My Documents\My Project\binary\A.vi (ZIP compressed archive with both VI source as XML and separate binary)

My Documents\My Project\binary\B.vi (ZIP compressed archive with both VI source as XML and separate binary)

</example>

This would allow much better integration with present source code control tools. Even XML merge would in principle work for the source files, although I'm not sure how usable it would really be.

[dannyt]

QUOTE(Tomi Maila @ Apr 26 2007, 10:28 AM)

I'd like to see source files and binary files to be distinguished in the future so that by default the VIs would be archive files (ZIP) that contain a XML source code and a separate binary. For novice users this would appear as if there was no change compared to what VIs are at present. However there should be a project level option to save the source part of the VI into a parallel file hierarchy with extension .vis (VI source). The binary files would still also include the source files but the separate source files would only contain a URI of the binary file.

Tomi

Separate source and binary would make such a huge difference to how LabView could be used with most source control systems, I think the archive form would still give problems and it would be better for just the two to exist at the same level. For example it is easy for CVS or Clearcase to deal with individual files like VI's but they cannot deal well with VI's within a LLB contect (though I supspect one could plug in window explorer LLB reading in Clearcase file type manager).

<example>

My Documents\My Project\My Project.lvprj (XML where each item links to both .vis and .vi)

My Documents\My Project\A.vis (XML file with VI source only)

My Documents\My Project\B.vis (XML file with VI source only)

My Documents\My Project\A.vi (binary)

My Documents\My Project\B.vi (binary)

A change to "A" would result in a new copy of A.vis and A.vi can happily effect B.vi is "B" depends on A but B.vis would not change.

</example>

However I suspect this is living in a dream world. so I will keep quite now

Danny

[Tomi Maila]

QUOTE(dannyt @ Apr 26 2007, 02:57 PM)

Separate source and binary would make such a huge difference to how LabView could be used with most source control systems, I think the archive form would still give problems...

You would never need to check-in the archived VI only the source .vis files. The archive files are there to provide backward compatibility with single source+binary package.

Tomi

[Omar Mussa]

QUOTE(mballa @ Apr 25 2007, 07:27 PM)

Can you elaborate on methods or patters you found useful? I'm curious if you were able to keep your OOP as a by value paradigm or were you forced to wrap them in a queue in order to protect and pass the data between loops.

I had to use most of my objects ByRef and that was obviously a challenge - got help from others on doing that but there are several ways (so far, no really great solution exists but I'm positive that at least one will emerge soon). To pass object event data between loops, I generated dynamic user events.

QUOTE(mballa @ Apr 25 2007, 07:27 PM)

One of the biggest drawbacks that I find with OOP is the difficulty of testing public Vis. Because the object data is not visible or settable it becomes difficult to inject data and see the results. Were you able to come up with an alternative way to test Publics.

I'm not currently unit testing my Publics. I didn't really come up with any great ways to do that. I did find it difficult to test Publics on other grounds though... If you set dynamically dispatched VIs to 'suspend when called' you will never see them suspend (because they are never 'called' - they are run dynamically). I ended up sticking breakpoints and temporarily saving them inside calls that were over-ride functions so that I could test the code (one more reason to avoid making everything dynamically dispatched - its a great feature but it creates a set of limitations that make it unwise to use it by default within classes).

Object data visibility on the other hand is not impossible to workaround. One workaround is to create a Public and Private cluster with the attributes organized appropriately and to stick those clusters in your class data. Then you can view your attribute data easily by creating a couple of private functions for getting the data (or setting it) and using that to help debug your class. Plus you get the benefit of having your code structures looking more similar to UML documentation that you may/should have made - which is good for other reasons

[Jim Kring]

QUOTE(Tomi Maila @ Apr 26 2007, 02:28 AM)

I don't think that this actually can change. Object-oriented programming allows to hide implementation on source level but there is no way the implementation can be hidden on the binary level. As long as LabVIEW embeds all the binary code to the same files as contain the source code there is now way to prevent these files from changing when the classes they rely on change.

I'd like to see source files and binary files to be distinguished in the future so that by default the VIs would be archive files (ZIP) that contain a XML source code and a separate binary. For novice users this would appear as if there was no change compared to what VIs are at present. However there should be a project level option to save the source part of the VI into a parallel file hierarchy with extension .vis (VI source). The binary files would still also include the source files but the separate source files would only contain a URI of the binary file.

<example>

My Documents\My Project\My Project.lvprj (XML where each item links to both .vis and .vi)

My Documents\My Project\source\A.vis (XML file with VI source only)

My Documents\My Project\source\B.vis (XML file with VI source only)

My Documents\My Project\binary\A.vi (ZIP compressed archive with both VI source as XML and separate binary)

My Documents\My Project\binary\B.vi (ZIP compressed archive with both VI source as XML and separate binary)

</example>

This would allow much better integration with present source code control tools. Even XML merge would in principle work for the source files, although I'm not sure how usable it would really be.

We might take a clue from http://www.python.org' target="_blank">Python. Source files are generally named with a *.py extension. When python executes a *.py file, it compiles it into bytecode that is stored in a *.pyc located in the *same* directory as the *.py file.

It is a simple matter to tell ones source code control system to ignore *.pyc files.

[Tomi Maila]

QUOTE(Jim Kring @ Apr 26 2007, 06:32 PM)

We might take a clue from http://www.python.org' target="_blank">Python. Source files are generally named with a *.py extension. When python executes a *.py file, it compiles it into bytecode that is stored in a *.pyc located in the *same* directory as the *.py file.

But we would loose the backward compatibility as many LabVIEW programs expect VI s to include both source and binary.

Tomi

[Chris Davis]

QUOTE(Tomi Maila @ Apr 26 2007, 10:41 AM)

But we would loose the backward compatibility as many LabVIEW programs expect VI s to include both source and binary.

Tomi

Since this change would only happen on a new version anyway, it would be up to this "new" version of LabView to handle converting between text-based source files and binary-based source files. (i.e. LabView 8 can open LabView 7 files, but not vise versa.)

[Tomi Maila]

QUOTE(chrisdavis @ Apr 26 2007, 07:37 PM)

Since this change would only happen on a new version anyway, it would be up to this "new" version of LabView to handle converting between text-based source files and binary-based source files. (i.e. LabView 8 can open LabView 7 files, but not vise versa.)

I meant the backward compatibility of non-NI created software that would rely on the fact that VI is a single file and an executable such. I guess the correct word would have been forward compatibility of such software

Tomi

[Omar Mussa]

QUOTE (Tomi Maila @ Apr 24 2007, 10:15 AM)

Nice

Tomi

I finally got around to doing this so I thought I'd post the http://expressionflow.com/2008/05/16/fighting-corruption-using-source-code-control-systems-scc-with-labview-class-files/' target="_blank">article link here for reference.