Jump to content

Daklu

Members
  • Content Count

    1,811
  • Joined

  • Last visited

  • Days Won

    82

Daklu last won the day on December 25 2018

Daklu had the most liked content!

Community Reputation

337

3 Followers

About Daklu

  • Rank
    Bringing the Fu to you
  • Birthday 03/04/1970

Profile Information

  • Gender
    Male
  • Location
    Portland, Oregon

LabVIEW Information

  • Version
    LabVIEW 2009
  • Since
    2006

Recent Profile Visitors

6,717 profile views
  1. That's in line with what I remembered, but I didn't want to spread misinformation. (Age plays havoc on my memory.)
  2. My apologies if I misrepresented what you said. Can you elaborate on why you recommend against using XControls?
  3. I am under the impression XControls have more or less been relegated to the rusty nails bin. I know I've seen NI employees recommend against using them in presentations.
  4. Nope. AFAIK the only way to set a class constant value is to write a VI setting the object's value, then copy the object with the desired values from an indicator and paste it onto the block diagram. I (as most developers I know) generally avoid using class constants on block diagrams and have adopted something more like what Dan suggests. Good ideas win out... For example, all my classes have a "Create <MyClass>" method that more or less acts like a constructor. The only time I ever drop a class constant on a block diagram is for typing operations (eg: upcasting or downcasting an object) or inside the class' Create method. You can use either parameters passed into the Create method or accessor methods to set the value of the object--it's a design decision. I quit using class constants to instantiate objects (other than in the Create method) primarily because it reduces flexibility. When I see an object wire on a block diagram, I want to know that object it going to work correctly. If a class has a reference-based construct--such as a queue--as a member, then an object instantiated from a class constant is not going to work until I call a method (eg: Init) that obtains the queue and stores it in private data.
  5. I agree none of this is a trivial task and recompiling NI Linux RT to run on an x86 processor might be easier. I haven't looked at the source code (and have never recompiled Linux), do you have any idea how much code would need to be changed to support an x86 processor? My gut says more than I'd be comfortable with. FWIW, QEMU looks the most promising of the VMs I looked at.
  6. I was thinking more along the lines of a direct ARM VM, not an ARM emulator running inside an x86 VM. There are a few out there... I haven't had a chance to try any of them yet.
  7. No, I haven't tried to do this. I didn't know ARM-based VMs were available.
  8. Wow... was it really four years ago that we talked about this? Time flies when you get old... I don't think I've used futures again since this thread** so I can't speak to the attitudes of the larger community, but my terminology preference is "future token" and "redeem." I do agree with Shaun though, it probably doesn't matter as long as you communicate it effectively and are consistent. [**My development focus over the last several years has shifted from pushing boundaries on actor-oriented and messaging systems to figuring out how to refactor, componentize, and deploy an NI-RT application across different target platforms.]
  9. I've never thought of eliminating the object out for methods that do not change state... interesting idea. One side effect of doing that is you are also ensuring no child classes can ever change their state in the overriding method either. That may or may not be desirable in any given situation. Just out of curiosity AQ, how do you arrange your block diagram when making calls to multiple non-state-changing methods? Do you just run the class wire underneath the methods that don't return an object?
  10. No, I didn't. To be honest it ended up on the ever-growing pile of partially finished things I hope to get to sometime.
  11. Jeff, I gave NI my test code and they confirmed it was an existing CAR. It is reportedly fixed in 2013 SP1, but I have not confirmed it yet.
  12. The only way to guarantee Labview loads the correct version into memory is to close and reopen the project. Sometimes LV will notice the version on disk is different and ask if you want to revert (which in this context means 'load from disk,' not 'undo any changes you made') but I wouldn't bet on it noticing every time.
×
×
  • Create New...

Important Information

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