Machine properties
In this article, we will go through all machine configuration in more detail
To open machine configuration go to “Settings” → “Signals and properties” → Select machine
The following page will appear, in the next sections we will go through each one of them.
Some of the sections might be hidden if the selected machine does not have any signal of type COUNTER
They will appear as soon as such signal is added
Production
Base unit
This is the unit in which the production for that machine is counted.
It corresponds to the unit of the COUNTER of that machine, to change it go to Signals, find the signal with type “COUNTER” and edit the unit
If a machine is marked as “Base Quantity”, this unit is critical when counting production for the line. Depending on the active packing structure, PackOS will multiply every counter increase with a necessary unit conversion multiplier before adding it to the line-level production.
Instantaneous performance
The period in which the performance is calculated determine how long counter history is taken into account. The longer the duration, the smoother the instantaneous performance will be.
Performance is recalculated with a constant resolution of 10 seconds, regardless of the ‘period’ selected. This means that a new datapoint in signal performance history will appear every 10 seconds.
Performance calculation resolution can be adjusted for a factory through a support request, but it’s usually more than enough
If the instantaneous performance is different than the base unit of the machine, an active packing structure will be applied to the result (https://ilabo.atlassian.net/wiki/spaces/LW/pages/1875968001)
Expected performance
Design & Validated performance are constant on machine level (not adjusted when a different SKU is started on the line). Before used, like the instantaneous performance, they are converted to a common unit using an active unit conversion
For example, it means that it’s possible to set an expected performance for a filler in ‘litres’ while the counter is counting ‘bottles'
They ‘Design performance’ is important also in the usage of hourlyExpectedPerformanceOffset in rules https://ilabo.atlassian.net/wiki/spaces/LW/pages/1795424257
It’s also possible to calculate OEE and planned production for a single machine.
Using either ‘Design’ or ‘Validated’ performance is available
Thresholds
Thresholds on machine levels help set conditions / triggers to correlated machine state with the counter.
Ending forced downtime threshold will automatically take down any ongoing forced state, when a counter increase is detected. This is very rarely used on machine-level, as all forced downtimes are usually selected on line-level. So in most scenarios just keep it empty (or 0)
Ending ongoing downtime threshold will “lock” the ongoing downtime until a new counter is detected. This significantly impacts machine states, if set, only the first state (which is not work) will become the reason of the stop, for the full duration of the stoppage.
You need to make sure that the first recognized downtime is always the actual reason of the stop. As soon as any downtime is detected, PackOS won’t touch it so long as the specified threshold has not been reached.
If ‘Allow production on downtime’ is disabled (see below), counts which occurred during the downtime won’t be counted towards the final production volume.
~80% of our clients do not use this setting, but rather use rules to make sure the correct downtime type is recognised in all cases. Use it only if:
You are confident with the result of the downtime rules. Very often the first recognised downtime is not the real reason of the stop, and the correct state shows up after a few seconds. This setting will hide the correct reason, locking on the first one detected.
You are not using the counter + delay in rules to determine that the machine is working (it just doesn’t make sense, because there will never be a ‘work’ state without new count anyway)
The machine is saying that “it’s working” when in fact no counter is registered for a long time.
If there is a reason you need it, usually “1” is enough - waiting only for the first count.
Counting OEE
Allow production on downtime
This flags determine if a counter during other states then “work” will be accepted by the system.
If this is enabled, you can configure exceptions, by tagging downtimes with a DiscardCounters tag.
PackOS will accept counters during all states, except during downtimes marked with this tag
Please see ‘State guard’ to read how this affects production: https://ilabo.atlassian.net/wiki/spaces/LW/pages/1828454403/Counting+Production#State-guard
Max instantaneous performance
Max performance lets you control what is the maximum jump in counter value.
It’s used in a counter guard to reject impossible counter increases, read more:
You can set it to “0” to switch off the guard completely
Note: If a batch of products is queued and leaves the machine all at once, the observed performance would be much higher than the maximum performance specified as “Designed performance”.
Threshold of a minor stop
If set, all downtimes shorter than the specified duration, regardless of assigned tags, will be classified as “performance loss” and will be hidden from downtime lists.
You can show them explicitly by selecting the little cog icon, and selecting “Show minor stops”
Signals
To understand Stop delay after the previous machine & Root cause delay please take a look at:
“Is dummy” - will be covered in the future by a separate article