update picture slows down

[tails]

I am using exactly this, in LV 2010, but I have one little problem.

If you don't wire the previous picture as an input, then you cannot use the draw line function - you can only draw a point.

It seems the draw-line requires a start-point, which is stored as part of the picture variable, and (from what I can see), the vi only takes in the end-point.

so if I don't wire a the picture control at the input, then it automatically uses 0,0 as the line start-point.

If I DO wire the input, draw-line now works, but the original situation where the vi slows down as it keeps adding data occurs.

Outside of creating my own sub-vi to implement a line-drawing algorithm by using points, is there any other solution?

[altenbach]

You can use "draw multiline" or similar...

[RavensFan]

This seems like a new problem, so it would be better to start a new thread then to add onto a 4 year old thread.

Plus attach your VI so we can see what you are doing.  I suspect that somehow you are not using the Draw Line function properly.

[tails]

Sorry for resurrecting the old thread - as it was apprpriate to what I found, I thought it an Ok thing to do.

I beleive the draw multi-line idea is a good one (thoguh it will still be interesting to see if the first start point is assumed to be the 0,0 point.

If I make progress on this I will post the results.

Note: the application is as follows - a uart is sending x-y coordinates back to the vi. These coordinates are intended to be plotted in real-time. 

The initial solution as just plotting points, but the make the output look continuous, you need a LOT of points for real-time plotting, and updating the picture control at 100's of fps is probably not possible.

so the next idea was to use fewer points, a slower update rate, and join the points with a line.

The vi is currently part of a larger application, some of which is propriterary. If I get a chance to break out the part of interest as a test-case (and one which does not require the uart code, as that would not be very portable for others to run!), I will post it for sure. I'll start a new thread then too, and post a link here, so this thread can stay buried.

[altenbach]

To draw a random line, use "move pen" followed by "draw line".

[tails]

I tried that, but move pen updates the 'local pen position' in the picture variable. - but - this only gets used if you wire the picrure control variable to the input fo the draw line vi. When you do this, it causes the problem the OP talked about - labview is forced to re-draw the whole picture and generate a new output, instead of just updating the existing output. 

So any action that involves connecting the picture control to the input of the draw line vi is a non runner, as far as I can see.

[altenbach]

(Sorry, my last two messages were posted via phone, so I kept it short.)

---

@tails wrote:

I tried that, but move pen updates the 'local pen position' in the picture variable. - but - this only gets used if you wire the picrure control variable to the input fo the draw line vi. When you do this, it causes the problem the OP talked about - labview is forced to re-draw the whole picture and generate a new output, instead of just updating the existing output. 

So any action that involves connecting the picture control to the input of the draw line vi is a non runner, as far as I can see.

---

As long as you don't wire an input to "move pen", the subsequent "draw line" would be very lightweight. I still don't see your problem.

We really need to see some code to understand what your problem is here.

You might also want to read this little gem. 😄