Skip to main content
Glama
Edge-JB
by Edge-JB

tc_fieldbus

Configure non-EtherCAT fieldbus devices (PROFINET, PROFIBUS, CANopen, DeviceNet, EAP) offline—create masters, slaves, or boxes, claim hardware resources, and import GSD or DBC files using single or batch operations.

Instructions

Create + configure NON-EtherCAT fieldbus masters/slaves/boxes (PROFINET / PROFIBUS / CANopen / DeviceNet / EAP net-vars) via ITcSmTreeItem CreateChild + ClaimResources + ConsumeXml. OFFLINE CONFIG ONLY — no confirm token needed; runtime needs a later activate/restart; TISC (safety) paths refused. For EtherCAT terminals/boxes use tc_ethercat instead. BATCH-FIRST: for more than one device use create_batch (N ops in ONE DTE attach, continue-on-error roll-up {count,succeeded,failed,results:[{parent,name,ok,child?,claimed?,error?}]}). SubType cheat-sheet — PROFINET ctrl 113/119/126/140, dev 115/118/142/143; PROFIBUS master 86 slave 97; CANopen master 87 slave 98; DeviceNet master 41/73/88 slave 62/74/99 monitor 59 box 5203; EAP device 112 publisher 9051 subscriber 9052. Actions: create_device (parent? default TIID / EAP device path, name, subType, before?, vInfo?, claimIndex?, save?) — CreateChild a master/slave/box; claimIndex immediately ClaimResources to bind underlying hardware; a wrong subType/vInfo ghost is cleaned up and reported as failure; create_batch (creates:[{parent?,name,subType,before?,vInfo?,claimIndex?}], save?); list_resources (path) — read-only; probes ITcSmTreeItem5.ResourcesCount then ResourceCount (Beckhoff pages disagree on the name) and reports which answered; claim_resources (path, index [1-based per Beckhoff examples], save?) — bind the node to underlying FC/EL hardware (offline config edit, NOT a runtime write); create_gsd_box (controllerPath, name, gsdPath, moduleIdentNumber, subType [REQUIRED — PN device subType, depends on controller variant], boxFlags? [GENERATE_NAME_FROM_PAB 0x0004 / GET_STATIONNAME 0x0400 / SET_NOT_IP_TO_OS 0x4000], dapNumber?, before?, save?) — PROFINET GSD/GSDML box; vInfo = gsdPath#moduleIdentNumber#boxFlags#dapNumber. CAVEAT: GSD box subType + vInfo format from a doc summary, confirm against infosys 1041677067 before relying on it; add_netvar (boxPath = EAP publisher/subscriber box, name, dataType [IEC type as vInfo, e.g. BOOL/INT], before?, save?) — EAP pub/sub variable (SubType 0; resulting ItemType 35 publisher / 36 subscriber); set_station_address (path = PROFIBUS slave/box, address, save?) — discovers the address element via ProduceXml then ConsumeXml a minimal envelope (the bare-number form is unverified and NOT shipped); if discovery fails, use get_xml + set_xml; import_dbc (masterPath = CANopen master, fileName [.dbc], importExtendedMessages?, importMultiplexedDataMessages?, keepUnchangedMessages?, communicateWithSlavesFromDbcFile?, save?) — CanOpenMaster/ImportDbcFile config import (requires TC3.1 build >= 4018); get_xml (path) — raw ProduceXml passthrough for discovering real param elements; set_xml (path, xml = partial XML, returnXml?, save?) — generic ConsumeXml escape hatch for any fieldbus param not covered above.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xmlNo
modeNoDTE attach mode; default active
nameNo
pathNo
saveNo
indexNo
vInfoNo
actionYes
beforeNoinsert before this sibling
parentNo
addressNo
boxPathNo
createsNo
gsdPathNo
subTypeNo
boxFlagsNo
dataTypeNo
fileNameNo
dapNumberNo
returnXmlNo
claimIndexNo
masterPathNo
controllerPathNo
moduleIdentNumberNo
keepUnchangedMessagesNo
importExtendedMessagesNo
importMultiplexedDataMessagesNo
communicateWithSlavesFromDbcFileNo
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Given no annotations exist, the description carries full burden and meets it thoroughly. It discloses offline-only behavior, no confirm token needed, runtime activation requirement, safety path restrictions, batch behavior with roll-up error structure, and cleanup of ghosts on wrong subType/vInfo. It also notes unverified caveats like 'bare-number form is unverified and NOT shipped' and GSD box subType format needing confirmation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and front-loaded with the core purpose, but its length (over 1000 words) is justified by the tool's complexity (10 actions, 28 parameters, multiple fieldbus types). Every sentence adds value, but the sheer volume could overwhelm an AI agent. A structured bullet format might improve scannability, but the current prose is functional.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's high complexity (10 actions, multiple protocols, no output schema), the description provides all essential context: offline-only constraint, sibling differentiation, batch optimization, detailed subType mappings, caveats on unverified features, and parameter semantics for each action. There are no obvious gaps for the described functionality.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only 7% schema description coverage and 28 parameters, the description compensates extensively. It documents each action's parameter usage inline (e.g., 'vInfo = gsdPath#moduleIdentNumber#boxFlags#dapNumber'), provides subType cheat-sheet for all fieldbus types, and explains purpose of action-specific parameters like claimIndex and importExtendedMessages. The description adds immense meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool creates and configures NON-EtherCAT fieldbus masters/slaves/boxes, listing specific protocols (PROFINET, PROFIBUS, CANopen, DeviceNet, EAP). It clearly distinguishes itself from sibling tc_ethercat by stating 'For EtherCAT terminals/boxes use tc_ethercat instead.' The verb+resource combination is highly specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use and when-not-to-use guidance. It states 'OFFLINE CONFIG ONLY — no confirm token needed; runtime needs a later activate/restart; TISC (safety) paths refused.' It directs toward create_batch for multiple devices and tc_ethercat for EtherCAT. This is comprehensive usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Edge-JB/TwinCAT-XAE-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server