Skip to main content

Have a feature request or idea for a new and improved functionality?

Then we want to hear all about it! We’re constantly working to improve the Charts product experience.

You can choose to either create a dedicated post (topic) in the Charts group by clicking the Create topic button OR simply post a reply below in this thread. Remember to say whether your feature request is Nice to haveImportant, or Critical to you and why. Screenshots, sketches, or explanatory videos are also encouraged.

 

Feature Request - Nice to Have - Time Range Entry

Especially with longer range charts, it would be nice to be able to easily enter the desired time range in number format (ex: 04/15/21). Currently I’m able to enter a range manually by typing in the 3 letters for the month name, but I think numerical is easier. In addition, there is an issue with manual entry as is (ex: Apr15,2021 interprets to Apr 5, 2021, as well as Apr25,2021). Using the calendar is slow and inefficient when using long time ranges.


Feature Request - Nice to Have - Single Scale

This is technically a nice to have, however, it is the default option in PI and so many people are very accustomed to viewing unit data in this way. Having this functionality will help with adoption significantly. By default a PI chart has a single y-axis scaled based on the highest max and lowest min of all time series on the graph. This makes apples to apples comparisons between different time series easier as it becomes a simple visual check.


Feature Request - Important - Time Ranges Relative to Current

This is a very useful feature for trending unit data. In PI, setting the end time to ‘*’ means that the trend will end at the current time and update its trends accordingly as new data comes in. Similarly, setting the start time to ‘* -xy’ means the trend will start at current time minus some offset where x is an integer and y is a string representing a time unit (ex: s, m, h, d, mo, y, sec, min, hour etc.). This feature makes monitoring the real time process a lot easier since the chart automatically updates to new data and removes old data. It doesn’t have to replicate the syntax of PI of course. I think it’s efficient syntax but the functionality however best implemented is what I’m after


Thanks so much for all the requests here @Brendan Buckbee. To respond to each one:

 

Feature Request - Nice to Have - Time Range Entry

Especially with longer range charts, it would be nice to be able to easily enter the desired time range in number format (ex: 04/15/21). Currently I’m able to enter a range manually by typing in the 3 letters for the month name, but I think numerical is easier. In addition, there is an issue with manual entry as is (ex: Apr15,2021 interprets to Apr 5, 2021, as well as Apr25,2021). Using the calendar is slow and inefficient when using long time ranges.

 

Great points and completely agree with you. We’re using this date selection component from the Cognite Design System, and we’re working with them as they’re currently gathering input to improve it. I’ll make sure this input makes it their way.

 

Feature Request - Nice to Have - Single Scale

This is technically a nice to have, however, it is the default option in PI and so many people are very accustomed to viewing unit data in this way. Having this functionality will help with adoption significantly. By default a PI chart has a single y-axis scaled based on the highest max and lowest min of all time series on the graph. This makes apples to apples comparisons between different time series easier as it becomes a simple visual check.

 

Just a clarifying question, how does a “single y-axis” work when you’re working with time series using different units? 

Or, do you mean there is a single y-axis single scale per unit?

When time series are added to a plot in Charts, the time series should auto-scale to the min and max values for a given range. If you want to return a time series’ y-axis scale to that min and max range, you can double click on that y-axis to quickly snap it into position. 

We do have the “Merge y-axis” functionality in Charts, but as you’ve definitely seen, it’s not enabled by default in each chart — a person needs to manually enable that option for each chart. Is this, combined with a clearer and more intuitive way of returning the y-axis to a time series’ min and max values, what you’re describing?

 

Feature Request - Important - Time Ranges Relative to Current

This is a very useful feature for trending unit data. In PI, setting the end time to ‘*’ means that the trend will end at the current time and update its trends accordingly as new data comes in. Similarly, setting the start time to ‘* -xy’ means the trend will start at current time minus some offset where x is an integer and y is a string representing a time unit (ex: s, m, h, d, mo, y, sec, min, hour etc.). This feature makes monitoring the real time process a lot easier since the chart automatically updates to new data and removes old data. It doesn’t have to replicate the syntax of PI of course. I think it’s efficient syntax but the functionality however best implemented is what I’m after

 

Again, completely agree with you and understand why this is so important. This is actually something we’ve already worked on from the design side and is awaiting frontend implementation. Here’s one sketch of the proposed design:

As you can see, we’ll add more time selections with the ability to “auto-refresh” the chart as new data enters CDF (this refresh will also trigger your calculations to re-run). How often would you need the chart to refresh based on the time series data you’re working with? Every 1 minute? Every 1 second? Would you prefer to have the control to set this refresh rate for yourself?

Note: The calendar date selector used in the above above is a copy/paste of the current one. As mentioned above, this updating this is a separate task from adding this auto-refresh functionality. 


Celanese - Critical

The ability to overlay other transactions on time  series data or create time series from transcations is necessary when troubleshooting. For example, i might be analysing several time series tag and i would like to plot work order and notification dates and/or other events on the same plot. 

This will really help us do better Root Cause Analaysis.


 

Feature Request - Nice to Have - Single Scale

This is technically a nice to have, however, it is the default option in PI and so many people are very accustomed to viewing unit data in this way. Having this functionality will help with adoption significantly. By default a PI chart has a single y-axis scaled based on the highest max and lowest min of all time series on the graph. This makes apples to apples comparisons between different time series easier as it becomes a simple visual check.

 

Just a clarifying question, how does a “single y-axis” work when you’re working with time series using different units? 

Or, do you mean there is a single y-axis single scale per unit?

When time series are added to a plot in Charts, the time series should auto-scale to the min and max values for a given range. If you want to return a time series’ y-axis scale to that min and max range, you can double click on that y-axis to quickly snap it into position. 

We do have the “Merge y-axis” functionality in Charts, but as you’ve definitely seen, it’s not enabled by default in each chart — a person needs to manually enable that option for each chart. Is this, combined with a clearer and more intuitive way of returning the y-axis to a time series’ min and max values, what you’re describing?

 

The Merge Units functionality only merges like units into a single y-axis (ex. All time series with the unit “gpm” will be on the same axis). What I’m talking about is merging all axes into one, discarding units and having one scale for all time series on that chart. 

As you can see, we’ll add more time selections with the ability to “auto-refresh” the chart as new data enters CDF (this refresh will also trigger your calculations to re-run). How often would you need the chart to refresh based on the time series data you’re working with? Every 1 minute? Every 1 second? Would you prefer to have the control to set this refresh rate for yourself?

I don’t think it’s critical to have control over the refresh rate. My general preference would be 15-30 seconds for a refresh rate.


Celanese - Feature Request - Important - Map “Bad” to “nan” on Data Ingress & Improved Replace

I have tried to use gap detection in order to replace bad values on transmitters as they come into cognite. However, I have encountered two issues. First, if the instrument is still bad, gap detection seems to return nothing. Secondly, threshold gap detection has been inconsistent depending on the time constant used for checking for the gap. For example, using 6hrs as the threshold has resulted in no gaps being detected while a 1day threshold detects gaps. This is counterintuitive because if I have a 1day gap, I certainly should have a 6hr gap. For Celanese, I think it would be much more efficient to just map “Bad” to nan. It is consistent across our site and other Celanese sites that when there is a transmitter issue, it will read “Bad” in PI. This will make the calculations simpler and more consistent as we could just use the Replace function. Coupled with a modification to the Replace function where we can link the desired number to replace “nan” with to another calculation or time series would give much easier and better functionality for us.


Celanese - Critical

The ability to overlay other transactions on time  series data or create time series from transactions is necessary when troubleshooting. For example, i might be analysing several time series tag and i would like to plot work order and notification dates and/or other events on the same plot. 

This will really help us do better Root Cause Analysis.

@ibrahim.alsyed 100% agree with and support this request. As I mentioned when we spoke over Teams this week, this is a high priority item on our roadmap. Based on the team’s capacity, I’m anticipating that we’ll implement and release in H2 2022.


The Merge Units functionality only merges like units into a single y-axis (ex. All time series with the unit “gpm” will be on the same axis). What I’m talking about is merging all axes into one, discarding units and having one scale for all time series on that chart. 

 

@Brendan Buckbee interesting, this isn’t something I’ve heard about before. Couldn’t this produce difficult-to-read visualizations if the time series scales are very different? E.g. A single y-axis comparing a time series that fluctuates between 2-3 bar vs. another that fluctuates between 60-90°F?

Regardless, this is a simple extension of the y-axis settings we currently have in Charts and one I suspect would be quite trivial to implement. I’ll add it to our backlog. 

 

Celanese - Feature Request - Important - Map “Bad” to “nan” on Data Ingress & Improved Replace

I have tried to use gap detection in order to replace bad values on transmitters as they come into cognite. However, I have encountered two issues. First, if the instrument is still bad, gap detection seems to return nothing. Secondly, threshold gap detection has been inconsistent depending on the time constant used for checking for the gap. For example, using 6hrs as the threshold has resulted in no gaps being detected while a 1day threshold detects gaps. This is counterintuitive because if I have a 1day gap, I certainly should have a 6hr gap. For Celanese, I think it would be much more efficient to just map “Bad” to nan. It is consistent across our site and other Celanese sites that when there is a transmitter issue, it will read “Bad” in PI. This will make the calculations simpler and more consistent as we could just use the Replace function. Coupled with a modification to the Replace function where we can link the desired number to replace “nan” with to another calculation or time series would give much easier and better functionality for us.

If the Gap detection, threshold function is finding gaps with a 1 day threshold, but can’t find the same gaps with a 6 day threshold, then this is definitely a bug. I’ve filed a ticket with the team and we’ll investigate. I’ll keep you posted about what we find.

As for storing instrument values as a value of bad in CDF, this is a time series API related feature and topic. @Thomas Sjølshagen, do you know whether this is something that can be done today? I’ve looked at one time series in the celanese project where I know there are these bad values in PI, but they don’t seem to be stored this way in CDF. These periods where the time series value is bad in PI is simply an empty gap in CDF.

The Replace function in Charts/InDSL does actually support replacing nan values today. However, it’ll only work if the time series values themselves are actually “not a number” in CDF, and again, this doesn’t appear to be the case with the various time series in the celanese project as per now. 


@Brendan Buckbee interesting, this isn’t something I’ve heard about before. Couldn’t this produce difficult-to-read visualizations if the time series scales are very different? E.g. A single y-axis comparing a time series that fluctuates between 2-3 bar vs. another that fluctuates between 60-90°F?

Regardless, this is a simple extension of the y-axis settings we currently have in Charts and one I suspect would be quite trivial to implement. I’ll add it to our backlog. 

Yes, it can produce difficult to read visualizations. I’m personally not a big advocate of using it, but there are many people within our company who are highly accustomed to viewing things that way as it’s the default option in the historian.


Celanese - Feature Request - Nice to Have - Log Scales for Y-axis

Hoping that this is a simple implementation. It would be great if we had the option to toggle a time series’ y-axis to/from log scale without making a calculation to perform a logarithm transformation on the data. 


Celanese - Feature Request - Nice to Have - Log Scales for Y-axis

Hoping that this is a simple implementation. It would be great if we had the option to toggle a time series’ y-axis to/from log scale without making a calculation to perform a logarithm transformation on the data. 

@Brendan Buckbee thanks, I’ll add this to our backlog. We’re doing some design work now to improve the usability and functionality of the y-axis controls now, so it’s a good time for us to consider how we might add this sort of added functionality UX-wise.

When it comes to how you imagined this feature to work, would you prefer that the scale toggle is only a feature related to the y-axis itself (meaning, no new calculation needs to be auto-created in the background)? Or would you want or expect a new calculation to be automatically added to the chart list when using this feature?


Celanese - Feature Request - Nice to Have - Vessel Volume Calculations

Vessel volume calculations would be very useful to have given a level time series and some basic inputs about the vessel. Horizontal Vessels in particular are time consuming to set up and lead to overly long calculations (prone to error) in PI in order to get an accurate volume on the vessel. In our industry the 2:1 elliptical heads are almost always what we use in our vessels so having a calculation just for those would help a lot. Eventually it would be good to be able to select a vessel head geometry and get accurate volume results in charts that way. Here’s a resource for the calculations that we use

https://neutrium.net/equipment/volume-and-wetted-area-of-partially-filled-horizontal-vessels/

Thanks,

Brendan


@Brendan Buckbee that’s a great request. Some of my colleagues in Cognite may have already built a function similar to this for a use case delivery with another customer.

I’ve added this request to our InDSL backlog and will follow up once one of our data scientists are able to work on it. 


Hi,

Not a critical feature, but very nice to have. Could the threshold events search in the raw data instead of using the aggregated data points? I am getting 0 hits, but I can see that we are over the limit several times, and when zooming in it will update with correct event count.

 


Hei Eric,

In Function/Detect/Change Point Detection, would it be possible to add the choice to select “change on positive” or “change on negative” changes in the value of the series of interest? Or does anybody in the group have another way of accomplishing this? 


@144842 yes, this is absolutely something we intend to support. We recently had a discussion in our team about a possibility for how to do so, so as soon as we have an update, I’ll be sure to let you know.

In the meantime, as you know, the best solution is to zoom in to a smaller range of time to perform this threshold calculation on a lower quantity of data. 

I also see that we need to be displaying a similar status warning if and when this threshold calculation is being run on aggregated/downsampled data (just like we do for calculations). FYI @Magdalena Rut regarding the update for the thresholds panel UI design you’re working on.


@Richard Manson Have you tried using the CUSUM function? It has some parameters that you should be able to tailor to detect these changes – likely with one calculation for positive changes and the other for negative changes. 

It might also be worth reposting this in the main Charts group or the Hub community page in order to get more eyes and input on this. 

Let me think about some other ways to solve this using the available functions and get back to you next week. FYI @Cristina Ferrer Teixidor, this was the case I spoke with you about. 


@Eric Stein-Beldring  following up on the post by Brendan on volume calculations of vessel above in this thread. Has the data scientist looked at it? can it progress?


@ibrahim.alsyed there has been an ongoing discussion among members of our data science team, but unfortunately the function is not yet ready for review or use. We’ll be sure to keep you all up-to-date once we have made further progress and the function is ready for use in Cognite Data Fusion. 


@ibrahim.alsyed @Brendan Buckbee, an update on the vessel volume calculations – @Everton Colling has used his pre-holiday time to wrap up the pull request for these calculations:

Our colleagues will be able to review the code after the break and then it should be a part of our first InDSL update in 2023. Until then, have a happy holidays!


Thank you - looking forward to it.


@Eric Stein-Beldring any update on when this can be released?


@Knut Vidvei 


Hi, Ibrahim.

We are working our way through the review process, and will have an update for you shortly.

Best regards, Knut


Reply