03-26-2010 12:50 PM
Ben I am perhaps in need another "jiggle the handle" solution. I tried writing to a few different property nodes for a WFChart that is "acting a-fool" with no results. Each update mode seems to have its own problems. Specifically, in sweep mode (or is it scope? I forgot immediately after the CLAD) there sometimes appears a second refresh cursor when the x-axis scale is changed, sections of vertical-horizontal lines on the chart come and go as the cursor passes or the front panel is scrolled, the waveform itself clears when the cursor reached the end of the plot area and acts like scope and then returns to sweep sometime later or the waveform itself is thick (as it is set to be) but then is very thin is some sections. In scroll mode when DAQ begins a few samples of data show up on the far end of the plot before beginning normal left-to-write plotting.
I have found some previous posts about video cards in laptops not being sufficient but the posts were pretty old, and it happens on a good desktop too.
Any suggestions? I am considering using a graph, its pretty slow acquisition and I figure there wouldn't be too much of a performance hit. No?
You gurus rock!
Greg
P.S. - My brother (a plumber) really appreciated your plumbing story with the power auger.
03-26-2010 01:06 PM
Can you post a simplified example that duplicates that behaviour?
It looks a lot like what we were talking about in the "What makes chart go wonky" thread. NI reported a CAR but it has been hard geeting examples they can use to enusre they fixed it.
so can you post a simple demo?
Ben
03-26-2010 02:49 PM
Absolutely. I have 2 that I will try to simplify. The other VI crashes when the chart x-axis scroll bar is visible, and does not crash when the scroll bar is not visible. Needless to say, that one was tough to debug.
This will take a little time...
Greg
06-18-2025 06:12 AM
Hey Ben and all,
Just wanted to chime in because I’ve seen something very similar in one of our older LabVIEW setups when using WFCharts in sweep mode. The chart would behave erratically especially with redraws like flickering lines, disappearing plots, and inconsistent cursor behavior. At first, I thought it was a GPU issue too, but after testing on different machines (including a high-spec desktop), it persisted.
One thing that helped in our case was switching to a waveform graph instead of a chart. Since we were working with relatively slow acquisition rates (~2–3 Hz), updating the entire buffer on each acquisition didn’t cause any noticeable lag, and it completely eliminated the weird rendering issues. The trade-off, of course, is losing that built-in scrolling behavior but for us, the consistency was worth it.
Also, for anyone working on embedded or property-heavy UIs and facing redraw/refresh issues, don’t underestimate layout complexity. We once had a situation where a third-party UI element caused redraw conflicts. In that case, we brought in a handyman-style solution not literally, but someone outside our dev team who approached the issue with a practical eye and found a conflict with hidden controls being updated behind the scenes. Weird fix, but it worked.
Here’s hoping NI follows through on that CAR. In the meantime, simplifying the VI or switching to a waveform graph might be your best bet if performance isn’t a big constraint.
Looking forward to seeing your example VIs!