Jump to content

bsvingen

Members
  • Posts

    280
  • Joined

  • Last visited

Posts posted by bsvingen

  1. If I would like to implement a couple of VIs which are licensed under the LGPL for an application in my company, then I would have to build a packaged project library (PPL) in order to prevent a licensing problem. The PPL can then easily be linked as external library from the build.

    This will obviously get more complex if I want to implement LGPL licensed VIs from several sources (which I can't pack into one PPL as I understand the license).

    I would have no problem with the BSD license, since there is no copyleft.

    Therefore the BSD license is prefered from the view of a company and for the sake of maintainable source codes.

    Greetings, LogMAN

    There is no problem including external libraries, several of them, and keep them nice and tidy and separately when distributing the source (directly from the source distribution in the build). Maybe this problem only exist when distributing exe?

  2. I have always like rolfk's explanation at http://lavag.org/top...post__p__25413.

    LGPL potentially requires segmenting your code into libraries that may not be natural to the architecture. BSD is much more permissive, in that it simply requires notices on the affected code, but doesn't really require an architecture change.

    I thought http://www.smashingm...milar-licenses/ was a pretty good summary, too.

    Joe Z.

    Yes, I have read all that, and that's why I am wondering. LGPL is supposedly too restrictive when used in a Labview environment.

  3. I am wondering aboout what type of license to use. LGPL or BSD (or maybe some other). I have read through some old discussions here, but since they are 4-5 years old, maybe something has changed. BSD is recommended here, but it is not entirely clear why LGPL is not recommended.

    Thanks

  4. Why do you think that the reentrant setting would still have any influence when VIs are inlined? Basically they then all have their own data space AND code path anyhow (using the data space of the VI they are inlined to and the code path which is copied verbatim into that VI), so no possible contention from having to protect data space and/or code execution from multiple concurrent accesses.

    And RT has no influence on that. Preallocated is best on RT as it minimizes the amount of memory allocations and reallocations, but since there are no clones that could compete for data space allocations anyhow here, this setting is again irrelevant for inlined VIs. That doesn't mean it has to be irrelevant for the VI that contains the inlined VIs but I think that should be obvious.

    Thanks. I just wondered, since the options can be hooked on/off even when inlined and I could not figure out why. For instance, if the compiler for some reason didn't want to inline the code after all, THEN the vi would be either a single clone or several based on the setting. Not much info about this.

    Also, "subroutine" for inline code makes no sence, unless there are som catches somewhere.

    So you are saying there are no catches, inline is inline no matter what and RT makes no difference.

  5. These are both as intended. In all the object oriented languages I know child classes automatically inherit parent methods and properties.

    And yes, you can add code to a property node to make it have a side effect, but that's probably poor programming practice (alliteration for the win!) . The intent of being able to add your own code is to make properties for class members which don't exist. Suppose you had two pieces of class member data named "Number of Front Wheels" and "Number of Back Wheels." You wouldn't want a third called "Number of Wheels" because you'd need to update it when you updated either of the first two. You can create a "Number of Wheels" property which adds the two and returns the sum (in addition to properties for two members). You can also add code to add some sort of caching behavior. In general, LabVIEW Class properties work a lot like C# class properties.

    OK, sounds good to me. With "ordinary" LVOOP I have to make dynamic dispatch vi's to be able to use get-set methods of data for the parents, (that's what I have been doing) . With these property nodes there are no longer any need to do that. Will this property node be faster execution vise than equivalent dynamic dispatch, or is it simply a dynamic dispatch (with all the overhead) in disguise?

  6. I am wondering if they are correctly implemented, and if so will they stay this way.

    For instance, all descendant classes can use the properties of the ancestor class with no implementation whatsoever of the read/write vi's of the descendant classes. The other thing is that I can add code into the class property node, making it a sort of strange invoke node.

    Regards

  7. That's all fine and sounds like a pretty good way of going about things. No complaints here and nothing I have posted earlier even hints at this being a bad idea.

    The only point I was trying to make was that the term "decoupling" is inherently a grey-area thing. There are pieces of software which are obviously more or less decoupled from each other but it's not a universal scale where one can say I'm 90% decoupled...... Adding to this the fact that "full" decoupling isn't achievable in any real-world sense makes certain aspects of the discussion which were going on kind of silly (regarding whether the decoupling is complete or whatever). The act of decoupling (to whatever level is appropriate for a given task) is a good thing and I didn't mean to make any negative comments regarding the efforts to decouple.

    Whether you call it decoupling, cliient-server, distributed producer consumer or whatever is secondary to the fact that the foundation you're building your software on is solid.

    Shane.

    If the UI and the "logics" can run separately, they are decoupled IMO. But decoupled does not mean void of interface, obviously there has to be some interface and some communication of data or there would be two completely separate programs (of course also decoupled, but irrelevant). A close coupled program has no real interface since the UI and the "logics" are woven together, as in a typical PC LV application. So decoupled means separate programs communicating through an interface. The two programs only have to know the interface.

  8. But true decoupling in a software architecture sense is only achieved in this real-world example if your new boss knows you exist but does not know what you do or how or how much you earn.

    In a software world, 100% decoupling is not achievable without having two completely independent pieces of software. As soon as both rely on a common interface (messagine protocol) there is inherently a certain amount of coupling present. So in a real-world sense I think the discussion about "full" decoupling is a discussion without any merit unless it's purely rhetoric. Even sharing data structures introduces a certain level of coupling between two modules.

    As with server up-time, squeezing the last few fractions of a percent of perfection (decoupling vs up-time) requires exponentially more effort. 99% decoupled software costs a WHOLE lot more time and effort to program than a 90% decoupled software in the same manner as a 99% reliability of a server is in a different ball park to 90% reliability.

    When it comes to decoupling, there are ONLY grey areas.

    Just my take.

    Shane.

    PS Here's a cool qoute from Wikipedia on the subject:

    "No couplingModules do not communicate at all with one another."

    We are developing on RT targets using cRIO and other embedded computers. The UI runs on a touch screen panel computer. This is decoupling in the correct sense IMO. The UI and logics run on different computers (kilometers apart), with different OS'es, in fact three OSes. The same architecture could also be used on one single computer with virtually no change in the code. The main point is that the UI is the "plug-in element", not the other way around. This is straight forward RT development using standard architecture learned at any RT course by NI.

  9. In case you haven't heard, LV 2011 is going to be largely a stability release. The entire LV team, acting on requests from customers, is going to pull back on features, focusing on bugs, performance and integration between existing features. There will be very little that is new in LV 2011, but we think customers will want it nonetheless.

    Excellent. Just now started with labview 2010 (SP1), and I find it slow and unstable. I remember 7.1, that was a good one, and 2009 is not so bad either. When is 2011 planned to be released?

  10. Finally started using 2010 (with sp1). I find it somehow slow and unstable. One VI that was upgraded from 09 made the entire LV shut down, no info, no error message, it just shuts down labview completely. I found the error to be within a formula node that works perfectly in 09. 2010 also runs slower on win7 (32bit) than in xp, by a factor of 2 or more. I am just wondering if someone else has this experience, or are there some tricks in 2010? Right now 2010 seems like a bad batch to me.

  11. The LVDIff.vi has a somewhat large BD. Where in the file am I supposed to insert your code?

    Another thing. I get an error when opening the lvdiff.vi. it complains about a missing ini file.

    Looking a bit closer, the lvdiff.exe is seemingly made in C++ (visual c project). The lvdiff.vi in there doesn't really do anything, and it will not run because an ini file is missing with unknown content. It is very confusing. frusty.gif

  12. Allright I made the move.

    And even got the merging (allright it was a single file) working.

    I've documented the settings in the LabVIEW Wiki: Mercurial

    In setting up LVDiff, there is a snippet to be inserted into the code? or is it to replace the code, or am I supposed to make a new file? I don't understand where the snippet is supposed to go.

    Also, why not use LVCompare that is shipped with Labview?

  13. I have traced the error to Listview.Create.vi

    IListViev node report Error 97 (Null Refnum). The “Value” outof AXCont is 0, even though the reference into it is a valid refnum.

    I am running Vista right now, maybe this has something to dowith it?

    Edit: It is the ListView ImageList that is an invalid ActiveX container (or dot NET?) "The Control could not be loaded" error.

  14. Quit trying to be diplomatic - it's an open forum, so open up. What *exactly* is the problem. If there's anything you could change, what would it be? Sum it up in one sentance per change.

    He he, I thought I did. Anyway, it is not as much to change as it is stating the facts. LV is a software for the corporate streamlined marked where DAQ and control of expensive equipment is the heart of the matter. This is a niche (as far as software goes) where there is a lot of money in few units, particularly in hardware but also in software and software related hardware. NI products are tuned to serve this niche, and they do it with excellent results for the customers. Believing, hoping or wanting LV to be anything but that, is wrong, plain and simple.

    As an engineer and scientist I have been using LV on and off for 15 years or something, and I know that if I use LV I will get exactly what I want, and I will get it done every time, almost no matter what it is (certainly not as elegant as several virtuoses here, but still smile.gif ). But, this doesn't change the fact that LV still is exactly what it is (as explained above). So, when the application starts to move outside the core niche boundaries, I will be alone. There will be no one to there to pick it up when I leave because no one knows both the application domain and LV sufficiently. If I had used Java or C the situation would have been very different, but even then I wouln't see a line of people.

    The other part is license. This particular application requires approx 5% of my time on average right now, maybe less. For me to pay a full LV license out of my own pocket, seems way out of line. I think I have explained enough how I ended up in this situation, and what should have been done to prevent it. But, the license problem may be solved very soon now, at least within a month. Nevertheless, I still regard this as the number one obstacle for more mainstream LV. Also, most programmers simply hate the idea that the LV luanguage itself is proprietary. Java is already diving into the embedded marked with much more reasonable licencing than NI.

    Finally, LV is an excellent tool when used inside its niche. Outside this niche it is also an excellent tool, but exclusively for those persons who already is working inside the niche. Licensing cost will prevent a change, because no one outside the niche will even dream of paying the license for something they perceive (right or wrong, it doen't matter) as a vastly inferior product for making general purpose programs.

  15. Ah - now I see the issue. Since you put it like that, I'd ask your previous employer to let you use one of their licenses. If they say no, then you say "I can't do the work for you". It's like the example that someone else mentioned: you're a mechanic at an aircraft manufacturer, they give you a hammer to use, then they take it away but still expect you to hammer stuff - your choices are to by your own hammer, or not hammer stuff.

    But then again, it is also my code, and I am the one that talked people into going this route, licenses and all. All in all the only real conclusion to be extracted from this, is that LV is not the ideal tool for more general purpose programming (trying to be diplomatic here rolleyes.gif ).

    But as my LabVIEW experience grows and I do more and more LabVIEW both at work and occasionally at home, I do feel I am doing the wrong thing because as an individual developer or "home enthusiast" programmer the cost of LabVIEW is out of reach. So the more LabVIEW is do, the more time I spend on it leave me more exposed I sometimes feel I become.

    Yes, LV is tuned towards streamline corporate, preferably controlling/measuring expensive and/or critical equipment. Taking it outside that frame, and the cost and time benefits really do not add up. It is similar to an airliner. A ticket with an airliner to the US is cheap, probably the cheapest cost per km you can get with any transport. But this doesn't mean that airliners are cheap, or that you would get the same cost benefit travelling with an airliner to see a movie in a town somewhat close by.

  16. Totally agree. It's like complaining that you can't open a spreadsheet of your home finances that you did at work using your employer's license of Excel. And, depending on the agreement you have with your employer, it might actually be considered against corporate policies.

    Not entirely. Although I agree with AQueue as a principle for preventing issues like this, what is going on right now is like this (remember, the license for "my" software is shared between me, A and B, and I only get paid by the hour for development) : My previous employer and B want me to continue maintaining the spreadsheet that they own and use, but they will not give me a license for Excel. MS will not even talk to me, even though I am sole responsible for selling them several licenses of Excel to B and making then continue updating their licenses.

  17. The software is like a toolkit, similar to the PID toolkit or one of the simulation toolkits. LV Full development system is needed to use it. Although finished systems can of cource be compiled like any other LV software, this is more like a bi-product, but I have made some of those as well and sold them.

    I don’t disagree with A Queue. In hindsight I should have made it clear that B was responsible for my ”personal development license” and any licenses I would need for future maintenance and development. This would have prevented this mess. Nevertheless, policies are policies, and licenses are licenses. That is a fact. By using Java, problems associated with these issues will disappear altogether, that is also a fact.

  18. Does not NI norway sales give you a quote if you ask them for the number of site licences you need for your customers and your development environment?

    I haven't asked that specifiq question. I think NI knows exactly what they are doing. Their licencing policy works well in a streamlined corporate world whre LV is used for DAQ and/or for development of DAQ-related software for customers, preferably together with NI Hardware. My error was to believe that LV could be used for more general software development. Technically it can, and it has some advantages with respect to speed of development/coding especially if it can be structured as some kind of toolkit utilizing the LV IDE as much as possible. But the licencing makes it a very rare software development tool that very few people actually understand and knows how to use other than setting up the "usual" logging system. My plan for further development/maintainance was to hand it over to someone at the university or previous employer, but this does not seem to happen anytime soon. There simply is no one that knows the technical part and LV enough to do it. They also have to be interested in doing it. Now I am stuck with it, and I wouldn't mind than if it wasn't for the fact that it will cost me money, but even if it didn't I would still have a problem sooner or later.

    Using LV for this was a mistake. That is really all there is to it. Java would be a better solution in the long run. This is not all that different from all the Matlab code that never leaves the cheap university licenses.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.