Problem mit Absolutwetgeber 6FX2001-5FS24 und FM351 Positioniermodul

[caveleira]

Zuviel Werbung?
-> Hier kostenlos registrieren

Anhang anzeigen FM 351 FIX. SPEED Parametrierung.pdf
Anhang anzeigen FC48.pdf
Anhang anzeigen FC50.pdf
Anhang anzeigen 6FX2001-5FS24_datasheet_de_en Absolut Geber.pdf

Guten Tag, hier mein erstes Topic.

Ich habe 4 PDFs angehängt, hoffe es geklappt hat.

Ich beschreibe jetzt unsere Anlage:
Wir messen Fässer, die auf den Rollenbahnnen gestelltsind. Die Fässer sind geführt bis zum Drehteller. Dort findet statt dieMessung. Erstens es gibt ein Serielle Kommunikation mit einem Rechner, der dieMessung steuert durch Serielle Befehle. Der Drehteller steht immer auf 0Position, d.h. ein metallisches Teil vom Drehteller steht direkt über einInduktives Schalter, -45S4 GS-233, (E 9.3). Wenn der Rechner den Befehl 'G'schickt, beginnt die Drehung, durch den Motor 53K3 M-231 Option F, (A 5.2).Während diese Drehung den Rechner schickt jede 500ms den Befehl 'A', somit erweiß die Position. Das ist bis 330°, danach wartet er einfach darauf, bis denDrehteller wieder erreicht den Nährungschalter -45S4 GS-233, dann schickt zu den Rechner Befehl'F', nur dann kann eine neue Drehung beginnen. Die Schritten sind gesteuert inFC140.

Das Problem ist, NUR MANCHMAL, der Position Stopp auf 353,5°, d.h. auf 4096 Absolutwertgeber Position. Dann die nächste Drehungbeginnt mit 0, da die FC48 nicht richtig begonnen hat, und bleibt so bis 302°,d.h. 3500wert, dann ist in FC48 >3500 und zählt er richtig weiter, bis 360°,also 4172. Den Rechner erkennt diese Drehung als Fehler(da bis 300° kein Infoposition hatte) und wiederholt die, dieses Mal richtig. Und weiter bis nächste Fehler. Und immer so. Den Absolutwertgeber wurde getauscht (gleiche Modell einfach angeschlossen, da die Parametrierung gleich ist , eine Probeg emacht, alles hat richtig funktioniert und dann wieder in Betrieb), aber der Fehler kommt manchmal wieder. Nächste schritt wird den Nährungschalter austauschen, aber ich denke es wird auch nicht helfen, da den Fehler trifft ein gute Stück bevor den Nährungschalter, und da der Fehler immer trifft genau in der Position 4096, genau wenn den Absolutwertgeber eine Drehung gemacht hat. Er ist ein Multiturn Absolutwertgeber, aber etwas stimmt nicht ganz, und weiß ich nicht genau. Vielleicht jemand hier weiß viel besser.

Eine Lösung wäre statt 3500 in die Funktion, 200 nutzen, dann hätte ich keine Warning von dem Rechner, weil ihn egal ist, 5° mehr oder weniger, da er die Messung/Drehung einfach in 12 Stücken verteilt (30° jede). Aber natürlich es ist keine schöne Lösung, und es gefällt auch nicht meinem Chef . Wir hoffen das richtig beheben.

Notiz: Ich habe hier nichts Programmiert oder installiert, die ganze Anlage wurde eingebaut vor 15Jahre ungefähr, und hier es gibt niemanden der das Programm kennt, und ich bin auch Anfänger.

 

[JoopB]

ich denke dass da etwas fals ist mit die paramentrierung von der FB351.

[FONT=Courier][SIZE=1][FONT=Courier][SIZE=1]Geber

Geberart 25 Bit Absolutgeber (SSI)

Zählrichtung Invertiert

Auflösung

Weg pro Geberumdrehung 1.000 grad

Inkremente pro Geberumdrehung 4096

Überwachung

Drahtbruch ein

Telegrammfehler ein

Fehlimpulse aus

Absolutgeber (SSI)

Umdrehungen 4096

Baudrate 188 kHz
[/SIZE][/FONT][/SIZE][/FONT]

Geber:

[B][FONT=SiemensSansGlobal-Bold][SIZE=1][FONT=SiemensSansGlobal-Bold][SIZE=1]Auflösung

[/SIZE][/FONT][/SIZE][/FONT][/B][FONT=SiemensSansGlobal-Bold][SIZE=1][FONT=SiemensSansGlobal-Bold][SIZE=1][/SIZE][/FONT][/SIZE][/FONT][I][FONT=SiemensSansGlobal-Italic][SIZE=1][FONT=SiemensSansGlobal-Italic][SIZE=1]Resolution
[/SIZE][/FONT][/SIZE][/FONT][/I]
[FONT=Arial][SIZE=1][FONT=Arial][SIZE=1]25 bit (8192 Schritte x 4096 Umdrehungen)

[/SIZE][/FONT][/SIZE][/FONT][I][FONT=SiemensSansGlobal-Italic][SIZE=1][FONT=SiemensSansGlobal-Italic][SIZE=1]25 bit (8192 increments x 4096 rpms)
[/SIZE][/FONT][/SIZE][/FONT][/I][FONT=SiemensSansGlobal-Italic][SIZE=1][FONT=SiemensSansGlobal-Italic][SIZE=1][/SIZE][/FONT][/SIZE][/FONT]

Da die auslossung von geber 2 x zu gross ist wie in FM351 paramentriert geht da warscheinlich etwas false mit das referieren.

Gruss Joop

 

[Morymmus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Frage wäre ja, ob dieser Fehler "schon immer" da war, oder ob sich etwas verändert hat und der Fehler erst neuerdings auftritt.

Wenn ich das richtig verstehe wird der Motor mit einem Seriellen Kommando gestartet - dreht dieser dann konstant bis zum Stop-Kommando oder nur einen bestimmten Winkel/Anzahl Schritte etc?
Wie genau erfolgt die Abfrage? Ich verstehe den Text so: Der Motor dreht ohne Regelung, alle 500ms fragt ein Rechner die Position ab. Diese Art der Abtastung ist natürlich auf einen recht hohen Gleichlauf der mechanischen Komponenten angewiesen -> evtl. Verschleiß?
Gegen den Verschleiß spricht wiederum die "Wiederholgenauigkeit" der fehlerhaften Position.

@Joop
der TE schreibt von 360° = 4172 Schritte - wäre das denn überhaupt ein möglicher Rückgabewert, wenn die FM351 nur auf 4096 parametriert ist?
Außerdem wären die 4096 doch bei diesem Geber nur ne halbe Drehung, oder habe ich da etwas falsch?

 

[JoopB]

Wenn die Geber gleich ist wie in PDF ist 4096 schritte ein halbe umdrehung. Aber die encoder gibt 8192 schritte x 4096 umdrehungen aus max ausgabe ist 2^26-1 = 25 bit. Und wenn er da vorbei komst fank er wieder an mit 0.
Die 351 habe Ich noch niet braucht . Aber die encoder Haben Wir verschiedene in einsatz Wir lesen diese mit ein et200s SSI module in sps. Wir Haben die nur auf liniare achse. Dass referieren machen Wir in das S7 programm.

Verstuurd vanaf mijn GT-I9301I met Tapatalk

 

[Morymmus]

Aber wenn ich den TE richtig verstehe "nullt" er den Geber jeder Umdrehung mit dem Schaltnocken des Drehtellers.
Ein Wert >8192 sollte somit eig. nicht vorkommen.


gesendet von meinem Moto G mit Tapatalk

 

[caveleira]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi, freue mich sehr auf Ihre Antworten, vielen Dank.
Für das Thema mit dem Resolution, will ich addieren, was von Siemens Support bekommen habe:

Bei der Projektierung der FM in Ihrem Projekt ist mir aufgefallen das nur 4096 Inkremente pro Umdrehung genutzt werden. Bei aktuellen 25Bit SSI Gebers die SIEMENS vertreibt, ist eigentlich immer 8192 Inkremente vorhanden. Dies resultiert in einer gröberen Auflösung würde jedoch keine Fehlerhaften Werte liefern.
Die Diagnse unter Datei > Eigenschaften > Grundparameter ist nicht aktiviert, d.h. wenn ein Geberfehler erkannt wird, dann würde die CPU dies nicht per OB82 gemeldet bekommen. Nach dem aktivieren dieser Einstellung wird der OB 82 aufgerufen und ein Eintrag im CPU Diagnosepuffer zu diesem Ereigniss wird erkennbar sein. Dies hilft meist bei der Diagnose spoardischer Themen.

Ich sagte dann:
Auf jeden Fall, Sie sagen nicht das etwas Falsch indie Parametrierung steht, oder? Die Resolution mit 4096 ist schon für unsereAnwendung genug, da nicht so viel genauigkeit wir brauchen, und möchte dasnicht ändern wenn man das nicht unbedingt braucht.

In jedem Fall ist es ungünstig keine Diagnose zuaktvieren, da Sie nun einen Fehler nicht direkt mitbekommen, das würde ich alsungünstig bezeichnen, da wir ansonsten ggf. schon weiter wären durch dieDiagnosemeldung. Die Auflösung mit 4096 ist nicht verkehrt wenn der GeberSSI Telegramme nach "umgedrehter Tannenbaum" liefert, was bei denSIEMENS Gebern der Fall ist.

Also, ich glaube die Resolution ist nicht das Problem, oder?

Die Frage wäre ja, ob dieser Fehler "schon immer" da war, oder ob sich etwas verändert hat und der Fehler erst neuerdings auftritt.

Da bin ich mir nicht ganz sicher, weil die Leute sagen früher war immer OK, nur in der letzten Monaten begann diese Fehler, und nichts geändert wurde von dem HW her. Aber wirklich die Position überprüfen mit den neuen Rechner es ist etwas neues.

Wenn ich das richtig verstehe wird der Motor mit einem Seriellen Kommando gestartet - dreht dieser dann konstant bis zum Stop-Kommando oder nur einen bestimmten Winkel/Anzahl Schritte etc?
Wie genau erfolgt die Abfrage? Ich verstehe den Text so: Der Motor dreht ohne Regelung, alle 500ms fragt ein Rechner die Position ab. Diese Art der Abtastung ist natürlich auf einen recht hohen Gleichlauf der mechanischen Komponenten angewiesen -> evtl. Verschleiß?
Gegen den Verschleiß spricht wiederum die "Wiederholgenauigkeit" der fehlerhaften Position.

Er dreht bis den Positive flanke des Induktives Nährungschalter (BI5U-M18-AP6X-H1141) kommt. Dann ist Drehende erkannt, und sendet ein 'F' zum Rechner, dann kriegt den SPS ein 'G' wenn eine neue Drehung beginnen muss. Also, stoppen und beginnen hat nicht zu tun mit dem Position, die Position ist einfach gefragt als Daten für Berechnungen durch den PC.
Verschleiß.. wir dachten den Absolutwertgeber. Aber er ist jetzt neu und der Fehler gleich. Der Nährungschalter hat auch kein mechanische Kontakt (induktives Funktion), die metallische Teil wurde geputzt, usw. Nur die Kabeln vielleicht könnte Mann noch austauschen. Aber das ist auch viel Aufwand. Und wirklich, der Fehler sieht so aus, als Software/Parameter Fehler. Ich verstehe nicht warum, aber ich denke ich werde die Resolution wechseln, zu probieren ob dann alles richtig ist. Aber das wird erst im Juli, also, ich muss mich mehrere Gedanken machen.

 

[Morymmus]

Mit dem Verschleiß meinte ich vor allem die mechanischen Komponenten wie z.B. die Drehlagerung.
Ich bin allerdings auch nicht der Meinung, das dies das Problem ist.

Wenn die Drehung nur von der Flanke des Näherungsschalters und nicht vom gemessenen Winkel abhängt und manchmal nur bis 353,5° gedreht wird scheint mir eher, das der Näherungsschalter "zu früh" getriggert wird.
Zweiter Ansatz: Läuft der Drehteller nach dem erreichen des Näherungsschalters aus oder wird er aktiv gebremst? Evtl. liegt das Problem auch hier.

 

[caveleira]

danke nochmal für die Antwort.

Ich kopiere hier noch eine Sache, ein Position Log Datei von dem Rechner, wo diese Fehler auftrifft:

[
02:22:01 G
02:22:01 G<13><10>
02:22:02 A
02:22:02 A000.0<13><10>
02:22:02 1 0.0
02:22:02 A
02:22:02 A000.2<13><10>
02:22:02 1 0.2"ab hier alles normal"
02:32:30 A330.3<13><10>
02:32:30 2 330.3
02:32:57 F<13><10>
"ab 330° den Rechner fragt nicht mehr die Position, und wartet einfach bis Drehende, deswegen es gibt kein Log aber den Drehteller dreht sich noch"
02:33:02 G
02:33:03 G<13><10>
02:33:03 A
02:33:03 A353.5<13><10>
02:33:03 3 353.5
"hier ist den Fehler entdeckt, d.h. er ist gestoppt an 353,5° Winkel von der letzte Drehung und dann den Programm es ist durcheinander und zählt nicht mehr, und kann die Position nicht richtig zurücksetzten. Weiß auch nicht warum :S"
02:33:04 A
02:33:04 A
02:33:04 A353.9<13><10>
02:33:04 3 353.9
02:33:05 A
02:33:05 A354.7<13><10>
02:33:05 3 354.7
02:33:06 A
02:33:06 A355.8<13><10>
02:33:06 3 355.8
02:33:07 A
02:33:07 A356.7<13><10>
02:33:07 3 356.7
02:33:08 A
02:33:08 A
02:33:08 A357.7<13><10>
02:33:08 3 357.7
02:33:09 A
02:33:09 A358.6<13><10>
02:33:09 3 358.6
02:33:09 A
02:33:09 A
02:33:09 A359.4<13><10>
02:33:09 3 359.4
02:33:10 A
02:33:10 A000.0<13><10>
02:33:10 3 0.0
02:33:10 A
02:33:11 A
02:33:11 A000.0<13><10>
02:33:11 3 0.0
"Programm läuft jetzt durcheinander weil den Geber nicht zurückgesetzt wurde, d.h. Positiongeber zählt weiter aber seit dem Programm gibt 0 wenn >360° (FC48) ist immer 0°."
02:37:35 A000.0<13><10>
02:37:35 3 0.0
02:37:35 A
02:37:35 A000.0<13><10>
02:37:35 3 0.0
02:37:36 A
02:37:36 A302.6<13><10>
02:37:36 3 302.6
"plötzlich kommt den richtigen wert, auf Grund das Position > 3500(FC48) und Overflow ist zurückgesetzt"
02:37:36 A
02:37:36 A303.5<13><10>
02:37:36 3 303.5
"ab hier alles wieder normal"

nächste Drehung läuft prima bis nächste Fehler auftritt.. auch nicht regelmäßig, habe ich kein Muster entdeckt, also kommt nicht jede 50Drehungen oder so was.. einfach nach 11 oder 33.. deswegen kann ich auch nicht den Fehler beobachten oder so.. weil ich kann dort nicht einfach warten und kann ich auch nicht sagen wann er wieder kommt und kann ich das nicht reproduzieren "

 

[Morymmus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich versuche mal eine Deutung:

02:22:01 G <= Anfrage Drehen
02:22:01 G<13><10> <= Antwort von der SPS

Habe ich das soweit richtig?

Was genau bedeuten die Zeilen, bei denen der Grad-Zahl eine Ziffer vorangestellt ist?

Soweit ich das verstehe wird die Anfrage "A" nur über eine Zeit getriggert - es wäre also möglich, das der Rückgabe-Wert 353,5° dem tatsächlichen Winkel in dem Moment entspricht - nur das das Programm damit nicht umgehen kann.

Du schreibst, das ab 330 keine weiteren Winkel-Abfragen erfolgen sollten - so wie ich das Log lese fragt aber der Rechner weiter und weiter die Position ab und wartet nicht auf das "F"...

Für mich sieht es aus, als ob sich der Drehteller langsam der Position annähert und bei 360° wieder auf null springt - es wäre also sehr spannend zu wissen, was genau die Hardware parallel zu diesem Log macht...

Ich gehe derzeit noch von der These aus, das der Fehler neu aufgetreten ist und Suche daher nach möglichen Veränderungen im System.


gesendet von meinem Moto G mit Tapatalk

 

[caveleira]

Ich versuche mal eine Deutung:

02:22:01 G <= Anfrage Drehen
02:22:01 G<13><10> <= Antwort von der SPS

Habe ich das soweit richtig?

Ganz richtig

Was genau bedeuten die Zeilen, bei denen der Grad-Zahl eine Ziffer vorangestellt ist??

Du meinst hier die 3.. das ist Drehung Nummer, eine Messung besteht normalerweise aus 10Drehungen. <13><10> sind ASCII für Carriagereturn und Linefeed. Und am Anfang steht immer die Zeit.
02:33:03 A353.5<13><10>
02:33:03 3 353.5

Soweit ich das verstehe wird die Anfrage "A" nur über eine Zeit getriggert - es wäre also möglich, das der Rückgabe-Wert 353,5° dem tatsächlichen Winkel in dem Moment entspricht - nur das das Programm damit nicht umgehen kann.

Ich muss sagen, zufällig war ich ein Mal wenn der Fehler kam, und konnte ich das sehen: Obwohl den Winkelwert(nicht nur auf dem Rechner sondern auch auf dem SPS, direkt Ausgangwert von FC48) 353,5° war, der Motor wurde gestoppt genau wie immer, oben dem Nährungschalter.

Du schreibst, das ab 330 keine weiteren Winkel-Abfragen erfolgen sollten - so wie ich das Log lese fragt aber der Rechner weiter und weiter die Position ab und wartet nicht auf das "F"....

doch, guck 02:32:57 F<13><10>, dannach kommt Drehung3, aber diese hat kein F weil ich nicht zu viel unnötige Text kopieren möchte, aber wenn ich sage..
02:37:36 3 303.5
"ab hier alles wieder normal"
d.h wartet auf das F und nächste Drehung beginnt mit 0, und richtig gemacht, und weiter bis 10 Drehungen, alles normal.

Für mich sieht es aus, als ob sich der Drehteller langsam der Position annähert und bei 360° wieder auf null springt - es wäre also sehr spannend zu wissen, was genau die Hardware parallel zu diesem Log macht...
Ich gehe derzeit noch von der These aus, das der Fehler neu aufgetreten ist und Suche daher nach möglichen Veränderungen im System.

Der SPS parallel? das Normal.. andere Funktionen aber nicht überlastet. Der Rechner was macht ist egal, das Problem kommt von SPS oder Sensor.
Die These ist nicht falsch, aber nicht ganz richtig. Meine Vermutung ist das diese Fehler immer dort war, aber nur versteckt (weil früher der Rechne hat nicht das gante überprüft). Aber hier die Leute sagen mir das ist neu, und früher hat immer prima funktioniert, also, hier habe ich ein Konflikt, und kann nicht ganz sicher sagen entweder oder..​

 

[caveleira]

Und etwas noch.. Ja. Die Winkelabfrage ist jede 500ms getriggert.

 

[Morymmus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mit dem "Hardware parallel" meinte ich, ob der Sensor / die SPS-Baugruppe falsche Werte liefert, oder ob die Dreh-Hardware sich tatsächlich tatsächlich so verhält wie es im Log aussieht.
Ich war allerdings davon ausgegangen, das das Log ungekürzt sei, sorry.

Du sagst bei 353° Messwert steht der Rundteller auf dem Näherungssensor (also 360°) - nun hängt es ja massiv vom Umfang des Tellers ab, was die 7° an Strecke bedeuten.

Eine Möglichkeit wäre z.B. auch, das der Näherungssensor so knapp an der Erfassungsgrenze montiert ist, das minimale Schwankungen um die Achse des Drehtellers den Erfassungszeitpunkt bereits verschieben. Besonders stark ist dieser Effekt bei Nicht-Eisen-Metallen wie z.B. Aluplatten.

Wie gesagt, ist ein bisschen Glaskugelschau, aber wäre immerhin eine Möglichkeit.

gesendet von meinem Moto G mit Tapatalk

 

[caveleira]

OK. Aber noch mal daran denken, dass diese Fehler mehrere Mals auftritt, und die Logdatei genauso immer aussieht, wie ich hier kopiert habe. Also, wenn so eine komische Wirkung wäre, ich glaube es wären auch verschieden Werte, und nicht immmer 353,5° (4096 Geberposition). Das Problem ist, warum manchmal den Wert kann nicht mehr als 4096, obwohl den Absolutwertgeber multiturn ist. Und trotzdem, warum er später den Referenzpunkt auf null nicht setzen kann. Ich gucke und gucke die FC48 aber verstehe nicht was schiff gehen könnte. Er sollte eigentlich immer mit dem Positiveflanke von Motor den Referenzpunkt auf 0 setzen, und auch die RND_Over_akt zurücksetzen

 

[Morymmus]

OK, die Wiederholgenauigkeit des Fehlers hatte ich nicht bedacht, da hast Du Recht.

Was den Wert des Sensors angeht, da muss ich wenn ich wieder in der Firma bin nochmal in die Doku schauen.
Wenn ich das aus dem Kopf zusammenkrame hattest Du doch 1 Umdrehung = 4096 Schritte parametriert, obwohl der Geber das doppelte könnte.
Auch wenn der Geber Multiturn ist sollte doch damit der Winkel-Wert die 4096 nicht überschreiten können, oder?

Beispiel:
Der Geber meldet 4000, dreht dann um 100 Schritte weiter, dann müsste die SPS doch eigentlich 1 Umdrehung + 4 Schritte sehen und nicht 4100.

Könntest Du versuchsweise die Auflösung der SPS-Baugruppe auf den realen Wert des Sensors hoch setzen?
Auch wenn Siemens sagt, das es so gehen müsste, wäre es interessant, ob es sich dann genauso verhält.

gesendet von meinem Moto G mit Tapatalk

 

[caveleira]

Zuviel Werbung?
-> Hier kostenlos registrieren

Auch wenn der Geber Multiturn ist sollte doch damit der Winkel-Wert die 4096 nicht überschreiten können, oder?

ich habe Heute die FC48 beobachtet für eine Stunde, leider der Fehler nicht aufgetreten aber du hast wieder Recht, der Wert (geteilt bei 1000) von dem Sensor geht bis 4096(353,5°) und dann die FC48 macht die Addierung +4096 bis zum Ende(da die Variabel DBxxx.RND_over_akt wenn >4000 gesetzt wurde), somit hat man die Zahlt bis 4172(360°). Danach, nur wenn den Motor ist wieder gestartet ist, bei Positive flanke
A) DBxxx.RND_over_akt zurückgesetzt
B)wieder den Wert von Sensor zurückgesetzt bei laden 0 auf Db1.REFPT.

Jetzt, von der Logdatei...
A) Nach dem Fehler ist alles wieder richtig nach dem Winkel 302°=3500. D.h DBxxx.RND_over_akt war früher 1. D.h. die Reihe von Nullen sind aufgrund von addieren 4096
B) Wenn die Drehung beginnt, Sensor läuft, falsch aber läuft, von 353° bis 360°. D.h er fängt an mit Wert 0, und DBxxx.RND_over_akt=1, und nach 360°=4172, ist immer >360° (aber Position <3500 also immer addiert 4096)

Dann die Frage ist, warum wurde DBxxx.RND_over_akt nicht zurück gesetzt bei der Positive Flanke von Motor?
Und warum kam der Wert nicht weiter als 353°=4096? Er stoppt einfach auf 4096 und kann nicht mehr? Oder er geht zum 0 und bleibt so , aber addieren funktioniert und addiert 4096 zu 0, und danach beginnt die neue Drehung, irgendwie referenzpunkt ist gesetzt aber die DBxxx.RND_over_akt nicht ? Jetzt beginne ich zu denken das vielleicht den Kabel doch ist das Problem... ich muss den überprüfen.

 

[caveleira]

Könntest Du versuchsweise die Auflösung der SPS-Baugruppe auf den realen Wert des Sensors hoch setzen?
Auch wenn Siemens sagt, das es so gehen müsste, wäre es interessant, ob es sich dann genauso verhält.

Ich werde das machen auf 8172, und wenn bring nichts, andere Änderungen.. aber wir haben Audit und wollen keine Änderungen in der Anlage bis dann, also erst im Juli

 

[Morymmus]

Ich muss gestehen so ein bisschen gehen mir da auch die Ideen aus.

Nach nochmaligem Nachdenken würde ich folgendes erwarten:

1. Drehung beginnt
2. Drehung erreicht 180° (4096 Schritte)
3. Ab hier wertet die SPS die zweite Halb-Drehung als Multiturn aus

Deinen Mechanismus mit einer Addition habe ich noch nicht verstanden - meiner Meinung nach müsstest Du {gemessene Schritte}/2 rechnen um auf den realen Wert zu kommen (oder halt die Parametrierung abgleichen)

Du könntest ggfs mal mit einem Oszilloskop der Geberleitung "auf die Finger schauen" Evtl sind die Geberdaten aufgrund eines Kabelbruchs zeitweise unplausibel.
Vielleicht kannst Du auch zum Probieren ein provisorisches Kabel an allem vorbei legen bevor Du Zeit in den Austausch investierst und am Ende war es das gar nicht.


Aber natürlich keine Änderungen vor oder während des Audits, wir wollen schließlich alle unseren Job behalten ;-)

gesendet von meinem Moto G mit Tapatalk

 

[caveleira]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich muss gestehen so ein bisschen gehen mir da auch die Ideen aus.

Nach nochmaligem Nachdenken würde ich folgendes erwarten:

1. Drehung beginnt
2. Drehung erreicht 180° (4096 Schritte)
3. Ab hier wertet die SPS die zweite Halb-Drehung als Multiturn aus

Deinen Mechanismus mit einer Addition habe ich noch nicht verstanden - meiner Meinung nach müsstest Du {gemessene Schritte}/2 rechnen um auf den realen Wert zu kommen (oder halt die Parametrierung abgleichen)

Du könntest ggfs mal mit einem Oszilloskop der Geberleitung "auf die Finger schauen" Evtl sind die Geberdaten aufgrund eines Kabelbruchs zeitweise unplausibel.
Vielleicht kannst Du auch zum Probieren ein provisorisches Kabel an allem vorbei legen bevor Du Zeit in den Austausch investierst und am Ende war es das gar nicht.


Aber natürlich keine Änderungen vor oder während des Audits, wir wollen schließlich alle unseren Job behalten :wink:

Aber die tatsächliche Drehung (Die Messung, nicht die Geber Drehung) sind nicht 4096 Schritte, sondern 4172, deswegen die Addierung.

Jetzt ist so: Drehung erreicht 353,5° (4096 Schritte), dann Over_akt ist gesetz, und die Schritten anfangen wieder bei 0 aber der Programm addiert 4096, bis 360° erreicht (4172).
Bei nächste Drehung Reftpunkt ist wieder auf 0 gesetz und Over_akt deaktiviert.

Wenn ich hätte 8192 Resolution, wäre erreicht 353,5° (8192 Schritte), und dann bis 360° muss ich etwas addieren. Ansonsten weiß ich nicht wie kann ich den Absolutgeber synchroneren mit dem Motor.
Andere Sache ist als Multiturn, den Geber fragen welche Drehung ist (aber nicht sicher wie)

 

[Morymmus]

Aber die tatsächliche Drehung (Die Messung, nicht die Geber Drehung) sind nicht 4096 Schritte, sondern 4172, deswegen die Addierung.

OK, ich verstehe die Worte die Du schreibst, aber den technischen Hintergrund verstehe ich gerade noch nicht.
Du hast einen Geber, der 8192 Schritte/Umdrehung auflöst - das entspricht einem Winkel von 0,04394°.
Du wertest diesen nur mit 4096 Schritten/U aus, also immer noch mit 0,08789°/Schritt.

Rein für die physikalische Betrachtung glauben wir jetzt mal an das Gute im Hersteller des Inkrementalgebers, d.h wir zweifeln jetzt mal nicht an der gebereignenen Wiederholgenauigkeit.
Dann erwarte ich, das der Drehteller bei der Schritt-Position 4096 volle 360° gedreht hat. Alternativ 180°, wenn man mit der doppelten Schrittzahl auflöst.
Von daher sollte eigentlich keine Addition eines Offset nötig sein, um die 360° zu erreichen.

Deine Abweichung von 6,6797° sind 1,85% bezogen auf den Vollkreis, nur warum kann ich nicht erklären

*Blitzidee*
könnte es sein, das der Nullpunkt zurückgesetzt wird, solange der Sensor aktiv ist und nicht z.B. mit der steigenden Flanke? Dadurch würdest Du den Zählvorgang um die Breite der Schaltfahne später starten als die Drehung und müsstest dies durch einen Offset kompensieren.

 

[caveleira]

Na ja, technische Hintergrund wären die Mechanische Anpassungen von Motor bis zum Drehteller. Welche genau weiß ich nicht, aber ein Geberdrehung sind 353,5° auf dem Drehteller, und nicht 360°. Dafür welche Resolution du nimmst, meine Meinung nach, ist Egal.

Die blitzidee: doch die Nullpunkt ist nur Gesetz bei Flanken. Die einzige Problem könnte sein, manchmal eine ist aktiviert ein Zyklus später oder so.
Heute könnte ich sehen das die Falsche Drehung nach dem Fehler war mit Over_akt aktiviert, aber ich habe verpass welche werte waren ganz am Ende. Montag komme ich wieder