LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

programattically creating/deleting graph cursors

Solved!
Go to solution

Hi

In LabVIEW 2011, we are working with a single-trace graph which is updating periodically; we need to plot cursors programatically during the run, as new data becomes available.  Initially, we just created a static array of cursors, made all invisible, then moved and made them visible as they became relevant; however, now we want to make the list dynamic.  Is this best done by reading the cursor list, manipulating the array as needed, then writing it back to the graph, or are there better ways?  The process is identifying peaks and valleys in a constantly-evolving plot of data.  I find it interesting that the user can create new cursors manually, but there is no property to permit the same programatically; ditto for delete; the user created cursors use default attributes which are not suitable for our needs.

 

I'm looking for the least runtime time-consuming solution, and rewriting the whole array seems to carry unnecessary performance penalties. 

 

Maybe we should create new cursors in blocks to reduce the number of cursor list updates?  I'd like to think the worst case scenario is about 60 cursors, but since the peak detect algorithm is automatic, an unusual data signal could result in several hundred.  Will the graph even survive this?  The data set will, worst case, be something like 15000 data points.  Any experiences/pointers/caveats will be appreciated.

Thanks

Blair

0 Kudos
Message 1 of 4
(3,390 Views)
Solution
Accepted by topic author GuessWho

@Blair Smith wrote:

 

[...] Is this best done by reading the cursor list, manipulating the array as needed, then writing it back to the graph, or are there better ways?


I don't see any method to add a cursor, so manipulating the array is the way to go.  You could save the time it takes to read the list by reading it once, at the beginning, and adding to it it as your plot evolves.  You could limit the updates to occur no faster than the operator can appreciate them.  If your data adds dozens of peaks in a fraction of a second, you could get away with adding them all at once every second or more.

Jim
You're entirely bonkers. But I'll tell you a secret. All the best people are. ~ Alice
For he does not know what will happen; So who can tell him when it will occur? Eccl. 8:7

Message 2 of 4
(3,383 Views)

Manipulating the CursorList array is the way to add/delete cursors programmatically. What do you think gets modified by the user creating a cursor manually? Look at the example that ships with LabVIEW.

 

As to performance penalties, it's unlikely that you will see any discernible performance penalties from the array manipulation, since you're not dealing with large arrays, even with 60 cursors (which, by the way, seems excessive to me). If you're really worried about it, you can use the In-Place Element Structure when manipulating the array. The performance penalty will come from the actual drawing of the cursors, not from the data manipulation. With respect to this you should really look to see when you actually need to update the list. 

 

 

EDIT: Created while Jim was posting his response.

0 Kudos
Message 3 of 4
(3,381 Views)

Jim

Since the list is empty to start, we'll just use a constant to establish our druthers for attributes, and add as needed.  Our hope is to be able to tune the parameters to not create bogus peak and valley markers, but all it takes is one signal that is not-quite-in-tune, and splat, twice as many cursors appear, hence our need for dynamic creation.  All we had hoped for is a create and/or delete option on the properties which would let the graph manage the list, but doing it ourselves is reasonable.

 

Thanks for the good-natured helpful reply.

 

0 Kudos
Message 4 of 4
(3,371 Views)