Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 10/03/2011 in all areas

  1. Another possibility, which I have done is such cases, is to use the Set Waveform Attribute vi to set the desired channel name in the waveform itself. For channel name and units the attributes are: NI_ChannelName NI_UnitDescription Once you do this then graph or charts will use the attribute to set the plot name. Also this is nice if you are using TDMS data storage which also uses the attributes in it's internal naming conventions.
    2 points
  2. I've done splash screens before, but they've not really served a purpose other than branding so their implementation really didn't matter from a performance perspective. Now I have an application which seems to take quite a bit of long time to load up, to the point where users regularly wonder, "Hmm, did I actually double click that? Better try again." More than once I've been right next to the person and told them, "No just be patient, it will show up." only to watch them try again and again to click that darned icon. Well at least I haven't set allowmultipleinstances=true in the ini file. Yet. I know there will be a constant time as the LabVIEW RTE spins up which is independent of the actual executable I create in LabVIEW. But does the size of my executable also affect load times? I'm under the impression that the whole thing must load, so if it's larger a splash screen can't be shown either way until the entire application has been loaded into memory. I might be wrong here. My current application is at 44 MB, this doesn't seem too large to me... Has anyone played around with dynamically loading their core application logic from outside of the executable to see if that reduced time to display a splash screen? I figure the best way to do this is have the bulk of my code in a LabVIEW built DLL, then have a shell of a LabVIEW exe display the splash screen and proceed to take its time loading the DLL, after which the splash screen hides itself? The DLL will not be statically linked, a path will be built to it at run time. Or is this road fraught with peril? I've never actually built a DLL in LabVIEW, this might be interesting.
    1 point
  3. I got bit after copying and refactoring a project, then installing the new application on the same PC as the original. The new installer deleted the original app and the old installer would quit when I tried to reinstall it. An NI AE told me how to fix it here.
    1 point
  4. The amusing part of that is I'm the opposite... I understand occurrences better than notifiers. Though, in full disclosure, I can't ever recall using notifiers. Tim
    1 point
  5. I thought I already was . Isn't my name on an openG FP somewhere?
    1 point
  6. There are some instructions, here and here.
    1 point
  7. If you make sure the indicators are updated after the benchmark (run their wires through all the remaining sequence frames) then array will win, with your current bench mark the winner will depend on which test is run first (I suspect the difference is due to pressure on the memory allocator). Personally I use also use an always copy node to copy any input data before entering it into the first sequence frame to make sure I'm not measuring a data copy (just wiring into the first frame maybe sufficient but I like being sure). That wont matter in this case since you're not modifying the U8 array. A couple side comments. A string to U8 array can be done in place so that it doesn't take any time (a u8 array and string have identical structures in memory so LabVIEW just has to reinterpret the data) You're greatly underestimating the size of the string array. Each string takes 6 bytes 4 for size 2 for data. An array of strings is an array of handles. 4 bytes (array size)+5.5 million * (4 bytes [string handle]+4bytes[string pointer]+6 bytes [the string itself] ) so a total of ~ 73.4 mebibytes. In 64bit the handles and pointers would double in size, I'm unsure if the sizes would double or not. If you avoid the string array (and it's 5.5 million allocations) things go much faster On the first run with 5.5 million elements I get For Loop: 4725 Array: 2758 Mine: 134 On the second run (where LabVIEW can reuse the large arrays allocated in the first run). For Loop: 2262 Array: 2279 Mine: 127
    1 point
×
×
  • Create New...

Important Information

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