LAVA 1.0 Content

Old Codger/Fogey and Argue emoticons. I've noticed that many LAVA folks are old, and prone to arguing... Old Timer Arguement

Hi Aristos, You Aristos probably ment something like this could work? In the image below there is a static VI that calls a dynamic VI and the return value of the dynamic VI is casted back to static VI. Currentyl it doesn't work but do you think this exact diagram would work in the future releases of LabVIEW? If so, then I leave it as it is and hope it will work correctly some day. Until then I'll type cast the return value of the static VI manually in the calling block diagram. Then a second thing. Would it be possible to extend this automatic type casting behaviour of static VIs to include object arrays. Especially the following cases: Array of objects class A as an input would cast the type of an output to an array of objects of class A. (Array -> Array) Array of objects class A as an input would cast the type of an output to an objects of class A. (Array -> Object, Index Array) An object of class A as an input would cast the type of an output to an array of objects of class A. (Object -> Array, Get All) All the same things Variants i.e. if there is a variant as an input and variant as an output and the type of the data in the variant stays the same then the calling block diagram would automatically see correctly typecasted output instead of variant output.

It get's lost outside the visible screen area. To fix the problem, remove the Labview ini file or alternatively remove all lines from ini that are related to functions palette.

Think of a company organization. CEO of the organization gives the vice presidents a task to take care of something. CEO is a busy man, he doesn't know how do the VPs deal with the issue, he just knows that the VPs get it done. The VPs may do it by them selves or they may delegate the issue further. The task may be delegated many many times to number of people and each one takes care of a small task. In object oriented programming data driven recursion is hard to implement as you do not know in the root class what kind of properties do the other classes in the hierarchy have. You can think the root class to be like the CEO of the company. The root class can only start the recursion but doesn't know any special issues it has to do with the recursion. It's the class methods further down the hierarchy that really know all special issues about the recursion. Even though recursion may perhaps be implemented in this case also using data driven recursion and intelligent class design, it is much easier to implement using direct function calls to appropriate methods. It is easy for the CEO to delegate almost any task to the VPs but it's hard to define a process that works for every possible task in the company troughout the whole company hierarchy. Still it's not very complicated to implement an abritrary process if people in the organization just delegate parts of the task further if they cannot do it. You can think of an organization consisting of LabVIEW objects. You have a CEO class, a VP class, a senior manager class, a junior manager class and a number of different kinds of expert classes such as a LabVIEW nerd class. Each employee object belongs to one of these classes. The CEO class has a method delegate and the CEO class knows the who are the VPs. That's all the CEO class knows about the organization, after all CEOs are busy doing PR on the field with other CEOs. So from this point of view, how can you model a task penetration in the organization as you only know what the CEO can do. In order to be able to mode the task penetration you would have to know the capabilities of all the different employee classes. Well, you can do it, you'll need a case structure for all your class types in a while loop but you could do it. But then when your company decides to hire lawers and consultants, you need to modify all your recursion loops. If you were doing recursion trough functions, you only need to implement these new classes and define the connections to other classes. This is something you need to do anyhow, but you save the work of rewriting all your recursion every time your class structure changes.

It seems to me that some sort of "encryption" will be necessary. I haven't used the technique, but there was a section (6.3) in "A Software Engineering Approach to LabVIEW" that discussed this EXACT problem, and presented a solution. You can download the examples from the book HERE. You would be interested in the CONFIG INI code. The idea is to replace the Config Data Read & Write vis in the Open Config Data and Close Config Data vis with the encrypted versions (downloaded from above). Maybe you could leave the NI libs alone and create a private version of the Open Config Data and Close Config Data vis. You could use case statements that key off of the Application:Kind property to select between using the unencrypted NI Open and Close INI vis during development and the encrypted when called from the runtime engine...

NI's emphasis is on amateur users and not experts. So I think with LabVIEW the diagram goes like this.... Of course also the death of the brain cells should be accounted....

I'm working hard to move above the "Suck Threshold" and into the "Kicking ###### Threshold" world of LabVIEW... I like the image, but the whole blog entry has given me something to think about on the way home tonight. What do you do to be a LabVIEW expert

I don't think a DB is a good example of LabVOOP locking since you have to acquire lock from the database server and not from LabVIEW runtime unless you have in-memory DB written in LabVIEW. In 99% of the cases related to LVOOP the synchronization is needed for multiple references of an in-memory object.

LAVA sent me a "New Topic Notification" on this topic. My email program considered the notification was junk and filed it to my junk folder... Never happened before with LAVA forum notifications. I've to disagree with my email program, which is btw Mozilla Thunderbird. Seriously thanks for the effort Jace

I just have a dataflow mind . Seriously this is a real problem we need to solve now and not like all those high flying ideas I have thrown around.

We have a large application that uses plugins that third parties can write using LabVIEW development environment. We have both a native VI application alternative for users who have LabVIEW and binary application for users who don't. For both the native VI application and the binary application we need to have plugins that work exactly the same way in both environments and do the same thing. We have used VI folder plugins for the not binary builded LabVIEW application and builded .exe plugins for the binary application. Both plugins have been called using Open VI reference. This worked perfectly in LV 8.0 as VIs inside exe file can be opened using Open VI reference. Now we are moving our application to LabVOOP. The intention was to create plugin classes or indeed we already have plugin classes. Each plugin would derive from a general plugin class. Each plugin would have a main VI which would just return an object of this general plugin class type. Due to the plugin nature this main VI needs to be opened using Open VI reference and then called using call by reference node. Everything works in with native non-built plugins under LabVIEW development environment application but it seems that LabVIEW 8.20 cannot call the VI inside a binary plugin exe file any more. So our plugin system that worked perfectly for binary distributions under LV 8.0 application doesn't work under LV 8.20 any more. What would be an alternative. A DLL doesn't support returning classes as far as I understand so it is probably out of the question. We just need to be able to call a main VI that returns a plugin object and then use this object in our binary application in a environemnt that doesn't have LabVIEW development environment installed. Any ideas anybody?

Perhaps the forum admins could copy/move the stuff here under this new topic?

Haa... gotcha. Here is my example. Class that tries to use notifier for what ever reason. Perhaps to communicate between different parts of the program. Two different notifiers created. Only two. Hangs always. W4MN doesn't help. This is defenitely expected behaviour from what you Aristos explained but I would like to call it a bug. You are responsible for both notifiers and LVOOP, should they work together. They do not work at the moment as you can immediately see. An here is the project file as well. Download File:post-4014-1160508999.zip EDIT: I tested that if I embed the W4N or W4MN call to reentrant VI everything works ok. However if I embed this reentrant VI into a dynamic method we end up into a hang again as expected. So if you have only one non-reentrant VI in your call chaing to W4MN or W4N then you have good chances of failing to catch a notifier. Bug or not? I modified my project to present this behaviour. The modified project is below. Download File:post-4014-1160510413.zip EDIT 2: If you at NI want to keep both the performance but would also want the flexibility to allow the use the notifiers in subVIs, loops and possibly also other unsafe structures the I have the following suggestion. Modify the implementatio so that on compile time you examine the code. If current implementation is absolutely safe i.e. there is only one notifier originating from the current block diagram then use the present implementation of W4N and W4MN. On the other hand if the usage of these nodes is not unsafe, for example if the notifier could origination from front panel control or what ever way the same node can receive multiple different notifier references then at compile time use the implementation that stores the time stamp for each combination of notifier ref and notifier node.

Thanks for the comprehensive explanation. As you noticed I also guessed the correct answer just before your reply. Well, you helped me to guess. Well, here is something that can make you consider it a bug. The problem can be avoided in this case by using the W4MN. But, what if I embed W4N node to a subVI to encapsulate some behaviour. Then this subVI always has only one node no matter from where it's called. As a result notification may become missed as the subVI taking care of catching notifications is used in multiple places of the application. I think W4MN doesn't solve this issue either as the notifications do not come from a single source and they therefore cannot be passed as an array. Well, you may say that you can avoid the problem if you use reentrant VI. This is true if you can make all your VIs reentrant. But if you have at least one non-reentrant subVI in your nested subVI hierarchy you end up to have the notifier problem again Well this has an implication to LabVOOP. If you decide to use OOP to hide your implementation of a system that uses notifiers you are very tempted to use dynamically dispatched class methods. If you do, notifier problem can cause troubles again as dynamically dispatched methods cannot be reentrant. Therefore you end up having only one W4N or W4MN node everywhere in your code. This single node then waits for possibly all the encapsulated notifications in your application. As these notifications can indeed arrive at random order you are very probably having a lock situation. Did I explain myself clearly. I suppose you must agree that there really is a bug or at least unwanted feature. If I wasn't clear enough, I can provide you an example. jimi

Suppose I shouldn't swallow the bait, as English really isn't my language. But, here goes; If you read the paragraph Free Open-Source Automobiles?, I think you'll see that the author only is emphasizing the difference between traditional and software businesses. If this difference didn't exist, we wouldn't even have this discussion of Open Source LabVIEW code.

I eagerly wait for the explanation. As I have read the notifier help files, I have got the impression that my example should have worked. Perhaps if you decide to stick with the current implementation you explain the limits in LabVIEW help in more detail. I'm happy I can help to improve LabVIEW. EDIT: I assume that the problem is related to this sentence: "If ignore previous is FALSE, each instance of the Wait on Notification function waits if the message in the notifier has a time stamp for the same time that the instance of the function last executed. If the message is new, then the function returns the message." I only have one instance of notifier wait functions in the loop. As a notification is catched, the time stamp is reseted to the new time value. If there was a notification sent before, in another notification ref, that cannot be catched any more. Am I right?

The article was interesting. There are very many good points raised up. The writes made also some mistakes as Crelf already mentioned. The writer is wrong when he says "software costs virtually nothing". The correct form is that additional costs of extra copy of software are virtually nothing, not the cost of the software itself. As a result the software costs virtually nothing when demand is large enough and technology is mature so there is no need for consuming 5-10% to R&D. However I don't see that this in any way affects the conclusions drawn. Virtually all programming languages are now in this mature FOSS stage except G. This is because LabVIEW hasn't really been a programming language but rather a measurement and automation environment and has therefore followed the market evolution of this field. There is hardware involved in this field so it's not as simple a market as a pure software market. However also electronics industry is experiensing the same kind of evolution as software industry. It becomes easier and easier to manufacture commodity hardware. Hardware gets closer to software as hardware parts used in electronics get more general purpose programmable integrated circuits. Less and less users need the state of the art hardware but can do what ever they need to do with cheap bulk hardware. Bulk hardware can be controlled with FOSS software so the market evetually leads towards combination of general purpose bulk hardware and FOSS software. The mariginal cost to manufacture an additional general purpose hardware is not nothing but however very close to nothing. In 100 years we'll see another interesting development - FOSS goods. As the manufacture process of everything develops, we'll eventually have factories that can produce anything common hard stuff from a recipe for very small cost. These recipes start behaving in much the same way as software. Evetually you can download a new recipe for your new computer from the net and you don't need Dell or HP to produce you outstanding computer recipes.

Well, if you use this definition of manufacture: "The act of making something (a product) from raw

It's at The Care and Feeding of FOSS /Lars-G

I think all of you who follow this topic may find this essay The Care and Feeding of FOSS interesting. /Lars-G

Sorry, wrong topic. I have erased contents of this post.

I'd like to stick with one of the existing licenses if possible. An open source license of a small company may frighten customers and developers. It's easier to have a reputation of a trusted third party behind the license. When I was working for a company of 6000 empolyees, we had many very talented lawers and even still they had hard time taking everything into account when we were writing contracts with other parties. To wire an open source license that would be good enough, one needs to hire a lawer specialized in the field if one wants to write a good license from scratch. It's a bit same thing than with patents. If you hire patent office that is not specialized to the field you apply the patent for, the patent will not be worth anything in the court. I'll go trough the main open source licenses and I'll report you which one I chose and for what reasons. I hope this will encourage the other companies and institutions in LabVIEW community to follow the example and select the same license model. It's easies for the developers if all the libraries they use are of the same open source license. GPL is especially nasty since it only allows other GPL compilant licenses to be used in the same project. I'm not certain if I will choose a GPL compilant license or not. I think Eclipse license is GPL compilant and is quite close to what I need but I've to see.

The vendors of T&M equipment should provide these, and for free! :beer: A few years ago, I worked as a customer service engineer for a wireless telecom equipment manufacturer. I requested CAD drawings from the drafting department, then loaded them into Visio via DXF. I cleaned them up a bit, made stencils and added terminals for wiring. I put Visio drawings with these stencils into my PowerPoint training slides and the customer BEGGED me for the stencil. I gave it to them, and our competition ended up making stencils because this customer made it a REQUIREMENT. For the most part, these types of drawings are already in their documentation (front panel, rear panel, etc) with the connectors. It's really a shame.... I don't necessarily advocate providing a specific file format (.vss), but maybe NI could add SVG or DXF files to the instrument drivers requirement checklist? It would only take one major player to include these to kick the others into "me too" mode P.S. I've managed to "scrape" images from manufacturer's manuals. You can cut and paste from some PDFs and at least make a hookup diagram in your LabVIEW code look like the actual equipment. I put the image in a .MHT file with my instructions (create .MHT using MS-Word) and load it into an ActiveX control with a configurable "OK" and "Cancel" button. EDIT OCT 11 2006 I posted a comment to one of Brian Powell's blog entries, and included a link to this thread. He replied that he was a bit concerned about the 'scraping' of images. I certainly respect and support copyrights; I suppose my use of the word "scrape" was a bit off. The cut-and-paste of an image from documentation for an instrument that I've purchased (and then use in code that communicates with said instrument) represents to me "fair use". The software does not function properly without the instrument. ( :laugh: I like to think that I'm preserving the equipment manufacturer's "image" by accurately portaying the "image" of their instrument :laugh: )

No, we especially want to release the library under open source license so that the community can further develop it and this further development would also benefir the community and not only ourselves.

Hi, I've written a LabVIEW VI library that I'd like to release for the LabVIEW community under an open source license. The license should be such that it allows LabVIEW community to use the library in their software without forcing the software to any particular license. However the modifications and additions to the library itself should stay open source. The license should also prohibit open source developers from adding patented technology to the library, or if they do, they need to release the patent rights to the open source community as well. This requirement must be there since patent laws override copyrights if they are in disagreement and this way malicious open source developers could take open source package into their posession. I've though of options. GPL is out of the questions since it forces any software that uses the library to become GPL. LGPL is also out of the option since it doesn't allow statically linking the library to the binary without the binary also becoming LGPL software. Many older licenses don't also protect agains this patent issue, only quite recent open source licenses take into accout the threat that pantenting of technology used in opens source library may be. BSD licenses are not an option since they allow other parties to close the source of the library. We don't want other parties such as NI to close source of our library and start selling it as a LabVIEW toolbox for oly $999. The library must stay open or if some party wants to benefit from a closed source library, our company can then sell this party a commercial license. So what are the options. I've been thinking of Common Public License, which seems to meet these conditions. Are there other common alternatives. Or should LAVA/OpenG release their own license. I know OpenG is moving to BSD license but that would be agains our company open source strategy in this issue. -jimi-