Lageregler - überwachen ob er richtig funktioniert

M

ML1982

Level-2
Beiträge
138
Reaktionspunkte
18
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

Ich habe einen einfachen Lageregler geschrieben, der nach dem Prinzip:
v=sqrt(2*s*a)
funktioniert.
Abhängig von dem Abstand zum Ziel(s) und der parametrierten Beschleunigung(a) wird die Sollgeschwindigkeit berechnet.
Der Lageregler funktioniert auch gut, obwohl die untergelagerte Drehzahlsteuerung ziemlich ungenau arbeitet.

Jetzt würde ich noch gerne die Zeit berechnen die, der Lageregler braucht um das Ziel zu erreichen.
Da Beschleunigung und Verzögerung bekannt sind, müsste das auch einigermaßen funktionieren. Der Fall wo bis v_max beschleunigt werden kann ist auch einfach. Aber was ist dort, wo das nicht der Fall ist, da fällt mir gerade nicht ein, wie ich es am besten ausrechne...


Zusätzlich überwache den Strom, wenn dieser zu groß wird, klemmt irgendwas. Funktioniert gut
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Realtime

nur 'mal angemerkt:

Falls die Hardware auf der der Algorithmus läuft eine SIEMENS S7 ist, sollte man darauf achten, dass der OB1 kein Realtimeverhalten hat. Die Zykluszeit, also die Widerholungsrate mit der die Formeln bearbeitet werden, ist eine Funktion der CPU Auslastung. Alle zeitbezogenen Berechnungen (Geschwindigkeit, Beschleunigung, Integration) liefern also erhebliche Fehler. Vielleicht ist das der Grund für die ziemlich ungenaue unterlagerte Drehzahlregelung, die Merten anspricht.

Dafür gibt es die OB 30 Bausteine. Diese haben ein festes Timing. Der FB oder FC mit dem Regelalgorithmus sollte aus einem dieser Bausteine aufgerufen werden. Allerdings ist dann auch für den synchronen Refresh der kritischen Ein- Ausgänge zu sorgen.

Nun hoffe ich 'mal dass Mertens mit einer Hardware arbeiten darf, dessen Entwickler ihre Hausaufgaben besser gemacht haben als jene Herren in Erlangen oder Karlsruhe, die zwar nie ein Ingenieurspatent erhalten hätten wenn sie nicht Realtime-Multitasking herbeten gekonnt hätten, aber diese Selbstverständlichkeit nicht in die Schöpfung jener SPS einfliessen liessen, die weltweit als DAS Deutsche Qualitätsprodukt schlechthin dastehen muß.

...übrigens: die Guys aus Milwaukee haben da auch Defizite..




BFlat
mit einer hoffentlich überflüssigen Anmerkung
 
Zuletzt bearbeitet:
die Drehzahlregelung mach nicht ich, sondern ein anderer CAN Bus Teilnehmer.

Ich MUSS leider mit einer Siemens S7 arbeiten.
Ich nehme aber auch den OB35 und arbeite nicht mit dem Prozessabbild das nur im OB1 aktualisiert wird.

Man kann aber auch den OB1 verwenden, denn in einer 319CPU ist die Zeitauflösung recht gut. Man benötigt dann nur Regler die mit dynamischen Zyklus. Habe ich auch schon gemacht.

Aber schlecht finde ich S7 bezüglich der "Threads" auch
 
OB1 ist die schlechteste Wahl für (dynamische) Regelungen allgemein, da das Zeitverhalten nicht vorhersagbar ist. Hier benötigt man, wie BFlat schon schrieb konstante Abtastzeiten wie sie von OB30 - OB38 zur Verfügung gestellt werden.
 
Ich programmiere ja zum Glück nicht nur S7 sondern auch manchmal ein C/C++ Programm unter Linux.

Das was Siemens mit OB3X und OB1 macht, sind im Endeffekt ja nichts anders als dass, was in der Hochensprachenwelt als threads Bezeichnet wird.
Wobei man sich jetzt drüber streiten könnte, ob es Threads oder Prozesse sind...
http://de.wikipedia.org/wiki/Thread_(Informatik)
 
Merten1982 schrieb:
Das was Siemens mit OB3X und OB1 macht, sind im Endeffekt ja nichts anders als dass, was in der Hochensprachenwelt als threads Bezeichnet wird.
Wobei man sich jetzt drüber streiten könnte, ob es Threads oder Prozesse sind...
http://de.wikipedia.org/wiki/Thread_(Informatik)
Zum Vergrößern anklicken....

Eigentlich sind die Siemens Zeit-OBs aber Interrupts. Denn der Code im Interrupt wird so lange ausgeführt bis er fertig ist, oder von einem höher priorisierten Interrupt unterbrochen wird. Ein Thread bekommt (je nach System) vom Betriebssystem einen festen Zeitschlitz zugeordnet.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Da haste recht.

BTW.:
Bei linux mit RT-Patch ist ein Interrupt auch ein Thread bzw. Prozess mit eigener Priorität.

Das ganze Handling finde ich hier bei S7 einfach nicht so toll.
Manchmal will ich gar keinen OB1 sondern nur einen OB35.
Dann gehts aber los, was ist mit dem Prozessabbild und was ist mit der Datenübertragung zum Touchpanel. Die Rechenzeit zur Datenübertragung ist sind ja ?% des OB1 Zyklus. Dann übertrage ich noch Daten per TCP/IP, wann und wo macht die CPU das? Dann nutze ich noch Funktionen wie Synchronisation per NTP, wann und wo macht die CPU das? Usw.
Dann hat die eine CPU einen Background OB die andere wieder nicht...

​
 
Die Diskussion ob OB1/OB35 entfällt, wenn man sich im OB1 anhand der Zykluszeit eigene Taktmerker generiert.

Den Zyklus, in dem dann die betreffenden Unterprogramme anhand dieses "User-Taktbits" aufgerufen werden, kann man zusätzlich durch ein Schieberegister "entlasten".

Mein OB35 ist eigentlich immer relativ leer...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich denke, so verfehlst du das Thema...

Was du vor hast funktioniert einigermaßen, wenn du lange Aufrufzyklen für deine Programmteile hast und einen schnellen OB1. Umgekehrt wird das in die Hose gehen.
 
Merten1982 schrieb:
Ich MUSS leider mit einer Siemens S7 arbeiten.
Zum Vergrößern anklicken....
Man benötigt dann nur Regler die mit dynamischen Zyklus. Habe ich auch schon gemacht.
Zum Vergrößern anklicken....
Schön, dass es hier auch Programmierer gibt ;)

Zum Thema, der Ansatz, aus jeder Situation heraus die Zeit bis zur Zielposition zu ermitteln, ist natürlich die vollständigste Lösung und ermöglicht mehr als nur Fehlerüberwachung.

Ausgehend vom Stillstand an der Startposition sollte es einfach sein: der halbe Weg wird für Beschleunigen, der Rest für Bremsen benutzt... aber angenommen, die 2 Rampen sind unterschiedlich. Wenn ich richtig verstanden habe, ist der Fall "Maximalgeschwindigkeit wird erreicht" schon gelöst. Ich hab auch grade keine Lösung parat. Aber versuch mal: nimm die Formeln fürs Beschleunigen vom Startpunkt aus und fürs Bremsen auf den Zielpunkt. Da, wo Position und Geschwindigkeit gleich sind, ist der Schnittpunkt, das wird die Maximalgeschwindigkeit für den schon gelösten Fall.

Interessant wird es, von jeder beliebigen Kombination aus Position und Geschwindigkeit die Zeit bis zum Stillstand am Zielpunkt zu ermitteln. An dem Problem war ich mal dran, habe aber nur eine Teillösung gebraucht.

Weitere Möglichkeiten zur Fehlerüberwachung:

Zum Lageregler gehört sicher noch ein "KP" wie in einem PID-Regler. Und eine Abweichung zwischen Ist- und Sollposition. Für die lässt sich eine Grenze angeben.

Aber ich habe schon mal einen Positionierer ohne Lageregler geschrieben. Der Lageregler übernimmt dann erst nahe der Zielposition.
 
Hallo Zusammen,
so wie ich das Thema verstanden habe geht es um die Zeit- bis das Ziel erreicht wird. Die Strecke kann in 3 Teilbereiche aufgeteilt werden.
1) Start- Beschleunigung bib ev. vmax
2) gleichförmige Bewegung mit Vmax
und dann
3) Verzögerung.
Da du für denn Fall V=vmax schon eine Lösung hast-wird in allen anderen Fällen dann nur der zweite Teil entfallen.
Eine Kalkulatin ist dann einfach- wenn du zu jedem "Meßpunkt" die benötigte Strecke- Zeit bis zum Stillstand berechnest.
Bei:
Gesamtstrecke= Beschleunigungsstrecke+Bremsstrecke< Strecke zum Ziel dann weiter Beschleunigne (wenn vax nicht erreicht).
Bei:
Gesamtstrecke= Beschleunigungsstrecke+Bremsstrecke= Strecke zum Ziel dann bremsen.
Wenn:
Gesamtstrecke= Beschleunigungsstrecke+Bremsstrecke> Strecke zum Ziel dann Soforthalt es wird dann in naher Zukunft krachen.
Hoffe etwas geholfen zu haben
So long
 

Similar threads

ZottelMD
Mal wieder ein Prüfstand - drehzahlabhängiges Gegenmoment
Antworten
2
Aufrufe
10K
ZottelMD
ZottelMD
L
igus D1 über CANopen - Homing funktioniert - andere Modi nicht
2
Antworten
21
Aufrufe
10K
LeFish
L
O
F: SPS-Fragen bzgl. kurzen Zykluszeiten etc. (lang)
Antworten
18
Aufrufe
10K
o.bartz
O
Zurück
Oben