Impact 2024: The Industrial Data and AI Conference for and by Users | Nominate Speakers Now for a Ch...
Hi! @Anita Hæhre Why has this been parked? This has been a highly requested change from multiple users to improve their ability to distinguish between open checklists. @Kristoffer Knudsen
Hi @Anita Hæhre Apologies for the delayed response! The explanation provided by @Kristoffer Knudsen is very helpful and should be acceptable in the short term for now. However, I do agree that the feature should be a bit more intuitive when considering a long term solution. Thanks!
Hi @crgomez13 , Could you please specify the applications or API in which you encountered the limit? Best regards, Que Tran The application is CDF. I have provided a snippet of the encountered error below.
Hi @Meg Ong is this something that is being considered for 2.0? As we look to digitize other forms of checklists at the site, this is becoming an increasing request from the users given that the average checklists for each unit can range around 20+. This feature would make it much easier to navigate between the different checklists.
Hi @Kristoffer KnudsenI think a simple fix for this would be to include the calendar date (MM/DD/YY) in the bottom right corner rather than just the week day; in addition to having the time. This would make it a lot easier for the process experts to differentiate as on occasion there may be multiple checklists that may have dragged over from a previous day or shift.
@Kristoffer Knudsen wanted to follow up on this item. The configuration did seem to work for most units but I am curious if there is a better way to approach this similar to the original ask above? The reason I ask is for assets that may have a large amount of “.mde” tags contextualized as well. It would be a cleaner experience to allow the users to select the tags they would like to see. I found a temporary fix by applying the “.mde$” configuration in both the “default visible trends” and “Regex pattern to filter out unwanted matches of default visible trends” dialogue boxes. This allowed me to view the trend page without any default timeseries being displayed. However, an unexpected side effect of this was when viewing the asset overview page, the “View trends” button was greyed out. Because of this I was required to revert back to the original configuration.
Thanks @crgomez13! Would any of these documents be interesting to contextualise for future use?We want to make the most of a reusable data model by organizing relevant data for reuse. However, I also recognize the need to occasionally add things on the fly.@Marius Biermann I think it would be great if these files could at the very least be contextualized to the work orders.
Hi Anita,This covers what was needed by the user. Thanks
Hi Knut,I believe this might be what the users were looking for! I will follow up if there are any more questions or concerns. Thanks!
@crgomez13 is filing a report of leak a paper? maybe we need to also look at the process. @ibrahim.alsyed yes, they currently do this via a “Leaker Log” that is maintained at the unit. This is a potential use case that we are looking into for digitalization to InField with the LDAR lead.
Hi @Kristoffer Knudsen - this particular use case has been brought up by multiple units across the Clear Lake site. The most recent being the Utilities unit as well as the LDAR team in which their checklists utilize “condition based” inspection tasks.
Hi @Kristoffer Knudsen there are a few items where the user is taking the same reading multiple times a day/shift within a single checklist. An example of this can be a process expert going to capture a concentration reading from an analyzer on 4-hr intervals. Rather than having to create a separate checklist for each it would be nice to see an added layer of advanced scheduling where the user can determine how many times a specific measurement reading needs to be captured within a single checklist.
@Kristoffer Knudsen This is great news! Thanks for the update!
Hi @Eric Stein-Beldring Thanks for the detailed reply! Based on the current needs, I believe these options should work. Will test these out and will follow up if the users run into any issues. Looking forward to the automated calculations release!Cheers!Cristian
Hey @Kristoffer Knudsen, yes I believe the users would like each “manually created state” to count towards completion. Thanks!
Thanks for the response! @Kristoffer Knudsen I believe it was more understanding what the manual status states were originally intended for. If they were designed to be more ‘pre-requisite” states in completing an item then that make sense. In terms of a potential use case brought up by the user see the example below.If creating a “housekeeping checklist” to walkthrough tools/inventory, the user usually has a checklist of items that are yes/no questions. The user intended to utilize the manual states function to create “Yes” and “No” options to complete these items.All tools properly stored in storage cabinet? (Y/N) Tool storage cabinet locked? (Y/N)
Already have an account? Login
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.