Setting Up Data Automation
The DPM automation integration allows data from connected pacemakers to be received by DPM in near real-time. A pacemaker is the work unit that sets the production pace for a work center. The DPM automation integration supports job order changes (starting production, stopping production, or changing the job order), production and scrap counts, and availability events resulting from machine codes being mapped to reason codes within DPM. Receiving data from the connected pacemaker results in property changes in ThingWorx. All property changes that have good quality data are stored in a value stream. Every 5 minutes, those transactions are retrieved in chronological order and are written to the appropriate event tables within DPM.
For example, when all data automation properties are configured, DPM can receive data that starts production on a job order. While the job order is in production, data can be received to add production count and scrap count for the job order, to log downtime events for the machine such as breaks or power outages, and to log when the machine returns to a running state. DPM can then receive data that completes the first job order and starts production on the next job order.
If the system is disconnected for less than 15 minutes, events that occurred during that time are captured. If the system is disconnected for longer than 15 minutes, events more than 15 minutes old are ignored. This is to avoid duplication of data, as operators may have manually entered data for that time. For more information, see Manual Data Entry and Automated Data Entry.
To set up data automation for DPM, complete the following steps:
1. Install and connect your data source to ThingWorx.
◦ For more information on Kepware, see KEPServerEX Version 6 Install Guide.
◦ For more information on Azure IoT Hub, see Azure IoT Hub Connector Help Center.
2. In ThingWorx Composer, create or use an Industrial Connection. To create a new Industrial Connection, create a new Thing with the IndustrialGateway Thing Template as its Base Thing Template.
3. Data automation can be configured on the pacemaker for each work center. Other equipment types (enterprise, region, site, area, or work center) cannot be automated.
On the work unit Thing for a pacemaker, complete the following steps:
a. Add the following Thing Shapes to the Implemented Shapes field:
▪ PTC.OperationKPI.AutomationEventsModelLogic_TS
▪ IndustrialThingShape
b. Set the Value Stream field to PTC.OperationKPI.Automation_VS.
c. Under Properties and Alerts, set the IndustrialThing property to the Industrial Connection from step 2.
d. Set the properties for the data automation activities that you want to use. Information on each of these properties is provided in the linked sections:
e. Click Save to save the changes to the work unit Thing.
4. Repeat step 3 for each pacemaker that you want to automate.
5. Navigate to the PTC.OperationKPI.AutomationEventProcessor_TI timer. Select the Enabled checkbox, and click Save. This starts the batch processing for data automation.
To Start Existing Job Orders
To start existing job orders using data automation, complete the following steps in ThingWorx Composer:
1. On the work unit Thing for a pacemaker, under Properties and Alerts, bind the PTCJobOrderID property to the appropriate tag. This property accepts STRING values.
2. Click Save to save the changes to the Thing.
Whenever the PTCJobOrderID property value changes, the specified job order starts. If a job order is currently running when the property changes, that job order is completed and the new job order is started. If the job order with that ID does not exist, an error is displayed for the operator. Job orders are created on the Job Orders page in Administration. For more information, see Creating a Job Order.
When the PTCJobOrderID property receives a value of 0 (the default value for the PTCJobOrderIDNullValue property), the currently running job order is completed and no new job order is started.
If an operator manually changes the status of a job order in the Production Dashboard by starting production or stopping production at a time after the timestamp for the PTCJobOrderID property change, the property change is ignored and an error is shown to the operator. Automated events are processed after they occur and the operator is assumed to be aware of what is happening on the equipment in real time.
To Create Job Orders Based On Specified Material
To create job orders based on a specified material using data automation, also referred to as a material run, complete the following steps in ThingWorx Composer:
1. On the work unit Thing for a pacemaker, under Properties and Alerts, bind the PTCMaterialMasterID property to the appropriate tag. This property accepts STRING values.
2. Click Save to save the changes to the Thing.
Whenever the PTCMaterialMasterID property value changes, a job order is created for the specified material with a default target quantity of 1. If a job order is currently running when this property changes, that job order is completed and the newly created job order is started. If the material matching the material master ID does not exist, an error is thrown.
If an operator manually changes the status of a job order in the Production Dashboard by starting production or stopping production at a time after the timestamp for the PTCMaterialMasterID property change, the property change is ignored and an error is displayed to the operator. Automated events are processed after they occur and it is assumed that the operator is aware of what is happening on the equipment in real time.
When the PTCMaterialMasterID property receives a value of 0 (the default value for the PTCMaterialMasterIDNullValue property), the currently running job order is completed and no new job order is started.
To Update the Target Quantity for Job Orders
The PTCTargetQuantity property is used to set the target quantity for job orders created using the PTCMaterialMasterID property. This property should always be set after the PTCMaterialMasterID property is set. When this property value changes, the target quantity for the currently running job order is updated.
 |
When there are two subsequent materials being run with the same target quantity, reset the PTCTargetQuantity property before sending the second target quantity value by sending a value of -1 (the default value for the PTCTargetQuantityResetValue property). The system does not recognize receiving the same value again as a data change. The property value must be reset for the target quantity of the second job order to be updated to the same value as was set for the first job order.
|
To update the target quantity for job orders using data automation, complete the following steps in ThingWorx Composer:
1. On the work unit Thing for a pacemaker, under Properties and Alerts, bind the PTCTargetQuantity property to the appropriate tag.
2. Click Save to save the changes to the work unit Thing.
To Log Production Counts
The production counter records the good production count that is happening on the pacemaker. The total production count is calculated as the good production count plus the scrap count.
To log production counts using data automation, complete the following steps in ThingWorx Composer:
1. On the work unit Thing for a pacemaker, under Properties and Alerts, bind the PTCProductionCount property to the appropriate tag. This property accepts numeric values.
2. Both absolute and rollover production counters are supported. By default, the production counter is absolute. To make the production counter a rollover counter, set the PTCIsProductionCountRollover property to TRUE and set the PTCProductionRolloverCounter property to the rollover value for the counter.
|
|
An absolute counter records new counts as they are received. For example, if counts of 3, 5, and 2 are received, a total of 10 is recorded.
A rollover counter records the difference between the previous count and the new count, until a designated rollover number is reached and the counter resets. When the counter resets, it records the difference between the previous count and the rollover number, plus the new count. For example:
• Counts of 0, 2, and 5 are received by the rollover counter. When 2 is received, 2 is recorded (the difference between 2 and 0). When 5 is received, 3 is recorded (the difference between 2 and 5).
• Counts of 990, 998, and 3 are received by the rollover counter, and the rollover number is 999. When 998 is received, 8 is recorded (the difference between 998 and 990). When 3 is received, 4 is recorded (the difference between 999 and 998, plus the new count of 3).
A rollover counter does not reset when the job order changes on the work unit Thing.
|
3. By default, the production counter starts at 0. If you want the production counter to start at a different number, add a row to the PTCLastAutomationProcessedValues infotable property with the following values:
◦ propertyName—PTCProductionCount
◦ value—The value at which you want the production counter to start.
◦ jobOrderUid—This field is ignored by DPM.
4. Click Save to save the changes to the work unit Thing.
|
|
For an absolute counter, when there are two subsequent production counts with the same number, reset the PTCProductionCount property before sending the second production count value by sending a value of -1 (the default value for the PTC.ProductionCountResetValue property). The system does not recognize receiving the same value again as a data change. The property value must be reset for the second production count of the same value to be recognized as a new production count.
|
To Log Scrap Counts
Scrap counters record the scrapped production that has happened on the pacemaker. There can be multiple scrap counters for a single pacemaker. The scrap count for a pacemaker is calculated from the values of all of its scrap counters.
Each scrap counter in DPM is mapped to a single scrap machine code that is generated by the pacemaker. As a result, if your pacemaker has a single scrap counter which can generate different machine codes for different counts, you need to create a unique scrap counter tag in your data source for each machine code for which you want to keep count.
Each scrap machine code is mapped to a scrap reason code in DPM.
To log scrap counts using data automation, complete the following steps:
1. Validate that the scrap machine codes are present on each pacemaker and are assigned to the appropriate scrap reason codes. Machine codes and their assigned reason codes can be viewed in Administration, on the Machine Code Settings tab for the work unit in the Equipment List.
|
|
If a machine code is not present on the pacemaker, or is not mapped to a reason code, then any events received through data automation for that machine code are logged with an event category (eventCategory) and loss category (reasonCategory) value of Invalid. These invalid events do not appear in the Production Dashboard event logs, do not add to the scrap count, and are not considered in any data calculations.
|
2. In ThingWorx Composer, on the work unit Thing for a pacemaker, under Properties and Alerts, create a property for each scrap machine code for which you want to keep count. Each scrap property is considered to be a scrap counter in DPM.
3. Both absolute and rollover scrap counters are supported. By default, the scrap counters are absolute. To make the scrap counters on the pacemaker rollover counters, set the PTCIsScrapCounterRollover property on the Thing to TRUE.
|
|
An absolute counter records new counts as they are received. For example, if counts of 3, 5, and 2 are received, a total of 10 is recorded.
A rollover counter records the difference between the previous count and the new count, until a designated rollover number is reached and the counter resets. When the counter resets, it records the difference between the previous count and the rollover number, plus the new count. For example:
• Counts of 0, 2, and 5 are received by the rollover counter. When 2 is received, 2 is recorded (the difference between 2 and 0). When 5 is received, 3 is recorded (the difference between 2 and 5).
• Counts of 990, 998, and 3 are received by the rollover counter, and the rollover number is 999. When 998 is received, 8 is recorded (the difference between 998 and 990). When 3 is received, 4 is recorded (the difference between 999 and 998, plus the new count of 3).
A rollover counter does not reset when the job order changes on the work unit Thing.
|
4. Update the PTCScrapEventProperties property to include each scrap property that you created in step 2. The value for the PTCScrapEventProperties property is an infotable. For each scrap property, add a row to the infotable with the following information:
◦ propertyName—The name of the scrap property.
◦ machineCode—The machine code associated with the scrap property.
◦ rolloverCounter—The rollover value. If the PTCIsScrapCountRollover property on the work unit Thing is FALSE, the rollover value is ignored.
◦ reallocateFromGoodCount—Select the checkbox (TRUE) if the scrap count received for this property needs to be reallocated from the good count that has already been recorded. If the scrap count received for this property does not need to be reallocated from the good count, do not select the checkbox (FALSE).
Consider the scrap counter’s position when determining whether or not the scrap counts reported by the scrap counter need to be reallocated from the good production count. Scrap counts can be recorded both before and after good counts are recorded, depending on where a scrap counter is physically located in relation to the production counter. The following image shows a simple example where a pacemaker has two scrap counters: scrap counter 1 is positioned in front of the production counter, and scrap counter 2 is positioned after the production counter.
When a scrap count is recorded from scrap counter 1, the good count has not yet been recorded by the production counter. As a result, the scrap count does not need to be reallocated from the good count. This assumes that any scrapped product which is counted by scrap counter 1 will not be included in the good count recorded by the production counter. Set reallocateFromGoodCount to FALSE for this scrap counter.
When a scrap count is recorded from scrap counter 2, the good count has already been recorded by the production counter. Any product that is now being scrapped needs to be reallocated from the good count, as it was included in the good count recorded by the production counter. Set reallocateFromGoodCount to TRUE for this scrap counter.
| | If the scrap property and machine code are not properly mapped in the PTCScrapEventProperties infotable, then any data received for that scrap property is logged as an event with an event category (eventCategory) and loss category (reasonCategory) value of Invalid. These invalid events do not appear in the Production Dashboard event logs, do not add to the scrap count, and are not considered in any data calculations. |
5. By default, each scrap counter starts at 0. If you want a scrap counter to start at a different number, add a row to the PTCLastAutomationProcessedValues infotable property with the following values:
◦ propertyName—The name of the scrap property.
◦ value—The value at which you want the scrap counter to start.
◦ jobOrderUid—This field is ignored by DPM.
6. Add a subscription for the data change event for each scrap property that you created in step 2. Under Subscriptions, click Add. Specify the following information:
◦ Under Subscription Info, enter a name for the subscription and select the Enabled checkbox.
◦ Under Inputs, select the DataChange event and select the name of the scrap property for which you are creating the subscription.
◦ In the script editor, paste in the following code:
me.AddPTCValueStreamEntry({
propertyName: sourceProperty,
newEventData: eventData.newValue
});
propertyName: sourceProperty,
newEventData: eventData.newValue
});
Click Done.
7. Click Save to save the changes to the work unit Thing.
| | For an absolute counter, when there are two subsequent scrap counts with the same number for a given scrap property, reset the scrap property before sending the second scrap count value by sending a value of -1 (the default value for the PTC.ScrapCountResetValue property). The system does not recognize receiving the same value again as a data change. The property value must be reset for the second scrap count of the same value for the same scrap property to be recognized as a new scrap count. |
| | If a scrap count property is deleted from the work unit Thing for a pacemaker, you must also delete it from the PTCScrapEventProperties property. A non-existent scrap count property that is listed in the PTCScrapEventProperties property prevents all events in the value stream from being processed for that Thing. |
To Log Availability Events
Availability events record the state that the machine is currently in by accepting machine codes from the machine that are mapped to reason codes.
To log availability events using data automation, complete the following steps:
1. Validate that the fault machine codes are present on each pacemaker and are assigned to the appropriate reasons. This includes a Running machine code that is assigned a reason code from the Running reason tree. Machine codes and their assigned reason codes can be viewed in Administration, on the Machine Code Settings tab for the work unit in the Equipment List.
| | If a machine code is not present on the pacemaker or does not map to a reason code from a reason tree that is assigned to the pacemaker, the event is recorded with an Unknown reason code. |
2. In ThingWorx Composer, on the work unit Thing for each pacemaker, under Properties and Alerts, bind the PTCAvailabilityEventFaultCode property to the appropriate tag.
3. Click Save to save the changes to the work unit Thing.