Zum Inhalt

TIA-Deployment

Das Repository ist der Bearbeitungsort für PLC-Quellcode. TIA Portal bleibt die Integrationsumgebung für Hardware-Konfiguration, Compile-Diagnosen, Online-Arbeit und den finalen Download.

Source-driven, nicht destruktiv

Das Deployment erstellt oder aktualisiert Bausteine und PLC-Datentypen aus Repository-Sources. Es löscht keine TIA-Objekte, die nicht im Repository abgebildet sind.

Source-Modell

Alle deploybaren PLC-Sources liegen unterhalb von tia/exports und sind nach Verantwortung gruppiert:

tia/exports/
  00_SYSTEM/
  01_PLATFORM/
  02_INTERFACES/
  03_CORE/
  04_POWER_MANAGEMENT/
  05_PROPULSION/
  06_ALARMS/
  07_HMI/
  08_SIMULATION/
  09_DIAGNOSTICS/
  10_VALIDATION/
  99_LEGACY/
Quelldatei TIA-Ziel
.scl Program blocks, für FB/FC/OB-Sources
.db Program blocks, für Datenbaustein-Sources
.udt PLC-Datentypen

Ordnernamen werden gespiegelt

Ordnernamen unterhalb von tia/exports werden als TIA-Gruppen erstellt. Zum Beispiel wird tia/exports/06_ALARMS/FB_AlarmRouting.scl in die Gruppe 06_ALARMS generiert.

Bestehende Demonstrationsbausteine bleiben in 99_LEGACY, bis sie in die nummerierte Architektur überführt werden.

Normaler Workflow

Edit source in VS Code
  -> run pcs deploy ...
  -> Openness imports external sources
  -> TIA generates blocks/types
  -> optional compile
  -> project is saved

Eine kleine Anzahl von Bausteinen ohne Compile deployen:

pcs deploy plcs=PLC_1 blocks=FB_AlarmRouting,FB_AlarmDelay no-compile

Ein vollständiges Subsystem deployen:

pcs deploy plcs=PLC_1 folder=06_ALARMS

Alles auf alle konfigurierten PLCs deployen und kompilieren:

pcs deploy

Deployment-GUI

Das Repository enthält außerdem eine schlanke Windows-GUI für Kolleginnen und Kollegen, die ein visuelles Deployment-Cockpit gegenüber Terminalbefehlen bevorzugen.

.\tools\tia-deployment-gui\build.ps1
.\tools\tia-deployment-gui\bin\tia-deployment-gui.exe

Gleiches Backend wie das Terminal

Die GUI ruft intern die pcs CLI auf. Projekt-Defaults, PLC-Ziele, Source-Auswahl, Dry-Run-Verhalten, Compile-Verhalten und TIA-Versionsbehandlung bleiben dadurch mit Terminal-Deployments konsistent.

Für tägliche Source-Synchronisierung das Sync Tool verwenden

Für den gemeinsamen Repo-<->TIA-Workflow mit TIA-Snapshots, Drei-Wege-Entscheidungen, Diffs und sicheren Apply-Aktionen verwende tools/pcs-tia-sync-tool/bin/pcs-tia-sync-tool.exe. Die Deployment-GUI bleibt das breitere Deployment-Cockpit.

Die GUI kann pcs.config.json aus dem ausgewählten Source Repository laden. Das Laden des Repositorys füllt Projekt-Defaults, meldet Projektname, TIA-Projektpfad, Exports-Root, konfigurierte PLCs und Autor und bietet Schnellzugriff auf die Konfigurationsdatei und den Exports-Ordner.

Die GUI kann alle Sources oder ausgewählte Bausteindateien aus dem konfigurierten tia/exports-Root deployen.

Verwende Validate vor dem ersten Deployment auf einer neuen Workstation. Es prüft Repository-Root, pcs.ps1, Projektpfad, Exports-Root, konfigurierte PLCs und Source-Anzahl.

Presets decken typische Workflows ab, zum Beispiel vollständiges Deployment, Alarmänderungen, Plattformbausteine, nur PLC_1 und schnelle Importe ohne Compile.

Nützliche Buttons

Dry Run löst das geplante Deployment auf, ohne TIA zu ändern. Load liest pcs.config.json aus dem ausgewählten Source Repository und aktualisiert die Deployment-Defaults. Scan PLCs fragt das ausgewählte TIA-Projekt über Openness ab. Open Config und Open Exports springen direkt zu den relevanten lokalen Pfaden. Der Tab Documentation enthält die Dokumentationssteuerung, einschließlich lokalem Serving und Öffnen der Docs.

Dry Run verwenden, wenn du unsicher bist

Ein Dry Run löst Projektpfad, PLC-Ziele und Quelldateien auf, ohne TIA zu öffnen.

pcs deploy plcs=PLC_1 folder=06_ALARMS dry-run no-compile

Deployment-Verhalten

Während des Deployments macht das Tooling Folgendes:

  • an den laufenden TIA-Portal-Prozess anhängen, wenn das angeforderte Projekt bereits geöffnet ist,
  • andernfalls das Projekt öffnen,
  • ausgewählte externe Quelldateien importieren,
  • Bausteine und PLC-Datentypen generieren,
  • optional das PLC-Softwareziel kompilieren,
  • Compiler-Ergebnisse im Terminal ausgeben,
  • das TIA-Projekt speichern.
Compile-Verhalten

Standardmäßig kompiliert pcs deploy nach der Generierung. Verwende no-compile während schneller Iterationen, wenn du Source-Änderungen nur importieren/generieren willst.

pcs deploy plcs=PLC_1 blocks=FB_AlarmRouting no-compile

Versionsbehandlung

Der Wrapper leitet die Openness-API aus der Projekterweiterung ab:

Projekterweiterung Openness-API
.ap19 Portal V19
.ap20 Portal V20

Überschreibe die Version nur bei Bedarf:

pcs deploy tia-version=V19
Wann die CLI neu gebaut werden muss

Verwende pcs build nach Änderungen an tools/tia-openness, nach dem Pull von Tool-Änderungen oder beim Wechsel der CLI auf eine andere TIA-Openness-Version.

Multi-PLC-Deployment

Standard-PLC-Ziele werden in pcs.config.json konfiguriert:

{
  "plcs": [
    "PLC_1",
    "PLC_2"
  ]
}

Auf alle konfigurierten PLCs deployen:

pcs deploy

Auf ausgewählte PLCs deployen:

pcs deploy plcs=PLC_1
pcs deploy plcs=PLC_1,PLC_2

PLC-spezifisches Verhalten explizit halten

Bevorzuge Konfigurations-DBs, Hardware-Konfiguration oder Parameter für PLC-spezifische Unterschiede. Verzweige den Source Tree nur, wenn die Logik wirklich unterschiedlich ist.

Sicherheitshinweise

Generiert bedeutet nicht heruntergeladen

Das Deployment importiert/generiert und kompiliert optional innerhalb des TIA-Projekts. Es lädt nicht auf die physische PLC herunter.

Das Repository ist keine Löschinstanz

Das Entfernen einer Datei aus tia/exports löscht nicht automatisch das entsprechende Objekt aus TIA. Löschungen sollten explizit und geprüft erfolgen.

Fokussierte Deployments verwenden

Bevorzuge während der Entwicklung blocks=... oder folder=... gegenüber einem vollständigen Deployment. Ein vollständiges Deployment ist am besten vor Integrationschecks oder Übergaben.

Troubleshooting

Baustein wurde nicht gefunden

Verwende pcs list blocks, um Source-Name und Speicherort zu bestätigen.

Falsches PLC-Ziel

Verwende pcs list plcs configured, um konfigurierte Ziele zu sehen, oder pcs list plcs, um das TIA-Projekt über Openness abzufragen.

Erster Openness-Lauf

TIA kann einen Trust Prompt für die generierte CLI-Executable anzeigen. Öffne TIA Portal selbst, bevor du deployest, wenn du Prompts interaktiv bestätigen musst.

Workflow-Diagramm

TIA Openness Deployment Workflow

PlantUML-Source: deployment-workflow.puml