Tomi Maila

QUOTE(karim @ Apr 2 2007, 09:27 PM) I wrote you a long answer that was supposed to help you. Then you quote my answer and say that you are not being helped.

Note that the same user asked a similar question in another thread a few days ago. And for karim, please forget the parallel port and use USB port attached DAQ hardware, PCI bus attached DAQ hardware or PCI-Express attached DAQ hardware. Parallel port is years old technology and nobody builds hardware for it.

:laugh:

Hi, The administrator and owner of this wonderful forum Michael "Mike" Aivaliotis has a birthday today. He turned 39. Happy birthday Mike!!!! I challenge everybody to donate to LAVA a few bugs as a birthday present for Mike. I made my contribution and donated $5. Tomi

I'm very excited to introduce a third article in my article series Introdunction to Object-Oriented Programming in LabVIEW. Today's topic is Don't miss other articles in this article series or other LabVIEW related articles at EXPRESSIONFLOW. You can also subscribe to the RSS feed of all articles at EXPRESSIONFLOW so you won't miss the next one. Tomi

QUOTE(Michael_Aivaliotis @ Apr 2 2007, 12:43 PM) Happy birthday to the LAVA master Michael! What would our world be without you Tomi

I would schedule NI Week on March. Another important issue is where NI Week should be held. Austin Texas is a trouble for travellers travelling from outside the States. U.S. restricts the airports to which foreign companies can fly to. As a results travel times to Austin Texas are quite long as one needs to take two-stop connections. As an example to get to Austin from Helsinki where I live it takes nearly twenty hours whereas a flight to New York is 8.5 hours. So my strong suggestion is to move the NI Weeks to a more accessible position near a major international airpot such as New York, Chicago or Los Angeles. Austin Texas doesn't have one of the major airports. Tomi

Add your main VI as a startup file. Add all your classes as support files so that each class goes in its own folder (or llb).

QUOTE(Aristos Queue @ Mar 30 2007, 02:50 AM) Perhaps if you did take a look at the example code I provided you would notice that this is the way the example indeed works. Tomi

QUOTE(Tomi Maila @ Mar 29 2007, 12:43 PM) Hi AQ. Here is my proposal how to remove functionality from the subpanel and place intelligence to the dialog window hosting the subpanel. It's not working perfectly but it's a proof of concept. The dialog window resizes to fit to subpanel and the subpanel is executing until the user presses ok or cancel. Real system would need much more intelligence in the dialog side but I think you can figure it out. Tomi

QUOTE(eaolson @ Mar 29 2007, 10:10 PM) You must be right. I've not been using feedback nodes so I misunderstood the meaning of initialization node, I guess. Tomi

QUOTE(eaolson @ Mar 29 2007, 09:34 PM) First call is not needed as feedback node can be initialized in the edge of the loop.

QUOTE(Ben @ Mar 29 2007, 08:24 PM) That's very wise of you as I made a mistake. The feedback node of mine doesn't work without the outer loop. To work it would need to have a loop. Jim, how do you create this feedback node of yours? It seems to be inside a hidden while loop. And it seems the hidden while loop is set up so that it goes on forever. At least for me. Did you really create this with LV 8.20 or did you happen to use something non-public? Tomi EDIT: The updated feedback node test is attached. It's still fastest but not by so clear marigin.

QUOTE(Aristos Queue @ Mar 29 2007, 04:36 PM) I didn't find the old tests but I quickly wrote new ones. They are attached. Feedback node was fastest, while loop second and for loop last. Tomi

QUOTE(Aristos Queue @ Mar 27 2007, 11:06 PM) Hi, I think this two-time call is overkill from the error class developers point of view. I propose the following. Use the front panel size of the subpanel VI to size the subpanel and the subpanel containing VI. Use multiple transparent panes to divide the error dialog into multiple parts top: header, middle: subpanel and bottom: buttons. Lock the bottom pane to bottom and top pane to top. Make the subpanel on the dialog frontpanel to resize with the window. This way your subpanel always fills the whole middle pane as you resize the dialog window. The buttons also stay at their correct locations. So when opeing the dialog window, resize the window to its correct size. Do not ask the subpanel for a size but use subpanel VI front panel size to determine the size of the actual dialog window. When you resize the dialog window, the subpanel automatically also resizes accordingly. This way the only task left for the subpanel is the actual error displaying and nothing else.

QUOTE(Aristos Queue @ Mar 29 2007, 05:30 AM) I tested this particular issue a month back while I was working on a piece of code that would use in everywhere. The result was that while loop indeed is faster than for loop for this particular task. I didn't figure out why, after all I don't have deep knowledge of diagram optimization like Jeff K does. Tomi

QUOTE(tcplomp @ Mar 27 2007, 11:44 PM) I wish I would have... Tomi

Hi Aristos, As you already know, I support the idea of refactoring the error management system to use classes. So great work! You wanted feedback so here is my initial feedback. - As a general remark I had difficulty following some of the code as it doesn't fit to my 1680x1050 screen and it wasn't very much commented - All connector pane terminals were not clear to me as they didn't include a description - The requirements for the subpanels of each user defined error class are much too heavy currently. New error classes should be very simple by default. Try to simplify the structures of subpanel construction. Perhaps the default functionality of most subpanels can be encapuslated to some error dialog helper classes. - I think by default a new error class shouldn't need to define new subpanel. I don't know if this is the case. I didn't check it. - I think normally each error class should include a single method that can be used to create an error of that class - There wasn't yet any means of catching errors. I think catching errors is even more important that displaying error information. I guess you are going to work on this side as well. - This is just a wild idea. Perhaps you could allow subpanels that are interactive i.e. that stay running during the display. This would allow interactive trouble shooting dialogs. I try to study the example in more detail later on. Tomi

QUOTE(Aristos Queue @ Mar 27 2007, 07:11 PM) I see, so you kind of have classes that should be of some sort of private scope. Wouldn't it be better then to use a special "private class" glyph for these private items. I think it would be more intuitive than using a glyph for "user customizable" classes. Anybody second me on this? Tomi

QUOTE(karim @ Mar 27 2007, 05:44 PM) This is a kind of elementary question that will more likely be answered at NI forums at http://forums.ni.com''>http://forums.ni.com' target="_blank">http://forums.ni.com. This is a forum for advanced issues as the name of the forum very well tells. However before posting, please at least try to read tutorials, documentation and go trough examples. You don't learn a new programming language by doing nothing yourself. Nobody will do the work for you. Second, if you post the question to a forum either here or there, the aswer will as well be posted to the forum so that it will benefit all the readers and not just you. That is the way forums work. So do not ask for an email answer. If you want an email answer, you can purchase support contract from National Instruments. Third do not format your text, do not use big fonts etc. It will only make those who could help you annoyed and they are more likely not to help you. So yes, it gets more attention that way but that is a bad thing and not a good thing as you may have thought. And then to your question. I must be patient today... Perhaps it's the spring. You cannot record directly from an electrode. At least it's not wise. You need stuff like an amplifier that amplifies your signal. This is it's own field of science and you should study it before you do anything else. Read some introductory text to electrophysiological measurements. After the signal is properly amplified and the setup is properly build in all the other ways as well, you can record the data with LabVIEW. To do this you need special hardware i.e. a DAQ card. See National instruments web pages for DAQ hardware. I recommend a "low cost" M-series PCI card that fits your needs. Only after you have your set-up ready and you can start playing around with the software side. By the time, check LabVIEW examples about data aquisition. p.s. Your question didn't deserve this good an answer. I was pollite. Please be pollite to our community and behave according to the recommendations I suggested. Tomi

Seems similar to signal-noise separation problems. Have you tried to google for "signal noise separation"? You may want also to read some text books on the issue, however I'm not that familiar with the topis so I cannot suggest any. Tomi After a minute of further thinking, why not to change the algorithm that does the classification so that it really does the classification all the way so that you didn't have to first use classification algorithm and then classify the result of classification algorithm. You can use Bayesian statistics to determine exactly the probability for a particular point belonging to one of your two classes. I guess however that this requires you to study some math... For quite an easy introduction to this kind of math, see for example D. S. Sivia: Data Analysis; A Bayesian Tutorial. Tomi

QUOTE(Aristos Queue @ Mar 27 2007, 01:21 AM) Aristos, could you share some of these use cases= QUOTE(Aristos Queue @ Mar 27 2007, 01:21 AM) The resolution of these: the class "network error" should inherit from user-defined error. So you are saying that the class hierarchy will be divided to segments that user cannot extend but NI can, and to segments that user can extend. What is the design decision behind this concept? QUOTE(Aristos Queue @ Mar 27 2007, 01:21 AM) As for the missing glyphs -- these are the LV class glyphs only. Not the entire iconography of LV. You mentioned XML. Why not TCP/IP? Or the glyph for file path? I was just listing the core concepts I use with LV classes. Well, I'm not using "break/interrupt" nor "advanced" currently. QUOTE(Aristos Queue @ Mar 27 2007, 01:21 AM) And there's no glyph for references included. Guess why... ;-) I think there should be. Consider someone writing a device driver for a device. Very propably a referece to the physical device will be used as private data. So actually the wire acts like a reference and not like a value. How does user know if a wire acts like a by-reference wire or like a by-value wire. I was suggesting that a glyph could be used to distinguish these two use cases. Well there is always the case of mixed wires as well with both references and values, but I've no solution for those wires. Tomi

Hi, I just posted my second EXPRESSIONFLOW blog article in the series of Introduction to Object-Oriented Programming in LabVIEW. The articles topic is Code Reuse with Interface Design and Composition. Take a look by following this link. Also read the previous article Introcution to Objects and Classes at the same location. I'll post a link to forthcoming articles in the series to this tread. If you want to dicuss the articles, please open a new discussion for specific articles or discuss at expressionflow.com. This way we can keep this thread as a list of articles in the series. Tomi

QUOTE(Aristos Queue @ Mar 26 2007, 01:30 AM) It was a internet explorer in a hotel in Copenhagen. I guess the version was 6.x. I'm back from my weekend trip so I can take a deeper look in the glyphs. First I think it's an excellent idea to use glyphs to decorate icons. However current icons are rather small to hold up many glyphs and I suggest this limitation to be removed in future version of LabVIEW. Second I'm not sure the LabVIEW object icon is good any more now that any object glyph is introduced. There is a risk of misinterpreting the one for the other. About write and read glyphs. I don't think they actually describe the the function of setting and getting data. Write and read may be the words used in English language but some other languages may have other words for this kind of actions. So using glyphs that describe English words write and read and not the action of setting and getting data is I think a bad idea. I know you have been using these gylphs in icons already so it may be hard to discard them now. However, for example for "Read property" I would use property glyph together with an arrow towards right originating from the prorepty glyph. About the polymorphic glyph. I don't really understand what is the intended use of this glyph. Could you AQ clarify your intentions. What ever the use is, I don't think the quesitomark should be there as polymorphism is not related to any "questions". Also the question mark is used as a glyph for warning so I think other uses should be avoided. About the recursion glyph. It's not intuitive to me. There are many kinds of recursion and I think the kind of recursion you are meaning here is a recursive VI. I would use a VI or "method" glyph together with an arror starting from right side of the VI glyph, going around the VI glyph somehow and ending to the left side of the VI glyph. For public methods, I don't think there is a need for glyph. I think public should be the default. Also a green key is still a key and the only intuitive interpretation is some kind of locking and not being open. The Initialize and start are different behaviours as I said in my previous post. They should have different glyphs. Starting means starting an action that goes on independently. Initializing doesn't have this dimension of independent action. Think of a VCR. When you power it on, you initialize it. When you press play, you start it. I think initialize and create should have similar but not same glyphs. I propose a glyph used for initialize is a star symbol without the diagonal elements. I mean a cross '+' with a 3x3 pixel hole in the center. For errors I would use the same symbol that appears on firefox addressbar when you go to a webpage that doesn't exist. I'm not sure if there is a need for "user defined" glyph and least not in professional use. I don't think user defined errors or other classes in class hierarchy should be separate from NI class hierarchy. Class hierarchy should always represent what objects really are. If I write my own network driver, the error it should throw should be a subclass of network error and not subclass of user defined error! So please consider removing the "starting points for customization" from the class hierarchy. These kind of classes do not belong to the class hierarchy!!! They are misusage of OOP and this kind of philosophy may cause troubles to serious developers such as OpenG developers. About the example hierarchy, network error and device error are both I/O errors and there should be a common superclass. Then there are some essentianl glyphs missing: - close (X symbol) - cleanup / destroy (a different kind of X symbol) - stop (square) - message (envelope) - by-reference (when your object refers to some real-world device for example, the same glyph used in property nodes) - send (envelope with some "speed lines" to the left or alternatively symbol similar to forward symbol in thunderbird) - reveice (mailbox) - open (similar to open symbol in MS word) - save to disk (similar to save symbol in MS word) - XML (<XML>) - clone object (when wire copy is not enough, ???) - advanced feature (I've no idea) - fail (red cross) - ok, not failed (green check-mark similar to the check-mark in system checkbox in Windows XP) - break, interrupt (a hexagon similar to stop sign) - wait (time glass) - timeout (time glass with error glyph) - lock by-reference object (a closed lock symbol) - release by-reference object (an open lock symbol) Regards, Tomi

QUOTE(Michael_Aivaliotis @ Mar 25 2007, 11:44 PM) I second Jim in this question.