Jump to content

orko

Members
  • Posts

    576
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by orko

  1. prober,

    Sorry we got off on the wrong foot, and I sincerely hope you got the answer you were looking for from AQ.

    Your response was unexpected to say the least, so I re-read the entire thread. To me the responses that you received were non-threatening, with a genuine desire to help you out. We apparently didn't have a full understanding of what your question actually was, so didn't provide the answer you were looking for. The questions that were asked of you were not answered either, which surprised me since forums by nature require a two-way conversation in order to be effective.

    I really don't mind if your personal opinion is that I am stupid for trying to clarify a muddied situation. Your accusation was without merit, and I hope you come to realize this. You may stay or go (and I hope that you stay), I just hope that you don't go away with false impressions you gathered based on this blatant miscommunication.

  2. Okay, okay...calm your jets, prober. You were very specific in your original post that you wanted DOS, so your answers (since LabVIEW will compile executables for Windows, Windows Mobile/CE, LabVIEW Real-Time, Linux, and Mac OS X off the top of my head...) were rightly directed to the point that DOS is ancient history. If you wanted to find out more about something else, then you should have asked a different question.

    QUOTE (prober @ Apr 19 2008, 04:22 PM)

    I haven't found any such limitation. The idea that LabVIEW is just for measurements and DAQ is about as ancient as DOS... Have you looked at some of its features? That my friend is only skimming the surface, as you can see by taking a tour of just this forum and seeing what people are doing with LabVIEW. It ain't just for measurements.

    What are you going to be using it for?

    QUOTE (prober @ Apr 19 2008, 04:22 PM)

    The only thing that is obvious so far is that we still don't know exactly what you are asking. You want to build an operating system from LabVIEW? First off, why? Second off, what does that have to do with comparing it to C++? Are you truly interested in writing a kernel/driver level from scratch with LabVIEW...? Someone correct me if I'm wrong, but isn't the LabVIEW RealTime O/S just that?

    QUOTE (prober @ Apr 19 2008, 04:22 PM)

    You all are making me think that I cannot create a program in Labview that runs alone without needing anything else to run. And that all the programs I write need Windows to run. Are these true? if so can we say that LabVIEW is not one of those programing languages that are considered a kitchen and you can only create windows based programs in LabVIEW(or another GUI operating system like Linux)?

    I don't understand. We're building applications, dlls that run on multiple O/S platforms. What are you doing with C++/Pascal that is so different?

  3. Thanks for your insight, rolf.

    There definitely is some sort of comparison check so that the DLL isn't loaded/unloaded with each call, which I would expect from using the hard-coded path method in the Call Library Function Node. I was pleasantly surprised to find that there may be the same checking going on when you pass the path dynamically into the CLFN. That makes sense though that the path comparison would probably be done inside the node itself, since the compiler would be working overtime to try and figure out if all of the paths to each DLL were dynamically resulting in the same path.

    FYI, some preliminary testing showed that there was ~40msec increase in delay by using dynamically built paths to a simple DLL "get value" call over 500,000 iterations. I can live with that! :thumbup:

  4. Your error is caused by trying to connect the upper 1D array to the picture control input on the Plot Waveform.vi. To remove the error, delete those broken wires and wire an empty picture control constant instead to the Plot Waveform.vi

    As far as getting all three 1D arrays to plot on one Chart, you could wire the output of the build array (which is a 2D array) to the chart. You may have to insert a transpose 2D array in there as well. See below for an example:

    post-3266-1208594036.png?width=400

  5. QUOTE (Michael_Aivaliotis @ Apr 18 2008, 04:14 PM)

    I had to read that one twice before I got it. ;)

    Dr. Fagin is also an interesting one...

    "With 24 years experience as a professional magician, Dr. Randy Fagin, M.D. has turned his slight of hand skills into real magic as a Urology surgeon."

    There are just some things I don't care to see "disappear". And then there's that freaky never-ending handkerchief trick...

  6. On one of our large projects, I'm converting all of our Call Library Function Nodes to accept dynamic paths to the same DLL - which may reside in different places on the user's computer after installation. We're pulling an installation path from the install out of the Windows registry and appending the DLL name to it, then passing this into the CLFN as opposed to having the path hardcoded like it has been.

    I haven't been able to find much info about the performance hit (if any) dynamically building these paths will cause in an application that may be calling this DLL in multiple threads at semi-reasonable (20Hz+) rates. Does anyone have experience with measuring this? I want to compare results, as my initial testing showed negligible difference...which surprised me.

    Sorry if the above isn't clear. I'm just trying to get a firm (but be gentle) grasp on what is happening "under the hood".

  7. I agree with rolf, but what you are doing is actually possible... if you make the indicators dependant on the output of the comparison (bring them outside the case structure):

    post-3266-1208551413.png?width=400

    Download File:post-3266-1208551317.llb

    Of course it totally relies on the indicators not being cleared (according to the "Clear indicators when called" setting)...

    Interesting, and I don't see anything inherently wrong with the logic, but it still makes me feel "dirty" relying on this method ;)

  8. QUOTE (pallen @ Apr 18 2008, 09:09 AM)

    Oh, I've been there... and know exactly what you mean.

    QUOTE (pallen @ Apr 18 2008, 09:09 AM)

    I still have not decided exactly how I will pass data between VIs. Queues? Functional Globals?
    Shared Variables
    ?

    I am going to run a few tests and see what works best for me.

    That's the best way to find out. There are many opinions on this, but personally I like using functional globals for settings/initialization parameter/state storage (ie: ini file settings, engine state, etc), and queues for communications/synchronization between threads (ie: you do this, you do that). I don't like to talk about the other method you listed. ;)

  9. I for one am JAZZED about this!!!

    Can you imagine all of the talent and fresh minds that will be generated by a national high school level robotics competition using NI hardware and LabVIEW? This will undoubtedly spark more interest in the industry, since the job market has always been highly dependant on what the current trends are amongst the graduates (and vice versa).

    There has been a push from the corporations to find ways to get kids more interested in the scientific realm. I'm excited to see NI is going to be part of the push. :thumbup:

  10. For your 411 (just happens to be the post count, which I found comical for some reason):

    Orko has joined the pack and is expecting his LAVA shirt and coffee mug to arrive in the mail in 2-69 weeks. Orko promises to stop talking in the third person sometime before the end of the day.

    A big Thank You to Michael and all on the board that have made this place such a God-send of information for me! :D

  11. QUOTE (reem @ Apr 17 2008, 12:24 PM)

    i have a manual but it's just introduction to labview

    Oh, but you have sooo much more than that... you have LabVIEW installed. Which means that you have access to a TON of information in the help documents that the people at NI spent years producing. In the "Getting Started" window, there is actually a whole section devoted to people who are new to LabVIEW. That would be an excellent place to start. In fact, just searching for "cluster" in the help I found very detailed information about how to build one, step-by-step... in about 30 seconds.

    If you really want to learn on a practical level, then your money would be well-spent on an introductory book (there are many available) or taking a Basics course.

    I'll be honest with you. If you're having this much difficulty just in trying to figure out which datatypes you should have in your cluster, it will be a very painful process to learn the rest of what you need over the forums.

×
×
  • Create New...

Important Information

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