Jump to content

cherold

Members
  • Posts

    3
  • Joined

  • Last visited

Profile Information

  • Gender
    Not Telling

LabVIEW Information

  • Version
    LabVIEW 2013
  • Since
    2010

cherold's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. I'm looking for a way to programmatically generate a unique identifier for each instance of a object class. E.g. is there a function to get a refnum from an object? Ideally, someone can suggest a built-in unique identifier so I don't have to build into object data and check it myself.
  2. Thanks ShaunR, hooovahh, and Mads. I was able to download an evaluation version of LV2013 and saw significant improvement (3-7x faster) for the slowest operations. As Mads says, updating the entire table still takes about 1 s which is an acceptable "loading" time. Most other operations can be optimized to only update a small portion of the table. However, operations like inserting/deleting a row near the top still require shifting the color of all subsequent rows. I'm not sure the responsivity will ever feel "instantaneous," but it should be passable with 2013. Thanks again for the quick comments.
  3. After getting pretty deep into an experimental control paradigm with a Table Control as the user interface, I've run into the very frustrating problem of slow formatting updates (cell background and text color). Even when deferring panel updates, formatting a 50 row by 200 column table based on each cell's string takes seconds. The UI table assists the user in generating a 2d string array, which is subsequently sent to a set of hardware objects to control a Bose-Einstein condensate experiment. From reading other posts on this forum and the NI forums, I've compiled the following suggestions: defer panel updates (helped a lot, but still too slow) set subVIs containing table Property Nodes to execute in 'user interface' thread (I've tried this but would love to know more about optimizing it. Should the subVI attempt to only contain Property Nodes with logic outside in a different thread?) maintain a "display" table which is a subset visible to the user (seems pretty complicated and may only give gains of factor of 2 or 3 since I want the Table to fill the user's monitor) obviously, take all steps to format by column, row, all (not possible for about half my columns whose coloring depends on each cell's value) Is the above list exhaustive? Can anyone suggest something I haven't listed? I'd also appreciate more information about UI thread control. My naive understanding is that table coloring is so slow because to color cell-by-cell the process must switch up to the UI thread and back down. And setting a subVI property to the UI thread saves some of this thread-switching time? Barring any other insights, it seems like we've been burned by trying to use a table control in an unintended way and LabVIEW simply can't do it fast enough. Do XControls suffer from the same thread-switching problems for front-panel appearance updates via Property Nodes? Otherwise, I'll work on rewriting the UI in another language and simply feed the 2d string array to the rest of my LabVIEW code.
×
×
  • Create New...

Important Information

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