Francois Normandin

QUOTE (prads @ May 20 2008, 09:12 PM) Hi there. It seems you confuse the reference out (which is really just a pointer if you're used to text programming) with the actual properties of the control or indicator. Have a look a the wiki for Control References: http://wiki.lavag.org/Control_References http://lavag.org/old_files/monthly_05_2008/post-10515-1211334833.jpg' target="_blank">

QUOTE (Choumann @ May 10 2008, 10:52 AM) The error I get when running your code dissapears when you switch "Create" to "Open or create". Although there was a missing subVI and I can't be sure that was your real problem. If you want to append data to the same file over and over again, then that would explain the error you got with "Create" attribute. You should take a look at some of the examples in LabVIEW's search engine under Fundamentals/File Input & Output. There are some nice examples on which you can rely for what you want to do.

QUOTE (Choumann @ May 9 2008, 06:19 AM) Hi Choumann, To extract Intensity plane, you need to have a HSL 32-bit, RGB 32-bit or RGB 64-bit image. You will get an error if you acquire a grayscale image. Check the image type you're acquiring like shown here: http://lavag.org/old_files/monthly_05_2008/post-10515-1210335436.jpg' target="_blank"> If that's not the problem, could you post an example of the image you're trying to process (in jpg or png format)? I don't have any cameras attached to my PC at the moment...

QUOTE (Karissap @ May 8 2008, 02:33 AM) OpenG :worship:

QUOTE (cmay @ May 5 2008, 07:39 PM) If you haven't changed any default values for limits, you could use the "Data Entry Limits" property to determine which datatype by correlation with expected value for each datatype, but I don't think there is a direct way. Maybe there is something accessible with VI scripting (see Rusty Nails forums), but I haven't found it yet...

Download File:post-10515-1209047068.vi Hi Osiris, hope this helps... PS: Credits to Guenther for his use of "Invoke Node: Map Coords to XY"... I learned the hard way there was actually an easy way to do this (while formula node is nice, it took me quite some time to do the same trick!)

QUOTE (Justin Goeres @ Apr 22 2008, 08:57 PM) I sure like this one best so far... I think it's very tight coding! :thumbup:

QUOTE (PaulG. @ Apr 22 2008, 01:42 PM) Although the 3 stars are truely disappointing... I guess that's to be expected from non-G believers. Anybody has a HTML version of this: "99 bottles of :beer: on the wall, 99 bottles of :beer: . Take one down and pass it around, 98 bottles of :beer: on the wall. 98 bottles of :beer: on the wall, 98 bottles of :beer: . Take one down and pass it around, 97 bottles of :beer: on the wall..." Download File:post-10515-1208902763.vi

QUOTE (orko @ Apr 10 2008, 06:33 PM) It does take care of the coercion dots but putting both of them "Scalar" doesn't solve the problem that the icons are not displayed on the second column of the left listbox...

QUOTE (tcplomp @ Apr 10 2008, 02:48 PM) Well, I can't say there is a difference either. I can even reproduce your error! I compared a new MCListbox with the one in PJM's VI and I get two different results... I can see from the coercion dots that they're not the same type. That seems a clue. However, I haven't found yet what's the difference. Hopefully, a good night of labview dreams will get me on track. Download File:post-10515-1207863359.vi (version 8.5)

I think you're looking for a master/slave or producer/consumer designs. Check out the templates that you can access when selecting "New..." You can get your inspiration from one of the templates you'll find there. (see picture)

QUOTE (Norm Kirchner @ Apr 4 2008, 11:45 AM) I agree with Norm. Just like Justin, I usually choose a wire color similar to the banner and mix with high-contrast colors when I'm using yellow or other light colors. But since I don't have a real systematic way of looking at it, I support this discussion before we all develop in mixed directions and become too conservative each about our own way to agree on a real practical "good wire design practices". If NI wants to see what's our reaction, well let's indulge them... since I won't have the privilege to have a paid trip to NI Week. One thing I tried and let go quickly is using large size wires (5+ px) or even size (2, 4, 6, 8px). I don't know, it might be that I don't have any imagination, but I can't seem to be able to create a nice-looking 4-pixel wide wire! So I'm stuck with 3/1 or 1/1 configuration. Any suggestion here would help! And don't refer me to Bezier-style wires... :laugh: One idea for colors could be to propagate the major color of a Parent Class to the Child Class (Parent's Edge foreground becomes its Child's Edge Background & Center foreground. A grandchild class would then look less its grandparent than it does its parent class... and so on. http://lavag.org/old_files/monthly_04_2008/post-10515-1207367911.jpg' target="_blank">

QUOTE (Aristos Queue @ Mar 19 2008, 03:14 PM) It was only a theoretical question. I thought I could build a superdriver for instruments I have in my lab, for example something that would call VISA, IVI or AI transparently. But I don't want something more complicated for me than it will be for the user... I think I'm asking for a small change that would have made my life easier in this situation but would inevitably complicate the task of everyone else!!! QUOTE (Aristos Queue @ Mar 19 2008, 03:14 PM) Ohhhh. Gotcha. Yes, that is very different. The solution is to have a parent class that doesn't have the numeric. The parent implements Read/Write Numeric.vi using the narrowest data type -- in this case, double -- but these two VIs do not actually do anything. Then you have two child classes. One of these children has a double and the other has a complex as its private data. You implement Read/Write Numeric on both of these. Now, that only allows you to store double values into the complex field. If you want to use the widest type in the parent -- complex -- then you have to lose data when ever you store into the class that only stores doubles. Does that make sense? Well, now it does. I didn't realize I was asking for Private Data Override. Thanks Justin for pointing that out... In this particular example, I could have the parent class contain a complex number as you suggested: any DBL value I'd wire as an input would be coerced to the form x+i*0, so I wouldn't lose any data/precision. For directory, I'd better use a string than to play around with type overrides.

QUOTE (Aristos Queue @ Mar 19 2008, 03:14 PM) It was only a theoretical question. I thought I could build a superdriver for instruments I have in my lab, for example something that would call VISA, IVI or AI transparently. But I don't want something more complicated for me than it will be for the user... I think I'm asking for a small change that would have made my life easier in this situation but would inevitably complicate the task of everyone else!!! QUOTE (Aristos Queue @ Mar 19 2008, 03:14 PM) Ohhhh. Gotcha. Yes, that is very different. The solution is to have a parent class that doesn't have the numeric. The parent implements Read/Write Numeric.vi using the narrowest data type -- in this case, double -- but these two VIs do not actually do anything. Then you have two child classes. One of these children has a double and the other has a complex as its private data. You implement Read/Write Numeric on both of these. Now, that only allows you to store double values into the complex field. If you want to use the widest type in the parent -- complex -- then you have to lose data when ever you store into the class that only stores doubles. Does that make sense? Well, now it does. I didn't realize I was asking for Private Data Override. Thanks Justin for pointing that out... In this particular example, I could have the parent class contain a complex number as you suggested: any DBL value I'd wire as an input would be coerced to the form x+i*0, so I wouldn't lose any data/precision. For directory, I'd better use a string than to play around with type overrides.

QUOTE (Aristos Queue @ Mar 14 2008, 10:47 AM) I tried what you're describing and it doesn't seem to work. If I wire the Parent type class as the output, I cannot call the child VI anymore as it won't propagate the child class to the next input, however dynamical these inputs. I'd have to cast to a more specific class and that removes the advantage of dynamic dispatch. For now, the only solution I see is to use variants, which is fine if that's the only way... There also the problem that broken arrows are not gone. I'd have to remove inheritance because the connector panes don't match. Yeap, variants will have to do. http://lavag.org/old_files/monthly_03_2008/post-10515-1205762115.jpg' target="_blank">

QUOTE (eaolson @ Mar 14 2008, 11:15 AM) Yes indeed, it would work if there are no more overrides to be done, which makes it a dead-end for future speciations. In the case I present it would still be a good compromise, since my instrument.model class would most probably be the end of the line (instrument = parent; model = child w/o any possible grandchild)... Which would make it a "sterile class" by not being able to reproduce. :laugh: Thanks all for your inputs.

I thought about starting a new thread but somehow I thought the title of this one applied nicely to my question too. So here it is. I'm trying to use override functions to change the datatype from ancestor to child class. My motivation is that for instrument driver, we sometimes have different types (VISA, strings, IVI, ...) and I would like to have all derive from the same ancestor class (say instruments.lvclass). I was surprised to find out I could not change the datatype. I get the error saying the connector pane should be the same, so I had to go around the problem by using a Variant and all the subsequent dealings associated with that. I made a simple test using Numeric and Directory in an ancestor class (DBL Numeric + String Directory) for which I override with a Complex Numeric in one case and a Path Directory in the second case. I'd like to know if it is even possible to imagine such a feature working correctly in LVOOP? Why is this diagram giving me a broken arrow? I am not used to OOP in C++ or other languages but I thought it was something possible in C++... Could that be solved with dynamic dispatch for controls/indicators other than Objects? For the moment, I saw this possibility is grayed out... By the way, all connector panes are the same, except datatype...

Hi Georges, Eight solutions. Here are solutions for the four (x,y) couples. Then resolve r for ± signs in the original equation: (x-x1)^2 + (y-y1)^2 - (r±r1)^2=0 to get the other four solutions. x1 = [2(y1-y3)(x1^2+y1^2-r1^2) - 2(y1-y2)(x3^2+y3^2-r3^2) - 4(y1-y3)(r1-r2)r + 4(y1-y2)(r1-r3)r ] / [ 4(x1-x2)(y1-y3) - 4(x1-x3)(y1-y2) ] y1 = [-2(x1-x3)(x1^2+y1^2-r1^2) + 2(x1-x2)(x3^2+y3^2-r3^2) + 4(x1-x3)(r1-r2)r - 4(x1-x2)(r1-r3)r ] / [ 4(x1-x2)(y1-y3) - 4(x1-x3)(y1-y2) ] x2 = [2(y1-y3)(x1^2+y1^2-r1^2) - 2(y1-y2)(x3^2+y3^2-r3^2) - 4(y1-y3)(r1-r2)r + 4(y1-y2)(r1-r3)r ] / [ 4(x1-x2)(y1-y3) - 4(x1-x3)(y1-y2) ] y2 = [-2(x1-x3)(x1^2+y1^2-r1^2) + 2(x1-x2)(x3^2+y3^2-r3^2) - 4(x1-x3)(r1-r2)r + 4(x1-x2)(r1-r3)r ] / [ 4(x1-x2)(y1-y3) - 4(x1-x3)(y1-y2) ] x3 = [2(y1-y3)(x1^2+y1^2-r1^2) - 2(y1-y2)(x3^2+y3^2-r3^2) + 4(y1-y3)(r1-r2)r - 4(y1-y2)(r1-r3)r ] / [ 4(x1-x2)(y1-y3) - 4(x1-x3)(y1-y2) ] y3 = [-2(x1-x3)(x1^2+y1^2-r1^2) + 2(x1-x2)(x3^2+y3^2-r3^2) + 4(x1-x3)(r1-r2)r - 4(x1-x2)(r1-r3)r ] / [ 4(x1-x2)(y1-y3) - 4(x1-x3)(y1-y2) ] x4 = [2(y1-y3)(x1^2+y1^2-r1^2) - 2(y1-y2)(x3^2+y3^2-r3^2) + 4(y1-y3)(r1-r2)r - 4(y1-y2)(r1-r3)r ] / [ 4(x1-x2)(y1-y3) - 4(x1-x3)(y1-y2) ] y4 = [-2(x1-x3)(x1^2+y1^2-r1^2) + 2(x1-x2)(x3^2+y3^2-r3^2) - 4(x1-x3)(r1-r2)r + 4(x1-x2)(r1-r3)r ] / [ 4(x1-x2)(y1-y3) - 4(x1-x3)(y1-y2) ]

QUOTE(eaolson @ Mar 6 2008, 10:16 AM) :worship: I think I'm not worthy!

QUOTE(george seifert @ Mar 5 2008, 02:47 PM) I guess you could iterate eaolsen's solution. Select any two circles of yours and find the circle that encompasses them both. Then repeat using this intermediary solution with your third circle should give a final circle encompassing the three circles. It could even work with "n" circles.

QUOTE(eaolson @ Mar 4 2008, 04:47 PM) I somewhat agree with this, except that it was my understanding that the circles are representing the irregular-shaped mass. In such a scenario, Vision will not give a circle completely inscribed in the others... ***EDIT*** Hummm, I think I made an other mistake... Maybe I should rethink again. It seems there's also a problem using cardinal points...

The best strategy will indeed be of calculating your way through this. Since you have three circles that represent your mass, you have their centers and radii, I assume. 1- Calculate the center of mass (xc, yc) of the whole system. There must be a way to do in Vision. Else, use a ponderated way using the radius of each circle. (A smaller circle would move the center of mass less than a larger circle...) 2- Find the extrema for each directions: i.e. for each circles, calculate the point furthest in each direction. (You need only the four cardinal directions if you're dealing with circles.) For example: center of circle1 = (x1, y1) and radius = r1 then left bound = (x1-r1, y1), low bound = (x1, y1-r1), etc. Calculate for each circles and keep the maximum in each directions. 3-Your minimum radius circle that encompasses all circles will be of the same radius as the maximum distance between the center of mass and any of those bounds. 4- Draw your circle from (xc, yc) with a radius rc = distance between (xc, yc) & largest (xn±rn, yn±rn). I hope this doesn't sound too complicated...

You are using three different data types... Your slider is SGL-precision, your indicator DBL-precision and your conversion to string uses Integer... Try to match your datatypes (right-click: representation) to get consistent results or to use "Round to -Infinity" to get 3,51 to be rounded to 3. It is definitely not a precision error to round 3,51 to 4.

QUOTE(shoneill @ Feb 15 2008, 07:00 AM) I agree that the traveling salesman problem is anything but trivial. However, I don't think this problem is an equivalent. The traveling salesman's solution is to find the shortest route possible to visit all points on a map. It's been extensively studied in many engineering problems such as reducing time to solder thousands of components on a circuit board. But if I understand Daku's problem, I tend to confirm Yuri33's assessment that we can discard any points in the middle as they will not give a result anywhere close to the maximum distance between any two points on the periphery.

QUOTE(tcplomp @ Feb 12 2008, 12:34 AM) It is very similar to tree control, but only because most of the methods and properties look alike. I only used MCL control type, no type casting needed. The difference between these two typecasts is that the tree control gives you much more ease of use in icon management. You can hide/show each icon individually identified to a particular tag name. The MCL allows for a whole list of icons to be shown quickly rather than individually controlled. http://lavag.org/old_files/monthly_02_2008/post-10515-1202824855.jpg' target="_blank">