Absolutwertgeber 6FX2001-5QN25

... schau Dir mal Beitrag #12 an, evtl. hilft es Dir weiter!?
http://www.sps-forum.de/simatic/75005-tia-v13-mit-sp1-und-profinet-drehgeber-2.html

Arbeitest Du auch mit den TO´s einer S7-1500? Dann würdest Du aber mit PLC- Open hantieren und müsstest Dir keine Gedanken über Gebersteuer-/zustandswort etc. machen.
Nö, ich habe ja im selben Thema schon geschrieben, daß ich keine Technologieobjekte von Siemens in meiner Steuerung haben möchte. Was den Betrag #12 angeht, so habe ich exact die umgekehrte Erfahrung gemacht: Wenn man Class 3.1 Kompatibilitätsmodus freigibt, dann lässt sich der Geber überhaupt nicht justieren und meldet auch kein "Steuerung angefordert". Hat auch eine Weile gedauert, bis ich die Class 4 eingeschaltet habe, dann gings.

Probiers also wirklich mal mit leeren OB100 und leeren OB1 und schau was sich der Geber bei Anlauf von der CPU holt.
Ggf. musst du wirklich bei jedem Neustart (OB100) den Preset neu übertragen.
Wie soll das funktionieren wenn es eine Absolutachse ist, und die auch schon mal per Hand im stromlosen Zustand verdreht werden könnte ? Ich sehe hier ganz klar einen Bruch der verbindlichen Funktionsdeklarationen, welche der Hersteller getroffen hat. Mein Geber ist nach dem Manual implementiert. Selbst der Handshake und Co. funktionieren nach Manual.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie soll das funktionieren wenn es eine Absolutachse ist, und die auch schon mal per Hand im stromlosen Zustand verdreht werden könnte ? Ich sehe hier ganz klar einen Bruch der verbindlichen Funktionsdeklarationen, welche der Hersteller getroffen hat. Mein Geber ist nach dem Manual implementiert. Selbst der Handshake und Co. funktionieren nach Manual.

Der Geberoffset hat nichts mit der realen Ist-Position zu tun.
Es muss nur vor Aktivieren der Lageregelung sichergestellt sein, dass der Geber referenziert / an die Mechanik angepasst ist.
Das Verdrehen bekommt der Geber ja mit.
 
Der Geberoffset hat nichts mit der realen Ist-Position zu tun.
Es muss nur vor Aktivieren der Lageregelung sichergestellt sein, dass der Geber referenziert / an die Mechanik angepasst ist.
Das Verdrehen bekommt der Geber ja mit.

Das würde ja darauf hinaus laufen, daß ich den Offset dem Geber selber vergebe und in der Steuerung speichere, anstatt ihn im Geber aufzubewahren. Sicherlich wäre das eine "Notlösung" falls alles andere nicht funktioniert.
Firma Siemens beschreibt aber in dem Handbuch, daß ich den Offset im Geber abspeichern kann.
 
Tja scheinbar war ich mit meiner Ansicht bezüglich des Tests nicht alleine. Beruhigt mich etwas... interessant wäre es schon was beim Testen herausgekommen ist. Oder ist die Erkenntnis so peinlich?

André
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Tja scheinbar war ich mit meiner Ansicht bezüglich des Tests nicht alleine. Beruhigt mich etwas... interessant wäre es schon was beim Testen herausgekommen ist. Oder ist die Erkenntnis so peinlich?

André
Also bei manchen Forumsusern und deren Betragen, frage ich mich ernstlich, ob sie gezielt offenen Streit suchen, oder es einfach gewohnt sind, in einem Gesprächsklima von Feindseligkeiten und gegenseitigen Angriffen zu agieren, und suchen von daher, hier ihre "gewohnte Lebensumgebung" zu installieren.

Lieber André, was soll mir bitte daran peinlich sein, und was soll bitte bei diesem Test schon rauskommen, daß mir peinlich wird ? Daß die Firma Siemens schon wieder irgendeine Produktzusammensetzung verbockt hat, und ich davon der Leidtragende bin ? Das ist mir in der Tat peinlich, aber nur insoweit, daß ich schon wieder irgendwelchen Siemens-Handbüchern blind vertraut habe, ohne das vorher bei uns in der Werkstatt auszutesten.

Ich habe diese blöde Maschine natürlich nicht am Wochenende bei mir zu Hause stehen, und das ist auch gut so. Aber grundsätzlich gibt's bei diesem Test zwei Möglichkeiten:
- 1. er behält seine Position wenn man ihn alleine abschaltet;
- 2. er verliert sie.

In in beiden Fällen nützt mir persönlich diese Erkenntnis wenig, und ich kann nichts daran verändern, weil den Geber muss ich mir einer Steuerung betreiben, und zwar mit dieser. Die Software ist auch fertig geschrieben, und alles funktioniert soweit prächtig, abgesehen von dieser seltsamen Offsettierung. Ich sehe auch nicht ein, weitere unbezahlte Stunden Arbeit in diese Geschichte zu investieren, denn ich kann ja nachweisen, daß die Kopplung Geber-CPU nach Handbuch eingerichtet wurde.
Soll Siemens sich damit rumplagen, aber bevor ich da einen Service-Request aufmache, werde ich wohl diesen Gegentest noch durchführen. Damit Siemens Support weiß, wo der suchen soll.
 
Oh Mann, bist du aber empfindlich. Normalerweise sollte ja nach her Woche schon mal ne neue Info drin sein. Deswegen die kleine Spitze hintendran. Heißt also dass du nichts getestet hast?

André
 
Oh Mann, bist du aber empfindlich. Normalerweise sollte ja nach her Woche schon mal ne neue Info drin sein. Deswegen die kleine Spitze hintendran. Heißt also dass du nichts getestet hast?
André

Leider nein. Wir hatten letzte Woche die Maschinenübergabe, derzeit wird dort aber noch nichts produziert, da der Betreiber außerdem noch einen Maschinenumzug in eine andere Halle plant.
Für nen Normalbetrieb ist der obige Umstand auch erst mal nicht so tragisch, man müsste die Anlage einfach am Strom dran lassen, und irgendeine Lösung wird sich zu gegebener Zeit schon noch finden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das Problem scheint sich gelöst zu haben. Es is eine ziemlich vertrackte Geschichte. Dieser Geber mag es - offensichtlich - nicht, wenn man ihm eine zu kleine Auflösung von INK/Udr vorgibt und fängt dann an zu kotzen. In meinem Fall mochte er die 1000 INK / Udr nicht. Mit 4000 hat sich das seltsame Verhalten plötzlich verflüchtigt (?). Eine ziemlich seltsame Geschichte. Die Krönung von dem Ganzen war, als das mir einmal mitten im Verfahren plötzlich von einem gültigen Lageistwert plötzlich auf - Schießmichtot was gesprungen ist. Einfach so, ohne Stromaus.
 
Sag mal Draco,
hast du den mal das 'G1_IST1' Überwacht, ob der Preset gültig ist?

Mit dem G1_XIST_PRESET_A -Signal kann die Steuerung einen Preset-Wert für den MC- ENCODER über das zyklische Datentelegramm eingeben und dieses mit dem Trigger-Bit aktivieren. Da das Trigger-Bit im selben Signal übertragen wird, kann in diesem Fall nur ein Preset-Wert von maximal 31 Bit eingegeben werden.
Die Struktur des G1_XIST_PRESET_A -Signals wird in der folgenden Tabelle „Absolutwert in G1_XIST_PRESET“ gezeigt.
Mit der 1 → 0-Flanke des Trigger-Bits wird der Preset-Istwert (Bit 0 – 30) als Istwert in G1_XIST1 akzeptiert. Wird dieser Preset-Wert akzeptiert, wird er automatisch remanent gespeichert. Dadurch wird sichergestellt, dass ein über Preset festgelegter Absolutwert auch nach einem Rücksetzen/Neustart des Absolutwertgebers gespeichert bleibt.
Wenn kein Preset-Wert festgelegt wurde, ist Trigger-Bit 31 auf den Standardwert 0 zu setzen.
Hinweis
Die Drehzahl der Geberwelle zum Zeitpunkt der Festlegung des Preset-Werts sollte so niedrig wie möglich oder null sein. Dadurch wird der Einfluss der Kommunikationstotzeiten auf den festgelegten Preset-Wert so gering wie möglich gehalten.
 
@rostiger Nagel:

Ich kommuniziere mit dem Geber mittels Standardtelegramm 82, dort gibt es keinen XIST_PRESET_A.
Ansonsten werden von mir für die Steuerung vom Justagevorgang folgende Bits in Anspruch genommen:
Code:
#TELEGRAMM_82."Ausgabedaten (PZD/Wort)".G1_STW.G1_STW.Bit11 := false;   // Referenzpunktmodus: Gibt an, ob der Lagewert auf einen vorkonfigurierten Absolutwert gesetzt oder um diesen Wert verschoben werden soll. 0: Referenzpunkt / Preset (absolut) setzen 1: Referenzpunkt / Preset verschieben (relativ = Offset)
#TELEGRAMM_82."Ausgabedaten (PZD/Wort)".G1_STW.G1_STW.Bit12 := #HOMING; // Absolutwertgeberjustage    Preset setzen / Verschiebung anfordern: Preset (bzw. Verschiebung) wird gesetzt, wenn dieses Bit auf „1“ geändert wird (steigende Flanke). Standard-Preset-Wert (Verschiebung): 0 Hinweis: Es kann auch parametriert werden, dass der Wert XIST1 mit einer steigenden Flanke ebenfalls einen Schritt macht.

Damit die Dinge, von denen Du sprichst, Aktualität gewinnen sollen, müsste ich Telegramm 860 in Anspruch nehmen. Oder ich verstehe nicht, wie das hier alles wieder so vertrackt und doppeldeutig definiert ist.
Genau genommen macht der Bit 11 im STW ja gar keinen Sinn, weil wenn ich keinen Preset in diesem Telegramm vorgeben kann, wie soll ich dann den Lageistwert um diesen Preset verschieben können ??
 
Zuletzt bearbeitet:
hast recht, das gilt nur für das 860 Telegramm.

aber beim 82er hast du doch das Zustandswort G1_ZSW, dort könntest du
das Bit 12 abfragen "Quittierung für Preset anfordern"

Dies geschieht bereits.
Code:
// Meldung "Geberjustage erfolgreich"
#"Geberjustage erfolgreich" := #TELEGRAMM_82."Eingabedaten (PZD/Wort)".G1_ZSW.G1_ZSW.Bit12;

Wenn ein Antrieb oder Geber mir zurückzumelden vermag, daß er sich erfolgreich geeicht hat, dann nutze ich das natürlich aus, und setze den Status intern erst dann als geeicht, wenn eine solche Rückmeldung vorliegt. Überdies wird die Zeitspanne, die ein Antrieb zum Eichen benötigt, ebenfalls überwacht und ggf. die Fehlermeldung "Zeitüberwachung Eichen Antrieb XXX" rausgehauen. Dazwischen kann sich der Benutzer am OP an einer Textliste erfreuen, wo entweder "Antrieb nicht geeicht" oder "Antrieb geeicht" bzw. "Eichen im Progress" steht.
 
Zuletzt bearbeitet:
Zurück
Oben