LabVIEW
How to zoom in X-axis of a XY graph
Solved!
@edmonton wrote:
Attached is a sample VI for troubleshooting purpose only.
While it's only a sample VI, you have some serious code issues and race conditions. Hopefully these don't exist in your actual code.
For example in the lower right loop, the property node gets read as soon as the loop start, so if you move the cursors and press "data selection", you'll operate on the stale cursor positions.
Similarly, the upper right loop ("greedy" for no reason!) could be done significantly simpler using an array of offsets and autoindexing. You already have the transposed array, so use that. No case structure needed. ("array subset" is convoluted to get a column, "index array" is correct.). Etc.)
Hi Dr Altenbach,
Thank you for your prompt reply. I do not know why the upper-left option does not work on my computer, it only works to zoom in Y as selected, leaving the X unchanged.
Attached is a screen shot of zooming in a area of X:0-8, Y:0-100000, the Y changed as wanted, however, the X is still in its original range 0-16.
The upper right loop, the plot loop, is for shifting/offsetting each curve separately on X axis as needed, each curve requires a different offset value depending on their real data situation. I wanted to make it simple, but could not make it.
Yes, there might be a race condition between the loops. It can run smooth, but uses CPU at almost 100% after the first data selection operation of the lower property node loop. I am also looking for a solution to avoid CPU usage at such a high %. both the upper and the lower loops have interactive operation. Ideally, the operation should be XY plot, zoom in, curve shift, cursor move and data selection. Could you please advise how to make the code a better fit?
Best regards,
Gu
Maybe you want to turn off auto-scaling for the x-axis? Your loop spins millions of times per second, so auto-scaling will take over immediately undoing the x-zooming.
The race condition is not between loops, but in the loop with the event structure. As I said, the property node gets read right away, so when the event fires, you display the cursor values from the previous iteration. You need to press the button at least twice after moving the cursors to get expected values..
If you would place a small wait in the upper right loop, the CPU usage would drop to near zero. No need to heat the room with the CPU. 😮
Here's basically a literal rewrite of your code with simpler data structure (note that the architecture is NOT good, it just shows some typical techniques. Code that just runs downhill and can never return to a previous loop in not reasonable!).
Recommendation: Still, you should not need all these parallel loops. All you really need is a simple state machine that can start/stop acquisition, change the offsets, and read the cursors all in one loop. Try it!
@edmonton wrote:By the way, how to make the indicators small as you did in block diagram? I alway get big boxes.
"right-click terminal...view as icon" (checked or unchecked)
(You can turn it off permanently for all new terminals in "tools...options..block diagram...place front terminals as icons...uncheck")
