LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Labview Waveform Chart

Solved!
Go to solution

Hello dear Labview colleagues,

A friend came to me who has some problems with his Labview code. He wants to display data in a waveform chart, but he cannot set the correct time. I have tried this with the timer function (Get Date Time in Seconds), but it happens that the data is deleted after about 20 minutes, which would be a disaster in this case. Then I tried it with a time loop, which worked with the time, but this has an influence on the buttons for operation (you have to press several times until a command appears.)
Question to you: How can I solve the problem?
Thanks in advance for your help

 

Attached you will find the code

 

0 Kudos
Message 1 of 11
(472 Views)
Solution
Accepted by topic author Marcschäfer59964

Sorry, cannot look at your VI unless you do a "save fore previous", (2020 or below).

 

A chart has a defined history length (configurable at edit time), and once the limit is reached, the oldest data is discarded. If you want to keep all data you should accumulate it in a shift register or stream it to disk.

 

To get correct timing on the x-axis, all you need is set x0 and dx once, (but that also depends on the datatype)

Message 2 of 11
(442 Views)
Solution
Accepted by topic author Marcschäfer59964

I managed to open your VI, but can make no sense of it.  Could you please write a single small VI (one that doesn't require a dozen 1920 x 1080 monitors stacked vertically to see the code), and describe what you are trying to do?  You can say "Acquire analog data at XX Hz for YY minutes and show (some? all?) of the data on a Waveform Chart, with the X axis being (Time of Day or Time since start of acquisition)".

 

If you are having difficulties with getting your big complex code (that can't easily be viewed) to work, try writing part of one of the (identical?) modules.  You can "generate data" using a While Loop and a random number (or sinusoidal waveform) generator.

 

Charts have a finite width (a few thousand points?) before they start to scroll (or sweep).  Graphs can hold more, but memory (and pixels, even with 10 monitors side-by-side) is limited.  To keep "everything", stream to disk and look at "selected pieces".

 

Bob Schor 

Message 3 of 11
(377 Views)
Solution
Accepted by topic author Marcschäfer59964

Seconded. Could be a lot of issues originating from trying to do too much in the context of a single vi, that thing is massive (yes, I opened it and there were a lot of blanked out .vi's).

 

Back to the original topic, I frequently find myself using a lossy queue of fixed size wired to a waveform graph rather than blasting data into a waveform chart. This potentially allows me to down-sample enough to prevent screen updates when the pixels aren't changing in a way that's meaningful (e.g. I have a really high sample rate channel but a limited number of pixels to display it on at 50hz queue update rate). As a thought experiment, suppose you want to display 1 hour of data sampled at 2khz on a 1080p screen in an X-Y chart. You have 1980 pixels to cover 7.2 million data points, it doesn't make sense to draw them all, some amount of down sampling is judicious.

 

edit: to add timing data: In my opinion, this should be inherent from your acquisition method. Use an analog daqmx read analog multiple channels, multiple samples, by waveform, and then stream that (via queue or some other mechanism) to a .tdms file. You can easily achieve very high read rates (kHz range for non-simultaneous mechanical things - my domain - and likely mHz or gHz if using simultaneous/RF acquisition devices) if you manage the hardware buffer correctly.

 

-AO

Message 4 of 11
(361 Views)
Solution
Accepted by topic author Marcschäfer59964

Hello,
to explain my code,
I work together with a Siemens PLC (S7-1500) and the program SP7. There are a total of 6 stations where the measurement data is recorded digitally. LabView is only used for a rough overview and for operation.
To the many under VI's. The data from the 6 stations is collected in these and transferred to the PLC using SP7. This also works without any problems. I would just like the waveform chart to show me seconds and not interfere with the buttons.

 

0 Kudos
Message 5 of 11
(345 Views)
Solution
Accepted by topic author Marcschäfer59964

Hi Marc,

 

please downconvert the VI for LV2019 (as asked before)…

 


@Marcschäfer59964 wrote:

To the many under VI's. The data from the 6 stations is collected in these and transferred to the PLC using SP7. This also works without any problems. I would just like the waveform chart to show me seconds and not interfere with the buttons.


There's only one VI with your first message…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 6 of 11
(341 Views)
Solution
Accepted by topic author Marcschäfer59964

Hi Marc,

 

I downconverted your VI to LV2019.

Beside your VI showing the naive approach by just duplicating code and having no structure, your problem could be caused by Offset and Multiplier of the X-Axis of your charts. You put 1/Frequency of your data into Multiplier and the X-Axis should show the right time scale. Since I don't have a german LV, I show the appropriate Properties- Tab on my LV:

 

Graph-Axis Props 2.png

 

 

Greets, Dave
Message 7 of 11
(326 Views)
Solution
Accepted by topic author Marcschäfer59964

Hi Marc,

 

thanks to Dave I could look at the block diagram of your VI…

 

Why are there loops set to run forever?

Why are there loops set to run just once? (And no, these aren't any "functional globals", so they are senseless!)

 

As you poll all the controls your timed loop will interfere with UX as it introduces a lag of 1000ms to the execution of the "Messplatz 1" loop! It's all in the "THINK DATAFLOW!" mantra of LabVIEW…

 

Suggestions:

  • Learn LabVIEW basics, like using arrays and clusters… (When learning about clusters you should also learn about type definitions!)
  • Learn LabVIEW basics, like using loops instead of duplicating code…
  • As you seem to handle identical testbenches: why not use just ONE (1) display for all of them and just switch between different benches by showing their data in ONE interface?
  • There are way too many frontpanel elements (and several spelling errors in the labels…)

I hope you use some kind of SCC tool - the names of those subVIs seem to indicate you are using a timestamp in the name to differ between versions…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 8 of 11
(320 Views)
Solution
Accepted by topic author Marcschäfer59964

I agree that your chart problem is just the tip of the iceberg. This code is not maintainable.

 

Silly loops, nests of over overlapping scalar wires going in an out of subVIs (that we don't have) in all directions, a block diagram that fills 25 screens, etc. etc. None of this is something I am willing to troubleshoot.

 

Way too much code stench.

 

 

altenbach_0-1752750778608.png

 

Message 9 of 11
(310 Views)
Solution
Accepted by topic author Marcschäfer59964

That code is out of control on so many levels. (facepalm) 

 

You need to use sub-vi's instead of making a block diagram so huge it take a wall of monitors to see the whole thing.

 

 

========================
=== Engineer Ambiguously ===
========================
Message 10 of 11
(286 Views)