Herstellerunabhänger Standardbaustein zur Ansteuerung von Frequenzumrichtern

[Andreas24]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo
ich habe ein kleines Problem, wer kann mir weiterhelfen?
Ich soll einen Standard-FU-Baustein für eine 1500 CPU entwickeln der Herstellerunabhängig eingesetzt werden kann.Es sollen verschiedene PPO-Typen über den Baustein gehändelt werden können und die Umschaltung der PPO-Typenn soll über eine INT-Variablen möglich sein.Der Baustein muss über Ethernet/PROFI-Bus kommunizieren.

Hat da jemand einen Lösungsansatz oder kann mir aussagekräftige Fachbüche empfehlen?

Ich hoffe auf eure Hilfe.

 

[andy_l]

Ein kleiner Tipp: schau mal in den §3 der Foren-Regeln und überlege Dir, wie viele Leute spontan bei Fragen wie "Wer kann mir helfen?" reinschauen.

Wenn jemand eine Idee dazu hat, schaut er in Deinen Beitrag eher rein, wenn im Thema etwas entsprechendes steht, um was es geht.

 

[rostiger Nagel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ein kleiner Tipp: schau mal in den §3 der Foren-Regeln und überlege Dir, wie viele Leute spontan bei Fragen wie "Wer kann mir helfen?" reinschauen.

Wenn jemand eine Idee dazu hat, schaut er in Deinen Beitrag eher rein, wenn im Thema etwas entsprechendes steht, um was es geht.

Ich habe die Überschrift mal ein wenig umgestaltet, also dann jetzt weiter zum Thema.

 

[vollmi]

Also wenns denn unbedingt so ein Allgemeiner Baustein werden soll.
Du könntest in TEMP für jeden Erdenklichen FU die PPOs als Struktur definieren.
Ausserdem definierst du eine Struktur die sämtliche Datenpunkte die benötigt werden besitzt.
Mit dieser gesamtstruktur arbeitest du grundsätzlich im Baustein. Aber am Anfang des Bausteins holst du den Datensatz und schreibst in in die Temporäre struktur die du per Case (Integer Auswahl) auswählst
Wenn du den Temp abgefüllt hast kopierst du die daten in die Gesamtstruktur (im selben Caseverzeigung.)

So als ansatz

CASE #typ OF
    VLT:
        #status := DPRD_DAT(LADDR := #HWID, RECORD => #VLT_Type);
        #FU_FULL.IW := #VLT_Type.IW;
        #FU_FULL.Status := #VLT_Type.Status;
    Danfoss:

Und am ende des bausteins natürlich wieder schreiben.
Wenn du die Daten auf der Peripherie hättest wäre das natürlich etwas einfacher da du auf DPRD/WR verzichten könntest.

mfG René

 

[Andreas24]

danke für den Tip mal sehen was ich daraus machen kann.
Die Aufgabe ist ein Teil meiner Projektarbeit doch in der Schule haben wir nie etwas mit Frequenzumrichtern gemacht,deshalb muss ich erstmal sehen wie man an das ganze Problem herangeht. Ich denke zwar dass ich seitens meines Betreuers da auch Infos bekomme, doch es ist ja immer besser wenn man sich schonmal etwas einarbeitet.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das ist in sofern ein recht sinnloses Unterfangen, als dass du den Inhalt der Prozessdatenkanäle bei den verschiedenen PPO-Typen überhaupt nicht kennst. Das einzige was (mehr oder weniger) standardisiert ist, ist der Aufbau des Status- und des Zustandsworts, und ggf. des Hauptsoll- und Istwerts.

Selbst bei einem FU-Typ für einen einzigen Hersteller kannst du so einen Standardbaustein nicht schreiben, weil der Inhalt variabel ist. D.h. andere Skalierungsfaktoren, anderes Datenformat etc. pp.
Zumindest nicht wenn du die PPO-Daten auch fertig skaliert ausgeben willst. Und nur die PPO-Daten 1:1 durchzureichen und dann muss der Benutzer selber wieder umrechnen bringt dem Anwender auch keinen Vorteil.

Bei mir gibt es z.B. einen Baustein für einen Danfoss VLT mit PPO5, und in der Bausteinbeschreibung ist festgelegt welche Parameter auf den PPOs parametriert werden müssen damit der Baustein funktioniert.

 

[Andreas24]

oh man wie kann man da weiter vorgehen? ich habe die CPU , HIM und den Antrieb den ich nutzen soll und den Baustein später zu prüfen.

 

[Andreas24]

wenn ich es bis jetzt richtig erarbeitet habe bedeutet PPO 5 ja, dass man 4 Wort für die Parameter und 10 Wort für die Prozessdaten zur verfügung hat . bei PPO1 und 2 hat man ebenfalls die 4 Wort Parameter und 2 bzw 6 Wort Prozessdaten und bei den PPO's 3,4,6,7,8 nur Prozessdaten. Ist es dann nicht sinnvoll den baustein auf ppo5 zu erstellen auch wenn später in der anwendung nicht alle worte genutzt werden oder gibt es da probleme?

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ist es dann nicht sinnvoll den baustein auf ppo5 zu erstellen auch wenn später in der anwendung nicht alle worte genutzt werden oder gibt es da probleme?

Der Peripheriebereich bei einer SPS ist begrenzt. Wenn du eine große Anlage mit vielen Teilnehmern hast, und dann bei jedem Profinet/Profibus-Teilnehmer immer den Maximalausbau verwendest auch wenn du ihn nicht benötigst, dann bist schneller an den Grenzen als dir lieb ist. Und mit der Profibus/Profinet-Geschwindigkeit hängt das auch noch zusammen.

Aber dein "Standard-PPO5" bringt dir nichts, weil eben der Inhalt der PPOs nicht Standard sondern variabel parametrierbar ist, und dann auch noch herstellerabhängig unterschiedlich skaliert wird. Bei manchen Siemens-FU musst du z.B. zur Umrechnung von Drehmomenten und Leistung noch einen kryptischen Online-Parameter zur Umrechnung heranziehen den du aus dem Parametriertool ablesen musst (oder über den Parameterkanal lesen). Selbst wenn du sagst, auf dem einen PPO muss der Strom übertragen werden, dann funktioniert das nur für genau einen Typ von FU.

 

[Andreas24]

Danke für diese Infos. Dann muss ich mal sehen wie ich da jetzt eine vernünftige Arbeit abliefern kann. Zum glück habe ich nächsten mittwoch wieder eine Projektbesprechung mal sehen was dabei rauskommt und inn wie fern die Aufgabenstellung geändert/ angepasst werden kann.

 

[vollmi]

Selbst bei einem FU-Typ für einen einzigen Hersteller kannst du so einen Standardbaustein nicht schreiben, weil der Inhalt variabel ist. D.h. andere Skalierungsfaktoren, anderes Datenformat etc. pp.
Zumindest nicht wenn du die PPO-Daten auch fertig skaliert ausgeben willst. Und nur die PPO-Daten 1:1 durchzureichen und dann muss der Benutzer selber wieder umrechnen bringt dem Anwender auch keinen Vorteil.

Die Faktoren und zuweisungen kann man ja ebenfalls Abhängig machen vom Auswahldatenpunkt. Aber am Schluss hat man hier vermutlich genau das Problem was die meisten "Standardbausteine" haben. Man schleppt n haufen Code mit rum den es garnicht braucht und am Schluss eh nicht abgearbeitet wird.
Dann doch lieber einen Standardsteuerbaustein machen und für die FU Typen verschiedene Vorbereitungsbausteine die man entsprechend wählt, welche einem dann die Daten so aufbereiten dass sie direkt vom Standardbaustein verarbeitet werden können.

mfG René

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Du kannst das ja grundsätzlich lösen - aber nicht einfach nur mit DEM Baustein ...
Ich würde es so angehen :
- wenn es um einen FU geht dann generell den PPO festlegen (z.B. PPO 3)
- innerhalb des PPO's festelegen, was wo zu stehen hat
- nun kannst du dir in deinem Baustein einen "Wahlschalter" einbauen, der dann die Hersteller-spezifischen Zuordnungen macht (Anpassung des Steuerworts, wie wird der Sollwert im Regler interpretiert usw.)
Aber auch diese Dinge MÜSSEN im Vorfeld festgelegt sein - also so eine Art "Norm eurer Firma"

Gruß
Larry

 

[Larry Laffer]

Ach ja ... in Anlehnung an das, was Vollmi geschrieben hat :
Ich mache das für mich so, dass ich für jeden Hersteller einen FB habe, der aber nach Aussen die gleiche Schnittstelle mit gleicher Verwendung hat.
Die anderen Dinge habe ich dann natürlich trotzdem festgelegt, wie schon oben beschrieben ...

Gruß
Larry

 

[maxder2te]

Spannendes Projekt!

Unser Antriebstreiberpaket ist auch herstellerunabhängig konzipiert. Allerdings nicht so, dass ich jeden beliebigen Umrichter anhängen kann, sondern dass für jeden Umrichter ein Treiber eingeklinkt werden muss. Die Challange dabei war, dass Umrichter UND Servos damit betrieben werden müssen.

Die wesentlichen Eckpfeiler:
1. Programmierung als FB mit statischen Instanzdaten - alles symbolisch!
2. Auswahl des Umrichters über einen Eingang ("Protokoll").
3. Das "Protokoll" enthält implizit Informationen darüber, wieviele IO-Daten gelesen/geschrieben werden können.
4. In den statischen Daten ist Speicher für die maximale Protokolllänge (aktuell 10 Wörter) als BYTE-Array reserviert.
5. Übergabe der IO-Daten mitttels Hardware-ID (Eingang vom Typ HW_IO), lesen/schreiben der Daten mittels GETIO_PART und SETIO_PART.
6. Festlegung jener Schnittstellensignale, die für den Betrieb jedes Umrichters notwendig sind (Sollgeschwindigkeit, Istgeschwindigkeit, Sollrampe, Iststrom, Motor dreht, .....) und Zusammenfassung in generischen Datentypen (PI-, PQ- und globale Daten)
7. Am FB-Beginn werden die Daten mittels GETIO_PART in einen Rohdatenbereich eingelesen, dann mittels "CASE" je nach "Protokoll" die PI-Rohdaten dekodiert und auf die globale Struktur umkopiert. Daten oder Signale, die der Umrichter nicht liefert, werden mit "sicheren" Werte beschrieben (z.B. wenn der Umrichter keinen Ausgangsstrom liefert, wir dieser in den globalen Daten mit "0" beschrieben und das "Ausganggstrom gültig"-Flag auf 0 gesetzt. Für verschiedene Darstellungsformate muss halt hier eine einheitliche Umrechnung festgelegt werden, z.B. dass die Istgeschwindigkeit immer in U/min angezeigt wird.
8. In einem generischen Bereich kann man mit den Istwerten anstellen was man will und Sollwerte/Freigaben/Betriebsarten generieren.
9. Am Ende des Bausteins gibt es wieder ein CASE, welches gemäß Protokoll die generischen Sollwerte und Freigaben wieder umrichterspezifisch codiert und mittels SETIO_PART auf den Umrichter schreibt.

Kommt ein neuer Umrichtertyp dazu, muss halt der Dekodier-/Kodierbereich entsprechend erweitert werden, ansonsten bleibt alles gleich. Für den Anwender ist faktisch kein Unterschied zu sehen, welches Umrichterfabrikat dahintersitzt.

Im Detail ist es natürlich etwas komlexer - vor allem wenn man einen Positionierbetrieb realisieren will. Zudem sind viele Aufgaben in Unter-FCs gekapselt, um den Code kompakt zu halten. Ich hab mir z.B. auch die Mühe gemacht, über die HW-ID die konfigurierte Länge der PI/PQ-Daten auszulesen und zu kontrollieren, ob die Länge zum Protokoll passen kann. Ein umfangreiches Meldesystem, .....

lg

 

[zako]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich soll einen Standard-FU-Baustein für eine 1500 CPU entwickeln der Herstellerunabhängig eingesetzt werden kann.Es sollen verschiedene PPO-Typen über den Baustein gehändelt werden können und die Umschaltung der PPO-Typenn soll über eine INT-Variablen möglich sein.Der Baustein muss über Ethernet/PROFI-Bus kommunizieren.

Am einfachsten wäre es für Dich wenn Du am Markt gezielt Umrichter aussucht, die "Profidrive"- Telegramme unterstützen (z.B. Wittenstein, Linmot, SIEMENS, Jenaer Antriebstechnik usw.) Dann ist die Schnittstelle definiert und v.a. Du programmierst alles sauber mit PLC Open Bausteinen. D.h. Dein Anwenderprogramm ändert sich nicht.
Für NICHT- Profidrive Antriebe kann man z.B. die Sollwerte der Steuerung auf einen Datenbaustein schreiben lassen. Anschließend im PostServo-OB kann man dann die Daten gewünscht rangieren (bei Drehzahlachsen mit Tel.1 z.B. ist Wort1 das Steuerwort und Wort 2 der Drehzahlsollwert). Aber da muss man dann schon wissen was man da macht (was sind die Bezugswerte im Antrieb, wie ist das Zusammenspiel zwischen Steuer- und Zustandswörter etc.).

... denke einfach mal darüber nach - vielleicht wäre das ja auch ein Ansatz für Dich

 

[DauYing]

Wo man sich denn über die Profidrive Telegramme informieren? Reicht es da wenn man sich im "Umrichter" die PZW / PSW vom Aufbau her selbst zusammen klickt oder muss vom Hersteller das Verhalten abgestimmt werden?... Und welcher Linmot Umrichter kann den Profidrive?

Gesendet von meinem MI 5 mit Tapatalk

 

[zako]

Wo man sich denn über die Profidrive Telegramme informieren? Reicht es da wenn man sich im "Umrichter" die PZW / PSW vom Aufbau her selbst zusammen klickt oder muss vom Hersteller das Verhalten abgestimmt werden?... Und welcher Linmot Umrichter kann den Profidrive?

... anbei der Link zu Linmot (hier steht u.a. "Einfachste Einbindung ... über Profinet IRT und ProfiDrive"):
http://www.linmot.com/de/produkte/servo-drives/

Info´s z.B. bei der Nutzerorganisation:
[SUP]​[/SUP]http://www.profibus.com/technology/profidrive/


In den SIEMENS Handbüchern ist das recht genau dokumentiert, z.B. Steuerwörter und Zustandswörter (Timing Diagramme, Zustandsdiagramme), Normierungen, usw.