Overview
The Fill Rate (%) represents the ratio of the combined volume of all parts within a specific build compared to the maximum allowable print volume of the assigned machine.
How Fill Rate is Calculated
The method used to determine the fill rate depends on whether a custom Worker Script is active in your environment:
1. Default (Hard-Coded) Calculation
If a Fill Rate worker is not implemented, the system uses a standard internal formula. This typically sums the volumes of all individual parts assigned to the build and divides that total by the total volume of the machine's defined bounding box.
2. Worker Script Calculation
When a custom Worker Script is used, the system bypasses the default logic in favor of the script's specific instructions. This allows for more complex logic, such as accounting for required gaps between parts or specific nesting orientations.
Setting Up the Worker in the Dashboard
This script calculates the Fill Rate (%) of a specific build within AMFG. It automatically retrieves the parts inside a build, calculates their combined volume, compares it against the selected machine's maximum allowable print volume, and returns a percentage to the AMFG interface.
To implement a script calculation, follow these steps in the AMFG Management Console:
1. AMFG System Prerequisites
For this script to function correctly, your AMFG environment must be set up with the correct Machine Groups: Machines must have their physical platform size dimensions defined (x, y, z). This can be done by navigating to Settings > Production Parameters > Machines tab > Machine Details.
2. Creating the Fill Rate Worker
Navigate to the Autonomous -> Worker Dashboard: Access the section of the platform where automated scripts (Workers) are managed.
βCreate a New Worker: Select the option to add a new worker specifically for the Fill Rate type calculations with the corresponding Language: Python.
βOpen the new worker and create a Rule that defines when this worker should be applied:
βInput the Script Phases: Your script must follow a three-phase structure to communicate with the UI:
Phase 1: Initialization: Use
engine.getContext()to fetch thecalculationTokenandbuildId.Phase 2: The Calculation: Use
engine.buildRetrieveto get the parts list and perform your volume math.Phase 3: Returning Values: Use
engine.updateResponseto send the final percentage back to the platform.
Save and Activate: Once saved, the Create a Build page will begin using your custom logic to display the Fill Rate percentage.
3. Script Breakdown: The Three Key Phases
Phase 1: Initialization (The Start)
The script must first orient itself within the AMFG environment by grabbing the current context.
# Initialise the "context" engine
context = engine.getContext()
engine.log(JSON.stringify(context))
What it does: It securely fetches the
calculationTokenand thebuildIdrequired to target the exact build the user is looking at in the UI.
Phase 2: The Calculation (The Middle)
This is the heavy lifting of the script. It breaks down into sub-tasks, starting with:
Retrieve the Build & Parts List
build1 = engine.buildRetrieve({'id': context.buildId});
model_array = build1.ticketModelsWhat it does: Uses the
buildIdto pull the full build data. It isolatesticketModels, which act as a key-value list of part IDs and their respective quantities.
This can then be used to perform various tasks, such as:
Sum up the volume of all parts in the build
Look up the machine
Look up various properties
Phase 3: Returning Values (The End)
Once the math is complete, the script pushes the final answer back to the AMFG user interface.
engine.updateResponse({
'fillRate': fill_rate,
'calculationToken': context.calculationToken
})What it does: It packages the calculated
fill_ratealongside the authorizationcalculationTokenand sends it back to the engine.
4. Understanding the Output Behavior
The fillRate sent back to AMFG is a standard number.
0 to 100: Represents the percentage of the available volume used.
Above 100: The calculation will successfully pass numbers higher than 100 back to the system. AMFG is designed to accept this and will display the build as red in the UI, flagging to the user that the build is currently over-capacity.
β



