Drawing unvarying value in an easy Chart

Greetings,

I’m not sure if it has to be posted in “Problems” or in “Feature requests”.

I’ve noticed that the pen in a chart is not drawn if the value is not varying. I don’t think that it is a configuration problem as it works perfectly with varying value.

Here are the history parameters of my tags (Capture).

Have you ever heard of such symptoms ?

Hi,

This can be caused by a number of things, but I imagine it’s probably not correct.

Probably the easiest way to get an idea of why it’s not showing up would be to do the following:

  1. In the gateway, go to Console>Levels, search for “History”, and turn “History.SQLTags” to Trace. This will turn on everything below it, as well.
  2. In the client/designer, go to Help>Diagnostics, and click the “clear tag history cache” button.
  3. Refresh your chart (change the range or something).
  4. Go turn off the logger, so that you don’t fill up the log with extra stuff.
  5. Copy/paste the results here, or put them in a text file and attach it.

I suspect that it must think that your data is “stale”. The trace logs will hopefully show why. Perhaps it’s accurate, if undesirable, or perhaps something has gone wrong.

Also, I assume you’re using 7.5.2. If not, let me know the exact version.

Regards,

Here is the file containing the logs.

Could you please explain “stale” ? Is is about OPC Quality ?
Ma data quality is good and when we receive a merely varying value, we can see that the chart is drawing. That’s why I think that the data doesn’t go to historian if the value doesn’t change.

My version is : 7.4.4 (b1017).
logs.bin.gz (824 KB)

Hi,

There are various queries in that log, but only one showed stale data. The others showed that only tag, “sites/pramorel/niveau/hvalue”, should have not shown, because its quality really was bad.

The stale quality mostly comes from the scan class execution validation. There is a table maintained of scan class execution windows, so that we can detect when the system was not actually running, and mark data as “stale”. But perhaps gaps in this table are causing your values to show as stale, as in the one query, each block was covering a lot of time (1 day range, but only 23 points? Is that right?)

The scan class records are contained in the “sqlth_sce” table. If you want, you can back that table up, then delete the contents, wait for rows to be inserted for each scan class, and then run a query to update the “start_time” to 0, so that each scan class has a record that covers from 0 to now. You then should not get “stale” reported.

Let me know if this helps.

Regards,

Hi,

Thank you for your reply.
I’ve made the delete/update on the SQL table sqlth_sce but it didn’t change anything.

I’ll try to explain better the way we get the data from our PLC.
In fact, we only retreive the data once a day. The PLC acquire the values and store them every quarter (15 min). We then contact the PLC (by phone) in order to retreive all the data (data = value + timestamp).
Then every couple of Value + Timestamp is sent to the Gateway at the rate of one value+tstamp per second, which stores it in database.
The problem is that in the case where, for a given timestamp, the value is equal to the one in the previous timestamp, the data is not stored in database.

For example :
tstamp Value Action
08:00:00 1,23 Value stored in database
08:15:00 1,23 Value NOT stored in database case it’s the same than the previous one
08:30:00 1,24 Value stored in database (different from the previous one)

The value of 08:15:00 should be stored in database as it is a known an valid value. But it is not…

I’ve another PLC using the same chart and datatype but with a varying value and I have absolutely no problem with the storage and the chart.

Hi,

Yes, I see, the real problem is that a change in the timestamp is not causing a new value to store. There isn’t exactly a good way to handle this right now- setting the max age to 1 will likely cause database errors because the timestamp is coming from the OPC item, and may not change (and values are keyed off of path and timestamp).

Instead, the solution is probably that when the deadband is 0, it will only log when a different value comes in, including if only the timestamp changes. Does this sound correct?

Regards,

[quote=“Colby.Clegg”]
Instead, the solution is probably that when the deadband is 0, it will only log when a different value comes in, including if only the timestamp changes. Does this sound correct?
Regards,[/quote]

Yes that is correct. The value has to be stored even if only the timestamp changes because the couple ‘New timestamp/Same Value’ is a new valid history point.

Regards.

Hi,

This has been changed for 7.5.4 beta 1. I hope it will go up tomorrow, so please give it a try and let me know how it goes. Again, for this to work, the Historical Deadband should be set to 0. In that case, it will log if the quality or timestamp changes (and of course, the value).

Regards,