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¶
PlantUML-Source: deployment-workflow.puml