Jump to content

Francois Normandin

Members
  • Posts

    1,208
  • Joined

  • Last visited

  • Days Won

    46

Posts posted by Francois Normandin

  1. You need to convert types to be compatible with the datatype accepted by the write.vi (or any VI for that matter). If you choose "string" as your paradigm, then convert everything to string and concatenate in a format you want (tabulated, coma-separated values, custom, etc.) Then write to file. Browse through the palette for "string" manipulations. You will find many fonctions to help you do just that. LabVIEW tutorials and help file contain many examples to get you started with.

    If you want more specific help, you should show us what you've done so far by uploading a VI with your best effort or posting a picture of your block diagram.

  2. QUOTE (Choumann @ May 10 2008, 10:52 AM)

    There is just one last thing I need to do now, and that is to write an acquired geometrical number to a file. I can write for a single image, but not for an entire avi.

    I get this error message:

    Error 10 occurred at Open/Create/Replace File in IPWD.vi

    Possible reason(s):

    LabVIEW: Duplicate path.

    =========================

    NI-488: New I/O attempted with old I/O in progress.

    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.

  3. QUOTE (cmay @ May 5 2008, 07:39 PM)

    Continuing on this topic... is there a property that tells which type of numeric the control is (i.e. whether it's an I32, DBL, etc.)?

    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...

  4. @Guenther:

    Your code works good, but I now found an even easier way, it is possible to use a cursor and set it to snap to all plots. So you can just move the cursor and it will snap to the nearest plot and show its name. Thanks anyway!

    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!)

  5. QUOTE (orko @ Apr 10 2008, 06:33 PM)

    Perhaps an even bigger clue is the fact that your MCL is an integer and his is an array of integers...

    :oops:

    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...

  6. 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">post-10515-1207367911.jpg?width=400

  7. 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.

  8. 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.

  9. QUOTE (eaolson @ Mar 14 2008, 11:15 AM)

    Would (b) prevent you from overriding the VI in a grandchild class? I should probably know the answer, but I have not had the chance to work with LVOOP as much as I'd like.

    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.

  10. 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...

    post-10515-1205503435.jpg?width=400

  11. 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) ]

  12. QUOTE(george seifert @ Mar 5 2008, 02:47 PM)

    I think I see how your sketch works with two circles. The center of the encompassing circle has to lie along the line between the two circles, right? I have three circles that I have to encompass and I'm not sure how your method would work in that case.

    George

    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.

  13. QUOTE(eaolson @ Mar 4 2008, 04:47 PM)

    I don't think normandinf's solution will work, exactly. If you consider the case where R2 is smaller and entirely contained within R1, then the containing circle is obviously centered at (x1,y1) with radius r1. But (xc, yc) != (x1, y1). So you get a circle of the right radius at the wrong location.

    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...

  14. 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... :wacko:

  15. 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.

  16. QUOTE(shoneill @ Feb 15 2008, 07:00 AM)

    The algorithm is also called "the travelling salesman" and it's anything other than trivial.

    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.

×
×
  • Create New...

Important Information

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