TIA Welches ist der schnellste Übertragunsgweg für schon genutzte Analogeingänge?

L

Ludewig

Level-3
Beiträge
1.075
Reaktionspunkte
238
Zuviel Werbung?
-> Hier kostenlos registrieren
Guten Abend

Gegeben ist eine laufende Anlage, SPS ET1512SP. Dieser Controller ist mit 85% Codespeicher und Kommunikation schon recht ausgelastet.
Es gibt technische Fragestellungen, die vorläufig experimentell geklärt werden sollen, bevor sie optimiert in das laufende, validierte Programm integriert werden.

Dazu müsste ich 2 bis maximal 8 PEW an eine provisorisch per PN angekoppelte SPS gleichen Typs separat übertagen, um im ersten Schritt einen Algorithmus zu entwicklen, der Schwingungen dieser Signale sauber erkennt. Wichtig ist dabei, dass das Zeitverhalten einigermaßen konstant ist, es geht allerdings um Frequenzen <= 5 Hz. Eine einigermaßen regelmäßige Übertragung alle 50ms sollte eigentlich ausreichen.

Welcher Weg ist der schnellste, aber auch ohne großen Aufwand integrierbare, um die PEWs zur zweiten SPS zu kopieren:
IO device geht nicht,da die Eingänge auch lokal genutzt werden müssen ?
GET ?
Was sont?

Die primäre SPS ist für die Entwicklung ungeeignet, da Stillstand pönalisiert ist.
 
Ludewig schrieb:
IO device geht nicht,da die Eingänge auch lokal genutzt werden müssen ?
Zum Vergrößern anklicken....
Die Analogeingänge mit der zweiten SPS lesen geht vermutlich als "shared device". Oder die primäre SPS kopiert halt die PEWs in PAWs zur zweiten SPS - notfalls in einem Weckalarm, falls die OB1-Zykluszeit zu lang ist.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich stimme Harald zu: Shared Device wäre hier super.

Alternativ:

Die zwei SPS per I-Device koppeln - dann kommunizieren die im Profinet-Takt.
Im OB1 (oder wie Harald sagt ggf. Alarm-OB) die AI dann auf das I-Device kopieren.

Grüße

Marcel
 
Ich würde ebenfalls über I-Device gehen. Idevice slave auf der CPU mit den analog Eingängen einrichten.
die Analogeingänge per Blockmove auf die PAW für die zweite steuerung bereitstellen.

Dazu muss ein mal die alte Steuerung in Stop genommen werden (für die Aktualisierung der Hardwarekonfiguration)

ggf ist es lohnenswert dafür eine 1512SP Steuerung (ist ja nun nicht so teuer) ohne IOs aufzubauen um die korrekte implementation von Idevice und Kopieren zu prüfen bevor man das Programm/HWConfig dann auf das Livesystem spielt.
 
Guten Morgen
Erst einmal vielen Dank für Eure Antworten. Ich habe diese Woche noch Urlaub.
Es gibt definierte Zeitslots, in denen ich die CPU kurz stppen kann. Andererseits wissen unsere Anlagenkonstrukteure nicht genau, was sich physikalisch abspielt, daher will ich die Sache möglichst getrennt vom Prozess entwickeln.

Ich habe bisher weder mit shared noch mit I-devices gearbeitet. Ich werde mich daher erst einmal einlesen. Auch habe ich zwei CPUs zum Testen in der Werkstatt. Schauen wir, was die nächste Woche bringt.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Shared Device ist sicher die beste Wahl. Sofern es eben die Baugruppe unterstützt.
Ansonsten eben I-Device-Kopplung der Steuerungen über Alarm-OB.

Als Alternative kann Get auch funktionieren. Und das (wahrscheinlich) ohne AG-Stop.
Allerdings würde ich hier ggf. einen Zeitstempel mit übertragen.

Gruß
Blockmove
 
Wenn es nur um 8 AI geht: ev. Trennverstärker einbauen und die 8 EI direkt in die neue SPS einlesen?
erfordert keinen Stop der laufenden SPS und die Unterbrechungszeit der AI zur alten Steuerung ist bei richtiger Vorbereitung minimal.
 
Ich will jetzt nicht behaupten dass das Einrichten des I-Device oder Shared-Device einen großen Aufwand mit sich bringt. Aber mit GET wäre es deutlich einfacher und für ein Provisorium mehr als ausreichend. Unter Umständen muss die Haupt-SPS hierfür nicht einmal gestoppt werden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe heute die Varianten GET und shared-IO-device ausprobiert:

A. GET:
Es wird beidseits mindestens eine unspezifizierte S7-Verbindung benötigt, also auch hier kurzer CPU-Stop wegen Aktualisierung der Hardware.
Danach flexibler Zugriff auf DBs, aber auch direkt auf Eingangsworte.
Vorteil: Wird das Entwicklungssystem angehalten oder abgeklemmt, passiert gar nichts, mal ab davon, dass die Verbindung in der Netzansicht errötet.

B. Nutzung der CPU als I-device durch durch Sharen der Funktion IO-device in der Form eines GSD-Datei-Ex-/Imports:
Einrichtung fast einfacher als GET. Keine Verbindungsprojektierung, nur E/A-Adresseinrichtung Sauschnell.
Kleiner Nachteil: Zieht man das Ethernet, fängt's an zu blinken.

Beide Versionen scheinen auch innerhalb eines Projektes zu gehen, aber mein Ziel ist eine vorübergehende Lösung und da ist mir ein separates Projekt lieber.

Nebenbei: An diesem Begriff Shared bin ich länger hängengeblieben ( hatte bisher nichts damit zu tun). Ergebnis:
1. Es gibt IO-devices, die einzelne Module verschiedenen Controllern zuordnen können, aber immer nur eins pro Controller.
2. Es gibt IO-devices, die einzelne Module mehreren Controllern zuordnen können, bis zu 4 Controller können das gleiche Modul parallel lesen, einer kann auch schreiben.
3. Es gibt IO-devices, die können gar keine Module sharen, sondern nur virtuelle Adressbereiche, auch hier immer nur ein Controller pro Adressbereich.
4. Vielleicht gibt's da noch mehr.

Finale Erkenntnis: Meine ET200SP1512 ist ein I-device, weil I-device= IO-device+IO-Controller in einem Gerät, und entspricht Typ Nr. 3, sozusagen Minimalsharing.
 
Zurück
Oben