Tomi Maila

I’m very excited to announce a new ExpressionFlow Studio video series that will concentrate on LabVIEW software development. The first episode Objects and Classes starts an ExpressionFlow Studio series introducing to LabVIEW object-oriented programming.

I think this is a Firefox bug where the browser has at some point failed to load the icon from LAVA and happens to use that particular moment to determine the icon for LAVA bookmark. For some reason Firefox doens't seem to update the icons when they change. I've seen similar issues with my Firefox.

QUOTE (Aristos Queue @ Jun 25 2008, 05:16 PM)

What would it take for LAVA to have a glyph of its own when it is displayed in my browser's list of shortcuts? Some websites have them, some don't, and I don't know what makes the difference.

http://lavag.org/old_files/monthly_06_2008/post-5877-1214407131.png' target="_blank">

Please post your code.

Static dispatching should be used

1. for the initialization method of a class
   
2. for high performance quickly executing methods executed more than ~ 100 000 times
   
3. for methods you do not want to allow to be overridden
   
4. for private methods
   
5. for methods that do not contain class input terminal
   
6. for methods you want to put inside polymorphic VI
   

Dynamics dispatching should be used

1. for cleanup method of a class
   
2. for recursively called methods (even for recursive init contrary to what was said above)
   
3. for all methods you want to allow child class to override
   
4. for all methods you are unsure if child class could benefit from overriding the method
   

Notice that you do not necessarily need to use dynamic dispatch output in dynamic dispatch methods. You can have dynamic dispatch input and a static dispatch output and a dynamic dispatch input wihtout any class type output. Normally you should use dynamic dispatch input together with dynamic dispatch output though. Use static dispatch output with dynamic dispatch input if you want a child class to return possibly other class type. See Aristos Queue's LVOOP Map as an example of this kind of metethods. Use dynamic dispatch input without class output if you want to clean up an object and the object is no longer valid after the method is executed.

Actually variants are faster as conversion to variant doesn't require memory allocation. Conversion to binary string requires memory allocation as all the items of composite datatype are moved to same sequential block of memory. Furthermore LabVIEW comes with a nice set of utilities to investigate what variants are made of; see vi.lib\Utility\VariantDataType.

QUOTE (Aristos Queue @ Jun 10 2008, 08:29 PM)

This is an area where I personally believe LV classes could lead to a major reduction in the amount of code that a driver author has to write. I would be very happy to hear of any success stories that driver authors have using LVClasses in this manner.

This is not exactly a driver but very similar though.... We wrote a very general file format interface using LVOOP and wrote an implementation for HDF5 files. This we have been using for a year now but about two weeks ago we needed to add support for proprietary TIFF image archive format based on MS JET databases and collection of TIFF files. Writing a new plugin that implements the class interfaces took a few days. Now our application framework fully supports this new format and no changes needed to be made anywhere outside the plugin. For us, a file format plugin is a collection of LabVIEW classes in a lvlib library. We load the plugin dynamically at runtime based on the selected file format when writing files or based on the file extension when reading files.

We have plans to write new plugins for various other file formats including TDM and TDMS.

QUOTE (Tomi Maila @ Jun 3 2008, 12:32 PM)

Actually just today I encountered this issue with LabVIEW 8.5.1 where LabVIEW corrupted my class file because of a dependency issue where there was two classes of the same name in the project.

It seems that the problem we had was much bigger than I thought. One class hierarchy keeps corrupting again and again. The origin of the problem is that I moved a highest class in a hierarchy into a lvlib library. As a result LabVIEW seems to have two different references to this class, one outside the lvlib and one inside the lvlib. It seems LabVIEW sometimes decides that the class is really not part of the lvlib and when it does so, all the hierarchy gets corrupted. I guess I've no other option but to go maybe a week back in my source code control regarding this hierarchy before I added the class to a lvlib. I hate that LabVIEW files are of binary format (including binary fields of class files) and that when something goes wrong with the compiler, there is no way to fix things manually or even investigate what is wrong manually to be able to report a bug. At the moment I cannot report a bug because I really don't know at which point LabVIEW screwed things up and how and I've no means of investigating it.

This swapping method actually sounds pretty nice as no new memory buffers are needed. At least as long as the buffers are not too big and we are not too close to LabVIEW memory limit (actually my team is very close to the physical memory limits all the time).

Is there any way to access the content of the swapped memory buffer i.e. the buffer that used to be the output of To Variant but after execution becomes the input of "To Variant"?

Hmm... I decided to make a test of using to variant in a loop (see below). It ended up crashing LabVIEW, which was something I was actually expecting...

I contacted NI. It ended up to be a feature as rolfk suggested. To variant works in-place by swapping the buffers of its input and output terminals.

Omar has raised up an important subject. Actually just today I encountered this issue with LabVIEW 8.5.1 where LabVIEW corrupted my class file because of a dependency issue where there was two classes of the same name in the project. It also appeared that LabVIEW file search algorithm that searches for missing files cannot locate class control inside class file but tries to locate it from a Windows folder instead. Naturally this fails and all class constants, controls and indicators in the project get broken. I didn't find any way to fix them so my project was ready for carbage bin. Luckily I do use SCC so only one day of work was wasted.

I think it's important not to think that corruptions cannot hapen with certain LabVIEW versions. The truth is that complicated software such as LabVIEW can always fail and developers should protect themselves against these failures.

QUOTE (rolfk @ Jun 3 2008, 09:09 AM)

An interesting test would be to see what happens if the small variant does not contain 0 elements but a few instead. Because I could imagine that on an incoming 0 size (or maybe very small size array) the existing internal buffer is reused (with copying of the incoming data to the internal buffer for small sizes) but on larger sized arrays the incoming handle is used instead and the internal handle gets really deallocated.

Good idea. I executed the test. Both arrays stay in memory, the large and the small. So it seems using variants can result in memory consumption cumulation issues.

QUOTE (neB @ May 27 2008, 05:04 PM)

Say I wanted to deploy Tomi's example as an exe that would allow other shapes to be added latter (example:customer wants an octogon added)...

from what I understand I would have to re-compile the library that houses the class.

Are there any other things I'd have to adjust to allow for the addtion of other shapes (aside from the menu that allows which shape to drop)?

I just wrote a blog post on this subject. See the discussion in this thread.

I've just posted an article Extending LabVIEW-built applications with LVOOP plugins with an example project to ExpressionFlow blog.

There are numerous reasons why you would like to allow your LabVIEW application to be extended with plugins. First you may want to allow your customer or a third party to add some new functionality to your application. LVOOP plugins provide a way for you to allow third parties to extend your application. Second you may want to separate the built and development process of the core application from the development process of the features of the applications. With OOP projects LabVIEW development environment slows down dramatically as the number of classes gets too high. It may be wise to separate your application so that only the core elements form the main application and all other elements are provided as add-on components. Third you may want to control the memory footprint of your application and specify at runtime which components are loaded into memory; there is no need to keep the code for unused features in memory. Consider for example that your application supports multiple file formats or device drivers. You can load the needed file format plugins or device drivers on demand into memory at runtime.

Read more...

Hi,

I'm wondering the mysteries of variant memory buffer allocations, as they seem to differ from what I would expect. As LabVIEW doesn't have memory manager, the buffers contain the data last written to them and the next data written to the buffer replaces what ever the buffer contained before. This is true for normal data types but doesn't seem to be true for variants. Take a look at the attached code. An array is created at each iteration of the loop every 5 seconds. The size of the array is either 10M elements every other iteration and the array is empty every other iteration. When I do not convert the array to a variant, LabVIEW behaves as I would expect; the old buffer get written over by the new buffer every iteration. This can be verified from the Windows Task manager. When the VI is stopped, LabVIEW doesn't do any cleanup but the buffer allocations remain as they were when the VI was running. When I added the conversion to a variant, LabVIEW seems to behave differently. When the big array is converted to a variant, LabVIEW reserves memory. However this memory never gets released, even when I replace the array with an empty one. Only when I call request deallocation node, LabVIEW seems to free the memory for the variant.

Is this a bug or a feature?

QUOTE (netta @ May 27 2008, 07:44 PM)

Anyways... The reason I ask is because I don't have the profession edition of LV so don't have access to LVMerge. I'm trying to figure out whether it's worth upgrading.

You can always download LabVIEW Professional tryout and test it by yourself. If you don't want to mesh up with your system, install it on a virtual machine.

Tomi

QUOTE (neB @ May 10 2008, 06:19 PM)

Tomi, your avatar will be a challenge.

I changed my avatar a little yesterday...

Should we ask this woman(?) to design LAVA NIWeek t-shirt?

I think merging is not possible within llbs but I'm not absoultely sure. Anyway it's easy to test out, it either works or doesn't work. I think it's not a good idea to keep VIs in LLBs when under source code control. I wrote a guide on using LVMerge with Tortoise SVN, maybe you can get some help from it.

QUOTE (Yen @ May 25 2008, 10:40 PM)

It looks like the Value Change event for a color box is fired twice even in the current beta. I'll report it.

Here's a much more simplified example (8.0).

Can you add to the report that if you in the color dialog window press the more colors button, and press Cancel button in the more advanced color dialog window, the event gets still fired.

We Thank You,

Aristos Queue,

To the Mysteries of Diagrams,

You Bring The Light of LAVA.

QUOTE (Aristos Queue @ May 22 2008, 12:13 AM)

Of course, that sort of defeats the whole purpose, finding those who picked similar icons who might have similar interests. If the icon set is open ended, there's really no point to the whole thing.

In wonder what is night club life in Austin like... "Isn't she good looking. A pity she has a purple dress. I guess we would have nothing in common anyway, I wear only blue and black."

Thanks all, I consider your suggestions and try to find up what suits best for our needs.

Tomi

QUOTE (Daklu @ May 20 2008, 04:35 AM)

In my class I have a vi that takes a cluster of data as an input. I would like this cluster to be a typedef that I could use internally in the class as well as have available to class users. However, any class vis that use the typedef as a input, as well as the typedef itself, break when the typedef is in the class structure. If I disconnect the typedef on member vis it works, or if I place the typedef outside the class heirarchy it works. Is this expected behavior?

Without an example code I cannot say for sure what is wrong. However in addition to what Justin said, it may be that you are having some sort of type recursion that is not allowed.

QUOTE (Daklu @ May 20 2008, 04:35 AM)

The dependencies item in your project explorer shows all items such as VIs and classes that your project depends on. It's a must have for a LVOOP developer as you need to call your parent class methods and you can find them in the dependencies unless you have added all the classes in your project.

QUOTE (Daklu @ May 20 2008, 04:35 AM)

Project is a project. What ever you need in your project you put into your project. Don't put items you don't use in your project.

QUOTE (Val Brown @ May 19 2008, 06:50 AM)

It seems to me like the only option I have to uninstall SVN, brute force delete ALL of .svn folders that have been created during this process and then start all over again.

I guess the problem is that you have added folders to repository that already were part of other repository. A single file can only belong to one repository.

What I sugges you do is

1) Go to your local folder where your files under souce code control reside

2) From TortoiseSVN right click menu select export to get a clean copy of your code

3) Create a new local repository (or remove all the files from the old repository)

4) Add your exported code to the new repository

5) Subscribe to this new repository

QUOTE (Jim Kring @ May 17 2008, 07:00 PM)

By copying the repository in Windows File Explorer you *might* possibly corrupt the new copy, but I can't imagine that you would corrupt your repository. You can avoid problems by using the svnadmin dump command. Here is a high-level tool that might help you (but I have no experience with it): http://www.systemwidgets.com/Downloads/FreeDownloads/SVNBackupWidget/tabid/73/Default.aspx' rel='nofollow' target="_blank">SVNBackupWidget.

The data corrouption of the backup can only occur if there are open connections to the repository at the moment of the backup. On a single user repository this can be easily avoided by not using the repository while backing it up. However, incremental backup is a nice feature if you don't want to keep many duplicates of your entire repository.

p.s. Never rely solely on incremental backups only. I once was using incremental backup software provided with Maxtor external harddrive. It ended up a catasrophy as for some reason the whole incremental backup database was corrupted and I was unable to restore anything from the backup. Of course the backup software never provided any indication that there could be some problems with the incremental backup database. Maxtor customer service never bothered to respond to my support requests when I tried to restore my stuff. Luckily only the boot sector of my backed up hardrive was damaged and I was able to plug the hardrive into another computer as a secondary hardrive and restore everything.