Databrowser oddities

[berryma4]

Below, note that in probe the value is -85.00 (correct), but Databrowser shows 0.

This was just odd:

[kasemir]

Are your time stamps causing this?

On Wed, Jul 3, 2013 at 11:58 AM, Eric Berryman notifications@github.comwrote:

[image: databrowser1]https://f.cloud.github.com/assets/854021/744274/4e8bed44-e3f9-11e2-803e-c22cfe984f0e.png

[image: databrowser2]https://f.cloud.github.com/assets/854021/744280/6766e990-e3f9-11e2-816c-9bbea8e7d8ae.png

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/75
.

[berryma4]

After restarting cs-studio everything looked fine (This is from one of my
users).

Thank you!
On Jul 3, 2013 7:28 PM, "kasemir" notifications@github.com wrote:

Are your time stamps causing this?

On Wed, Jul 3, 2013 at 11:58 AM, Eric Berryman notifications@github.comwrote:

[image: databrowser1]<
https://f.cloud.github.com/assets/854021/744274/4e8bed44-e3f9-11e2-803e-c22cfe984f0e.png>

[image: databrowser2]<
https://f.cloud.github.com/assets/854021/744280/6766e990-e3f9-11e2-816c-9bbea8e7d8ae.png>

—
Reply to this email directly or view it on GitHub<
https://github.com/ControlSystemStudio/cs-studio/issues/75>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/75#issuecomment-20451443
.

[kasemir]

Could still be a time stamp issue, in the live samples.
On restart, it gets archived data for that time range.
Next time, check the "inspect samples" view for the time stamps of the strange region in the plot.
Or "export" with data source = plot.

On Jul 4, 2013, at 8:42, Eric Berryman notifications@github.com wrote:

After restarting cs-studio everything looked fine (This is from one of my
users).

Thank you!
On Jul 3, 2013 7:28 PM, "kasemir" notifications@github.com wrote:

Are your time stamps causing this?

On Wed, Jul 3, 2013 at 11:58 AM, Eric Berryman notifications@github.comwrote:

[image: databrowser1]<
https://f.cloud.github.com/assets/854021/744274/4e8bed44-e3f9-11e2-803e-c22cfe984f0e.png>

[image: databrowser2]<
https://f.cloud.github.com/assets/854021/744280/6766e990-e3f9-11e2-816c-9bbea8e7d8ae.png>

—
Reply to this email directly or view it on GitHub<
https://github.com/ControlSystemStudio/cs-studio/issues/75>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/75#issuecomment-20451443
.

—
Reply to this email directly or view it on GitHub.

[berryma4]

In the first image, you can see the timestamp in probe, it's correct.

In the second image, (again by looking at the probe timestamp for current time), you can see that all data should be coming from the archiver in this situation (it's last month). On restart this went away.

[berryma4]

moving to milestone 3.2.9

[berryma4]

I am watching one of the A1900 dipole magnets, and when I came back from lunch, this is what I saw: The set value (pale blue) was set to 80 A, while the read value (dark blue) showed only 40 A, up to 12:32, when it jumped to 80 A. It looked like CSS had updated the values, but this read value persisted even when I changed the time scale from 30 minutes to 31 minutes (see first screen shot).

I then changed the time scale to 1 h 31 min and it read the value properly (second screenshot).

I am running version 3.2.6.201306010008

[kasemir]

I cannot tell what is live and what is historic data.
Try to look at the sample detail view.
What could have happened is that you were looking at live data, the I've data buffer was too short, so you had old archived data, then a gap, then the last N samples of live data.
Inside that gap would have been the jump from 40 to 80.
Once you change the time scale, it gets archived data for start of plot ... start of buffered live data, so now there is no gap and you see the 40 to 80 jump as it happened.

[shroffk]

Moving to milestone 3.2.10

[berryma4]

Moving to milestone 3.2.11

[berryma4]

Moving to 3.2.12

[berryma4]

What happened to the third dip in Z048DS-V voltage (orange around 11:51:00)?
And why does Z048DS current (dark blue around 11:51:00) look different too?

[kasemir]

Regarding the orange line, it's related to the gap between the last sample we got from the archive, which by now has scrolled out of the "left" edge of your plot, and the live data buffer.
The default buffer size for that is 5000 samples, see "Buffer Size" in the "Traces" tab.
Your screen covers about 30 minutes. Maybe your channel produces about 5000 new values in 15 minutes (5 updates/sec), so the "live" trace can only hold about half of the display?

If you want the scrolling display to always fill the screen, your buffer size must be big enough to hold all expected samples for the displayed plot period.

If you trigger a re-fetch of archived data (zoom in/out a tiny bit), you'll get archived data and again have a complete line, but typically the archived data is not written as frequently as the live updates, so the plot is more coarse.

Not sure what to do about this.

Just grow the live data buffer until you run out of memory?
-> You would run out of memory sooner or later, so not good.

Re-fetch archived data whenever we notice that the previously fetched archived data has "scrolled out of the window", and there's now a gap from start of window … end of live data buffer?
-> Can't re-fetch archived data all the time, it's slow enough as it is.

[berryma4]

Maybe this is an archiver issue then ... the ADEL is .1, that should be a
better resolution. I'll check the actual samples.

On Wed, Feb 5, 2014 at 1:23 PM, kasemir notifications@github.com wrote:

Regarding the orange line, it's related to the gap between the last sample
we got from the archive, which by now has scrolled out of the "left" edge
of your plot, and the live data buffer.
The default buffer size for that is 5000 samples, see "Buffer Size" in the
"Traces" tab.
Your screen covers about 30 minutes. Maybe your channel produces about
5000 new values in 15 minutes (5 updates/sec), so the "live" trace can only
hold about half of the display?

If you want the scrolling display to always fill the screen, your buffer
size must be big enough to hold all expected samples for the displayed plot
period.

If you trigger a re-fetch of archived data (zoom in/out a tiny bit),
you'll get archived data and again have a complete line, but typically the
archived data is not written as frequently as the live updates, so the plot
is more coarse.

Not sure what to do about this.

Just grow the live data buffer until you run out of memory?
-> You would run out of memory sooner or later, so not good.

Re-fetch archived data whenever we notice that the previously fetched
archived data has "scrolled out of the window", and there's now a gap from
start of window ... end of live data buffer?
-> Can't re-fetch archived data all the time, it's slow enough as it is.

Reply to this email directly or view it on GitHubhttps://github.com//issues/75#issuecomment-34220391
.

[berryma4]

I'm able to re-create this. There seems to be an issue that as archive data takes over from live data, sometimes it doesn't. A right click refresh on the graph fixes the issue.