# Absolutwertgeber 6FX2001-5QN25



## Draco Malfoy (25 Februar 2015)

Moin zusammen!

Folgende Frage, falls das einer weiß: Wenn ich dem o.g. Geber mit Mitteln des Telegramms 82 oder 83 eine Absolutwertgeberjustage verpasse, soll er dann in der Theorie den Offset remanent speichern oder gilt das nur bis zum nächsten Stromausfall ?

Ich habe heute die Erfahrung gemacht daß er seinen Offset nach dem Stromaus verliert, allerdings kann ich nicht ausschließen, daß es z.B. an einem defekten Geber, oder am falschen Handling in der Software lag.

Besten Dank für Licht im Dunkeln,

Grüße Draco


----------



## offliner (25 Februar 2015)

Der Wert sollte eigentlich remanent gespeichert werden (bei aktivierter Class 4-Funktionalität).


----------



## Draco Malfoy (26 Februar 2015)

Class 4 Funktionalität ist aktiviert. Vielleicht klappt irgendwas beim TIA Portal mit der Geberkommunkation nicht richtig ?
Er verliert ständig seine geeichte Posoition nach Stromaus und landet nach dem Wiedereinschalten wieder ber -Zigtausend-Schießmichtot INK. Ich habe schon mit der Antriebsfachberatung von Siemens telefoniert, die wussten auch keinen Rat.


----------



## MSB (26 Februar 2015)

Also soweit ich das laut Handbuch verstanden habe, scheint es da auch noch einen Zusammenhang mit einem Parameter in der HW-Konfig des Gebers zu geben.
"Preset beeinflusst XIST1", steht Standardmäßig wohl auf "Sperren" und führt, soweit ich das laut Handbuch verstehe auch dazu das der Preset nicht remanent übernommen wird.


----------



## Draco Malfoy (27 Februar 2015)

MSB schrieb:


> Also soweit ich das laut Handbuch verstanden habe, scheint es da auch noch einen Zusammenhang mit einem Parameter in der HW-Konfig des Gebers zu geben.
> "Preset beeinflusst XIST1", steht Standardmäßig wohl auf "Sperren" und führt, soweit ich das laut Handbuch verstehe auch dazu das der Preset nicht remanent übernommen wird.



Aha. Ja, besten Dank für den Hinweis. Steht bei mir nämlich auch auf "Sperren".... Werde ich ausprobieren ob es was bewirkt, wenn man den freigibt.


----------



## Draco Malfoy (28 Februar 2015)

Upd: Ich habe mich bei der obigen Aussage vertan - dem ist nicht so!
Bei mir ist alles freigegeben, und trotzdem landet er nach dem Wiedereinschalten immer wieder scheinbar bei der untersten Gesamtauflösungsgrenze bzw. Geberbereichsgrenze.

Siehe Screenshot:


----------



## Blockmove (28 Februar 2015)

Hab diese Geber noch nicht verwendet ... aber bei manchen Herstellern musst du die Konfig explizit in den NV-Speicher schreiben.

Gruß
Dieter


----------



## Draco Malfoy (28 Februar 2015)

Blockmove schrieb:


> Hab diese Geber noch nicht verwendet ... aber bei manchen Herstellern musst du die Konfig explizit in den NV-Speicher schreiben.
> 
> Gruß
> Dieter



Ich habe eine solche Option am Geber nicht. Das müsste dann i-wie heißen "Config remanent speichern" oder "Konfiguration hochladen" oder so ?


----------



## JoopB (28 Februar 2015)

Mit der Profinet geber hab ich noch nicht gearbeittet, aber mit der Profibus version, gibt man die preset wert durch das ausgang DW hex 8xxx xxxx zu steueren , darnach die input auf hex 0xxx xxxx abvragen und dan wieter das hochste ausgang bit auf 0 steueren. Die preset ist darnach rement in die geber gespeichert. Diese weisse von presset eingeben werkt mit Siemens , Fraba und mit Lika profibus absoluut encoders. Mit die Profinet variante soll dass nicht viel anders sind.

Gruss,

Joop


----------



## Draco Malfoy (28 Februar 2015)

JoopB schrieb:


> Mit der Profinet geber hab ich noch nicht gearbeittet, aber mit der Profibus version, gibt man die preset wert durch das ausgang DW hex 8xxx xxxx zu steueren , darnach die input auf hex 0xxx xxxx abvragen und dan wieter das hochste ausgang bit auf 0 steueren. Die preset ist darnach rement in die geber gespeichert. Diese weisse von presset eingeben werkt mit Siemens , Fraba und mit Lika profibus absoluut encoders. Mit die Profinet variante soll dass nicht viel anders sind.
> 
> Gruss,
> 
> Joop



Moin. Danke für deine Rückmeldung, aber - ganz ernsthaft ich verstehe nicht was Du meinst bzw. wie du das beschreibst, verstehe ich es nicht. Ich kommuniziere mit meinem Geber mittels standardmäßiger Profidrive-Telegrame, in meinem Fall 82, aber es gibt auch 83 oder noch andere Telegrame. Profibusgeber haben bei Siemens zumindest einen gänzlich anderen Kommunikationsstandard. Mir liegt ein Baustein aus der Siemens Easy Motion Control Library vor (als SCL-Quelle), nämlich FB24, der mit Profibusgebern kommuniziert, und dort siehts gänzlich anders aus.


----------



## sps-concept (28 Februar 2015)

Hallo,

Solltest evtl mal prüfen ob das nur bei kompletten Abschalten von CPU und Geber ist oder nur wenn der Geber spannungslos war und die CPU nicht. so was nennt sich Fehlersuche durch Ausschluss. Meist sitzt in solchen Fällen auch der Fehler vor der Tastatur.

André


----------



## Draco Malfoy (28 Februar 2015)

sps-concept schrieb:


> Hallo,
> so was nennt sich Fehlersuche durch Ausschluss.





> Meist sitzt in solchen Fällen auch der Fehler vor der Tastatur.


Ich entschuldige mich vielmals, aber kommt es nur mir so vor, daß ich meine in diesem Beitrag einen gewissen Hauch von nicht ganz freundlicher Gesprächsrichtung zu erkennen ?


> Solltest evtl mal prüfen ob das nur bei kompletten Abschalten von CPU  und Geber ist oder nur wenn der Geber spannungslos war und die CPU  nicht.


Und was soll mir diese Prüfung bringen wenn ich mal so fragen darf?


----------



## sps-concept (28 Februar 2015)

Hallo,

Was soll das bringen? Eigentlich solltest du da auch selbst drauf kommen? Was weiß ich was im Anlauf der CPU programmiert ist... So findest du raus was beim reinen Ausfall des Gebers passiert. Um ganz sicher zu gehen dass nichts von der CPU aus angestoßen wird mache ein Testprogramm wo du nur lesend auf den Geber zugreift.

André


----------



## Draco Malfoy (28 Februar 2015)

> Was weiß ich was im Anlauf der CPU programmiert ist... So findest du raus was beim reinen Ausfall des Gebers passiert.


Ich habe da nichts reinprogrammiert, der Anlauf-OB ist bei mir OB100 und dort wird mit dem Geber nicht kommuniziert.


> mache ein Testprogramm wo du nur lesend auf den Geber zugreift.


Wenn ich nur lesend auf den Geber zugreife, kann ich ihn nicht eichen also keine Absolutwertgeber-Justage durchführen. Damit werde ich niemals herausfinden ob er seine Eichposition verliert, weil ich kann ihm ja dann keine vorgeben.


----------



## sps-concept (28 Februar 2015)

Hallo und wie wäre es denn Geber mit dem Originalprogramm zu presetten und dann mit dem Testprogramm nein Spannungsausfall zu testen? Sorry wenn ich nicht komplett alles vorkaue. Aber anscheinend muss man das.... Ich klinke mich jetzt hier wieder aus.

André


----------



## Draco Malfoy (28 Februar 2015)

sps-concept schrieb:


> Hallo und wie wäre es denn Geber mit dem Originalprogramm zu presetten und dann mit dem Testprogramm nein Spannungsausfall zu testen?


Ich sehe keinen Grund dafür, in meinem Programm ist völlig transparent und dort kann eigentlich keine "ungewünschte Eichung" oder sonst noch etwas derartiges passieren. Ich habe eine standartisierte Vorgehensweise zum Eichen von Antrieben und Gebern, aufgebaut mit mehreren RS-Flipflops, die eigentlich auch einwandfrei funktioniert und die ich seit Jahren schon einsetze. Und nur dieser Geber reagiert seltsam.


> Sorry wenn ich nicht komplett alles vorkaue. Aber anscheinend muss man das....


Ich begreife halt nicht wo Du hin willst.


> Ich klinke mich jetzt hier wieder aus.


Mal ganz ehrlich, hast Du diese Geber überhaupt schon mal im Einsatz gehabt ?


----------



## Blockmove (1 März 2015)

Die Idee von sps-concept mit dem Prüfen von Geber und  / oder CPU spannungslos-schalten ist sinnvoll.
Evtl. holt sich der Geber beim Hochlauf die Einstellungen aus der Hardware-Config...


----------



## Knaller (1 März 2015)

Moin
Das mit diesem Test von CPU und Geber ist sinnvoll.   
Der Geber ist nicht von Siemens. Daher sollte man den orginall Hersteller raus kriegen.
Die grossen Firmen Heidenhain und Sick-Stegmann sind da manchmal auch nicht schuldlos. 
Da wird manchmal was geändert und schon fällt man auf die Sch.,...,.Beim Stegmann haben die mal Zeiten an die Speck angepasst und schon gab es Probleme.
Das gleiche bei Beckhoff.  Ethercat ist nicht gleich Ethercat.  Da wurden auch die maximal zulaessigen Jitter Zeiten nicht eingehalten.   Eine gerundete 1 ist nicht immer 1 vor allem bei einem 64bt System.
grüße Herbert


----------



## Draco Malfoy (1 März 2015)

Hallo Herbert !


Knaller schrieb:


> Das mit diesem Test von CPU und Geber ist sinnvoll.


Werde ich ausprobieren.


> Der Geber ist nicht von Siemens. Daher sollte man den orginall Hersteller raus kriegen.


Korrekt. Diese 6FX2001-.... Geber sind in der Regel von Siemens nur gelabelt, und Hersteller ist m.W. Heidenhain.
Ist bloß die Frage, warum man sich als Anwender mit so einem Mist überhaupt auseinandersetzen muss, wenn ich also ein Produkt X bei Firma S kaufe, und dann noch ein Produkt Y bei derselben Firma, und beide lt. Handbuch miteinander kompatibel sein sollten.


----------



## Blockmove (1 März 2015)

Draco Malfoy schrieb:


> Ist bloß die Frage, warum man sich als Anwender mit so einem Mist überhaupt auseinandersetzen muss, wenn ich also ein Produkt X bei Firma S kaufe, und dann noch ein Produkt Y bei derselben Firma, und beide lt. Handbuch miteinander kompatibel sein sollten.



Du kaufst nicht bei Produkt X und Produkt Y bei Firma S.
Dein Produkt X ist von Unternehmensbereich A der Firma S und dein Produkt Y ist von Unternehmensbereich B der Firma S.
Das war schon immer ein Riesenproblem bei Firma S. Aus diesem und einigen anderen Gründen sind sie bei uns im Bereich Antriebstechnik vor x Jahren rausgeflogen.
Hilft dir aber bei deinem Problem nicht wirklich.

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.


----------



## zako (1 März 2015)

... 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.


----------



## Draco Malfoy (1 März 2015)

zako schrieb:


> ... 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.


----------



## Blockmove (1 März 2015)

Draco Malfoy schrieb:


> 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.


----------



## Draco Malfoy (1 März 2015)

Blockmove schrieb:


> 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.


----------



## sps-concept (8 März 2015)

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é


----------



## Draco Malfoy (8 März 2015)

sps-concept schrieb:


> 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.


----------



## sps-concept (8 März 2015)

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é


----------



## Draco Malfoy (8 März 2015)

sps-concept schrieb:


> 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.


----------



## Draco Malfoy (26 März 2015)

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.


----------



## rostiger Nagel (15 April 2015)

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.
> ...


----------



## Draco Malfoy (15 April 2015)

*@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:

```
#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 ??


----------



## rostiger Nagel (16 April 2015)

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"


----------



## Draco Malfoy (17 April 2015)

rostiger Nagel schrieb:


> 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.

```
// 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.


----------



## boulette (24 August 2016)

Draco Malfoy schrieb:


> Upd: Ich habe mich bei der obigen Aussage vertan - dem ist nicht so!
> Bei mir ist alles freigegeben, und trotzdem landet er nach dem Wiedereinschalten immer wieder scheinbar bei der untersten Gesamtauflösungsgrenze bzw. Geberbereichsgrenze.
> 
> Siehe Screenshot:
> ...



wo kann man einstellen


----------

