Config Package
4 minute read
A config package holds the files a Motorcortex application reads when it starts: its settings, the EtherCAT bus layout, the links between modules, the mechanism description and your own parameters. You change the behaviour of the application by changing these files, without recompiling it.
How the files find each other
The application is told about one file only: config.json, on the command line in motorcortex.conf. Every other file is named from inside config.json. Click a box to open its page.
- A relative path starts in the folder of
config.json, which on the controller is/etc/motorcortex/config/. A path that starts with/is used as it is. - A file that
config.jsondoes not name is never read. The application does not scan the folders. - A feature’s files load only when the feature is enabled. A disabled feature’s link file can stay in the package.
That is why two config packages can look quite different and both be correct. When a package looks unfamiliar, read its config.json first.
Where the package lives on the controller
When you deploy a config package from motorcortex.io, the controller:
- Stores it in
/etc/motorcortex/apps-available/<name>-<version>-<timestamp>/. - Points the link
/etc/motorcortex/configat that folder, so it becomes the active configuration. - Restarts the
motorcortexservice, which starts the application with the new files.
Warning
Deploying a config package restarts the application straight away. Bring the machine to a safe stop before you deploy.
Earlier deploys stay in apps-available/, so you can point /etc/motorcortex/config back at one of them. Files the application writes while it runs, such as saved parameter values, land in the active package folder. Use Fetch config on your project in motorcortex.io to bring them back into your project; see Portal basics.
A shipped config package
This is MCX-Anthropomorphic-Robot, the config package of the standard robot application:
├── config.json # start-up settings and the paths of all other files
├── motorcortex.conf # which executable to start, and its command line
├── control
│ └── control.xml # parameter values
├── io
│ └── master.xml # EtherCAT bus configuration
├── linking # link files: two always loaded, one per feature
│ ├── base.link.json
│ ├── referencing.link.json
│ ├── manipulator-control.link.json
│ └── … # 14 in total
├── mech
│ └── mech-parameters.xml # mechanism description
├── motionfiles
│ ├── 00_ExampleFile.csv # recorded joint trajectories
│ └── 01_ExampleFile.csv
├── udp
│ ├── udp.link.json
│ └── udp.packets.json
└── user
└── parameters.json # your own parameters
Some files are not in the package:
control/persistence.binis created by the application at its first start.- The licence is kept outside the package, at
/etc/motorcortex/license.lic, so a new deploy does not leave it behind. accounts.confis only needed when you turn on login; the stock package does not name one.- An
io/firmwarefolder holds SII data for EtherCAT slaves whose EEPROM is too small.
The files
| File | Holds |
|---|---|
| config.json | Start-up settings, and the paths of every other file |
| motorcortex.conf | Which executable to start, and its command line |
| control.xml | Parameter values, plus persistence.bin for persistent values |
| io/master.xml | EtherCAT bus configuration |
| mech/mech-parameters.xml | Mechanism description and IK solver settings |
| linking/*.link.json | Links between parameters, and start-up values |
| udp/udp.packets.json | UDP packet definitions and their linking |
| user/parameters.json | Your own parameters, added without recompiling |
| motionfiles | Recorded joint trajectories the motion player replays |
| accounts.conf | User accounts and passwords for login |
| license.lic | The licence for this controller |