Intensity Chart X scale flip = image drift

[ceties]

Hi all! When programming one application for measurement I encountered following problem. Because scanning in this measurement is performed at first from left to right and then immediately from right to left I write the data to intensity chart and when the end of scanning region is reached I flip the x axis and I write the chart history data into history of the chart but in reversed order . This creates the effect of preserving the image as it was during previous scan (only flipping itself without writing the reverse history would also cause flip of the already drew image).

All seems to work smoothly but if you run it you see small drifting of the image when reaching the edges. On the right the image drifts to the left a bit and on the left to the right.

What does it cause?
Thx a lot.

[GerdW]

Hi ceties,

sorry, I couldn't watch any "drift" in the intensity chart (using LV8.5)...

I also switched on autoscale for y and z axis to see something at least. But the x axis flippedjust nicely without any "drift" in the graph.

[altenbach]

I don't quite understand what you mean by "drift", but using an intensity chart for this seems incorrect.

Use an "intensity graph" and work on a fixed-size 2D array, replacing rows as you go. Whenever you reach the end, modify offset and multiplier to keep track if the time axis if so desired.

Attached is a quick rewrite (LabVIEW 8.5.1). See if this works for you.

This is only a rough draft. Most likely, you need to tweak a few things further but this should give you a start.

[altenbach]

And if you want to show the current "insert point", use a vertical cursor. Here's a quick example (LabVIEW 8.5.1):

[ceties]

Thx both of you for your time. Maybe better word than drift would be 'shift'. Just choose some point on the chart and stare at it before the axis flips and you have to see it. It's really tiny but visible and annoying.

2Altenbach: thx for your example. I have in the beginning used your approach but there is crucial difference between this approach and the one I use and it is computation power demands. At my 2Ghz dualcore my way takes around 2% and yours between 20% to 50%. What makes the difference is that you are always redrawing the graph with whole array which needs power. And imagine that the array has 2000rows instead of 70 and there should be much more processing than only displaying it.

[altenbach]

---

ceties wrote:
Thx both of you for your time. Maybe better word than drift would be 'shift'. Just choose some point on the chart and stare at it before the axis flips and you have to see it. It's really tiny but visible and annoying.

---

Yes, now I see it. I would file a bug report.

---

ceties wrote:

2Altenbach: thx for your example. I have in the beginning used your approach but there is crucial difference between this approach and the one I use and it is computation power demands. At my 2Ghz dualcore my way takes around 2% and yours between 20% to 50%. What makes the difference is that you are always redrawing the graph with whole array which needs power. And imagine that the array has 2000rows instead of 70 and there should be much more processing than only displaying it.

---

Currently, if I take out the delay and measure the average loop rate, I get the following times.

Yours: 140 microseconds

Mine (no cursor): 240 microseconds 

Mine (with cursor): 36000 microseconds (36ms. As expected, because of the synchronous property node call at each iteration)

What kind of loop rate are you using that gives you 20%-50% CPU?

As an alternative, you might want to adapt a picture indicator to display your data.

[ceties]

Hi and thanks again.

Now I realized why Gerd didn't see anything - When testing different datasets I forgot to switch the 'transpose' to false. So please do it and then you will clearly see the shift - maybe focus on the white part in the middle of the picture.

 

I am sorry for that inconvenient.

For the same reason Altenbach we had totally different results of power consumption. The original data has 8001 dbls for one vector(not 100) which in your example results in really high CPU usage(around those 50%)

My measurement with correct data (reading vi excluded, no delays):

Mine: 60-70ms

Yours without cursor: 1200ms

Yours with cursor: 9200ms

I am still trying to come with some logical explanation for the shifting because using the picture control seems to bring a lots of work and troubles

Message Edited by ceties on 08-24-2008 05:29 AM