TIA 15xx CPUs PLCSIM & Software Units

Draco Malfoy

Level-1
Beiträge
1.168
Reaktionspunkte
82
Zuviel Werbung?
-> Hier kostenlos registrieren
15xx CPUs PLCSIM & Software Units - TIA V15.1

Zwei Fragen an schlaue Leute hier.

1) Früher war es mal möglich, in der PLCSIM die Aufrufe von Alarm-OBs wie OB82, 83, und 86 zu simulieren. Heute scheints nichts derartiges mehr zu geben, außer ich kaufe mir ein Stück ET200SP Station, und reiße dort im Minutentakt Module ein und aus, bzw. schließe sie kurz und tausche sie an ihren an Plätzen. Ist es so, oder bin ich blöd ??

2) In den 1516F-3PN/DP neuester Versionen scheint es möglich zu sein, irgendwelche Software-Units mit Deklarationen und Private/Public Eigenschaften zu definieren. Damit scheint der Wunsch bestimmter Hochsprachen-Orientierter Kollegen nach etwas, was diese Leute OOP nehmen, in Erfüllung zu gehen.

Jetzt meine Frage an der Stelle:

- Hat damit schon jemand gearbeitet ? Wozu ist es gut ?
- Warum kann ich aus einer Programm Unit keine Hardware HW-IO Adressen erreichen ?
- Wenn ich einen Ablauf in einer Programm Unit verpacke, wer ruft diese Programm Unit dann auf ? Hat diese Programm Unit dann ihre eigene OBs ?
 
Zuletzt bearbeitet:
Vorneweg: Ich hab Software-Units auch noch nicht getestet.

Hauptvorteil, den ich sehe, ist das gezielte Herunterladen in die Steuerung.
Sollte bei Änderungen das Leben leichter machen.
Bei Youtube gibt's ein kurzes Tutorial von Siemens:
https://www.youtube.com/watch?v=ZL5NczVlk4s

Objektorientierung ist das rudimentär. Um Querzugriffe von Units zu ermöglichen müssen die entsprechenden Eigenschaften eben als public deklariert werden.
In wie weit das praxistauglich ist ... hmmm ...

Gruß
Blockmove
 
Zuviel Werbung?
-> Hier kostenlos registrieren
also ich hab über die Softwareunits nachgedacht... So richtig ist mir kein Anwendungsfall für uns in der Prozessautomatisierung eingefallen.
Das mit dem separaten Laden, naja, uns bringt das nix. Wieviele Softwareunits will man da anlegen, damit man sinnvoll separat Laden kann? Irgendwie sind das Sonderspezialfälle, die man sich konstruieren, aber auch anders lösen kann...
Spätestens wenn man zwischen den Softwareunits Daten austauschen will, wirds haarig...
 
Also wenn man mehrere komplett unabhängige Anlagenteile hat, könnte man die in einer SPS in Softwareunits kapseln... Ich würde an der Stelle aber lieber mehrere (kleinere) SPSn einsetzen... Das hat nämlich einige andere Vorteile....
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also wenn man mehrere komplett unabhängige Anlagenteile hat, könnte man die in einer SPS in Softwareunits kapseln... Ich würde an der Stelle aber lieber mehrere (kleinere) SPSn einsetzen... Das hat nämlich einige andere Vorteile....

Von der Struktur könnten bei mir schon viele Anlagen passen.
Das Interface-Konzept ist auch nicht uninteressant.
Das Zusammenspiel und die Konsistenz ist mir noch nicht klar.
 
@ ducati, würdest Du die genannten Vorteile benennen?

Interessiert mich, wie Du argumentierst.

Naja, wenn die Anlagenteile jeweils ne eigene SPS haben, dann:

- bei nem Defekt, ist nur ein Anlagenteil ausgefallen
- Hardwareänderungen (HW-Konfig laden, Abschalten vom Schaltschrank wegen Umbau) betrifft nur einen Anlagenteil
- es können mehrere Mitarbeiter problemlos gleichzeitig an den Anlagenteilen inbetriebnehmen, oder am Revisionstag umbauen
- Trennung des Feldbusses, je Anlagenteil ein separater Feldbus, keine Beeinträchtigung untereinander
- Anlagenteile können u.U. von verschiedenen Instandhaltern betreut werden, oder sogar von verschiedenen Anlagenbauern gebaut werden
- manchmal ist es in kritischen Anlagen-(teilen) nicht erlaubt, irgendwelche Arbeiten durchzuführen. Da ist eine strikte Aufteilung von Vorteil.

...

Gruß.
 
Naja, wenn die Anlagenteile jeweils ne eigene SPS haben, dann:

- bei nem Defekt, ist nur ein Anlagenteil ausgefallen
- Hardwareänderungen (HW-Konfig laden, Abschalten vom Schaltschrank wegen Umbau) betrifft nur einen Anlagenteil
- es können mehrere Mitarbeiter problemlos gleichzeitig an den Anlagenteilen inbetriebnehmen, oder am Revisionstag umbauen
- Trennung des Feldbusses, je Anlagenteil ein separater Feldbus, keine Beeinträchtigung untereinander
- Anlagenteile können u.U. von verschiedenen Instandhaltern betreut werden, oder sogar von verschiedenen Anlagenbauern gebaut werden
- manchmal ist es in kritischen Anlagen-(teilen) nicht erlaubt, irgendwelche Arbeiten durchzuführen. Da ist eine strikte Aufteilung von Vorteil.

...

Gruß.

Du beschreibst Anlagen, die ohnehin unabhängig voneinander arbeiten können. Hier sind separate Steuerungen selbstverständlich die bessere Wahl.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Du beschreibst Anlagen, die ohnehin unabhängig voneinander arbeiten können. Hier sind separate Steuerungen selbstverständlich die bessere Wahl.

jo.

So selbstverständlich ist das aber nicht immer. Und manchmal die Abgrenzung auch nicht eindeutig.

Aber im Zusammenhang mit der Softwareunit, die Softwareunit ist sowas wie "mehrere" SPSn in einem Hardwaregerät. So hab ich das zumindest verstanden. Wenn die Anlagenteile eng zusammenhängen, dann machts genausowenig Sinn die in verschiedene Softwareunits zu packen, wies keinen Sinn macht, die in verschiedene SPSn zu legen. Selbst das hab ich auch schon erlebt. Und wenn die Anlagenteile unabhängig voneinander sind, ist es u.U. besser, gleich ne separate SPS zu verbauen...

Gruß.
 
Erzähl bitte mehr dazu, ich weiß gerade damit nicht so viel anzufangen. API ist für mich "Application Process Instance".

Wie schon gesagt:
API = Application Programming Interface

D.h. ein Interface, um mit einem selbst geschriebenen Programm (C#,C++) auf die PLCSim Instanz zuzugreifen. Du kannst dann beispielsweise I/Os auslesen / schreiben, die CPU "anhalten", Ereignisse auslösen (z.B. ziehen / stecken) und noch viel mehr.
 
Zurück
Oben