LabVIEW
extract x, y values from a waveform graph
I think the reason he's wanting to use the Value property is because this is a graph, not a plot. Since the graph is collecting data for him anyway, he wants to just pull that variable out to use somewhere else, rather than keeping up with it himself.
OP- in addition to what I said earlier, you can also use graph cursors to get individual points, if that's what you're looking to do.
@BertMcMahan wrote:
I think the reason he's wanting to use the Value property is because this is a graph, not a plot. Since the graph is collecting data for him anyway, he wants to just pull that variable out to use somewhere else, rather than keeping up with it himself..
A graph is not "collecting data", it just passively displays whatever is wired to it. The collection happens before that..
Unless that graph is elsewhere (different VI) and we need to access the property via reference, a local variable would be functionally equivalent to the value property node, but with much less overhead.
We don't really have sufficient information to give advice beyond that.
Brilliant! No need for the property node. The (x, y) pairs apparently are directly accessible if you know to treat the waveform graph as an array - which I didn't know you could do. Thanks
@Jim12345678 wrote:
Brilliant! No need for the property node. The (x, y) pairs apparently are directly accessible if you know to treat the waveform graph as an array - which I didn't know you could do. Thanks
Why not take a LabVIEW class? It will help a lot.
@altenbach wrote:
@BertMcMahan wrote:
I think the reason he's wanting to use the Value property is because this is a graph, not a plot. Since the graph is collecting data for him anyway, he wants to just pull that variable out to use somewhere else, rather than keeping up with it himself..
A graph is not "collecting data", it just passively displays whatever is wired to it. The collection happens before that..
This is what I get for posting on a Friday. Yes, graphs just display things. My brain swapped "chart" and "graph". I thought he was trying to get data from a chart which does collect things. Thanks for the correction.
@Jim12345678 wrote:
Brilliant! No need for the property node. The (x, y) pairs apparently are directly accessible if you know to treat the waveform graph as an array - which I didn't know you could do. Thanks
Please don't mark complete garbage code as "solution". There is nothing "brilliant" about that.
- Why would you need to read the same local variable in two different locations.
- Why are you reading the local variable over and over inside the loop? Are you expecting it to change within the few nanoseconds of all the iterations?
- LabVIEW has autoindexing. Have you ever heard of it? No need to wire N.
- Your loop completes in nanoseconds and all you get in the two array indicators are the values from the last plot while the data from all earlier iterations gets discarded. IF that's all you need, you could index it out once. No loop needed.
- It is an xy graph, not a waveform graph. The datatype is determined by what is wired to the terminal and you simply need to "treat" it as whatever that is. (Of course if all plots share the same equally spaced x values (wavelength array in your case), a waveform graph would be sufficient. Do you know the difference? Do you know how to set x0 and dx?)
If all plots have the same number of points, the following would give you two 2D arrays, one for X and one for Y, one row per plot. Of course we have no idea what you need to do with the data later. (note that I named the cluster elements for clarity so I can use "by name")
@BertMcMahan wrote:
@altenbach wrote:
A graph is not "collecting data", it just passively displays whatever is wired to it. The collection happens before that..This is what I get for posting on a Friday. Yes, graphs just display things. My brain swapped "chart" and "graph". I thought he was trying to get data from a chart which does collect things. Thanks for the correction.
Well, almost 30 years ago I once used a chart as a fixed history buffer, adding scalar elements to the terminal and reading out the chart history. 😄 Was faster to implement with my then limited skillset (and much uglier!) that trying to come up with a more appropriate solution.
I can't remember the last time I used a chart. Easily over a decade.
And speaking of "limited skillset"- for my first program, I didn't know about case structures but needed some conditional operation based on a boolean. So, this is what I came up with:
It wasn't a great solution 😄
@Jim12345678 wrote:
I tried tinkering with the value property but never got anywhere with it. I couldn't find a way to get to the data. I'd try to unbundle but just got an unidentified dead end.
Yeah, that's because there's no data when the VI is not running, so it doesn't have any way to know what type of data it is in edit mode. I tried to explain that, but I'm a little unclear on how to get around it. I always code with proper data structures, so I never need to do work-arounds like this. 🤔
EDIT, should have read the rest of the thread. I actually do remember using the plain unbundle for a few tasks similar to this. Getting old I guess. It's still better to keep your data in a proper structure though. 😉
@NIquist wrote:
Yeah, that's because there's no data when the VI is not running, so it doesn't have any way to know what type of data it is in edit mode.
The "type" of data is known at edit time and cannot change at runtime here. Only the value can change. The only problem here is that the cluster elements are not named, so unbundle "by name" does not work.
..
