Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 07/21/2014 in all areas

  1. I am heading to NI Week again this year and bringing along my camera and mic. I'm taking request for sessions that you would like recorded. Please give me you top 2 to 3 choices. No promises but it will influence my decision. The session guide can be found Here Thanks Mark
    2 points
  2. As a side note, this has been useful to me. Also, check this idea exchange topic. http://digital.ni.com/public.nsf/allkb/92080885AFE94B2D8625794A007B6D0C?OpenDocument http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Please-clearly-mark-the-IMAQ-functions-that-require-a-Run-Time/idi-p/1832859
    1 point
  3. Okay Jack you were right. I thought 2ms was too low. In my test I was reading the same attribute over and over and the compiler must have some how optimized for this. So I did a new test, where I had 1M tags, like your example, then read them all using a normal VI that is inlined, a normal VI that is non-reentrant, and my XNode. For added interest I also had the This VI returned from the Xnode because I figured I would be able to read the execution inofrmation from the XNode VI. With my test the Normal Inlined VI took 607ms. Probably lower than yours because I am just reading, not checking for validity like your was. My non reentrant was 701ms. The XNode option was 606ms. But interestingly enough when I read the VI Name of my XNode VI reference returned it was the name of the calling VI. So an XNode appears to do some sort of inlining, but I can have things like property nodes in my XNode which normally inlined VIs cannot. Of course doing this screws with all the performance numbers I mentioned earlier so I removed that. Attached for those interested is my read XNode, along with the VI to check performance. This has a dependency on the LAVA Scripting Tools. But I think that's it. I made this Read XNode because I wanted it to have the combined ability that a polymorphic VI can have, where you right click and choose the type, or you could wire in the type. So right click the XNode and you can choose from a large list of data types to read, or if you pick Automatic you can wire in the type to use. I'd like to release this at some point but for now it is a learning exercise. EDIT: Saved in 2012 XNode Performance Test.zip
    1 point
  4. There's the red flag; that's a couple order magnitudes lower from gut instinct. I suspect one of two compiler optimizations due to the benchmark harness: 1) loop invariance that's applied on inlined but not detected for non-inlined VIs, or 2) dead code elimination, from not accessing the contents of the attribute I hear this as excellent news, that your the XNode is just as performant as a "regular" VI! To substantiate, here's a harness that shows 1,000,000 accesses in a loop that exhibits no potential loop invariance or dead code -- on my machine, it takes roughly ~900msec:
    1 point
  5. I never looked at the details, but you can examine the VIs LV uses to see the process. Not all of them are unlocked, but some are. Specifically, you'll probably want to start with <LabVIEW>\resource\Framework\Providers\LVClassLibrary\NewAccessors\BaseAccessorScripter\ScriptAccessorVIs.vi
    1 point
  6. All my dislikes are purely aesthetic, I think they look quite cartoony and waste way too much space. I pretty much use System controls exlusively for GUI front panels.
    1 point
×
×
  • Create New...

Important Information

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