Adapting I/O Devices

This example shows how to use the dobot-plus skill in an AI Agent to adapt external devices via controller I/O (DI/DO) or tool-end I/O (ToolDI/ToolDO). Instead of writing Lua, HTTP APIs, and UI pages by hand, the Skill generates plugin scaffolding from your I/O requirements in Requirements.md—you only need to prepare the document and invoke /dobot-plus in the IDE.

Workflow

Environment Setup

Confirm the following before development. See Development Environment for more detail.

Dependency	Version / Notes
Node.js	v20 or later
IDE	Supports Agent Skills (e.g. Cursor)
@dobot-plus/cli	Global install; provides the dpt command
@dobot-plus/skill	Global install; provides the /dobot-plus skill

Install:

npm install -g @dobot-plus/cli @dobot-plus/skill@latest

Verify:

node -v    # Should print v20.x or later
dpt -v     # Confirm CLI works

After install, the Skill is deployed to ~/.agents/skills/dobot-plus. Enable Agent Skills in your IDE settings to use it.

Writing Requirements.md (General Requirements)

The Skill does not create or modify Requirements.md. You must write a complete I/O requirements document in the project root.

Required Content

Category	Description
Communication method	Controller DI/DO, or tool-end ToolDI/ToolDO (pick one; do not mix)
I/O ports	Port number and direction (input/output) for each function
Level semantics	What high/low level means for each port
Status criteria	Success/failure conditions for read functions (e.g. DI-1 high = started)
Function semantics	Each atomic operation exposed externally (output control / status read)
Operation flow	Typical start/stop/reset sequence (including wait and timeout guidance)

Recommended Outline

1. Device overview
2. Communication method (controller I/O or tool-end I/O)
3. I/O port details (port number, direction, level meaning)
4. Function list (split into atomic operations)
5. Operation flow
6. Version info and safety notes

Split functions into atomic operations whenever possible—each function should do one thing. Use camelCase Verb+Noun naming, e.g. StartDevice, GetStartStatus.

I/O vs Modbus

Item	I/O control	Modbus RTU
Protocol field	"protocol": "io"	"protocol": "modbus-rtu"
Underlying API	DI / DO / GetDO or ToolDI / ToolDO	Register read/write
Document focus	Port numbers and level semantics	Register addresses, bit fields, comm params
Generates modbus.lua	No	Yes

Controller I/O APIs: IO commands. Tool-end I/O: Tool commands.

Generate with AI

If you have wiring diagrams, PLC interaction specs, or vendor manuals, ask a general-purpose AI model to turn the I/O definitions into Requirements.md, review it, and save it in the project root.

Sample AI prompt:

You are an industrial device I/O integration documentation assistant. From the materials I provide, produce a Requirements.md document that meets the requirements below.

## Output requirements
1. Output Markdown only from my materials; do not invent port numbers, level meanings, or timing
2. Mark uncertain items as "TBD"; do not guess
3. Keep function names in English camelCase, e.g. StartDevice, GetStopStatus

## Must include
1. Device overview
2. Communication method: controller DI/DO or tool-end ToolDI/ToolDO
3. I/O port table: port number, direction (input/output), high/low level meaning
4. Function list: one atomic operation per item, with port and expected level
5. Typical operation flow (e.g. start → wait for feedback → confirm status)
6. Version info and safety notes

## Function splitting rules
- One action per function; camelCase Verb+Noun naming
- Do not merge: StartAndStopDevice, ControlDevice, etc.
- Separate write (DO output) and read (DI input) functions
- Read functions must define return value meaning (e.g. 1=success, 0=failure)

---
Source material:
[Paste wiring notes / manual sections / PLC interaction table]

After generation, verify manually:

• Communication method (controller vs tool-end) matches actual wiring
• DI/DO port numbers match on-site wiring
• High/low level meanings match the device manual
• Functions are split into atomic operations
• Status read success/failure criteria are clear

Save the file as Requirements.md in the project root, then invoke /dobot-plus in an IDE Agent session.

Device Examples

The examples below use controller DI/DO to interact with external devices: DO sends start/stop commands; DI reads device feedback. Run dpt create first, then write Requirements.md.

External device I/O control

Create project:

dpt create

Example prompts:

$ dpt create
? Please input plugin name: io
? Please input plugin description: A plugin demo for external device IO control
? Please input plugin version: 1-0-0-test
? Please input device IP: 192.168.5.1

Then:

cd io

Full I/O control Requirements.md example

# I/O Control Example

> Send commands to an external device via controller digital outputs (DO) and read status via digital inputs (DI).

## 1. Device overview

This plugin controls an external processing device over controller I/O—no Modbus or TCP.

## 2. Communication method

| Item | Description |
| --- | --- |
| Protocol | Controller I/O |
| Output ports | DO (digital output) |
| Input ports | DI (digital input) |
| Lua API | `DO(index, ON\|OFF)`, `DI(index)`, `GetDO(index)` |

## 3. I/O ports

| Port | Direction | High level | Low level |
| --- | --- | --- | --- |
| DO-1 | Output | Start command | Idle / not started |
| DO-2 | Output | Stop command | Idle / not stopped |
| DI-1 | Input | Device started | Device not started |
| DI-2 | Input | Device stopped | Device not stopped |

## 4. Functions

### 4.1 StartDevice — start external device

- Action: `DO(1, ON)` — high level on DO-1
- UI: button

### 4.2 GetStartStatus — read start status

- Action: read `DI(1)`
- Return: `1` if DI-1 is high (started); `0` if not ready or failed
- UI: read-only status

### 4.3 StopDevice — stop external device

- Action: `DO(2, ON)` — high level on DO-2
- UI: button

### 4.4 GetStopStatus — read stop status

- Action: read `DI(2)`
- Return: `1` if DI-2 is high (stopped); `0` if not ready or failed
- UI: read-only status

## 5. Operation flow

### Start

1. Call `StartDevice` — DO-1 high
2. Wait for device response (1–3 s recommended)
3. Call `GetStartStatus` — confirm DI-1 is high

### Stop

1. Call `StopDevice` — DO-2 high
2. Wait for device response (1–3 s recommended)
3. Call `GetStopStatus` — confirm DI-2 is high

## 6. Safety notes

- Confirm DO wiring before operation to avoid unintended device triggers
- After stop command, confirm safe shutdown via DI feedback
- If DI stays low, check external device fault or wiring

After generation, verify:

• Communication method in Requirements.md is controller I/O (or tool-end I/O if applicable)
• DO/DI port numbers match on-site wiring
• Each function describes a single operation

---

Tool-end I/O (ToolDI / ToolDO)

If the device is wired to the robot tool end rather than the controller, set communication to tool-end I/O and use ToolDO / ToolDI in function descriptions. For manual implementation, see Basic IO example.

Using the Agent Skill

1. Invoke the Skill in the IDE

Open the plugin project and run in IDE Chat:

/dobot-plus

The Agent runs the Skill workflow automatically:

1. Read and parse Requirements.md
2. Split functions into atomic items and write function.json (protocol.protocol = io)
3. Validate function.json
4. Generate httpAPI.lua, userAPI.lua, block/script configs, etc.
5. Generate ui/Main.tsx
6. Implement I/O logic in lua/[projectName].lua using DI / DO APIs

2. Review generated output

File / directory	Description
function.json	Function definitions; protocol.protocol is io
lua/[projectName].lua	I/O read/write and business logic
lua/httpAPI.lua	HTTP handlers for UI
lua/userAPI.lua	Block/script programming API
configs/Blocks.json	Block programming config
configs/Scripts.json	Script programming config
ui/Main.tsx	Plugin control UI
.dobot/http/http.ts	Frontend HTTP client

I/O protocol does not generate modbus.lua. The Agent uses DI, DO, GetDO (or ToolDI, ToolDO) directly in lua/[projectName].lua.

Example generated Lua:

projectName.StartDevice = function()
    DO(1, ON)
end

projectName.GetStartStatus = function()
    return DI(1) == ON and 1 or 0
end

3. Local debugging (optional)

Run this step only if you need to validate behavior before building; skip if you will test after importing into DobotStudio Pro.

Confirm hardware connection

• Controller DI/DO wiring must match port definitions in Requirements.md
• Ensure the controller IP in dpt.json matches the real device

{
  "ip": "192.168.5.1",
  "pluginPort": 22100
}

From the plugin project directory, run:

dpt dev

The CLI will prompt whether to connect to a real device:

$ dpt dev
? Debug lua on real device? Yes
? Please check the device IP: 192.168.5.1 (y/n)

After connecting, saved Lua files sync to the controller automatically; test DO output and DI reads in the browser UI.

Adjust UI copy, Resources/i18n/, and block/script configs as needed after debugging.

Build

When development and debugging are complete, run from the project root:

dpt build

Output:

• dist/ — built plugin source for inspection
• output/ — zip package <plugin-name>-<version>.zip for import

Import and use

1. Open DobotStudio Pro → Dobot+ plugin management
2. Uninstall any existing plugin with the same name
3. Import the zip from output/
4. Use the plugin from the nav bar (UI, blocks, scripts)

Package name format:

<plugin-name>_v<major>-<minor>-<patch>-<status>.zip

See Development Guide — Build & Use for screenshots and details.

Example Plugin UI Screenshots

FAQ

Skill reports missing Requirements.md

Ensure Requirements.md is in the project root with I/O port definitions and functions. The Skill will not create it for you.

No DI feedback after DO output

• Verify DI/DO wiring and port numbers in Requirements.md
• Confirm external device is powered and ready
• Some devices respond slowly—add a short wait before reading DI in Lua

Mixing controller and tool-end I/O

Pick one method in Requirements.md. Controller: DI / DO. Tool-end: ToolDI / ToolDO—do not mix APIs in one function.

Unsatisfactory Agent output

• Clarify port numbers and level meanings in Requirements.md
• Ensure atomic function split (one action per function)
• Model quality matters: GPT-5.4+ for VS Code Copilot; Auto mode works well in Cursor

Related links

• IO commands (controller DI/DO)
• Tool commands (tool-end ToolDI/ToolDO)
• Basic IO example (manual)
• Agent Skill overview