مهندسی یک برنامه S7 در TIA Portal مملو از کارهای تکراری و از پیش تعریف شده است: ایجاد جداول تگ (Tag Tables)، ساخت دیتابلوک‌های سراسری (Global DBs)، وارد کردن (Import) بلوک‌ها از منبع، دسته‌بندی بلوک‌ها در گروه‌ها، کامپایل کردن و بررسی خطاها. زیمنس قبلاً تمام این موارد را از طریق Openness API در دسترس قرار داده است. آنچه تا کنون جای خالی‌اش احساس می‌شد، روشی تمیز برای یک دستیار هوش مصنوعی (AI Assistant) بود تا بتواند مستقیماً این API را هدایت کند، بدون اینکه شما مجبور باشید کدها را مدام در پنجره چت کپی-پیست کنید.

پروتکل Model Context Protocol (MCP) این خلاء را پر کرده است. این مقاله یک راهنمای عملی برای ساخت یک سرور MCP است که روی TIA Openness V21 قرار می‌گیرد؛ به طوری که دستیاری مانند Claude بتواند بلوک‌های شما را لیست کند، تگ‌ها را از اکسل وارد کند، از کدها خروجی (Export) بگیرد و پروژه را سازماندهی کند—همه‌ی این‌ها فقط با فراخوانی ابزارهای دارای تایپ مشخص (Well-typed tools). ما در این مقاله به بررسی پروتکل، معماری، تغییرات خاص Openness در نسخه V21 که معمولاً باعث سردرگمی افراد می‌شود، کاتالوگ کامل ابزارها به همراه نمونه داده‌ها (Payloads)، مدل امنیتی و نحوه توسعه آن خواهیم پرداخت.

پروتکل MCP واقعاً چگونه کار می‌کند؟

MCP یک استاندارد باز است که در اواخر سال ۲۰۲۴ توسط Anthropic معرفی شد و اکنون در بخش بزرگی از اکوسیستم هوش مصنوعی پذیرفته شده است. ایده ساده است: یک سرور مجموعه‌ای از ابزارها را معرفی می‌کند و یک کلاینت (اپلیکیشن هوش مصنوعی) آن‌ها را از طریق JSON-RPC شناسایی و فراخوانی می‌کند. سه پیام اصلی وجود دارد که باید به آن‌ها توجه کنید:

  1. initialize: کلاینت و سرور روی نسخه پروتکل توافق کرده و قابلیت‌های خود را مبادله می‌کنند.
  2. tools/list: کلاینت لیست ابزارهای موجود را درخواست می‌کند. سرور نام هر ابزار، توضیحات قابل فهم برای انسان و یک JSON Schema برای آرگومان‌های آن را بازمی‌گرداند.
  3. tools/call: کلاینت یک ابزار را با نام و یک شیء JSON شامل آرگومان‌ها فراخوانی کرده و نتیجه‌ای ساختاریافته دریافت می‌کند.

تفاوت کلیدی با یک ابزار خط فرمان (CLI) معمولی در «شناسایی» (Discovery) و «تایپینگ» (Typing) است. در یک CLI، شما باید از قبل فلگ‌ها (Flags) را بشناسید. در MCP، مدل هوش مصنوعی لیست ابزارها و اسکیماها را در زمان اجرا (Runtime) می‌خواند و تصمیم می‌گیرد چه چیزی را فراخوانی کند. در یک چیدمان محلی (Local)، سیستم انتقال داده (Transport) از نوع stdio است: کلاینت فرآیند سرور را اجرا می‌کند و آن‌ها پیام‌های JSON-RPC جدا شده با خط جدید را از طریق ورودی و خروجی استاندارد مبادله می‌کنند. این همان روشی است که ما در اینجا استفاده می‌کنیم.

معماری کلی

سرور به‌طور عمدی به دو لایه تقسیم شده است. بخش سخت کار، یعنی تعامل با Openness، در یک موتور خط فرمان (CLI Engine) مبتنی بر .NET قرار دارد. لایه MCP یک فرآیند سبک پایتونی است که فراخوانی‌های ابزار را به دستورات قابل اجرا برای موتور اصلی ترجمه می‌کند.

MCP client (Claude Desktop / Cursor / your code)
   |  JSON-RPC over stdio
   v
server.py  (Python, FastMCP)
   |  subprocess: ControlByteTiaCli.exe --attach-open --json
   v
ControlByteTiaCli.exe  (.NET Framework 4.8)
   |  Openness API
   v
TIA Portal V21  (running, project open)

چرا به جای یک سرور درون‌فرآیندی (in-process server)، دو لایه داریم؟ دو دلیل وجود داره:

۱. نیاز Openness به .NET Framework کامل: Openness نیازمند نسخه کامل .NET Framework (4.8) هست که بهترین و مطمئن‌ترین جا برای میزبانی منطق مهندسی (engineering logic) محسوب می‌شه.

  1. قابلیت تست و اسکریپت‌پذیری مستقل موتور: نگه داشتن موتور به عنوان یک رابط خط فرمان (CLI) مستقل، باعث می‌شه که بشه اون رو به صورت جداگانه تست کرد و از طریق اسکریپت‌ها اجرا کرد. در این حالت، سرور MCP فقط چند خط کد می‌شه که پرچم‌ها (flags) رو جمع می‌کنه و دستورات رو اجرا می‌کنه (shell out). این موتور به یک نمونه در حال اجرای TIA که پروژه‌اش از قبل باز هست، متصل می‌شه، کارش رو انجام می‌ده و پنجره TIA شما رو دست‌نخورده باقی می‌ذاره.

 

Openness V21: تجزیه اسمبلی که باید بدانید

اگر برای نسخه‌های V20 یا قدیمی‌تر ابزارهای Openness ساخته باشید، مهم‌ترین تغییری که در V21 رخ داده، تغییر ساختاری هست. اسمبلی monolithic (تک‌قطعه‌ای) Siemens.Engineering.dll به اسمبلی‌های ماژولار (modular assemblies) شکسته شده و به یک پوشه فرعی جدید منتقل شده است.


C:\Program Files\Siemens\Automation\Portal V21\PublicAPI\V21\net48\
  Siemens.Engineering.Base.dll     (TiaPortal, Project, HW, Compiler)
  Siemens.Engineering.Step7.dll    (PlcSoftware, Blocks, Tags, Types)
  Siemens.Engineering.WinCC.dll    (HMI Classic)
  Siemens.Engineering.WinCCUnified.dll
  Siemens.Engineering.Safety.dll
  ...

در نسخه V20 شما به یک اسمبلی (Assembly) ارجاع می‌دادید. در نسخه V21، ابزاری که بر PLC زیمنس متمرکز است، به Base و Step7 ارجاع می‌دهد. فضای نام‌ها (Namespaces) بدون تغییر باقی مانده‌اند (Siemens.Engineering, Siemens.Engineering.SW, Siemens.Engineering.HW, Siemens.Engineering.Compiler)، بنابراین بیشتر کدهای موجود شما تنها با به‌روزرسانی ارجاعات و مسیر Runtime Resolver کامپایل می‌شوند.

در فایل پروژه، شما به این دو اسمبلی ارجاع می‌دهید و گزینه Copy Local را غیرفعال می‌کنید:


<ItemGroup>
  <Reference Include="Siemens.Engineering.Base">
    <HintPath>C:\Program Files\Siemens\Automation\Portal V21\PublicAPI\V21\net48\Siemens.Engineering.Base.dll</HintPath>
    <Private>false</Private>
    <SpecificVersion>false</SpecificVersion>
  </Reference>
  <Reference Include="Siemens.Engineering.Step7">
    <HintPath>C:\Program Files\Siemens\Automation\Portal V21\PublicAPI\V21\net48\Siemens.Engineering.Step7.dll</HintPath>
    <Private>false</Private>
    <SpecificVersion>false</SpecificVersion>
  </Reference>
</ItemGroup>

از آنجا که گزینه‌ی Copy Local غیرفعال است، اسمبلی‌ها (Assemblies) در کنار فایل اجرایی (Executable) شما کپی نمی‌شوند؛ بنابراین باید آن‌ها را هنگام اجرای برنامه (Runtime) به‌صورت دستی پیدا و بارگذاری کنید.

پیش از آنکه هر نوع (Type) مربوط به Openness مورد استفاده قرار گیرد، یک هندلر (Handler) برای رویداد AssemblyResolve ثبت کنید.


AppDomain.CurrentDomain.AssemblyResolve += (_, args) =>
{
    var name = new AssemblyName(args.Name).Name;
    if (name is null || !name.StartsWith("Siemens.Engineering", StringComparison.OrdinalIgnoreCase))
        return null;
    var path = Path.Combine(
        @"C:\Program Files\Siemens\Automation\Portal V21\PublicAPI\V21\net48",
        name + ".dll");
    return File.Exists(path) ? Assembly.LoadFrom(path) : null;
};

چند نکته دیگر درباره نسخه V21

  • Public Key Token اسمبلی‌ها تغییر کرده است؛ اما اگر اسمبلی‌ها را بر اساس نام ساده (Simple Name) و با تنظیم SpecificVersion = false بارگذاری کنید، این تغییر تأثیری روی برنامه شما نخواهد داشت.
  • مسیر اصلی Registry به شاخه 21.0 منتقل شده است.
  • همچنین، از آنجا که فایل‌های باینری (Binaries) بین نسخه‌های مختلف با یکدیگر سازگار نیستند، باید برای هر نسخه از TIA Portal یک نسخه (Build) جداگانه از برنامه خود ایجاد کنید.
    • یک Build که برای V20 کامپایل شده باشد، قادر به بارگذاری اسمبلی‌های V21 نیست.
    • برعکس، Build مربوط به V21 نیز نمی‌تواند اسمبلی‌های V20 را بارگذاری کند.

 

پموتور برنامه و ساختار JSON آن

موتور .NET یک ابزار خط فرمان (CLI) با چندین حالت (Multi-mode) است.

هر حالت (Mode) متناظر با یک عملیات مشخص است، از جمله:

  • وارد کردن (Import) تگ‌ها و Data Block (DB) ها از فایل Excel
  • وارد کردن یک بلاک از فایل SCL
  • وارد کردن گروهی فایل‌های SimaticML XML
  • خروجی گرفتن (Export) از یک بلاک به فرمت SCL یا XML
  • سازمان‌دهی و مرتب‌سازی بلاک‌ها
  • نمایش فهرست پروژه‌ها
  • نمایش فهرست بلاک‌ها

برای استفاده در اتوماسیون نیز این موتور از گزینه --json پشتیبانی می‌کند.

در حالت JSON:

  • تمام پیام‌های ثبت وقایع (Logها) به Standard Error (stderr) ارسال می‌شوند.
  • خروجی استاندارد (Standard Output یا stdout) فقط شامل یک ساختار JSON منظم (Structured Envelope) خواهد بود.

{
  "ok": true,
  "mode": "list-blocks",
  "project": "MyMachine",
  "plc": "PLC_1",
  "dryRun": true,
  "result": { "blocks": [ ... ], "types": [ ... ] },
  "compile": null,
  "error": null
}

خطاها نیز با همین ساختار بازگردانده می‌شوند؛ به‌طوری که مقدار ok برابر false قرار می‌گیرد و پیام خطا در فیلد error قرار داده می‌شود. بنابراین، فراخواننده (Caller) هرگز مجبور نیست یک Stack Trace را از میان متن استخراج کند.

این ساختار (Envelope) همان چیزی است که نتایج ابزار را برای یک مدل مفید می‌کند؛ مدل به‌جای خواندن چهل خط شامل Timestamp، مستقیماً result.blocks را می‌خواند.

 

لایه MCP در Python

سرور از SDK رسمی MCP و ابزار کمکی FastMCP استفاده می‌کند.

یک تابع کمکی، موتور را با گزینه --json اجرا می‌کند، خروجی Standard Output را تجزیه (Parse) کرده و آن را بازمی‌گرداند.

هر ابزار (Tool) یک تابع کوچک است که Signature آن به JSON Schema تبدیل می‌شود؛ همان ساختاری که کلاینت مشاهده می‌کند.

شکل کلی آن به این صورت است:


from mcp.server.fastmcp import FastMCP
import subprocess, json, time

mcp = FastMCP("controlbyte-tia-mcp")

def _run(args: list[str]) -> str:
    cmd = [EXE] + args + ["--json"]
    proc = subprocess.run(cmd, capture_output=True, text=True,
                          encoding="utf-8", timeout=240)
    return (proc.stdout or "").strip()

@mcp.tool()
def list_blocks(plc: str | None = None, project_name: str | None = None) -> str:
    """List all blocks (OB/FB/FC/DB) and UDTs in the PLC of the open project."""
    return _run(["--list-blocks", "--dry-run", "--attach-open"])

if __name__ == "__main__":
    mcp.run()  # stdio transport

Docstring اهمیت دارد؛ زیرا همان توضیحی است که مدل هنگام تصمیم‌گیری برای فراخوانی ابزار (Tool) آن را می‌خواند. Type Hintها به Argument Schema تبدیل می‌شوند. پارامترهای اختیاری (Optional Parameters) از مقدار پیش‌فرض None استفاده می‌کنند.

دو نکته برای افزایش پایداری (Robustness) وجود دارد که بهتر است از همان ابتدا در نظر گرفته شوند.

نخست، عملیات نوشتن (Write Operations) به‌صورت پیش‌فرض در حالت Dry Run اجرا می‌شوند؛ بنابراین، یک ابزار تنها زمانی پروژه را تغییر می‌دهد که فراخواننده (Caller) به‌طور صریح این کار را تأیید کرده باشد.

دوم، اتصال به TIA ممکن است به‌صورت موقت با شکست مواجه شود؛ برای مثال زمانی که برنامه برای لحظه‌ای مشغول است یا یک پنجره Modal Dialog نمایش داده شده است. در چنین شرایطی، تابع کمکی (Helper) پیش از بازگرداندن یک خطای JSON تمیز، در مواجهه با خطاهایی مانند "operation timed out" یا "RPC busy" چند بار تلاش مجدد (Retry) انجام می‌دهد.

 

فهرست ابزارها (Tool Catalog)

نسخه نمایشی (Demo) شامل هشت ابزار است.

ابزارهای فقط‌خواندنی (Read-only Tools) هرگز پروژه را تغییر نمی‌دهند؛ ابزارهای نوشتنی (Write Tools) نیز به‌صورت پیش‌فرض در حالت Dry Run اجرا می‌شوند.

list_projects :نمونه‌های در حال اجرای TIA و پروژه‌های بازشده در هر یک را فهرست می‌کند. این ابزار کاملاً فقط‌خواندنی (Read-only) است.


{ "ok": true, "mode": "list-projects",
  "result": { "instances": [ { "pid": 12612,
    "projects": [ { "name": "MyMachine", "path": "C:\\...\\MyMachine.ap21" } ] } ] } }

list_blocks. درخت (Tree) بلاک‌ها و UDTهای PLC را بازمی‌گرداند؛ به‌طوری که هر ورودی شامل مسیر گروه (Group Path)، نوع (Type) و نام (Name) است. این ابزار برای آشنا کردن یک دستیار با ساختار یک برنامه ناآشنا مفید است.

import_tags_db. جدول‌های تگ PLC و Global DBها را از یک فایل Excel که شامل کاربرگ‌های Tags و DB است، وارد (Import) می‌کند.

پارامترها:

  • excel_path
  • plc (اختیاری)
  • project_name (اختیاری)
  • dry_run (به‌صورت پیش‌فرض true)
  • overwrite_db

اجرای Dry Run بدون انجام هیچ‌گونه عملیات نوشتن، فقط تعداد موارد را گزارش می‌کند:


{ "ok": true, "mode": "excel", "dryRun": true,
  "result": { "tags": { "TablesCreated": 3, "TagsCreated": 19, "TagsSkipped": 0, "TagsFailed": 0 },
              "db":   { "Created": 3, "Skipped": 0, "Failed": 0 } } }

import_scl. یک بلوک را از یک فایل .scl به عنوان منبع خارجی وارد می‌کند و FB، FC یا DB را تولید می‌کند.

import_xml. دسته‌ای SimaticML XML را برای UDTها و بلوک‌ها از یک فایل یا پوشه، با وابستگی چندگذری و تلاش مجدد وارد می‌کند تا انواع ارجاع شده توسط انواع دیگر به ترتیب صحیح وارد شوند.

export_scl. یک بلوک یا UDT را به یک فایل .scl صادر می‌کند. این فقط برای بلوک‌هایی که در SCL یا STL نوشته شده‌اند کار می‌کند، زیرا TIA نمی‌تواند منبع SCL را از یک بلوک LAD یا FBD تولید کند.

export_xml. یک بلوک یا UDT را به عنوان SimaticML XML صادر می‌کند. این برای هر زبانی کار می‌کند، بنابراین یک خروجی همه منظوره است.

organize_blocks. بلوک‌ها و UDTها را با استفاده از قرارداد نامگذاری به زیرگروه‌ها منتقل می‌کند، به عنوان مثال بلوک‌های کتابخانه را به یک گروه PackML و انواع ربات را به یک گروه Robot.

 

اتصال به کلود دسکتاپ

شما موتور را می‌سازید، یک محیط پایتون کوچک برای سرور ایجاد می‌کنید و آن را در کلاینت خود ثبت می‌کنید.


# 1. Build the engine
dotnet build .\src\ControlByteTiaCli\ControlByteTiaCli.csproj

# 2. Python environment for the MCP server
cd .\mcp-server
python -m venv .venv
.\.venv\Scripts\python.exe -m pip install "mcp[cli]"
سپس یک ورودی اضافه کنید :

%APPDATA%\Claude\claude_desktop_config.json


{
  "mcpServers": {
    "controlbyte-tia-mcp": {
      "command": "C:\\path\\to\\mcp-server\\.venv\\Scripts\\python.exe",
      "args": ["C:\\path\\to\\mcp-server\\server.py"],
      "env": {
        "TIA_MCP_EXE": "C:\\path\\to\\src\\ControlByteTiaCli\\bin\\Debug\\ControlByteTiaCli.exe"
      }
    }
  }
}

کلاینت را مجدداً راه‌اندازی کنید، پروژه خود را در TIA Portal V21 باز کنید، و ابزارهای controlbyte-tia-mcp ظاهر می‌شوند. یک اعلان مانند «لیست بلوک‌ها در پروژه TIA باز» list_blocks را فراخوانی می‌کند و مدل، درخت ساختار یافته را می‌خواند.

 

نوشتن کلاینت خودتان

شما به یک برنامه دسکتاپ نیاز ندارید. mcp SDK از کد خودتان متصل می‌شود، ابزارها را فهرست می‌کند و آنها را فراخوانی می‌کند:


import asyncio
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client

async def main():
    params = StdioServerParameters(command="python", args=["server.py"])
    async with stdio_client(params) as (read, write):
        async with ClientSession(read, write) as session:
            await session.initialize()
            tools = await session.list_tools()
            print([t.name for t in tools.tools])
            result = await session.call_tool("list_projects", {})
            print(result.content[0].text)

asyncio.run(main())

قرارداد اکسل برای import tag و DB


import_tags_db انتظار یک فایل .xlsx با دو کاربرگ حساس به حروف بزرگ و کوچک را دارد.

کاربرگ برچسب‌ها از این ستون‌ها به ترتیب استفاده می‌کند: Name، DataType، LogicalAddress، Comment، TagTable. برای مثال:


| Name        | DataType | LogicalAddress | Comment        | TagTable   |
|-------------|----------|----------------|----------------|------------|
| iStart_PB1  | Bool     | %I0.0          | Start button   | TT_Inputs  |
| qMotor1     | Bool     | %Q0.0          | Motor 1 output | TT_Outputs |
| wStep       | Int      | %MW12          | Step number    | TT_Memory  |

کاربرگ DB از ستون‌های زیر استفاده می‌کند:

DbName، MemberName، DataType، InitialValue، Comment، Retain

ردیف‌هایی که دارای DbName یکسان هستند، در یک Global DB قرار می‌گیرند.

جدول‌های تگ (Tag Tables) در صورتی که از قبل وجود نداشته باشند، به‌صورت خودکار ایجاد می‌شوند و تگ‌هایی که از قبل وجود دارند، به‌جای ایجاد نسخه تکراری، نادیده گرفته می‌شوند.

این ابزار از یک قرارداد نام‌گذاری (Naming Convention) ساده پیروی می‌کند:

  • i برای ورودی‌ها (Inputs)
  • q برای خروجی‌ها (Outputs)
  • x برای پرچم‌های بولی (Boolean Flags)
  • w برای Word و Int
  • d برای Double Word و DInt
  • r برای Real
  • پیشوند DB_ برای Data Blockها
  • پیشوند TT_ برای Tag Tableها

مدل ایمنی (Safety Model)

کنترل یک ابزار مهندسی توسط یک LLM نیازمند مکانیزم‌های حفاظتی (Guard Rails) است.

نسخه نمایشی از یک مدل محافظه‌کارانه استفاده می‌کند:

Dry Run به‌صورت پیش‌فرض. همه ابزارهای نوشتن (Write Tools) به‌صورت شبیه‌سازی اجرا می‌شوند، مگر اینکه فراخواننده (Caller) مقدار dry_run را برابر false قرار دهد. اولین اجرای هر حالت (Mode) باید همیشه به‌صورت Dry Run باشد تا بتوانید پیش از اعمال هر تغییری در پروژه، دقیقاً مشاهده کنید چه تغییراتی انجام خواهد شد.

تهیه نسخه پشتیبان پیش از اولین عملیات نوشتن. موتور می‌تواند پیش از ذخیره‌سازی، پوشه پروژه را در یک پوشه پشتیبان (Backup Directory) کپی کند.

اتصال، نه در اختیار گرفتن. سرور به یک پروژه که از قبل در TIA باز شده است متصل می‌شود و آن را باز نگه می‌دارد. این سرور هرگز نشست (Session) TIA شما را نمی‌بندد.

تلاش مجدد در خطاهای موقتی (Transient Retry). اگر عملیات اتصال (Attach) به این دلیل که TIA به‌طور موقت مشغول است با شکست مواجه شود، به‌صورت خودکار دوباره تلاش می‌شود و تنها در صورتی که خطا پایدار باشد، یک خطای JSON بازگردانده خواهد شد.

کنترل‌های قوی‌تر می‌توانند گام‌های منطقی بعدی باشند؛ از جمله تأیید صریح برای هر عملیات نوشتن، مدیریت اختصاصی برای بلاک‌های Fail-Safe (F) و ثبت سابقه (Audit Trail) فراخوانی ابزارها. این موارد را باید به‌عنوان بخشی از نقشه راه (Roadmap) در نظر گرفت، نه قابلیت‌هایی که در حال حاضر به‌صورت داخلی (Built-in) وجود دارند.

 

عملکرد و محدودیت‌ها

موتور به یک فرایند (Process) در حال اجرا متصل می‌شود، بنابراین بیشتر فراخوانی‌ها (Calls) در حدود یک یا دو ثانیه پاسخ می‌دهند. باز کردن یک پروژه جدید یا کامپایل یک برنامه بزرگ زمان بیشتری نیاز دارد؛ به همین دلیل موتور امکان استفاده از یک Timeout نسبتاً طولانی را فراهم می‌کند و تابع کمکی MCP برای هر فراخوانی، یک مهلت 240 ثانیه‌ای در نظر می‌گیرد.

دو محدودیت ساختاری را باید در نظر داشته باشید:

  • ابزار روی پروژه‌ای کار می‌کند که از قبل در TIA باز شده باشد (خودش فایل‌های آفلاین را باز نمی‌کند).
  • فهرست کردن (Listing) یا خروجی گرفتن (Exporting) از بلاک‌های بسیار بزرگ، به سرعتی که Openness می‌تواند آن‌ها را Serialize کند، محدود است.

 

عیب‌یابی (Troubleshooting)

TIA باید در حال اجرا باشد و پروژه در آن باز شده باشد. سرور به یک فرایند (Process) در حال اجرای TIA متصل می‌شود. اگر چیزی پیدا نشد، ابتدا TIA را اجرا کنید و پروژه را باز کنید.

با همان کاربر ویندوز اجرا کنید. Openness فقط می‌تواند فرایندهای TIA را که توسط همان کاربر ویندوز اجرا شده‌اند مشاهده کند. یک TIA که با دسترسی Administrator اجرا شده است را با ابزاری که بدون دسترسی Administrator اجرا شده است (یا برعکس) استفاده نکنید.

مجوز (License) و گروه Openness. شما به مجوز Openness و عضویت در گروه محلی Siemens TIA Openness نیاز دارید؛ در غیر این صورت API یک Security Exception ایجاد خواهد کرد.

FileNotFoundException برای Siemens.Engineering.Base. حل‌کننده (Resolver) نمی‌تواند پوشه V21 net48 را پیدا کند. مسیر را اصلاح کنید؛ فایل‌های DLL را در کنار فایل اجرایی (Executable) کپی نکنید.

InvalidProjectVersionException. پروژه‌ای قدیمی که از طریق V21 باز شده است، نیاز به ارتقا (Upgrade) دارد. یک بار آن را در TIA V21 باز کنید، ذخیره کنید، سپس از ابزار استفاده کنید، یا به پروژه‌ای که از قبل باز است متصل شوید.

خطاهای Culture هنگام وارد کردن XML. توضیحات (Comments) موجود در فایل XML به زبانی اشاره می‌کنند که در پروژه پیکربندی نشده است. واردکننده (Importer) تنظیمات Culture را اصلاح می‌کند، اما اگر مشکل همچنان باقی بود، زبان‌های پروژه را بررسی کنید.

 

توسعه آن با ابزارهای خودتان

اضافه کردن یک قابلیت از همان ساختار دو لایه (Two-layer Split) پیروی می‌کند.

اگر عملیات موردنظر از قبل به‌صورت یک Engine Flag وجود داشته باشد، کافی است یک ابزار Python اضافه کنید که آن Flag را ایجاد کند و تابع کمکی (Helper) را فراخوانی کند، سپس کلاینت را دوباره راه‌اندازی کنید.

اگر قابلیت واقعاً جدید باشد، ابتدا باید یک Flag جدید و منطق مربوط به آن را در موتور .NET اضافه کنید، پروژه را دوباره Build کنید، سپس آن را در Python در دسترس قرار دهید.

یک توسعه مناسب برای شروع، اضافه کردن یک ابزار فقط‌خواندنی (Read-only) است؛ مانند خواندن کد منبع (Source) یک بلاک به‌صورت متن، یا ابزاری برای کامپایل و گزارش‌گیری که پیام‌های کامپایلر را به‌صورت JSON ساخت‌یافته بازگرداند.

این الگو قابل انتقال (Portable) است؛ هر سیستم مهندسی که یک Automation API داشته باشد، می‌تواند پشت همین لایه نازک MCP قرار بگیرد.

 

نقشه راه (Roadmap)

نسخه نمایشی هم‌اکنون JSON ساخت‌یافته بازمی‌گرداند و در صورت بروز خطاهای موقتی هنگام اتصال (Attach)، به‌طور خودکار دوباره تلاش می‌کند.

گام‌های طبیعی بعدی عبارت‌اند از:

  • مجموعه ابزارهای غنی‌تر (Cross-References، خواندن کد منبع بلاک به‌صورت فقط‌خواندنی، کامپایل و گزارش)
  • استفاده اختیاری از انتقال HTTP برای استفاده از راه دور
  • تأیید (Confirmation) برای هر عملیات نوشتن
  • نتایج ساخت‌یافته برای تمام حالت‌ها (Modes)

هیچ‌یک از این موارد ایده اصلی را تغییر نمی‌دهد: یک لایه کوچک و با نوع‌بندی دقیق (Well-Typed) روی Openness که یک دستیار بتواند با امنیت از آن استفاده کند.

 

پرسش‌های متداول (FAQ)

  • این ابزار برای کدام نسخه TIA طراحی شده است؟
    برای V21 و اسمبلی‌های جداشده (Split Assemblies) آن. برای V20 باید یک Build جداگانه داشته باشید، زیرا فایل‌های باینری Openness بین نسخه‌های مختلف با یکدیگر سازگار نیستند.
  • آیا با فایل‌های آفلاین .ap21 کار می‌کند؟
    خیر. این ابزار به یک نمونه در حال اجرای TIA Portal که پروژه از قبل در آن باز شده است متصل می‌شود.
  • آیا چیزی به فضای ابری (Cloud) ارسال می‌شود؟
    تنها داده‌هایی که کلاینت MCP شما برای مدل ارسال می‌کند. اگر از یک مدل میزبانی‌شده (Hosted Model) استفاده کنید، ورودی‌ها و خروجی‌های ابزاری که از طریق آن ارسال می‌کنید از دستگاه شما خارج می‌شوند؛ برای محیط‌های ایزوله (Air-Gapped)، از یک مدل محلی (Local Model) استفاده کنید. سرور MCP و اتصال TIA هر دو به‌صورت محلی (Local) اجرا می‌شوند.
  • هزینه آن چقدر است؟
    سرور و موتور تنها کدی هستند که روی Openness ساخته شده‌اند. پیش‌نیاز اصلی، داشتن یک مجوز معتبر TIA Portal Openness است که شرکت Siemens آن را به‌صورت جداگانه مجوزدهی (License) می‌کند.
جدیدتر نحوه رفع تاخیر ارتباطی PLC: میلی‌ثانیه‌ واقعا کجا از دست میروند؟
بازگشت به لیست
قدیمی تر مقایسه کابل های شبکه زیمنس با سایر برندها

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

هفده − ده =