Config Package

See which files a config package holds, how the application finds them at start-up, and where the package lives on the controller.

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.json does 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:

  1. Stores it in /etc/motorcortex/apps-available/<name>-<version>-<timestamp>/.
  2. Points the link /etc/motorcortex/config at that folder, so it becomes the active configuration.
  3. Restarts the motorcortex service, which starts the application with the new files.

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.bin is 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.conf is only needed when you turn on login; the stock package does not name one.
  • An io/firmware folder 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