Kommunkation SPS -> Regler

Mu1337

Level-1
Beiträge
6
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin Moin,

Mein Kollege und Ich sind duale Studenten und haben von Firma ein Projekt bekommen, welches sich mit dem Antrieb eines Portals über Servomotoren beschäftigt. Hierzu muss ich Anmerken das Servomotoren sowie deren Regler normalerweise bei uns im Betrieb nie benutzt werden.

Somit begann das Abenteuer, wir haben uns ein Regler ausgesucht und bestellt samt Motor. Nun arbeiten wir uns ein wenig ein in die Materie mit Try und Error.

Wir haben jetzt etwas festgestellt, was wir uns nicht erklären können und wir hoffen das Ihr villeicht wisst woran es liegt undzwar:

Hatten wir als erstes zum testen eine alte 315-2DP genommen (6ES7 315-2AF03-0AB0). Über die Regler SOftware haben wir ein standart Telegram ( Drehzahl regulierung ) genommen welches 2 Aus- sowie 2 Einganswörter besaß. Da wir hierüber den Motor zucken lassen konnten sind wir auf benutzer spezifische telegramme umgestiegen. Dies war leider nicht möglich, eine kommunkation zwischen SPS und Regler fand nicht statt.

Also sind wir zurück zu den Standarttelegrammen, dort haben wir festgestellt das alle telegram typen die über 2 Aus- / 2 Eingswörter gingen nicht mehr mit der SPS kommunizieren konnte. Der Prozessabbild war in diesen fällen ausgegraut, bei dem ersten funktionierendem Telegram wurde dieser automatisch ausgefüllt.

Mit einer 314C 2PN/DP welches ich noch aus meiner Ausbildung besaß waren diese telegramme kein Problem, wir konnten sofort ein Eingangssignal an den Eingangswörtern feststellen.

Wie kann man sich das erklären?

Ich möchte noch anmerken das wir bis jetzt in der Universität kaum automatisierungs Technik hatten und uns alles selbst via Lektüre oder Foren beigebracht haben, bitte habt Rücksicht auch wenn es eine doofe Frage ist. :smile:

Liebe Grüße
 
Hi,

das könnte durchaus an der etwas arg alten S7 315 liegen das dort einige Einstellungen nicht funktionieren die bei neueren CPU Typen funktionieren.
Aber bevor man da tiefer einsteigt wären ein paar mehr Informationen schon hilfreich:

Welche Software wurde genutzt und in welcher Version?
Welche FW Version hat die CPU?
Welcher Umrichter wurde verwendet?
Wie wurde der Umrichter im Projekt integriert (per GSD oder per Katalog(OM,HSP)?)?
Welche Telegramme wurde genau verwendet, es gibt da wesentlich mehr als nur eins?
Was bedeutet "nicht mehr mit der SPS kommunizieren" was kamen für Fehler?
Warum wurde auf benutzerspezifisch umgestellt, was bedeutet "zucken lassen konnten"?

Generell sind Screenshots sehr zu begrüßen, insbesondere bei der Sache mit dem Prozeßabbildeinstellungen, damit man weiß was genau gemeint ist!

Gruß
Christoph
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Möglicherweise müsst ihr die SFC14/SFC15 benutzen. (Read/Write DP-Daten)

Zweck der SFC 14

Sie benötigen die SFC 14 "DPRD_DAT", weil Sie mit den Ladebefehlen, die auf die Peripherie bzw. auf das Prozeßabbild der Eingänge zugreifen, maximal vier Bytes zusammenhängend auslesen können.

HinweisSie können konsistente Daten ggf. auch über das Prozeßabbild der Eingänge einlesen.
Ob Ihre S7-300-CPU diese Funktionalität beherrscht, können sie dem Handbuch Automatisierungssystem S7-300: Aufbauen entnehmen.
Alle S7-400-CPUs beherrschen diese Funktionalität.
 
Danke Christoph für deine Schnelle antwort:

Wir benutzen hier in der Firma Simatic V5.5, die alte CPU hat die FW 1.2.1.
Zur steuerung des Reglers wird ein LTI Motion S024.007.0020.0000.1, hier wird von LTI eine Gerätestammdatei zur Verfügung gestellt welche hier genutzt wird.
LTI bietet 4 Standart telegramme zur Drehzahlregulierung, Positionierung/Geschwindigkeit etc. Diese haben den Vorteil das man nicht selbst mappen muss sondern dies automatisch vom Regler gemacht wird. Weitere Telegramtypen sind PPO 1-5 und noch viele weitere. Dies sind jene die man sich selbst zusammen stellen kann, hier muss das mappen auch von uns durchgeführt werden.

Es kam nicht direkt Fehler: Wir haben die Eingangswörter bei eingeschalteter Anlage beobachtet, da hier ständig informationen über Geschwindigkeit, Position oder Drehrichtung übergeben werden. Diese Werte waren bei der alten CPU bei Telegrammentypen die länger waren als 2 aus- 2 eingangswörter konstant auf W#16#0000 während man bei der neuen CPU ein ständiges ändern der Werte beobachten konnte.

Zucken lassen war eventuell ein wenig unprofessional ausgedrückt, wir konnten bei der Drehzahlregulierung ein Analogwert übergeben und damit den Motor bereits über ein simplen Aufbau über die SPS bewegen.

Wir möchten benutzerspezifische Telegramme nutzen um den Regler komplett auf unsere Anforderungen anzupassen.

Unbenannt.png

Bei diesem Fenster waren bei der alten CPU, bei den Telegrammen über 2 Aus/Eingangswörter die Spalte Prozessabbild leer und grau hinterlegt.
 
Diese Werte waren bei der alten CPU bei Telegrammentypen die länger waren als 2 aus- 2 eingangswörter konstant auf W#16#0000

Bei euch eingestellt: konsistenz über die gesamte Länge.

Sie benötigen die SFC 14 "DPRD_DAT", weil Sie mit den Ladebefehlen, die auf die Peripherie bzw. auf das Prozeßabbild der Eingänge zugreifen, maximal vier Bytes zusammenhängend auslesen können.

Deswegen die SFC14/SFC15.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die E/A-Adressen des Reglers liegen zwar im Prozessabbild PAE/PAA, konsistent auf Peripherie > 4 Byte zugreifen kann die alte CPU aber nur per SFC14/SFC15. Automatisch in der Firmware die Peripherie lesen/schreiben geht erst ab Firmware 2.5 - deshalb hat es mit der neueren CPU ohne SFC14/SFC15 funktioniert.
Wie können Sie auf konsistente Daten ohne SFC14/15 als Teil des Prozessabbildes zugreifen?

Harald
 
Zurück
Oben