RTPPM KPI Downtime Model Configuration using AMU property to configure as downtime tag. versions 9.6

[WL_10521300]

For some reason my downtime kpi is not showing up. I configured the downtime model and added the shift event to the machine and ran the KPI Engine sql query. And the availability isn't showing up. I check the timeslice table to see if there is data but it's empty. There is entries in timesliceschedule table. I am not sure where I went wrong. I am using binding to an AMU property instead of a tag because how we are tracking of this machine is on or off is based on a temperature range. So I made a AMU attribute/property called status that returns "Running" or "Stopped " when the temp changes. I configured status with a DummyTag with an address of S0050 and use a service to update the status to return the "Running" or "Stopped" based the datachange event of the  AMU attribute/property called Temp. (This idea come from this article: https://community.ptc.com/t5/ThingWorx-Developers/How-AMU-attribute-logging-works/m-p/930097#M65531)

so I am not sure if there is a better way for this to work for both RTPPM and AMU. My goal is to use the temp data tag that I have to determine if the machine is running or not. (Eg, if temp is within the limits configured in Characterisitcs, then return Running. Else out of the range return Stopped). Let me know if you can think of a better way for me to does this to work for both RTPPM and AMU. 

I ran queryPorpertyHistory and I see rows but I don't see some columns populated.   Compare to another machines who Availbility KPI is working. 

[mstarnaud]

Hi WL

Let's look at this piece by piece.

I configured the downtime model and added the shift event to the machine and ran the KPI Engine sql query. And the availability isn't showing up. I check the timeslice table to see if there is data but it's empty. There is entries in timesliceschedule table.

Yeah my first suspect was that the TimesliceSchedule table was empty, but I see you already checked that. So here's a few more items to check : 

• Can you validate your shifts are correct? Go in the Configuration -> Shift And Crew -> Shift Events tab, open the filter, select all equipments and time Today. Do you see records for the specific equipment that is producing? If not, are there records for its parent? For its grandparent?
• Can you validate that in the Timesliceschedule table, for your equipment the StartDate is in the past by at least a couple hours? Usually when I configure an equipment, I set the StartDate to that day or the previous day, at midnight.
• In Composer, go on Timer PTC.SCA.SCO.KPIEngineTimerThing. In the General Information tab, make sure it has the Automatically Enable Timer At Startup option (if not, check it). In the Properties And Alerts tab, make sure the Enabled property is set to true (if not, execute the EnableTimer service). In the Subscriptions tab, make sure the RefreshCache subscription is enabled.
• If that's still not enough, maybe the Timer is running but getting errors. Please check Scriptlog for errors in the last 20 minutes, and/or the ErrorLogMessage table : SELECT TOP 100 * FROM errorlogmessage ORDER BY uid DESC.

I am using binding to an AMU property instead of a tag because how we are tracking of this machine is on or off is based on a temperature range. So I made a AMU attribute/property called status that returns "Running" or "Stopped " when the temp changes. I configured status with a DummyTag with an address of S0050 and use a service to update the status to return the "Running" or "Stopped" based the datachange event of the  AMU attribute/property called Temp.

I never tried using a text value for the downtime tag, I'm not sure if it's supported. But the goal is to send the value in the DowntimeByTag_DowntimeTag property and its valuestream, so using a local property instead of a Kepware tag should be acceptable, I'm just not sure about the "it's text" part. You may need an extra step to convert it into 0/1 instead of stopped/running.

so I am not sure if there is a better way for this to work for both RTPPM and AMU. My goal is to use the temp data tag that I have to determine if the machine is running or not. (Eg, if temp is within the limits configured in Characterisitcs, then return Running. Else out of the range return Stopped). Let me know if you can think of a better way for me to does this to work for both RTPPM and AMU. 

It's not "officially supported", but what you're doing is a simple workaround that should work. Except maybe the "transform the text into a number" part that I'm not sure is required, as mentioned above.

I ran queryPorpertyHistory and I see rows but I don't see some columns populated.

First, this is the Value_Stream table in the Thingworx database if you want to query it in SQL (the UI can show repeated values for example, SQL is safer). Second, the way to have values into it is to either use a tag with the Log setting on the property, or if you push values via subscription then you also need to push the value into the Valuestream you can see an example in subscription JobOrderProdEvent_Subscription : calling the AddStringValueStreamEntry service. Third, Valuestream records get deleted after they are processed by the models. This is probably why your downtime tag only has "Running", even though the history tag has all the other values. The history tags are supposed to keep the values for 24h before deleting them, for debugging purposes. The fact that we just see Running for downtime and alternating Running/Stopped in history makes me think it's processing the values, if the downtimes don't get created then I would look in Scriptlog and ErrorLogMessage for related errors.

Let me know if you're able to progress further with this information.

[WL_10521300]

• I checked the shift events for the machine I see for today and it's configured for 12-01-2024 through 02-01-2024
• Yes, it starts on 12-01-2024.
• PTC.SCA.SCO.KPIEngineTimerThing's Automatically Enable Timer At Startup is enabled. The subscription RefreshCache is enabled.
• I doe see errors with the timeslice SP.Create time slices -1 KPIEngine_TimeSliceCreate_SP Cannot insert duplicate key row in object 'dbo.timeslice' with unique index 'TimeSlice_StartTime_EndTime_EquipmentUID_TimeSliceTypeUID_ShiftEventUID_JobOrderUID_EventSubTypeUID_ProductUID_Unique'. The duplicate key value is (2024-12-05 17:00:00.0000000 +00:00, 2024-12-05 18:00:00.0000000 +00:00, 26, 1, <NULL>, <NULL>, 1, <NULL>). - Parameters: NONE
  Create new time slices -1 Cannot insert duplicate key row in object 'dbo.timeslice' with unique index 'TimeSlice_StartTime_EndTime_EquipmentUID_TimeSliceTypeUID_ShiftEventUID_JobOrderUID_EventSubTypeUID_ProductUID_Unique'. The duplicate key value is (2024-12-05 17:00:00.0000000 +00:00, 2024-12-05 18:00:00.0000000 +00:00, 26, 1, <NULL>, <NULL>, 1, <NULL>). - Parameters: NONE

I did change it to true/false and I tried 0/1 as well. Unfortunately the timeslide table is still empty after 1 hr of run for each datatype (boolean, integer)

[WL_10521300]

I did run the KPI Engine SQL code just in case. I think those errors are related to that.

[mstarnaud · Accepted solution]

Ok yes, this is why the KPIs are not showing up. You have a record for December 5th (2024-12-05) with empty Uids (Shift, Product & Joborder mostly) and for some reason it's trying to create a duplicate. It should not be doing that, it must have encountered a bad scenario somehow. But the end result is that there is an error in the KPI calculations. And when there is an error, it rolls back all the calculations and tries again. I'm guessing you have no record at all since December 6th.

So there's 2 options. #1 : we can leave the data as it is and try to debug the procedure & data to figure out how it gets that wrong scenario. Then we can find a way to fix it and also alert the software team, to prevent this from happening in the future. #2 : fix it now : DELETE timeslice WHERE equipmentuid = 26 AND starttime >= '2024-12-05 16:00'. This should allow the KPIs to be calculated immediately.

[WL_10521300]

Your 2nd option worked for my and my KPIs are showing again. Thank you so much!!