Kann SRAMP beim Start negativ Werden ?

[jojoax]

Moinsen,
ich versuche mich gerade daran eine saubere S-Rampe zu implemtieren.
So in der Art geht es soweit sehr gut.

CALL  "SRAMP"
       X         :=#sw   //  -90 .. + 90 möglich
       A_UP      := 16.66
       A_DN      := -16.66
       VU_MAX    := 16.66
       VD_MAX    := -16.66
       LIMIT_HIGH:=  100.0
       LIMIT_LOW := -100.0
       RST       :=L19.0
       Y         :=#out
       V         :=#vk
      NOP   0
...

Die SW werden in % angegeben, der Ausgang in % ausgewertet, damit kann ich recht gut zur Maschine skalieren.

im ff. wird #out aut den Antrieb skaliert. Leider rennt mir mein Antrieb jedesmal erst in die "falsche" richtung los.
Vorwärts wird zu einem Impuls Rückwärts und umgekehrt.

Hmm, kann die S-Rampenfunktion kurz am Anlauf Negativ werden ?

also bei den Startbedingungen Soll=15 Ist=0 ? So das Out kurz < 0 wird ?


Grübeln ...
Jojo

[Fussel0804]

Hi,
Ich werde es heute abend mal testen.

Dann berichte ich näheres.

Gruß Stefan

[Fussel0804]

Also,
nach Ausgiebigem Testen kann ich folgendes Berichten:

Das Verhalten eines entgegengesetzten Impulses kann ich nicht erkennen.

Ich habe noch 2 Bilder angehängt:

DB-Online Werte

Bild 1:
Istwert:  0
Sollwert: 0

Bild 2:
Istwert:  15
Sollwert: 15

Die letzten 4 Zeilen schreiben Min und Max-Werte mit:
Wenn hier ein "Ausreißer" in die Falsche Richtung kommen würde, könnte man den Wert dort ablesen.

Also, irgend etwas stimmt bei dir nicht, aber der Baustein rechnet richtig.

Welche Hardware setzt du ein?
Zykluszeit?
Verarbeitest du den Ausgangswert irgendwie weiter?

Gruß Stefan

[gelöscht durch Administrator]

[jojoax]

Moin,
danke für das 2te Augenpaar.
mir war mein Antrieb im Test/Labor auch korrekt geblieben,
in der realen Anlage jedoch negativ aufgeblitzt.

Ich habe eine S7-315DP, und Stellglied via DP auf FU/Refu Drive 500.
Der Zyklus liegt bei ca. 30ms im Schnitt. Speiche bei ca. 40% belegt.
#out vom SRAMP wird nur noch von Prozentwerten auf die Hardware Scaliert.

Hatte das mit einem <CMP und einem SR gefangen.
Muss wohl noch tiefer graben...

Gruß Jojo

PS: arbeitet schon jmd. an einem Positionier-Modul ?
falls nicht  könnte bei mir sowas für die Lib abfallen :)

[Fussel0804]

Wenn ich dich richtig verstehe, übergibst du den Wert mittels Profibus als (WORD) an deinen Antrieb.

Kann es sein, dass die SPS und der Antrieb eine andere Wortstruktur benutzen?

Vertauschen von Low und High Byte im Wort?

Da du ja eine Siemens CPU hast:

Schreibe vor den Transferbefehl (T PAW...)
den Befehl TAW

Bsp:
L [Sollwert für Umrichter]
TAW
T PAW...

Damit wird Low und HighByte vertauscht.

Das gleiche hast du auch, wenn du WAGO PROFIBUS-Koppler an ner Siemens CPU betreibst.

Gruß Stefan

[Fussel0804]

PS: arbeitet schon jmd. an einem Positionier-Modul ?
falls nicht  könnte bei mir sowas für die Lib abfallen :)

Ja, das mache ich.

Jedoch setze ich dafür ein Positioniermodul von ControlTechniques ein
(Umrichter CONTROL TECHNIQUES UNIDRIVE SP)

Ich gebe dem Umrichter einen Positionswinkel oder Linearposition mit einem Steuerbit zum Losfahren
Alle Rampen werden im Umrichter verarbeitet.

Feine Sache

Gruß Stefan

[jojoax]

Ja, das mache ich.

Jedoch setze ich dafür ein Positioniermodul von ControlTechniques ein
(Umrichter CONTROL TECHNIQUES UNIDRIVE SP)

Ich gebe dem Umrichter einen Positionswinkel oder Linearposition mit einem Steuerbit zum Losfahren
Alle Rampen werden im Umrichter verarbeitet.

Tja, das mit den Rampen im FU ist so eine Sache. Ich stoße im Job sehr häufig auf Positionierprobleme.
Die meisten Sorgen machen mir da komplexe Frequenzumrichter im Stellglied. Die verursachen immer wieder Ärger mit ihrem unkontrolliertbarem Zeitverhalten - bemerkbar macht es sich oftmals in einem verschmiert wachsendem I-Anteil im Gesamtregelkreis. Folge, Regler, Positioniersystem schwingt.
Das kann man wohl nur mit 2 Strategien vermeiden, eine davon ist Deine. Ein Technologie Regler zur Positionierung im/am FU, bzw. abgestztes Regelgerät (ich hatte die früher).

Das ist jedoch eine für Anlagen- und Steuerungsbauer nicht so dolle Lösung, da man auf eine Gerätekombination festgelegt ist.
Damit wird man auch von dem Gerätebauer abhängig, der resultierende Code ist sehr Geräte und Anlagenspezifisch, kaum über Projektgrezen zu portieren.

Ich hatte eine ähnliche Kombination seit über 10 Jahren im Dienst, jedoch ist der Pos. Regler in der ursprünglichen Form (worauf meine Projekte massiv aufbauten) ist nicht mehr verfügbar. Obwohl technisch sehr gut, waren die Positionsregler für die "vor Ort" Wartungskollegen kaum zu beherrschen. Ähnlich sehe ich das inzwischen mit komplexen Frequenzumrichteren.
Je mehr die können, desto schwerer ist es die korrekt zu bedienen und über Jahre weg in Betrieb zuhalten. Zu leicht werden Einweisungen und Schulungen in den grauen Sumpf des Vergessens verschoben.

Daher meine 2. Strategie:
Der Umrichter wird so "dumm" wie irgend möglich gehalten/geplant; er wird als "Servo"-Verstärker ausgelegt. Im Prinzip muss der mit der "Geräte-Intelligenz" nur melden und den Antrieb schützen, ansonsten gilt alzeit FRG & Soll := Ist.  ;)
Damit sind FU und Antriebsanordnung austauschbar. Diese Anforderung erfüllen alle Geräte am Markt.
Das Verfahren der Achsen erledigt die PLC/SPS.

Meine Lösung sieht dann so aus:
Manueller Betrieb via "SRAMP" oder "FT_RMP".
Positionierbetrieb via "CTRL_PID" mit nachgeschalteter "SRAMP" oder "FT_RMP", die bei Limit := true aktiv sind.

Meine Laborversuche haben ergeben, daß sich diese Kombination als recht robust darstellt und anfühlt.
Ich werde das auf einer realen Maschine am Wochenende mal ausgiebig testen.
Da sollte am Ende ein Ergebnis bei rauskommen, das sich evtl. in die OSCAT aufnehmen ließe.

Idealer weise mit einer Schleppfehler Erkennung, die eine Abweichung vom Soll zu jedem Zeitpunkt erkennt.

Gruß Jojo