Waveform chart x-axis range

[df_rob]

Hi everyone,

 

I'm having some problems with my waveform charts, I dont quite understand how the below code isnt working (see screenshot). It just flickers... any ideas? The intention of the code is to programatically show the last t seconds worth of data when sampling continously at 1 kHz. Where t is some value defined by the user, however in the screenshot t is a constant set to 10.

 

Thanks for your time!

 

Edited July 7, 2015 by df_rob

[ShaunR]

Hi everyone,

 

I'm having some problems with my waveform charts, I dont quite understand how the below code isnt working (see screenshot). It just flickers... any ideas? The intention of the code is to programatically show the last t seconds worth of data when sampling continously at 1 kHz. Where t is some value defined by the user, however in the screenshot t is a constant set to 10.

 

Thanks for your time!

 

 

 

Have you turned off auto-scaling?

[ensegre]

Can your display and your eye keep up with updating 1000 times per second a graph with one point? Wouldn't it be more sensible and less cpu & gpu intensive, not to mention timing exact, to update it 5 times per second with 200 new points?

 

Remember that also Chart History Length gets in the way. Default is 1024 which is much less than 10sec * 1000Hz.

 

Ah now that I think, for a waveform chart you don't even need to bother setting dynamically x axis limits. Update mode Strip chart does it.

Edited July 7, 2015 by ensegre

[hooovahh]

Okay you set up your hardware to sample at 1Khz, but then you choose to read it one sample at a time, so you hope to read a sample every ms.  But you also need to do some thread swapping because every iteration you are using property nodes.  Wouldn't it be better to say read n values at once, then wait however long you want, and read how every many samples there are to read?  Change polymorphic type to one channel N samples.

 

You're going to want to use a waveform graph as well, and keep the history your self.  After you read N samples append them to the previous samples, then if the array size is too large, containing too much time, use array subeset to get the last N samples.

[df_rob]

Have you turned off auto-scaling?

 

Thanks, for the reply. It was off, but I have changed a fair bit now in response to the below posts.

 

Can your display and your eye keep up with updating 1000 times per second a graph with one point? Wouldn't it be more sensible and less cpu & gpu intensive, not to mention timing exact, to update it 5 times per second with 200 new points?

 

Remember that also Chart History Length gets in the way. Default is 1024 which is much less than 10sec * 1000Hz.

 

Ah now that I think, for a waveform chart you don't even need to bother setting dynamically x axis limits. Update mode Strip chart does it.

 

 

Okay you set up your hardware to sample at 1Khz, but then you choose to read it one sample at a time, so you hope to read a sample every ms.  But you also need to do some thread swapping because every iteration you are using property nodes.  Wouldn't it be better to say read n values at once, then wait however long you want, and read how every many samples there are to read?  Change polymorphic type to one channel N samples.

 

You're going to want to use a waveform graph as well, and keep the history your self.  After you read N samples append them to the previous samples, then if the array size is too large, containing too much time, use array subeset to get the last N samples.

 

Thanks for the feedback, I believe I have made the recommended changes:

 

Edited July 8, 2015 by df_rob

[df_rob]

Using what you guys recommended I think this is now solved! Thanks a lot, I appreciate the help. It seems the flickering I was getting was also due to the chart history length being to small!

 

Edited July 8, 2015 by df_rob

[ensegre]

I think you can (in fact probably you might be better to) skip the AvailSampPerChan, and just read a suitable fixed number of points. The way I understand continuous DAQ works, is that data is acquired into a ringbuffer internal to the DAQ device at it's own pace, and the DAQ driver cares for transferring enough data to the computer memory as long as the ringbuffer is half full/ there is enough data/ etc. Asking the DAQ to give all its available data just now leads you to interrogate the daq at a rate dictated by the time it took to plot the previous chunk, not at a rate determined by real display need or load balance. I suspect that if you would monitor the number of points which you're getting at each iteration and the time for it, you'd discover that you're ending up still asking too frequently few points at a time, with 100% cpu load.

 

ETA: I missed the Wait 100ms block. However, a fixed number of read points has the same effect, actually better since it is deterministic and dictated by the daq clock, not dependent on whether the GUI thread is delayed by concurrent processes. [Ascertaining, that the time needed for plotting these points is in average shorter than that for acquiring them]

Edited July 8, 2015 by ensegre

[hooovahh]

Glad you found a solution.  In the future post your code not pictures of your code.  Things like history length on a chart is real easy to check when you have source code, but impossible to know from a picture.