Leaderboard

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.

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]

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.

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.

Can't wait for one of the most entertaining events of NIWeek. The LabVIEW Tools Network team will again be donating a brand-new myRIO for the Door Prize again this year. <Trippy, plasma app tornado not included>

I'm using git, and because of its decentralized nature, there is no one incrementing commit number that I could put into the "build number" field. What I decided to do instead is: Create a tag in the VCS (which is just a named pointer to a commit) which is following the semver notation If building a Windows applicationWrite the tag info into the major / minor / patch fields of the build spec Write the build timestamp into the description field of the build spec If building a source distributionAppend tag label and build timestamp to each VI's description (so it shows up in context help) Automatically create a readme file that is distributed together with the built package (.zip in my case) that shows project name, version info, changelog (all commit messages since last tag) etc. After playing around with pre-build VIs for some time, I decided that I wanted more of a continuous integration type of tool / process, so I started automating the whole build process (I wrote about that here, amongst other places). Executing a build specification has always the purpose of releasing an application or source distribution. So I made the creation of the tag in the VCS the starting point of my build process (my gitlab repository will then trigger a Jenkins task on my local build server, but manually invoking the build tool does just the same). The build tool will first check the working copy for changes (or rather, the absence of any), then run some VI analyzer tests, read the tag name associated to the latest commit, update the build spec fields and/or VI descriptions, create the readme file, execute the build spec, create the release package (.zip), and copy that package to a local directory which is synchronized with my web server. I run Dokuwiki and created a plugin that uses the gitlab API to read all tag labels for a given repository, and then automatically displays all available files for that tag label as download links.