Retrieval-grounded robot program generation and simulation-based correction via Model Context Protocol

# Retrieval-grounded robot program generation and simulation-based correction via Model Context Protocol
Source: [https://arxiv.org/html/2608.21417](https://arxiv.org/html/2608.21417)
## Retrieval\-grounded robot program generation and simulation\-based correction via Model Context ProtocolJournal:CIE53 Proceedings

Zhichao ZhouEmail:[zhousaiensi@gmail\.com](mailto:[email protected])Address:Department of Mechanical Engineering, Chalmers University of Technology, Hörsalsvägen 7a, Gothenburg, SE\-412 96, SwedenSiyuan ChenEmail:[siyuan\.chen@chalmers\.se](mailto:[email protected])Corresponding author:Corresponding authorAddress:Department of Mechanical Engineering, Chalmers University of Technology, Hörsalsvägen 7a, Gothenburg, SE\-412 96, SwedenOmkar SalunkheEmail:[omkar\.salunkhe@chalmers\.se](mailto:[email protected])Address:Department of Mechanical Engineering, Chalmers University of Technology, Hörsalsvägen 7a, Gothenburg, SE\-412 96, SwedenEbru Turanoglu BekarEmail:[ebrut@chalmers\.se](mailto:[email protected])Address:Department of Mechanical Engineering, Chalmers University of Technology, Hörsalsvägen 7a, Gothenburg, SE\-412 96, SwedenJohan StahreEmail:[johan\.stahre@chalmers\.se](mailto:[email protected])Address:Department of Mechanical Engineering, Chalmers University of Technology, Hörsalsvägen 7a, Gothenburg, SE\-412 96, SwedenAnders SkooghEmail:[anders\.skoogh@chalmers\.se](mailto:[email protected])Address:Department of Mechanical Engineering, Chalmers University of Technology, Hörsalsvägen 7a, Gothenburg, SE\-412 96, Sweden

###### Abstract

Flexible manufacturing requires industrial robots to be reprogrammed rapidly as product variants change\. This paper presents a language\-model\-based workflow that generates, validates, and iteratively corrects ABB RAPID robot programs from natural language task descriptions\. A dual\-stream retrieval\-augmented generation \(RAG\) pipeline grounds code generation in verified technical documentation and production templates, reducing domain\-specific errors produced by ungrounded language models\. A custom Model Context Protocol \(MCP\) server connects the language\-model client directly to ABB RobotStudio for automated code upload, simulation execution, and diagnostic feedback\. The evaluation combines a 30\-query retrieval benchmark, scoped code\-generation checks, and RobotStudio case studies in a simulated pick\-and\-place manufacturing cell\. The simulation loop exposes execution failures that static and semantic checks alone cannot catch, including suction release\-height errors, unreachable placement targets, and configuration\-dependent recovery motions\. The results show how RAG and MCP can connect grounded code generation with executable feedback from industrial robot simulation software, while reducing but not eliminating expert setup and final supervision\.

###### Keywords:

Robot programming , Model Context Protocol , Large language models , Retrieval\-augmented generation

## 1Introduction

Flexible manufacturing depends on the ability to reconfigure production systems when product variants, fixtures, tools, or production volumes change\[[1](https://arxiv.org/html/2608.21417#bib.bib1)\]\. Industrial robots are central to this flexibility because they can perform handling, assembly, and process tasks across different product families\. Yet changing a robot task is still not as simple as changing a product plan: the new behavior must be programmed, checked against the cell layout, and validated before it can be trusted in production\[[2](https://arxiv.org/html/2608.21417#bib.bib2)\]\.

Robot programming therefore remains a persistent engineering bottleneck\. Conventional online and offline programming methods reduce deployment risk, but they still require specialist knowledge of robot languages, coordinate frames, tools, sensors, and process constraints\[[3](https://arxiv.org/html/2608.21417#bib.bib3)\]\. This challenge becomes more visible in high\-mix manufacturing, where product variants change frequently and the cost of repeated manual programming can limit the practical flexibility of the cell\.

Large language models \(LLMs\) offer a new interface for robot programming because they can translate natural\-language intent into code\-like control logic\[[4](https://arxiv.org/html/2608.21417#bib.bib4)\]\. Studies on conversational robot programming show that these models can reason about tasks and robot actions, but they also reveal limitations in reliability and domain specificity\[[5](https://arxiv.org/html/2608.21417#bib.bib5)\]\. Retrieval\-augmented generation \(RAG\) addresses part of this problem by grounding generation in external documentation and examples\[[6](https://arxiv.org/html/2608.21417#bib.bib6)\]\. For robot code generation, this is useful because local manuals and validated examples reduce hallucinated instructions and invalid programming patterns\[[7](https://arxiv.org/html/2608.21417#bib.bib7)\]\.

However, grounded text generation is not enough for industrial robot programming\. A generated robot program may follow the requested task and still fail when executed in a configured cell\. Reachability, path geometry, gripper release behavior, I/O state, and controller recovery are execution properties, not only code properties\. Automated testing research for industrial robotic systems makes the same point from a validation perspective: acceptance must be based on system behavior, not only on program structure\[[8](https://arxiv.org/html/2608.21417#bib.bib8)\]\. This leaves a gap between RAG\-based code generation and the execution\-level feedback needed for manufacturing use\.

This paper addresses that gap in a concrete industrial robot programming environment\. The workflow targets ABB RAPID programs and uses RobotStudio as the simulation and controller\-execution environment\. RAG retrieves relevant technical documentation and production templates, while the Model Context Protocol \(MCP\) exposes RobotStudio operations as callable tools\. Generated programs are uploaded to a virtual controller, executed, monitored, and corrected using execution status, event logs, joint readings, I/O signals, scene information, and program variables\. Screenshots are retained for documentation and human confirmation, but not used as the primary automated detection signal\.

The paper contributes a RobotStudio\-connected workflow for generating and validating vendor\-specific robot programs from natural language, an evaluation of dual\-stream RAG for reducing domain\-specific generation errors, and case evidence showing how execution feedback can reveal failures missed by text\-level checks\. The paper is structured as follows\. Section[2](https://arxiv.org/html/2608.21417#S2)reviews related work on industrial robot programming, offline simulation, RAG, and tool\-using LLM workflows\. Section[3](https://arxiv.org/html/2608.21417#S3)describes the proposed workflow\. Section[4](https://arxiv.org/html/2608.21417#S4)explains the evaluation design and metrics\. Section[5](https://arxiv.org/html/2608.21417#S5)reports the retrieval, generation, and RobotStudio results, followed by discussion and conclusion\.

## 2Literature Review

Industrial robot programming is shaped by proprietary controller languages and closed platform ecosystems\[[3](https://arxiv.org/html/2608.21417#bib.bib3)\]\. ABB systems use RAPID modules to define motion instructions, workobjects, tool data, I/O behavior, and execution routines\[[9](https://arxiv.org/html/2608.21417#bib.bib9)\]\. Offline programming and simulation environments such as ABB RobotStudio allow robot programs to be developed and tested before deployment\[[10](https://arxiv.org/html/2608.21417#bib.bib10)\]\. CAD\-based offline programming has also been studied as a way to reduce manual programming effort and make robot programming more accessible to users with manufacturing process knowledge\[[11](https://arxiv.org/html/2608.21417#bib.bib11)\]\. These approaches are useful because virtual controllers and simulation environments can reproduce controller behavior, robot kinematics, and many execution constraints without immediate access to hardware\.

For generated robot programs, offline simulation is more than visualization\. Code that passes a structural check can still fail because a motion is unreachable, a joint solution approaches a singularity, an arc is geometrically invalid, or a part is not released by an end\-effector\. Automated acceptance testing for industrial robotic systems has therefore been identified as an important direction for reducing manual validation effort\[[8](https://arxiv.org/html/2608.21417#bib.bib8)\]\. In the context of LLM\-generated robot code, this means that text\-level checks should be complemented by execution feedback from the target programming and simulation environment\.

Retrieval\-augmented generation addresses a separate but related problem: LLMs are prone to hallucinating technical details when asked to generate code in specialized domains\[[12](https://arxiv.org/html/2608.21417#bib.bib12)\]\. RAG injects external knowledge at inference time by retrieving relevant source material and conditioning generation on it\[[6](https://arxiv.org/html/2608.21417#bib.bib6)\]\. Retrieval quality is especially important in technical domains because relevant source material must appear early in the prompt context to influence generation\. Query reformulation methods based on hypothetical documents illustrate one way to reduce the vocabulary gap between user requests and technical documents\[[13](https://arxiv.org/html/2608.21417#bib.bib13)\]\. For robot code generation, this is useful because users describe intentions such as “pick a part from the conveyor”, while the knowledge base describes instructions, data types, and controller semantics\.

Tool\-using LLM workflows extend RAG by adding query decomposition, typed tool calls, and iterative correction\[[14](https://arxiv.org/html/2608.21417#bib.bib14)\]\. Recent work on agentic retrieval\-augmented generation also combines retrieval with tool use and feedback\[[15](https://arxiv.org/html/2608.21417#bib.bib15)\]\. The Model Context Protocol provides a standardized client\-server pattern for exposing external tools and data sources to LLM applications\[[16](https://arxiv.org/html/2608.21417#bib.bib16)\]\. In the proposed system, MCP is used as the interface layer between the LLM client and RobotStudio\. This separation keeps the language model outside the simulator while making simulator actions available as typed tools\.

These strands show that AI assistance can support robot\-program synthesis, but they leave an important validation gap for industrial cells\. Language\-model robot control has shown that natural\-language intent can be translated into executable\-looking programs\[[4](https://arxiv.org/html/2608.21417#bib.bib4)\]\. Conversational robot\-programming studies report similar potential, while also emphasizing reliability limits\[[5](https://arxiv.org/html/2608.21417#bib.bib5)\]\. RAG reduces some domain\-specific hallucinations by grounding generation in manuals and examples\[[7](https://arxiv.org/html/2608.21417#bib.bib7)\]\. However, text\-level correctness does not establish that a generated RAPID module will behave correctly in a configured RobotStudio station\. The novelty of the present work is therefore not only using an LLM to produce robot code, but connecting generation to execution\-level feedback from RobotStudio, where controller state, event logs, I/O signals, RAPID variables, and scene objects can be used to diagnose and correct failures\.

## 3Proposed Workflow

The workflow has two connected layers: a retrieval and planner layer that prepares grounded RAPID\-generation prompts, and a validation and execution layer that runs generated programs in RobotStudio and returns diagnostic feedback\. Figure[1](https://arxiv.org/html/2608.21417#S3.F1)summarizes the overall architecture\.

![Refer to caption](https://arxiv.org/html/2608.21417v1/pipeline.png)Figure 1:Overall retrieval\-and\-planning and validation\-and\-execution workflow\.### 3\.1Retrieval and planner layer

The retrieval and planner layer uses two retrieval streams\. The documentation stream is mainly based on ABB’s RAPID technical reference manual for instructions, functions, and data types, while the code\-template stream contains 106 validated RAPID examples provided by a Nordic leading vehicle company\. This separation is important because the two streams answer different questions\. Documentation explains instruction semantics and data types, while templates show how instructions are combined into executable module structures\.

For a user request, a query\-decomposition step splits the task into smaller retrieval tasks, such as locating motion instruction rules, I/O signal patterns, tool definitions, workobject conventions, or error handling examples\. Retrieved snippets are assembled into a structured prompt that requires a complete RAPID module, explicit entry procedure, balanced delimiters, no unresolved placeholders, and use of user\-specified tool and workobject names\.

### 3\.2Validation and execution layer

The validation and execution layer connects the LLM client to RobotStudio through a RobotStudio MCP bridge developed for this study and released as an engineering artifact\.111The RobotStudio MCP implementation used in this study is available at[https://github\.com/zhou\-zhichao/robotstudio\-mcp](https://github.com/zhou-zhichao/robotstudio-mcp)\.A RobotStudio add\-in exposes a local HTTP API over port 8080\. The MCP server translates tool calls from the language\-model client into HTTP requests to the add\-in, which then interacts with RobotStudio SDK objects and the virtual controller\. The bridge exposes 16 MCP tools covering station status, joint\-state reading, simulation start/stop/reset, RAPID upload and execution, event\-log retrieval, module/source inspection, RAPID variable access, I/O signal access, scene\-object inspection, and screenshot capture\.

### 3\.3Validation cycle

The validation cycle starts after the generator produces a RAPID module\. The workflow first applies structural checks to ensure that module and procedure delimiters are balanced and no template placeholders remain\. A semantic validation step then checks whether user\-specified objects, tools, I/O signals, and motion intent are represented\. The MCP bridge subsequently uploads the code into RobotStudio, executes it on the virtual controller, and retrieves controller feedback\.

When execution fails, the workflow uses the diagnostic output to revise the program\. The main feedback signals used in this paper are controller execution status, event\-log errors, joint readings, I/O signal values, and scene\-object positions and bounding boxes\. Scene introspection also helps avoid hardcoded assumptions\. For example, the workflow can list availablewobjdatadeclarations instead of manually deriving workobject coordinates, and it can read object bounding boxes to compute placement heights for different part sizes\.

## 4Experimental Setup

The evaluation combines retrieval benchmarking, code\-generation checks, and RobotStudio simulation cases\. Table[1](https://arxiv.org/html/2608.21417#S4.T1)states the unit of analysis for each part so that the results are interpreted at the correct scope\. Retrieval metrics compare configurations over the same 30 queries; code\-generation checks summarize observed module quality within logged generation sets; RobotStudio cases examine whether execution feedback can expose failures missed by text\-level checks\.

Table 1:Evaluation scope and intended comparisons\.The retrieval benchmark contains 30 queries constructed for pick\-and\-place operations, pallet flow, soldering sequences, signal processing, and error recovery logic\. Each query was manually associated with relevant documentation and code chunks\. In addition, 21 code\-generation trials were used to evaluate RAPID module quality across seven categories, including path following, pick and place, gripper libraries, simple motion, arc welding, tool definition, and target\-based programming\.

The first RobotStudio case is a conditional pick\-and\-place task in which a suction tool handles boxes of different heights\. This case was selected because the critical failure is not a syntax error: the generated program can compile and move to reachable targets while still failing to release the workpiece correctly in simulation\.

The second RobotStudio case evaluates product\-variant reconfiguration\. Two 14\-block pyramid tasks were run in the same RobotStudio cell with different product variants and target pallets\. The green box variant was twice as tall as the orange box variant and was placed on a different pallet\. This pair tests whether scene introspection and simulation feedback can support changed product geometry, placement heights, and robot configuration constraints\.

Three system configurations were compared for the code generation part\. The pure LLM baseline generated RAPID directly from the user query without retrieval\. The naive RAG configuration used the dual retrieval streams but no query decomposition or semantic validation step\. The full pipeline added query decomposition, structured prompt assembly, semantic review, and MCP\-based simulation feedback\. The metrics were selected to match the engineering risks in the workflow\. Retrieval precision, recall, and mean reciprocal rank \(MRR\) indicate whether relevant manuals and templates enter the prompt context early enough to influence generation\. For a query setQQ, MRR was computed as:

MRR=1\|Q\|​∑q∈Q1rankq,\\mathrm\{MRR\}=\\frac\{1\}\{\|Q\|\}\\sum\_\{q\\in Q\}\\frac\{1\}\{\\mathrm\{rank\}\_\{q\}\},whererankq\\mathrm\{rank\}\_\{q\}is the rank of the first relevant retrieved item for queryqq\. Structural pass rate checks whether the output is a complete RAPID module, while content pass rate and validation issues check whether the program represents the requested tools, workobjects, I/O behavior, and motion intent\. RobotStudio case studies were evaluated by generate\-test\-correct iterations, detected failure signal, correction source, and final execution outcome\.

## 5Results

### 5\.1Retrieval grounding and semantic validation

Table[2](https://arxiv.org/html/2608.21417#S5.T2)shows the retrieval benchmark results\. The document\-only baseline achieved 0\.52 precision and 0\.58 MRR\. Adding the code\-template stream raised precision to 0\.68 and MRR to 0\.72\. The improvement indicates that code examples help bridge the gap between user intent and formal RAPID terminology\.

Table 2:Retrieval performance averaged over 30 test queries\.The pure LLM baseline produced complete RAPID modules in all five baseline trials, but only one module passed content validation, giving a 20% content pass rate within this diagnostic set\. Typical failures included hallucinated instructions such asDIReadandDInput, misuse ofCTime\(\)as a numeric value, invalid signal declarations, redeclaration of built\-in constants, and non\-standard error handling syntax\. These errors are plausible to a general coding model but invalid for ABB RAPID\.

With retrieval grounding, all 21 generated modules passed structural validation\. The full pipeline also improved functional coverage in the logged generation set: motion\-instruction inclusion reached 100%, and I/O instruction coverage increased from 36% in naive RAG to 50% in the full pipeline\. Semantic review was logged for a subset of 10 full\-pipeline modules; 4 were flagged for correction because of missing user\-specified tools or workobjects, incorrect RAPID data type structures, non\-compiling function misuse, missing section markers, unsafe motion patterns, or excessive speed and blending\. These results are therefore reported as scoped quality checks rather than as one statistically balanced benchmark\.

### 5\.2Release\-height validation in RobotStudio

The pick\-and\-place case demonstrates why static and semantic checks are insufficient for robot programs that interact with physical workpieces\. The task used a suction tool to pick boxes from a conveyor and place them on a pallet\. A release offset calibrated for a 100 mm orange box was reused for a 200 mm green box\. The generated RAPID code remained structurally valid, and the motion targets were reachable, but the suction cup failed to release the green box because the tool\-center point was geometrically embedded in the box during release\.

![Refer to caption](https://arxiv.org/html/2608.21417v1/fig_release_height_geometry.png)Figure 2:Release\-height failure exposed through RobotStudio simulation\. The same \+40 mm offset works for the 100 mm orange box but leaves the TCP inside the 200 mm green box\. The corrected release offset is \+140 mm\.Figure[2](https://arxiv.org/html/2608.21417#S5.F2)shows the physical cause of the error\. The programmed release plane was valid for the orange box but 60 mm below the top surface of the green box\. The corrected release offset was computed as \+140 mm, equal to the original \+40 mm clearance plus the 100 mm height difference between the two product variants\.

The failure signal was not a manual judgement from the screenshot\. After the release command switched the suction output off, the workflow queried I/O state and scene objects through MCP\. A placement was accepted only when the workpiece was no longer moving with the suction tool and its global scene position remained near the expected pallet pose\. A failed release was recorded when the generated box did not detach or did not settle as an independent pallet object after the release command\. Structural checks did not detect this failure because the module syntax and motion instructions were valid; semantic review only partially captured it because it did not model suction geometry\. Screenshots were retained for documentation of the final state\.

This case shows that the purpose of MCP is not only to upload code into RobotStudio, but to close a feedback loop around cell constraints\. The diagnostic value comes from running the generated program in the same type of virtual controller and scene geometry that an engineer would use for offline validation\.

### 5\.3Product\-variant reconfiguration

The product\-variant reconfiguration case used two 14\-block pyramid tasks in the same simulated manufacturing cell\. In both variants, the workflow had to generate blocks from the conveyor, wait for sensor conditions, pick one block at a time, and place it into a 3\-layer pyramid\. The important difference is that the product and target pallet changed\. The orange case used shorter boxes on the right pallet; the green case used taller boxes on the left pallet\.

![Refer to caption](https://arxiv.org/html/2608.21417v1/fig_result_orange_pyramid.png)![Refer to caption](https://arxiv.org/html/2608.21417v1/fig_result_green_pyramid.png)\(a\) Orange\-box variant, right pallet\(b\) Green\-box variant, left palletFigure 3:Product\-variant reconfiguration in the RobotStudio cell\. The orange variant succeeded on the first attempt after scene introspection; the green variant required additional recovery because the changed pallet and box geometry exposed reach and joint\-configuration constraints\.Two MCP introspection tools were decisive in the orange\-box variant\. First,list\_rapid\_variablesallowed the workflow to discover existing workobjects directly from the controller, avoiding manual coordinate reconstruction\. Second,get\_scene\_objectsreturned object bounding boxes, allowing the workflow to read the orange box size as 200 mm×\\times200 mm×\\times100 mm and compute the placement heights for the pyramid layers\. The orange 14\-block pyramid succeeded on the first attempt\.

The green\-box variant changed both the box height and the placement side\. The workflow again read the bounding box, now 200 mm×\\times200 mm×\\times200 mm, and recomputed the release and layer heights\. The first two attempts failed because some placement targets were outside the feasible reach envelope\. After the target base and approach height were adjusted, the third attempt placed six blocks but then triggered a controller\-reported out\-of\-range error on the robot’s fifth axis, one of the wrist\-orientation axes\. This was not a textual error in RAPID code; it emerged from the interaction between target placement, robot kinematics, and the joint configuration selected during repeated cycles\.

![Refer to caption](https://arxiv.org/html/2608.21417v1/fig_result_green_pyramid_j5_fail.png)![Refer to caption](https://arxiv.org/html/2608.21417v1/fig_result_green_pyramid.png)\(a\) Failure after wrist\-axis drift\(b\) Successful run after recovery patternFigure 4:Joint\-configuration recovery in the green\-box variant\. The successful correction usedMoveAbsJto reset the robot to a calibration pose andMoveJto return to the named home pose without forcing the fifth axis back near its stored high\-angle home pose\.The correction is shown in Figure[4](https://arxiv.org/html/2608.21417#S5.F4)\. The unsuccessful versions returned to the stored home joint pose usingMoveAbsJ; joint readings showed this pose placed the fifth axis at approximately 111\.7 degrees\. This value is reported as a high\-angle recovery pose, not as the maximum angle reached during the failing path\. The actual failure was identified from the RobotStudio controller error state and the experiment log entry reporting an out\-of\-range wrist\-axis motion during the subsequent move\. The successful version first usedMoveAbsJto move to a calibration pose with the fifth axis near zero, then usedMoveJto return to the named home pose so the controller could choose a safer joint solution\. The final green\-pyramid program placed all 14 blocks successfully\.

## 6Discussion

The results suggest that industrial robot programming needs a different kind of LLM workflow from general robot\-task planning\. Code as Policies shows that LLMs can translate natural\-language intent into executable control logic\[[4](https://arxiv.org/html/2608.21417#bib.bib4)\]\. ChatGPT\-for\-robotics shows a related potential for robot\-oriented reasoning and programming, while also noting reliability limits\[[5](https://arxiv.org/html/2608.21417#bib.bib5)\]\. That framing is useful, but it often leaves the generated program separated from the vendor\-specific controller, workobjects, I/O signals, and station geometry that determine whether the program will actually run\. In contrast, the workflow in this paper treats RobotStudio feedback as part of the generation process rather than as a final manual check\.

The RAG results are consistent with earlier work on RAG for robot code generation\[[7](https://arxiv.org/html/2608.21417#bib.bib7)\]: grounding helps because RAPID programming contains many domain\-specific names, data structures, and controller conventions that are unlikely to be reliably inferred from a general model alone\. The present work extends that idea by adding an execution channel\. The release\-height and pyramid cases show that some errors only appear after the program is run in the configured RobotStudio station\. This is an important distinction from retrieval\-only approaches: RAG can reduce invalid code constructs, but it cannot by itself know whether a suction release height, a placement pose, or a repeated recovery motion is feasible in the active station\.

The role of MCP in this workflow is to make RobotStudio feedback available through explicit interfaces instead of screen interaction or ad hoc scripts\. The language\-model client can request event logs, joint readings, I/O values, RAPID variables, and scene\-object data as tool outputs, which makes the correction loop easier to inspect and reproduce\. Compared with conventional automated testing for industrial robotic systems\[[8](https://arxiv.org/html/2608.21417#bib.bib8)\], the distinctive point is that the same feedback can be used not only to accept or reject a program, but also to guide the next code\-generation attempt\.

The human involvement boundary is also important\. The reported workflow did not autonomously design the RobotStudio station, tools, workobjects, I/O mapping, or Smart Components; these were prepared before the experiments\. The documentation set, templates, prompts, and task descriptions were also curated by the authors\. During the reported validation loops, no manual line\-by\-line RAPID editing was counted inside the generate\-test\-correct cycle, but a human still initiated tasks, selected when to run candidate corrections, and confirmed final results using tool outputs and screenshots\. The claim is therefore reduced manual program debugging, not fully autonomous cell engineering\.

Several limitations remain\. The evaluation is preliminary and uses a limited number of tasks and one RobotStudio cell\. The pure LLM baseline contains only five trials, the semantic\-review subset contains 10 modules, and no statistical significance test was performed\. The RobotStudio evidence should therefore be read as case\-based mechanism validation rather than a broad benchmark\. Safety PLC integration, welding process constraints, and multi\-robot coordination were not validated\. The current bridge is also platform\-specific: applying the method to KUKA, FANUC, or PLC environments would require corresponding MCP tool implementations\. The system also does not yet persist learned corrections across sessions; product\-specific release offsets, feasible placement envelopes, and recovery poses should eventually be stored in a persistent knowledge base and enforced as hard generation constraints\.

## 7Conclusion

This paper presented a workflow for generating and validating ABB RAPID programs by combining retrieval\-grounded code generation with Model Context Protocol access to RobotStudio\. The retrieval results show that combining technical documentation with production\-style code templates improves access to relevant RAPID knowledge, while the generation checks show fewer domain\-specific errors than an ungrounded LLM baseline\. The RobotStudio cases demonstrate the added value of execution feedback: generated programs that are textually plausible can still fail because of release geometry, unreachable targets, or unsafe recovery motions\. By exposing RobotStudio operations through MCP tools, the workflow connects natural\-language task descriptions, grounded RAPID generation, simulation execution, and diagnostic correction in a single loop\. The approach does not remove the need for a prepared station or expert supervision, but it provides a practical route toward faster reprogramming and debugging of industrial robot cells\.

## Acknowledgments

The study was supported by Vinnova, Sweden’s innovation agency, under grant number 2024\-03234, “Code Agents: AI\-powered end\-to\-end solutions for flexible manufacturing\.” The work was carried out within Chalmers’ Area of Advance Production, whose support is gratefully acknowledged\. The computations were enabled by resources provided by the National Academic Infrastructure for Supercomputing in Sweden \(NAISS\), partially funded by the Swedish Research Council through grant agreement no\. 2022\-06725\.

## References

- Johansson et al\. \[2009\]B\. Johansson, J\. Heilala, S\. Leong, A\. Fasth, Y\. T\. Lee, J\. Stahre, F\. Riddick,Enabling flexible manufacturing systems by using level of automation as design parameter,in: Proceedings of the 2009 Winter Simulation Conference, 2009, pp\. 2183–2194\. doi:[10\.1109/WSC\.2009\.5429336](http://dx.doi.org/10.1109/WSC.2009.5429336)\.
- Hagele et al\. \[2016\]M\. Hagele, K\. Nilsson, J\. N\. Pires, R\. Bischoff,Industrial robotics,in: B\. Siciliano, O\. Khatib \(Eds\.\), Springer Handbook of Robotics, Springer, Cham, 2016, pp\. 1385–1422\.
- Pan et al\. \[2012\]Z\. Pan, J\. Polden, N\. Larkin, S\. Van Duin, J\. Norrish,Recent progress on programming methods for industrial robots,Robotics and Computer\-Integrated Manufacturing 28 \(2012\) 87–94\. doi:[10\.1016/j\.rcim\.2011\.08\.004](http://dx.doi.org/10.1016/j.rcim.2011.08.004)\.
- Liang et al\. \[2023\]J\. Liang, W\. Huang, F\. Xia, P\. Xu, K\. Hausman, B\. Ichter, P\. Florence, A\. Zeng,Code as policies: Language model programs for embodied control,in: IEEE International Conference on Robotics and Automation, 2023, pp\. 9493–9500\.
- Vemprala et al\. \[2024\]S\. Vemprala, R\. Bonatti, A\. Bucker, A\. Kapoor,Chatgpt for robotics: Design principles and model abilities,IEEE Access 12 \(2024\) 55682–55696\.
- Lewis et al\. \[2020\]P\. Lewis, E\. Perez, A\. Piktus, F\. Petroni, V\. Karpukhin, N\. Goyal, H\. Kuttler, M\. Lewis, W\.\-t\. Yih, T\. Rocktaschel, S\. Riedel, D\. Kiela,Retrieval\-augmented generation for knowledge\-intensive nlp tasks,in: Advances in Neural Information Processing Systems, volume 33, 2020, pp\. 9459–9474\.
- Salunkhe et al\. \[2026\]O\. Salunkhe, S\. Chen, A\. Syberfeldt, J\. Stahre,Developing rags for robot code generation,IOP Conference Series: Materials Science and Engineering 1342 \(2026\) 012064\. doi:[10\.1088/1757\-899X/1342/1/012064](http://dx.doi.org/10.1088/1757-899X/1342/1/012064)\.
- dos Santos et al\. \[2024\]M\. G\. dos Santos, S\. Halle, F\. Petrillo, Y\.\-G\. Gueheneuc,Aat4irs: Automated acceptance testing for industrial robotic systems,Frontiers in Robotics and AI 11 \(2024\)\.
- ABB Robotics \[2024a\]ABB Robotics, Technical reference manual: RAPID overview, RobotWare 7, 2024a\. Document ID: 3HAC065040\-001\. Accessed April 2026\.
- ABB Robotics \[2024b\]ABB Robotics, Robotstudio suite: Offline programming and simulation software,[https://new\.abb\.com/products/robotics/software\-and\-digital/robotstudio](https://new.abb.com/products/robotics/software-and-digital/robotstudio), 2024b\. Accessed April 2026\.
- Neto and Mendes \[2013\]P\. Neto, N\. Mendes,Direct off\-line robot programming via a common cad package,Robotics and Autonomous Systems 61 \(2013\) 896–910\. doi:[10\.1016/j\.robot\.2013\.02\.005](http://dx.doi.org/10.1016/j.robot.2013.02.005)\.
- Zhang et al\. \[2025\]Z\. Zhang, C\. Wang, Y\. Wang, E\. Shi, Y\. Ma, W\. Zhong, J\. Chen, M\. Mao, Z\. Zheng,Llm hallucinations in practical code generation: Phenomena, mechanism, and mitigation,Proceedings of the ACM on Software Engineering 2 \(2025\)\.
- Gao et al\. \[2023\]L\. Gao, X\. Ma, J\. Lin, J\. Callan,Precise zero\-shot dense retrieval without relevance labels,in: Proceedings of the 61st Annual Meeting of the Association for Computational Linguistics, 2023, pp\. 1762–1777\.
- Yao et al\. \[2023\]S\. Yao, J\. Zhao, D\. Yu, N\. Du, I\. Shafran, K\. Narasimhan, Y\. Cao,React: Synergizing reasoning and acting in language models,in: International Conference on Learning Representations, 2023, pp\. 1–12\.
- Singh et al\. \[2025\]A\. Singh, A\. Ehtesham, S\. Kumar, T\. T\. Khoei,Agentic retrieval\-augmented generation: A survey on agentic rag,arXiv preprint arXiv:2501\.09136 \(2025\)\.
- Anthropic \[2024\]Anthropic, Introducing the model context protocol,[https://www\.anthropic\.com/news/model\-context\-protocol](https://www.anthropic.com/news/model-context-protocol), 2024\. Accessed April 2026\.