Search the Community

Hi All, I am trying to plot three XY scatter data and move one against the others. It does work when I make a new x-axis and change the scales of one manually. However, when I try and use it programmatically, the numbers of the scale change, but the plots do not change, meaning the one that was moving is not anymore. I could just recalculate X values separately and replot every time I change scale, but I don't think that should be the only way to do this. Any help would be appreciated.

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.

Some background: I'm trying to use the name of the library my VI is executing in as part of a string which will be used in the name of a Rendezvous, to keep it distinct from other Rendezvous I will create. When attempting to use the VI Property Node to access the Library property on the CompactRIO, error code 1 is returned. Running the same code on my computer runs as expected and returns the Library. Accessing the VI Name using the Property Node appears to work no problem on the RT, though. Does anyone know what could be causing the problem? I tried searching the documentation, but didn't turn up anything. Is this error part of some general behavior wherein some VI properties are not accessible when a VI is running on a real-time target? Code is attached. Please see attached pictures: Project Explorer: Block Diagram: Front Panel - RT Results: Front Panel - Computer Results: Experiment with VI Property Node Error.zip

Hi, I didn't know how to entitle this topic. I hope this title is not too generic.. I have attached two VIs with the same code. Purpose of the code is "calculate the position of the upper left corner of a button, in display coordinates, not panel coordinates". When I created the code, see CORRECT RESULT.vi, it worked fine. Then I copied the code into other VIs and the calculated result is not correct, see WRONG RESULT.vi (I have highlighted the wrong value with red backgrond) I have checked the VI properties, but I haven't found a specific property that solve the issue. My colleagues discovered this odd behaviour because they placed the function in existing panels (some of them have complex interfaces with mutiple panes and splitters and in some cases it works, in other cases doesn't work. Have you seen something similar in past? CORRECT RESULT.vi WRONG RESULT.vi

I've created a class which contains (mainly) a bunch of settings and a bunch of events. To keep things organized, I've put these into a Settings and Events cluster, respectively, in the class private data control. If I want to create neat property nodes for such clusters, I have to follow a rather cumbersome procedure: 1. Create a vi for data member access to the whole cluster via the appropriate dialog 2. Create a vi for data member access each individual element via the same dialog 3. Open the Class properties window and navigate to Item Settings 4. Locate the whole cluster accessor and set its Short Name to (e.g.) Settings, plus the Long Name to (e.g.) Settings:All Elements 5. Locate each individual accessor and set its Short Name to (e.g.) Stngs.Polarity, plus the Long Name to (e.g.) Settings:Polarity. This is very tedious, whereas it seems like a very common scenario in LVOOP development. Are there any solutions to this issue?

I'm trying to create a better user interface for my tree navigation. The tree will ultimately have hundreds of items within it and I'm adding a search bar (simple string control). I'm looking for someway to problematically hide all of branches that don't contain the search query but I can't find any methods or properties that can do this. Any ideas?

If you have your class and you want to create a pull right menu on a property node for it, you can use the colon ( to separate property items for it. Just right click on the class » Properties » Item Settings » Localized name. Also, on a separate note and since I'm in the neighborhood, you could also take advantage of the "Documentation" tab in the Class properties to change the "Localized name" from the default (in my case, "NI_VSA.lvclass") to something shorter or more meaningful. .This makes it easier on the eye. Regards

When working with code that uses LVOOP property nodes, debugging becomes difficult because there is no easy way to go to the accessor code that runs when the property node executes. So in order to alleviate this I created the Property Popper. Run this floater helper VI (leave running during development) When you want to get to an accessor, select the property node Click 'Get Properties' on Pop Property.vi Double click on the property you want to get accessor access to Enjoy ~,~ The Captain was here See Video Detailing this <!-- copy and paste. Modify height and width if desired. --> <object id="scPlayer" width="892" height="708" type="application/x-shockwave-flash" data="http://content.screencast.com/users/NJKirchner/folders/Jing/media/e7471e93-bf0b-4801-b050-8e7c58d7a0fc/jingh264player.swf" > <param name="movie" value="http://content.screencast.com/users/NJKirchner/folders/Jing/media/e7471e93-bf0b-4801-b050-8e7c58d7a0fc/jingh264player.swf" /> <param name="quality" value="high" /> <param name="bgcolor" value="#FFFFFF" /> <param name="flashVars" value="thumb=http://content.screencast.com/users/NJKirchner/folders/Jing/media/e7471e93-bf0b-4801-b050-8e7c58d7a0fc/FirstFrame.jpg&containerwidth=892&containerheight=708&content=http://content.screencast.com/users/NJKirchner/folders/Jing/media/e7471e93-bf0b-4801-b050-8e7c58d7a0fc/2012-01-10_1033.mp4&blurover=false" /> <param name="allowFullScreen" value="true" /> <param name="scale" value="showall" /> <param name="allowScriptAccess" value="always" /> <param name="base" value="http://content.screencast.com/users/NJKirchner/folders/Jing/media/e7471e93-bf0b-4801-b050-8e7c58d7a0fc/" /> <iframe type="text/html" frameborder="0" scrolling="no" style="overflow:hidden;" src="http://www.screencast.com/users/NJKirchner/folders/Jing/media/e7471e93-bf0b-4801-b050-8e7c58d7a0fc/embed" height="708" width="892" ></iframe> </object> pop property.vi