LabVIEW
XY Graph scale increments changing arbitrarily
Solved!
Yes, there is definitely a bug here (tested in LabVIEW 2012 and 2013). (reported here)
I eliminated all that extra baggage (e.g. also writing to the minor increments, etc.)
I was able to eliminate the problem for the Y scale, but the x-scale still showed the problem. However, I found that if you write the increment, then read it out in the same property node, the problem does not occur. Even if I now remove that new read property again, the problem is fixed. Go figure. 😮
Attached are two simplified versions of the VI. (1) demonstrates the problem clearly.
- Disobeying_Graph_ScalesMODCA1.vi
- Disobeying_Graph_ScalesMODCA2.vi
(1) sets the X-increment once outside the loop (it should never change anyway!), but checks the increment after each write in the loop. The Loop terminates early because the x-increment suddenly changes for no good reason at all.
To demonstrate the problem, run it several times. It will alternately stop at iteration 0 or 7 instead of completing the FOR loop normally.
(2) Set everything inside the loop, and read out the increment. Now everything works correctly.
@camerond wrote:
Now, there's something you have in your VI that I didn't know about. If you set up a "Value" (write to) property node to your graph, then wire your X and Y data to it, it updates your graph itself, IIUC. Cool. This looks like it should make a bunch of things doable (or at least more readable on the BD) than I had thought possible.
I was doing that mostly to play with execution order. Property nodes execute top to bottom, so instead of using complicated sequence structures for testing as proposed by others here, you can write the value at the beginning or the end of the property node. (Turns out that it does not make a difference for this bug.).
One thing to remember is that property nodes execute synchronously and (if performance matters) writing to the terminal is orders of magnitude more efficient (in this case it is microseconds vs. milliseconds). However here you are writing to a property node anyway so it does not really add that much. I typically place property nodes inside a case structure and call them only if the inputs actually change.
Writing to a value property node is also less convenient at edit time, because it does not automatically adapt to the datatype. XY graphs take a variety of datatypes (I typically prefer complex arrays), but if you change the type wired to the value property node, you get a broken wire until you also temporarily wire the same new datatype to the xy graph terminal directly.
Also note that in this particular example the x-axis is spaced equally and all you need is a plain waveform graph with the correct x0 and dx. (See also this comment). Simpler code!
Issue still present in LV2018. Altenbach's workaround works, just read the property in the same node.
@pogo wrote:
I'm also currently using LV 2018.
Altenbach's solution did not work for me...
Well, it turned out that it didn't work well enough for me. I still had issues with the scale sometimes. Doing the trick several times made it better. I ended up having to do the trick in the timeout loop of an event structure since there was no event to trigger on where the trick worked well enough. It looks bad that the scale flickers but it was acceptable.
