Image on shift register slowing down the program

[Ben]

Dave's suggestion to over-writ ethe previous point can also be applied for the changing coordinates. Redraw the area with the numbers with the background color and then instert the new test on top of that.

Ben

[mam1nej]

What I had in mind was something line the current beam position in a large circle ( like the on in the center ) and the previous positions with small black dots.

The was I was making the current position float without leaving a 'print' on the circle was by allowing the picture to erase first, then draw a new circle.

I also realized that the program is still getting very slow even with Dave's suggestion. I got rid of the shift register and removed the erase first option ont he picture box, now after about 30 min of operation, the program runs very slow.

[daveTW]

How many points do you have after 30 mins?

[mam1nej]

My refresh rate is pretty high, every 10 ms. so after 30 min, I would probably have 180K points.

This shouldn't matter, correct ? if the image does not carry the draw point commands anymore ( after removing the shift register and disabling the erase first )

The reality is, my end goal is to keep track at not only the laser beam position, but the power at wich the beam moved to that position, through the pixel color. The beam will change position as result of some factors, that I am going to incode through different colors.

You are certainly thinking that I should never have a short refresh rate when my window of observation is 30min. and you are certainly correct, I can easily change that. but I still don't understand why is the program getting slower when it shouldn't..

[Ben]

Post a representative version of your code (backsaved to 2015) for us to look at.

10ms between uptes is silly. The PC screen will only update at 30fps and the human eye can not see quicker updates. I would throtle the update rate and present multiple points less often.

You may be running into issues with the GUi update rate. In those cases, user the FP property

DeferFPUpdat = T

TO defer FP updates

Prior to revising the image

and then sett that property fale after the update may help.

Just speculating and sharing what I can ...

Ben

[daveTW · Accepted solution]

This is a good point. To get a feeling about the performance of the picture indicator (which is the limiting element) I made a VI to measure performance:

This VI plots dots inside a circle. For timing reasons it is necessary to set the picture indicator to Synchronous Display. With this I see, that with around 6000 dots the loop has a delay of 10 ms, this is your cycle time. In the length- indicator you can see that the amount of data (drawing instructions) is constantly increasing.

My idea of limiting this is to repeatedly convert this drawing-instruction-data into a raster image and draw new dots onto this rasterized history data:

This shows, that the data is around 700kB, but not increasing anymore and the cycle time keeps stable at around 3 ms.

[Hooovahh]

Your time measuring code is flawed.  Controls are updated asynchronously, so writing to a terminal can take a varying amount of time.  Basically this means all control terminals should not be read or written to in your sequence structure.  Also you may want to turn off debugging, and automatic error handling if you haven't already for more consistent readings.  As others have said the picture datatype is more or less just a string data type.  And what you are doing with the shift register is making a larger and larger string,  that is unbound.  As a result you'll run out of memory or have performance issues at some point. Here is a thread I made a while ago asking about how to handle this in my situation.  And here is another thread that my thread links to which talks about the issue a bit more.

[daveTW]

Hello Hoovah,

that's why I switched on the Synchronous Display of the picture indicator. This ensures that the frame isn't finished before the picture terminates drawing actions. I think, this is quite reasonable.

Btw. the speed is increased, when the "smooth updates" setting is switched on. I forgot to mention this before.

[Hooovahh]

---

@daveTW wrote:

Hello Hoovah,

that's why I switched on the Synchronous Display of the picture indicator.

---

The Length indicator and # of points are being written to at times that the timer is going on as well.  These are pretty minor and probably don't effect your result but for best timing results I'd recommend not writing to these indicators until after the last timer is taken, or before the first one is taken, with data flow to force the appropriate order.

[altenbach]

It is often a very bad idea to build a picture in a shift register. An old discussion can be found here.

Personally, I would use a simple 2D U8 array and keep it in a shift register without ever changing the size. Display it in an intensity graph resized for the correct number of pixels. For each new dot, you would just replace an existing element with a new value.

This way you could even  implement a fading. subtract 1 from the 2D array and replace the newest beam with 255. Now the older beam position are dimmer proportional to their age.