Hi,
I try to show some related boolean events in a table so I use As stored tag history binding as shown below but I get multiple rows with the same timestamp.
Why do we this some behaviour?
Is there any workaround to force ignition historian merge values in a single row for the same timestamp?
Not sure how this is possible since the timestamp is part of the key, at least I thought it was.
Yes really strange and annoying
I’m assuming that probably the problem is in how you are converting the Unix time to human readable.
Did you add a transform after the shown binding?
If you did for some reason, you should use system.date.fromMillis().
Another possible problem is the date format you’re giving to the column prop, especially for the millis part has the wrong pattern. If so, which format are you using?
I dont use any convert for time format and only use table column format for displaying. Even without it the millis value is the same
How the pattern looks?
This is a known limitation/behavior of the historian. You’ll have to manually collapse the rows with a script.
1 Like
Can you guide me with a simple python example of how to merge them?
I notice that the data is different between the timestamps if I’m reading this correctly. If you compressed them with a script how would you figure out which data points are correct?
For the tags themselves, are you storing with Auto/Analog or Discrete mode?
Ohh, that explains that time I tried…
Thanks for the clarification.
I was about to tell him to avoid millis precision
No there are times that they have the same time stamp but it returns a different row.
Look at the first post
I think this happens because you have three tags, (3 columns). duplicate timestamps correspond to different tags. try putting just one tag
Also, you could try for special cases like this to use ‘system.tag.storeTagHistory’ , it allows you to specify a timestamp so you can control the value when this is loaded to history. We use this to get values on exact top of the hour for statutory reporting. system.tag.storeTagHistory(historyprovider, tagprovider, paths, values [, qualities, timestamps])
- Parameters
String historyprovider - The historical provider to store to.
String tagprovider - The name of the realtime tag provder to associate these tags with. The tag provider does not need to exist, and the tag paths do not need to exist in it.
List paths - A list of paths to store. The values, qualities, and timestamps are one-to-one with the paths. A single path may be present multiple times in order to store multiple values.
List values - A list of values to store.
List qualities - A list of integer quality codes corresponding to the values. Quality codes can be found on the Quality Codes and Overlays page. If omitted, GOOD quality will be used. [optional]
List timestamps - A list of Date timestamps corresponding to the values. If omitted, the current time will be used. A java.util.date object may be passed, so the system.date funcitions can be used to return a timestamp. [optional]
The problem is I have over 200 UDTs and it is easy to just enable historian on them
Do you mean 200 UDT instances; or 200 UDT types? if instances, then ‘system.tag.storeTagHistory’ may be easily included in the UDT type script, that way you can have the proper behavior for time stamp as you design for all UDT’s.
Yes it is good idea thanks
Hi Paul,
Look at this script that I manually insert value into historian with the same timestamp but as you see it return 2 separate rows with the same t_stamp which is undesired.
One thing not mentioned is how you want to handle these cases. Last value wins? Values ORed together?