Efficient writing to waveform charts via property nodes

[surflab]

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

[surflab]

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

[surflab]

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
the 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