Jump to content

azhew

Members
  • Posts

    6
  • Joined

  • Last visited

Profile Information

  • Gender
    Not Telling
  • Location
    Tucson, AZ

LabVIEW Information

  • Version
    LabVIEW 2012
  • Since
    2006

azhew's Achievements

Newbie

Newbie (1/14)

  • Week One Done
  • One Month Later
  • One Year In Rare

Recent Badges

0

Reputation

  1. Thank you all for the very informative answers! drjdpowell : thanks for making me aware of the JSON library, especially since we use JSON in another project (in C though), this is going to be very helpful in the next few months I believe. Thanks manudelavega and smithd for suggesting separating the configuration from the initialization. I looked at the decorator pattern, but I might have to read this multiple times before I am ready to try it ;-) I usually mostly do hardware stuff, so as long as classes correspond to physical objects I am not too lost. I think I will try that approach on my next small project, and I will also add a VI that prompts the user to enter the appropriate settings like ned suggested. A question to smithd : what do you mean by "actively managing" the state of the object if it has a reference? Thanks!
  2. Hi! A few weeks ago, I had the opportunity to use the factory pattern, something I wanted to do ever since I heard about it. I would like to know if I did it right, and what I could have done differently. ;-) I wanted to build an abstract class that I could use with multiple scientific CCD cameras. This class has 5 VIs: - Initialize - Snap - Sequence - Close - GetTemperature The main question I have is that every camera that inherits this abstract class had a different way of being initialized. For example, CameraA had a controllable temperature setting and CameraB did not, so when implementing the Initialize VI, CameraA will need a target temperature input, while CameraB won't. For each camera, I created a "initializing options" cluster, and I passed this cluster to the Initialize VI through a variant. For CameraA this cluster had a "target temperature" numeric among other things, while CameraB did not. The specific implementation for each camera uses the "Variant to Data" function to retrieve the cluster values. It works, but I am wondering if this is a good way of doing it. While I was researching how to pass specific data using the factory framework, I could not find a "this-is-the-one-and-only-method-you-should-use" answer. Are there potential problems with using a variant that I did not think about? Is there another way of passing clusters that will be different for every child using the factory pattern? Other than this specific question, is there a major drawback to using the factory pattern? Thanks!
  3. azhew

    CUDA

    I guess it would help you write code for the GPU without actually having to write CUDA. I have installed the entire toolkit (apparently you can with an academic license) and here is what I see: - VIs to allocate memory, free memory, copy your data to the device etc... - VIs built on the CUBLAS library (linear algebra: matrix product, triangulation...) - VIs for FFT and IFFT - a "GPU SDK", but I have not looked yet what you can do with it... So if you do large matrix manipulation, maybe this would be a straightforward way to accelerate your application with a GPU without needing to know cuda. If you already know cuda and have a lot of code written in it, you are probably better off making a library to use with labview. I will look more into the SDK later.
  4. Thank you all for your answers and also for the reality check ;-) I think that what I am going to do is develop the software so that the system can be used for routine acquisitions, maybe with the possibility of having an adaptation rule loaded on the control computer, and leave the remote communication part as a "future work". I do not know how much longer I have for my PhD, but hopefully less than a year (more than 6 months though). I will work on the software this summer while I am getting some big parts machined. I will come back and describe the architecture when it is ready ;-) Thanks for the useful input!
  5. Thank you for your answer. To be honest, I would like to avoid doing two phds, the hardware is already a big task ;-) But if I don't have time to implement everything myself in the software, I would at least like to plan the architecture so that the next student can build on top of that without re-writing the entire software. I actually see it as a good opportunity to learn more about labview programming. So I will at least try! I will look into the VI Server interface, thank you. Ideally, external applications could be written in any language (most likely C or Cuda).
  6. Hi, First, I am new to this forum, and also not so well versed with Labview as others, so please forgive me if this question should be somewhere else, or is not interesting. I am currently developing an imaging system (for my phd), and now that the hardware is almost done, it is time to develop the software ;-) My system has many detectors that can move, along with other stuff, which allows it to go from one imaging configuration to another (it's an adaptive system, a bit similar to adaptive optics in telescopes). Ideally, I would like to have a main application to control the hardware in my system, and from this main app, be able to load an external application that will then "take over" the control. By this I mean: the external application should get acquisition data as input (continuously), and send some commands for the hardware as output (continuously, or once, or every minute depending on the situation...), and when it is done, it will end and the main app will again be in control. The external application could be located on the same computer that controls my hardware, or on another computer, or a cluster of computers... (or the cloud maybe...). Is this something that can be done in Labview? Is there something in what I said that can't be done? Can someone direct me towards some material I can read about this? Thank you in advance for any help! -cecile
×
×
  • Create New...

Important Information

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