Line-level state is mainly reflecting the state of the main machine. However, there are some line-wide activities which should impact reporting and in some sense ‘Ignore’ what’s happening on the main machine
You can set a line-level state rule to start an appropriate line-level changeover, depending on:
Whether it’s running
Whether it’s delayed (expected time exceeded)
Make sure that this state does not have a ‘Forced’ flag |
This allows you to cover scenarios like:
If any changeover is delayed, the time outside of expected time should classify as availability loss
To update line state based on the changeover status, you need to create a signal with the Source Uri:
line_{LineName}_active_changeover_execution_status |
e.g. if the line name is Line With Filler
the Source Uri will look the following:
line_Line With Filler_active_changeover_execution_status |
(note the spaces)
(Keep the “Device ID” empty)
This signal will automatically provide the following values, depending on the changeover state on the line:
0
- if no changeover is running
1
- if there is changeover, but it's planned duration has not been exceeded
2
- if the running changeover has exceeded it’s planned duration
You can incorporate this statuses in any rules you like, but the simplest configuration assigns a line-level ‘changeover' downtime, when the value of the signal is > 0
, or separate states for 1
and 2
:
Future improvements:
You will be able to set a changeover type, and take into account the type of the changeover in the line-level rule
This will allow you to cover scenarios like:
Changeover of type ‘A' classify as availability loss, and type 'B’ classify as utilisation loss
After an order is completed. PackOS looks for a downtime marked with a NoPlan
tag. This can be a downtime in any of the states (usually an ‘Inactive’ state).
The selected downtime will be started on line-level. It can have any of the other tags influencing the OEE impact, to adjust reporting of this period. Read more:
This state should have a ‘Forced’ flag. Otherwise, it will be overwritten from a machine-level state just after it starts. States with tag ‘Forced’ |
If there is no shift planned in the calendar, instead of immediately setting ‘No Plan’ state after order ends (like described above), PackOS looks for a downtime marked with a NoWorkHours
tag.
This can be a downtime in any of the states (usually an ‘Inactive’ state). The selected downtime will be started on line-level. It can have any of the other tags influencing the OEE impact (can be different then NoPlan), to adjust reporting of this period.
This state should have a ‘Forced’ flag. Otherwise, it will be overwritten from a machine-level state just after it starts. States with tag ‘Forced’ |
Relation with orders:
Orders by default has higher priority than ‘NoPlan’ or ‘NoWorkHours’ states. If the shift is overrunning the expected time, and there is still an order running, PackOS won’t enforce ‘NoWorkHours’ state.
If the order is expected to be continued the next day, the operator must manually enforce line-level breakdown at the end of day.
You can change this behaviour using the ENFORCE_OUTSIDE_WORKING_HOURS
flag set as a plant property.
When set to ‘true’, downtime selected as “NoWorkHours” will begin regardless of the running order. If the order is overrunning outside the shift time someone will need to manually “start” the line
You can set a line-level state rule to start an appropriate line-level cleaning, depending on whether it’s running
Make sure that this state does not have a ‘Forced’ flag |
Configuring cleaning state
To update line state based on the cleanming status, you need to create a signal with the Source Uri:
line_{LineName}_active_cleaning_execution_status |
e.g. if the line name is Line With Filler
the Source Uri will look the following:
line_Line With Filler_active_cleaning_execution_status |
(note the spaces)
(Keep the “Device ID” empty)
This signal will automatically provide the following values, depending on the cleaning state on the line:
0
- if no cleaning is running
1
- if there is cleaning
You can incorporate this statuses in any rules you like, but the simplest configuration assigns a line-level ‘cleaning' downtime, when the value of the signal is = 1
, like in the example below:
Coming in 2023 Similarly to the changeover described above, activitiey ‘Maintenance’ will trigger a tag value which can be used to influence line state We plan to improve user experience for configuring line state. vs schedule behaviour and create a single view in line settings which with just a single checkbox will allow you to: |