Import a PROFINET GSDML into the CODESYS device repository

Why the download action fails on a GSDML

download missing device information reaches one source: the descriptions for devices published with CODESYS itself. Fieldbus slaves arrive differently. A PROFINET device is described by a GSDML file, the standardized machine-readable description format for PROFINET, and the drive or device vendor supplies the file for its own product. EtherCAT slaves ride in on ESI files and CANopen slaves on EDS files, and every one of them lands in a project the same way: installed into the device repository, then assigned to the node. Clicking the download action on a node whose description comes from a vendor file produces Download fehlgeschlagen every time, because that route never carried such files.

The same import-first rule holds on every fieldbus. It is why, when you choose a PROFIBUS DP slave for CODESYS Control Win, the slave's own GSD file travels with your selection and still has to go through the repository.

What you need

• The GSDML package from the drive maker, matched to your model and interface. For the Schneider Electric Lexium mDrive PROFINET interface, the maker's download page supplies Profinet_3_0_0_2.zip; one package, extracted before import.
• A project that shows the missing-device placeholder, the node the download action was failing on.
• A CODESYS 3.5-era engineering environment. Menu labels shift between versions, so use the repository's install function wherever your build keeps it.
• About 5 minutes.

Extract the package before importing unless your dialog accepts archives, and keep any files delivered alongside the GSDML in the same folder.

Install the GSDML into the device repository

1. Unpack the maker's package on the engineering workstation and locate the GSDML XML.
2. Open the device repository dialog in your CODESYS version and run its install command.
3. Select the GSDML XML for your drive and finish the dialog.
4. Check the repository list before touching the project tree: the drive's entry must appear there, and that check is the gate for every step after it.

If the install rejects the file, you usually picked the .zip instead of the XML inside it, or the file describes a sibling model. Both are fixed by re-selecting; neither touches your project.

One nearby command is not the import. Some installations expose a dialog called Generate PROFINET Device from GSDML, which builds a CODESYS devdesc.xml from a GSDML you authored yourself, for publishing your own device. Consuming a vendor's file is the reverse job, and it happens in the repository.

Set the device on the placeholder node

1. In the project tree, right-click the node showing the missing-device placeholder.
2. Choose Gerät setzen, the set-device command.
3. Select the imported drive entry and confirm.
4. The tree now shows the drive's own description in place of the placeholder.

Pick the entry that matches your hardware, and skip whatever the list happens to show by default. The Lexium32 entries that ship with SoftMotion EtherCAT drivers, for instance, describe a different product on a different interface; they are not the mDrive PROFINET device. The same trap exists on CANopen, where an example fails when the device type is wrong.

Check the import and the configuration

• The repository list keeps the drive's entry after you close the dialog.
• The project tree shows the device, and the missing-device placeholder is gone.
• A compile finishes with 0 device-configuration errors.
• The node now offers the drive's catalogue: the modules and process-data fields the GSDML defines. Select a module arrangement the drive documentation supports, then map each application variable to its field and direction.

The GSDML carries the network identity and that catalogue. It carries no motor sizing, no current limits and no control-word semantics; those come from the drive documentation, and the drive needs its station name and IP address assigned on the network before anything moves. Confirm data exchange with the diagnostics, and keep the axis clear until the diagnostics show clean exchange: a drive that has just received valid process data can move on the first enable.

Example: an mDrive placeholder, end to end

Scenario: you opened a SoftMotion example, added the mDrive PROFINET node, clicked download missing device information and got Download fehlgeschlagen. The project is intact; the description is simply absent from the repository. Here is the job against a 5-minute budget:

1. Extract Profinet_3_0_0_2.zip and locate the GSDML XML: 1 minute.
2. Install the XML through the repository's install command and confirm the entry in the list: 2 minutes.
3. Right-click the placeholder and run Gerät setzen on the imported entry: 1 minute.
4. Compile to 0 device-configuration errors: 1 minute.

That is 1 + 2 + 1 + 1 = 5 minutes, one vendor package and two IDE operations. The result: the repository carries the mDrive description, the tree shows the device instead of the placeholder, the build is clean and the module catalogue is ready to map. Drive setup, motor sizing and motion tuning are still ahead of you, and they are driven by the drive documentation, not by anything the import did.

Which route to use when

Recommendation: when a third-party PROFINET, EtherCAT or CANopen slave shows a missing-device placeholder, skip download missing device information entirely. Import the vendor's description into the device repository, set the device with Gerät setzen, and compile to 0 errors before you map process data. Keep the download action for devices published with CODESYS itself, and keep Generate PROFINET Device from GSDML for device makers.

Once the drive and controller are exchanging data, the operator-facing side is its own job: plan a touchscreen operator interface for factory controls covers the screen, its mounting and the text sizes for a shop-floor viewer.

Questions