Efficient writing to waveform charts via property nodes

[surfhippo]

I am updating a waveform chart within a data collection/generation loop, and I have found that doing so either directly to the chart or to a local variable that is bound to the chart is much faster (10-100x?) than if I write to the "Value" property of the chart's property node. Is this a fundamental limitation? I would like to use the property node approach since I actually have several charts available, and I would like to easily (programmatically) choose the destination of the data within the loop among the charts.

[johnsold]

Property nodes are usually slower. Check the archives for past threads comparing speed of locals vs. property nodes. You can put the locals inside different cases of a case statement and steer the data to the chart you want by selecting that case.

Lynn

[surfhippo]

Thanks for the references. The answer seems to be that LV can "synchronize the display with the diagram updates, and the value property is basically stuck using this synchronized version". Indeed, I have a version of my system that works according to your suggestion, that is wherelocals bound to various graphs are inside a case statment. However, I want to refer to an arbitrary group of graphs inside the fast loop, for example via an array of graph references (and thus using the appropriate array element as the input to a generic property node). Locals (as I understand it) require explicit bindings. So, is there a work-around that allows an unsynchronized update when using property nodes? Or, is there another way that I can reference graphs? Any suggestions
appreciated!

[johnsold]

I am not sure I fully understand what you are trying to do. A user interface needs to update only a few times per second. The human observer cannot process data much faster than that. Thus, it seems to me that it may not really be necessary for the "fast loop" to refer to the graphs at all. Let the fast loop pass its data to the user interface loop (via queues, functional globals, or globals) and let the user interface determine which graphs display the data. This way the data is wired directly to the graph terminals and the speed issue is moot.

Lynn

[surfhippo]

The goal is to display 1-3second duration traces in real time, like a scope, at sample rates of 10-20khz. Thus, the chart indicator seems perfect except for the speed issue when feeding it one sample at a time using the property node - again, the property node approach is the only way I can see to avoid explicit references to graphs. This latter point applies whether the data is handled immediately in the fast loop, or externally in another user interface loop. For the moment, I am trying a hack using a waveform graph, in which the fast data loop outputs arrays of data points in chunks smaller than the total trace length, which are then successively concatenated and sent to a graph (via its property node of course)at each iteration. When t
he chunks are short enough, the UI result looks like a scope chart.

[Jabba]

Surlab,

Je pense que l'utilisation de graphs et de tableaux est bien plus avantageuse, que celle des charts.

L'utilisation de chart est tres gourmande en ressources, et chaque rafraichissement n'est pas forcement utile (L'oeil ne peut pas suivre).
Donc toute reduction dans le nombre de mise à jour est la bien venue.

Cordialement,
Raphael TILLET
NI FRANCE