LAVA 1.0 Content

I wouldn't use notifiers for the task. This is a functionality you would like to package as subVI library or class library so that it can be reused in any of your applications or in a single application with multiple different windows. In this usage notifiers are unsafe and may freeze the application without "throwing" an error.

Does anybody know how to interpret the type string output of "Variant To Flattened String" node when a class is connected to the variant input?

Thanks for being there for all of us!

Hi, As a LabVOOP rookie I started using subroutine priority dynamic VIs in my projects to enhance the execution speed. I've not really verified that the execution speed really is better when using subroutine priority, after all dynamic VIs are somewhat different from normal VIs. Now that I've been using LabVOOP intensively since August this year, I've come into a conclusion that one should really carefully consider the pros and cons when setting the priority of a dynamic VI other than the default Normal. The reason is following. All of the Override VIs must have the same priority as the VI they override. So if developer sets the priority to be something else than Normal, then all the VIs overriding this VI must have the same priority. This is ok, if you develop a small project only to yourself and you are certain that nobody else is never going to reuse your classes. Often this is not the case, indeed one of the main advantages of OOP is reusability of the classes. Now setting the priority of your dynamic VI to something else than Normal forces all the override VIs to this priority. This is a limiting factor for the developer of the override VI. Especially if the priority is set to Subroutine, the overriding VI cannot use any asynchronous nodes. As dynamic VIs are considered asynchronous in LabVOOP, override VIs of subroutine priority cannot call other dynamic VIs. This on the other hand is very limiting as it may often be required to call other class methods from your new class method. I think a warning should pop up in LabVIEW when setting a subroutine priority to dynamic VI or when making a subroutine priority VI dynamic. The warning should warn that one cannot call any dynamic VI from this VI or any of the VIs that override this VI. This is not really a question or anything like that. This is more like a warning to other LAVA members to avoid usage of subroutine priority in dynamic VIs.

Is there a way to find out the runtime class of a LabVOOP object (wire) i.e. something similar to MyLib.lvlib:MyClass.lvclass? -jimi-

Is the source code of these dynamic VIs protected or locked automatically or do I have to lock the block diagram manually? I could try this out but I'm lazy. This is btw something I've never thought of, are the VI block diagrams accessible from an executable?

I prefer using an installer rather than an exe as the distributable for an application

Hi friends.... I need some sample projects with Wincc..Has anybody have it?Actually it can be document or file (*.pdl) Best regards.. :thumbup:

I can still hear the echo... Why not to use similar packaging method that is used for Java application and libraries i.e. the library is packaged as a zip package which includes some sort of directory structure.

Your DLL works just fine. You just made a few mistakes when you tried to call it from LabVIEW. First in your build specifications you defined your dll to use standard calling convention and not C convention. However when you call your library you call it using C convetion. Use Standard instead. Second you should check the function defenition of the created DLL from SharedLib.h. It says that your DLL call is defined as follows: _2dDLL(TD1Hdl *ArrayIN, TD2Hdl *ArrayOut); This means that in order to call the DLL from LabVIEW you should define the function prototype properly. Double click on the Call Library Function Node. Select ArrayIN and ArrayOUT parameters separately. For both parameters the Array format should be changed from Array Pointer to Array Handle Pointer. Then it should work properly. I don't however assume you want to create a DLL from LabVIEW and call it from LabVIEW. There are easier ways to build VIs than that. On the other hand if you want to call your LabVIEW DLL from C, you are on the right track. LabVIEW passes multidimensional arrays as array handles or array handle pointers. Handles are pointers to pointers to array structure. Array structure is a array of long of the size of the array rank defining the dim sizes of each dimension followed by the array data itself. The struct for your case looks like this: typedef struct { long dimSizes[2]; double Numeric[1]; } TD1; typedef TD1 **TD1Hdl;

As far as I know the smallest addressable memory element in C++ is one byte i.e. 8-bits. If your OPC interface uses something like 1 bit variables, they very probably are really 8-bit variables of which only 1-bit is used. Can you provide the defenition of the OPC method API you are trying to pass bits and how these bits are defined in the API.

Maybe you want this one? http://www.ni.com/images/devzone/us/idnet_...ossary/gain.gif There is an Icon Art Glossary on the NI web site at http://www.ni.com/devzone/idnet/library/ic...rt_glossary.htm There are also instrument icons in the file examples\instr\insticon.llb\Icon256.vi

Hi, XControls seem to violate the encapsulation scheme of LabVOOP as they cannot be included into a class. This means that the developer cannot class private or protected methods in an XControl. As a result the developer is forced to make some unnecessary methods public so that these methods can be used in an XControl. These methods will then become as an API of the class which may not be ideal, as this may unnecessarily expose the implementation. After all one important concept in OOP alltogether is hiding the implementation. Consider that you want to encapsulate graphics objects as a class. You only want to expose the graphics objects to an XControl, there would be no methods to query any of the properties of the graphics objects. You would like to write a dynamic method draw, but make it only accessible to the XControl, as it makes no sense outside the XControl. XControl may be integral part of the class, but LabVOOP forces it to be separated from the class.

You may be facing the same builder feature that Aristos Queue explained in this thread http://forums.lavag.org/index.php?showtopic=5147

You got to be joking! :headbang: This means our projects will very probaly face the same issue when it's time to build them. We've been developing with the expectance that long names (LibA.lvlib:ClassA.lvclass:anything) really stay long after the builf process also. Can't this feature be fixed in the builder to use the long names instead of renaming stuff errorneously?

:thumbup:

You can call the HDF4 DLL directly from LabVIEW, I don't kwow if there is any workaround. Well zlib shouldn't be a problem as you can download it for free from http://www.zlib.net/ .

There is a very good reason to create unnamed clusters, namely they consume less memory... LabVIEW is not optimal in memory usage when creating clusters. Especially it wastes memory when you create a named cluster.

Do you have any good reasons to make it closed soruce? I doubt you would get huge income from a closed source packagee. I also doubt that the the net revenue will be worth the effort of supporting the product and consuming your most important asset, namely your software developer's time. But with open source package you can get a lot of goodwill and you do not have to provide support.

HDF5 is not downwards compatible with HDF5 so you cannot use HDF5 libraries directly. However you can convert HDF4 files to HDF5 files either using a command line tool or by calling a DLL library. For HDF5 there are sever libraries. I've implemented HDF5 1.8.0 alpha for LabVIEW. If you are interested in this package, you can send me a personal message and we can add you to the beta program. The package very strictly follows HDF5 C API and even has a reference manual for LabVIEW.

I think XControls do not come with FDS in LV 8.20 so you'd need PDS. You should check this issue from NI.

Here is what I suggest. Write one or more interface classes for your temperature controller. Add dynamic VIs to these classes that define the interface methods. These interface classes do not need to be the top most classes but if you think there is even more general interface that you can take advantage later on, you can derive temperature controller from some general controller class. Put all of these interfaces into a single lvlib library. Define which of your methods are public, which are private and which are protected for each interface class. Then write one or more implementations of the above interface classes. As you do not want anybody to use your implementation directly put the implementation into another lvlib and define it to be private (from the lvlib properties). Then only VIs inside the library can access the interface. Add a VI to the implementation library which returns the class constant of your interface class typecasted to the interface class (My Temp Controller) or returns an initialized class if your implementation needs initialization. This VI should be outside your implementation class and it should be defined public from lvlib properties/item settings. Now you can access your implementation by placing this VI to the block diagram. The whole of your implementation however is hidden from the class users. They can only use the API classes you have derived your implementation classes from. This forces the user of your API to keep strictly using your API and that only and not the private properties of your implementation. You can also access your implementaion in a plug-and-play way by opening a VI reference to the above mentioned VI. If you want, you can search plugin directory for such VIs and then dynamically open the plugins as needed. You can allow user to define the path for the plugin, or perhaps you'd like to call it the driver. As you have encapsulated your driver into a lvlib, you can easily distribute it. So your stucture would look like this Driver Interface.lvlibInterface Class.lvclassDynamic API method 1 Dynamic API method 2 Dynamic API method 3 [*]My Hardware Driver.lvlib Get Initialized Plugin.vi (public) My Hardware Implementation.lvclass (private) derives from Driver Interface.lvlib:Interface Class.lvclassDynamic API method 1 Dynamic API method 2 Dynamic API method 3

I really have not put any consideration to implementing HW drivers using LabVOOP, however I've implemented LabVOOP API on top of other "physical" resources. The best thing LabVOOP can provide, I think, is the fact that you can abstract the hardware away into an OOP API. If you make the API general enough, it works for any similar hardware. So you can write one or more interface classes and then hardware specific implementations for specific hardware instruments. This way the rest of your code remains the same even though you change your hardware into a different one. You can even use hardware plugins that you can plug-and-play into your system that implement your API classes for specific hardware (there was some discussion on this subject in another thread).

I'm pretty much LVOOP ignorant at this point, but what the heck... I think I would look to the IVI Classes as a starting point. "IVI drivers provide either a IVI-C or an IVI-COM API." My limited experiences with IVI has been poor, but mostly because of the vendors I use. When I need to know what's going on inside the driver, I'm blind. Maybe a IVI-VI API could make it possible to interchange, edit, and debug instrument control completely within the LabVIEW environment? ( I here by trademark the name LVOOPIVIVILAVA! )

Saw this digg entry, and thought of this thread... ( points to http://www.pistonheads.com/news/default.asp?storyId=15492 )