Tomi Maila

QUOTE(mesmith @ May 14 2007, 05:52 PM) I'm using OpenG Package Builder to build source installation packages from LabVIEW OOP projects and VI Package Manager to install these packages. This solution works fine and works on all LabVIEW supported platforms. Any third party installer buidler should work fine as well. For example http://nsis.sourceforge.net/Main_Page' target="_blank">Nullsoft install system would propably do the job. Tomi

Hi, I strogly recommend using object-oriented design for the instrument drivers. Object-oriented programming allows you to write generic interface class for all of your instruments and a specific driver implementation class for each of your instrument. All instruments can then be accessed using the generic interface class method VIs allowing to write generic programs that can use any of your instruments. Functionality that is shared by all of the instruments can be implemented in the generic class so it can be shared by all of the instrument drivers. Functionality that is shared by some but not all instrument drivers can be implemented using a object-oriented design concept called composition. I've been writing a few articles introducing to object-oriented programming with LabVIEW and have plans to go on with some more articles. Please take a look at the articles on my blog at Expressionflow. Tomi

I'm very excited to announce that Rolf Kalbermatter will be blogging a series of articles on LabVIEW external code interface at Expressionflow. The first article in the series is To avoid missing the next articles in the series, please subscribe to the Expressionflow feed with your favorite feed reader. Tomi

QUOTE(LV Punk @ May 9 2007, 01:30 PM) We have to help you and post some LV related videos to YouTube so that you can say your boss that the new Websense system prevents you from doing your job. Alternatively you can change the employee to one that appreciates you more. Tomi

QUOTE(Aristos Queue @ May 5 2007, 08:44 PM) In my experience it's quite normal that a LabVOOP project has unsaved changes immediately after it has been opened from the disk. Of course there really cannot be any chages but LabVIEW seems to think so and saves some VIs when one presses Save all. Tomi

Some of you had commented this blog article but the comments never appeared on my blog. I've now resolved the issue (I hope). I was able to reconver the lost comments, so very interesting discussion is going on... Sorry again for the inconvenience. Tomi

QUOTE(crelf @ May 4 2007, 07:58 PM) Hehe, en oikein usko että tämä keskustelupalsta toimisi kovin hyvin jos kaikki käyttäisivät omaa kieltään. Toisaalta olisihan se kiva kirjoittaa suomeksi... Tomi

I just want to point out in this thread that a friend of mine is not reading LAVA too often because the discussion here is mostly too obvious and straighforward to him and he feels the time is wasted reading too obvious discussions. The more there is discussion on LabVIEW basics, the more there are advanced users starting to feel the same way as my friend. LAVA or no other forum can never serve everybody. We need to choose who do we want to serve. We will always loose some users, we need to choose which one we do want to loose. Tomi

QUOTE(Michael_Aivaliotis @ May 4 2007, 09:30 AM) I don't think flush queue would be a replacement for lossy queues. The problem is that if consumer loops is undeterministic, then the queue may get full, no matter how many elements you are able to dequeue at once. Consider for example that your consumer runs in UI thread and the UI thread get's busy for an external DLL call or heavy UI refresh. As a result your queue can gets full because your flush queue does't get called in time. This results in producer not being able to enqueue elements and the determinism of producer loop is lost as it becomes entangled with the consumer loop.

QUOTE(Eugen Graf @ May 3 2007, 09:46 PM) The memory is sometimes limited. If it wasn't you wouldn't need a lossy queue. I don't understand what's the benefir of warning the user? What can the user do about anything? Tomi

QUOTE(yen @ May 3 2007, 09:13 PM) It's all about marketing. You should have called it LabVIEW CAPTCHA and everybody would have loved it . CAPTCHA is an acronym for those spam prevention systems where you need to enter the letters in a hard-to-read automatically generated image to be able to register a web site.

Or am I missing something here? Lossy queues are usually needed when the queue writing process needs to be deterministic to avoid source buffer overflow, and the queue consuming process is often undeterministic. You need lossy queue because the undeterministic consumer is sometimes slow consuming the queue and the queue get's full. The problem with locking is that it makes the producer thread undeterministic. You can no more rely on the fact that you always succeed to enqueue your stuff. This may result in source buffer overflow. A common use case is that you try to enqueue the elements in your DAQ hardware buffer, whichi is of limited size. You need to clean-up the buffer deterministically to avoid overflow. If you lock your queue, you cannot guarantee this anymore. EDIT: Read crelfs articles Deterministic Data Acquisition and Control with Real-Time and Deterministic Data Acquisition and Control with Real-Time - Part 2 to learn more on deterministic operations. Tomi

Error cluster can be used to define the execution order of almost anything. When you wire error out of an item to error in of another item, the items will be executed sequentially. So wire error cluster out from one of your loops and into another loop. Tomi

QUOTE(alfa @ May 3 2007, 08:54 AM) Is integral geometry somehow related to differential geometry?

Just from the symptoms my guess is following. There is a bug in the hardware driver your hardware is relying on. The process doesn't exit even when terminated because it waits for kernel level reply to hardware interface is properly closed (or something similar). Because of the driver bug, the driver never processes clean-up request. As a result your application clean-up request hangs on the driver and therefore your application never exits. If the problem was not in kernel level thread, then windows would most presumably simply shutdown the less important thread. But as far as I understand Windows won't touch kernel level processes as they are trusted to work properly and touching them could crash the whole system. So I recommend you to contact the vendor of easyDAQ. It may be that the bug appears only in very special circumstances such that your hardware is broken, you have problems with your PC hardware, your application is doing something abnormal etc. Still I guess the underlying problem is a driver bug that only the driver vendor can debug or fix. Tomi

QUOTE(yen @ May 2 2007, 11:47 PM) I learned LabVIEW complitely without option 3.) course or tutorial. Indeed I think that's what makes LabVIEW so great, it's so intuitive that you don't need to study tutorials, just start wiring and if you don't understand something, open the help. If you still don't understand something, ask you collegue. Thanks Matias for patiently answering my questions Tomi

I was just considering if it would be possible to try to learn the LabVIEW FPGA by trying to code a DVB (digital video broadcasting, digital tv) receiver. The problem is that the DVB signal stream may be up to 60 Mbps, so I guess it's out of the speed range of NI RIO hardware. I'd call thid high-speed digital DAQ Tomi

QUOTE(george seifert @ May 2 2007, 10:44 PM) Are you able to post a bare minimum project reproducing the problem here? Tomi

QUOTE(crelf @ May 2 2007, 11:19 PM) I think it's very ok to ask help for a homework as well as long as the help request is specific to a particular issue or feature and not generic help me request.

Hi, I was thinking of the lossy queue issue today that has been discussed on this forum earlier. I came up with a solution that I think should work for most of practical use cases. The idea is to proxy the enqueue operation via an user event and handle the user event in a proxy loop or thread. As long as the proxy-loop is guaranteed to run at priority comparanble or higher than the producer loop and the queue operations themselves are not the bottleneck in the system, this solution should work. The user event can be replaced with a second queue but user events are more practical to use. It's starting to be late at night, so I ask you dear LAVA gurus, do you find loop holes. The attached VI is for 8.0. http://forums.lavag.org/index.php?act=attach&type=post&id=5697

This is not a bug as "Destroy user event" works as documented. Howevere the way it works when error has occurred before the node is inconsistent with the way other destroy reference nodes work in LabVIEW. When error occurs before "Destroy user event" then this node doesn't execute normally. At least most destruction nodes in LabVIEW execute normally even if error has occurred before the node. I didn't submit a bug report as I doubt it will not be changed any more... I noticed the issue with LV 8.2.1 EDIT: I went and submitted bug report after all. I don't have a CAR yet. Tomi

Newer versions of glibc are not binary compatible with old versions. You have to use the old version of glibc. I guess LV ships with the proper version of glibc, I'm not sure however. Use linux command ldd to check the library used with your LabVIEW executable. You can link to a non-default version of library by using the envionment variable LD_LIBRARY_PATH. For more information on shared libraries in general, see the link below http://tldp.org/HOWTO/Program-Library-HOWT...-libraries.html Tomi

QUOTE(Aristos Queue @ Apr 30 2007, 09:35 PM) AQ, was the LabVOOP project at NI just a regular project among other new functionality projects or did you leverage external programming language research knowledge by including related research groups or research scientists to the concept planning phase of the project? Tomi

QUOTE(Aristos Queue @ Apr 30 2007, 07:56 AM) A 'node' is an element of a file system. A node may contain other nodes. 'Files' are nodes; 'directories' are nodes. Files are those nodes that choose to not include further nodes. Directories are those nodes that chose to include further nodes. A 'node' is an element of a file system. A 'file' is a node. A 'directory' is a node with the ability to include other nodes within itself. Which of these two class hierarchies is the better choice and -- here's the important part -- why? Should the ability to include other nodes be a capacity of the node class itself or a capacity only of the directory class? What are the ramifications between them? If we say that "file is a node" and "directory is a node", which definition of these classes best reflects the implementation? This discussion is related to my earlier posts on problems with trees and graphs in LabVOOP. As a theoretical physicist from my education, I'm a very practical person. So I like to concentrate on practical implications of programming models and not so much on philosophical considerations. But I also like elegant programming language constructions, elegant meaning something that allows simple solution to a wide range of problems. From philosophical point of view both answers to your question are equally good. But from elegant programming point of view the alternative 2. "A 'node' is an element of a file system. A 'file' is a node. A 'directory' is a node with the ability to include other nodes within itself." is more elegant. Why? There are two issues that make the second alternative superior to the first one; simplicity and and extendability. In general people are not very good at handling complexities. Delay of Windows Vista is an excellent example of what happens when things get too complicated; people just don't handle it anymore. To handle complex issues they need to be divided into logical pieces that are easy to comprehend. This is what abstraction in programming is all about, dividing the program achitecture into managable pieces. The question AQ is actually asking is if the complexity should be visible to abstraction layers where it could logically belong to but where it doesn't necessarily need to belong to. The answer to this question from the complexity point of view is not so simple if we only think of files and directories. But assume that the nodes in a graph or tree could also have some other properties in addition to being able to contain other nodes. Should we expose all of those properties to our generic node or should we leave our generic node totally unaware of all these properties. I don't think we should. This would make the generic node complex and filled with properties that doesn't necessarily need to be there. We would loose most of the benefits of abstraction making things simple to understand. Second issue supporting the second alternative is extendability of the code. If we take the view that the specific properties such as "ability to contain other nodes" are properties of generic classes such as node class, then we make it harder to extend our classes later on. If we later on decide to add a new property similar to "ability to contain other nodes" to nodes, we would need to do changes to the generic class level. On the other hand if we from the start design our class relationships so that only the absolutely necessary functionality is exposed at each hierarchy level, we end up with more extendable software architecture. Perhaps I give a practical example. Consider a parse tree of a mathematical expression of the form +(2,*(3,5)). The root node in this tree is +, which has subnodes of 2 and *. The latter * has two subnodes 3 and 5. Indeed we can express almost any mathematical expression as a tree of similar form. + 2 * 3 5 Now the question AQ is asking would be if each mathematical expression should be aware that any mathematical expression can be constructed from subexpressios. Of course pure numbers in our example cannot have subexpressions, so for numbers this information would be irrelevant. Indeed only functions can have subexpressions or perhaps we should call them function arguments. Now if we adopt the point of view that each node should be subexpression aware, then we need to ask, should each node be aware also of some other specific features. Should each node aware of the if this particulae node is a function? Should each node be aware if this particular node is a number? Should each node be aware if the particular node can be converted to string? I guess you notice this is an never ending story. Eventually you have to limit the properties that are exposed to all of the nodes but that are not generic in a way that all nodes have these properties. I think a better way is to delegate the functionality to nodes. For example consider an evaluation of the above expression. Our root node is +, which is a function of two expressions. We make a call to "+.evaluate". This function delegates the job the arguments of this particular + instance, namely to number 2 and to another function *. "2.evaluate" simply returns the value 2. "*.evaluate" delegates the evaluation process further to numbers 3 and 5. This recursive process continues until the expression is evaluated. In a similar manner it's possible to implement different kinds of functionality such as "toString" etc. Eventually most of the functionality can be delegated further. The delegation scheme is not available in LabVIEW, as LV doesn't allow recursive dynamic dispatch method calls, not at least yet. There is a little ambiguity in the question. I may have misunderstood what was being asked. QUOTE(Aristos Queue @ Apr 30 2007, 07:56 AM) Side note: This is but one point of discussion highlighted by the document. Honestly, if I had read this three years ago, LabVIEW classes might have a very different implementation! What would LabVIEW Object-Oriented Programming have been like should you have read the document?

My few words to this thread. Michael, you are right, nobody should be bullied here at LAVA. This problem is all about very basic psychology. People get frustrated when they try to help newcomers and these newcomers ignore everything they say. I was able to foresee the kind of bullying to occur sooner or later. What we need is constructive moderation. First when newcomers ask a question in a way that it really cannot be answered as there is not enough information, it would be better to have an answer template that guides the newcomers to conform the forum rules and guidelines. It's really better to have a nicely written template answer than to make the advanced users to consume their time explaining the guidelines. Why? The template answer can be nicely written whereas the answers of the experienced users is not always that nicely written. Also because experienced users don't get so annyoyed if they don't give a lot of effort trying to explaing guidelines to newcomers that then ignore the guidelines complitely. In addition the message may get its audience in a better way. When a post is malformatted or doesn't have enough information to be answered, then it would be wise to moderate the message away from that specific forum to some kind of temporary forum to avoid other users getting annoyed. This would also be an indication to newcomers that there are rules and guideliness that needs to be obeyed. The moderation should not be left to the hands of one or two people as then it would feel like a job. There should be at least a few handfuls of regular users who could moderate or an automatic moderation button that would do the moderation, either from a single click or when more people press the button. Societies work only if there are some kind of rules either written or implicit. These rules need to be obeyed or the societies become anarchies. In every society that has grown large enough some kind of rule-enforcement is needed. Internet forums make no exception. I think LAVA has lately progressed toward this anarchy state because of confrontations between newcomers and experienced users.