Scaling Check

What is the recommended overall approach to scaling a Kanoa implementation?

Build a good reference implementation for an asset type first, then reuse it with import/export, asset duplication, or scripts, and review and adjust whatever must be unique for each copy (name, tag paths, ERP name, schedule settings, and so on). Scale a validated pattern rather than copying incomplete configuration. See Scaling Across the Enterprise.

You need to migrate an existing asset hierarchy from another system. What approach does the course recommend?

Export the hierarchy to a flat file, convert it into Kanoa's asset export JSON structure (using an existing asset export file as the template, for example with AI), and import the file on Configuration → Ops → Assets. The more you export (assets, items, states, modes, links), the more you can import. See Create Assets with Scripting.

How does the rollout script decide which asset to copy, and why does that depend on asset groups?

It looks up the assets in the Machines asset group and copies the first one returned (Machine 1) with system.kanoa.asset.copyAsset. Asset groups let a script find a template for a type of asset without hard-coding an asset ID. See Create Assets with Scripting.

What does system.kanoa.asset.copyAsset copy?

An identical copy of the asset, including its child assets and its links to modes, states, items, and attributes. See Create Assets with Scripting and copyAsset.

After copying Machine 1, why does the rollout script still write to tags in Ignition?

Copying the asset doesn't connect the new asset to its own equipment data. The script writes each new asset's MQTT path parameter (Line/Parameters.MQTTPath under the asset's tag path) to its matching [Kanoa]CoreForge Sim/Site/Machining/Machine N/assetInputs path. Without that, the copy would not read its own simulator tags. See Create Assets with Scripting.

The item rate script stops with a KeyError on 'boxes'. What is the likely cause?

The script looks up unit IDs by name, and the boxes unit doesn't exist (or isn't enabled). It is used as the outfeed unit for Manual Pack 1, and you create it in Configure Production Rates. See Create Items with Scripting.

Why is the system.kanoa API preferred over direct SQL for bulk configuration?

It follows Kanoa's data model, executes application logic consistently, reduces the risk of missing related records, and uses supported functions that behave the way the product itself does. See Create Assets with Scripting.

In what order must downtime configuration be created, and where is the state code assigned?

State categories must exist before states can be created in them, and states must exist before they can be linked to assets. The state code is assigned on the asset-state link, by system.kanoa.asset.linkAssetStates, not on the state itself. See Create States with Scripting.

How does the generateStates script avoid assigning a state code that is already in use on the asset?

It reads the states already linked to the asset, takes the highest existing state code, and numbers the new links from the next value up. If the asset has no linked states, it starts at 1. See Create States with Scripting.

Why do the scripts look up IDs by name or path instead of hard-coding them?

Database IDs may differ between development, test, and production systems. Names and paths, like CoreForge\Philadelphia\Machining\Machine 1, are more portable, so the same script works on any gateway that has the same configuration. See Create States with Scripting.