Auswerten der Fischertechnik Encoder mit einem 750-403 Input Module auf einer PFC200?

[chrisdutz]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich bin noch extrem neu bei CodeSys und generell PLC Entwicklung allgemein, daher habt bitte Geduld mit mir

Um mein Fischertechnik Hochregal-Lager mit einer WAGO PFC200 zu steuern habe ich ein IO Modul besorgt, dass schnell genug sein sollte um die pulse des Fischertechnik Encoders verarbeiten zu können. Dieser Encoder schickt mir zwei digitale Signale, sowie ich eine positive flanke des einen erkenne, gibt die aktuelle position des 2. signals die Richtung an. Da ich davor die Sortierstrecke mit einer S7 im Tia automatisiert hatte, hatte ich hier einen schnellen counter genommen und im Roboter-Arm mit einer Fatek im WinProLadder hatte ich einen eingebauten counter, der direkt schon mit dem Encoder arbeiten konnte.

Nun stellt sich mir die Frage: Wie mache ich das auf meiner Wago PFC200 mit 750-403 Input Module in CodeSys (Structured Text). Ich tue mich hier ein klein wenig schwer.

Ich hoffe sehr, dass es in CodeSys geht und ich mir nicht nur über ein 750-631 Modul geht.

Wäre hier über ein paar Hinweise sehr dankbar.

Chris

 

[chrisdutz]

Je mehr ich über diese Quadratur-Encoder nachlese, desto mehr befürchte ich, dass ich wohl um erneute 500-600€ für zwei Wago IO module nicht umher komme. Wäre super dankbar, wenn hier jemand noch eine Idee hätte, wie ich das mit den Bordmitteln hinbekomme.

Ich hatte jetzt versucht das in CodeSys mit Flankenerkennungen nachzubauen, allerdings sah das Ergebnis ähnlich zappelig aus als wenn ich das auf einer LOGO ohne schnelle zähler hab' laufen lassen (Generell gehen Die werte in die richtige Richtung, zappeln aber immer ein wenig hin und her)

Was ich jetzt mal versucht hatte, war sowas hier:

horizontalPulseRisingFlank(CLK := horizontalEncoderA, Q => horizontalPulseRisingFlankDetected);    <- R_TRIG
horizontalPulseFallingFlank(CLK := horizontalEncoderA, Q => horizontalPulseFallingFlankDetected);   <- F_TRIG
IF horizontalPulseRisingFlankDetected THEN
	IF NOT horizontalEncoderB THEN
		horizontalIncrement := TRUE;
		horizontalDecrement := FALSE;
	ELSE
		horizontalIncrement := FALSE;
		horizontalDecrement := TRUE;							
	END_IF
ELSIF horizontalPulseFallingFlankDetected THEN
	horizontalIncrement := FALSE;
	horizontalDecrement := FALSE;
END_IF
horizontalCounter(CU := horizontalIncrement, CD := horizontalDecrement, RESET := horizontalRefSwitch, CV => horizontalPosition);        <- CTUD

Wie gesagt, passt das im groben und ganzen, ist aber nicht genau und kommt mir so vor als wenn das nicht flott genug wäre. Ist halt sehr zappelig.

 

[Rayk]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
da deine Informationen bezüglich Frequenz der Impulse mager sind, fallen mir nur zwei Möglichkeiten ein:
-Taskzeit reduzieren, damit möglichst viele Impulse erkannt werden
-ereignisgesteuerte Task, damit jeder Impuls gezählt wird, sofern die Freqenz nicht zu hoch ist

mfg
Rayk

 

[PN/DP]

Wie gesagt, passt das im groben und ganzen, ist aber nicht genau und kommt mir so vor als wenn das nicht flott genug wäre. Ist halt sehr zappelig.

Ob flott genug kannst Du leicht ausrechnen: Wie schnell ist Deine Programm-Zykluszeit? Werden auch die Eingänge so schnell eingelesen oder kannst Du so schnell auf die Eingangszustände zugreifen? Wie viele Striche bzw. Flanken hat der Encoder pro Umdrehung? Wie schnell max dürfte er sich drehen, damit die Zeit zwischen 2 Flanken länger als die Zykluszeit ist? Oder umgekehrt wie schnell müsste die Zykluszeit sein, damit sie kürzer als die Zeit zwischen 2 Flanken ist?

Hier findest Du verschiedene Software-Auswertungs-Varianten. z.B. in Codesys ST
Programmierwettbewerb, 2. Aufgabe

Harald

 

[georg28]

Oder vielleicht einen frequenzteiler damit alles langsamer wird wie z. B. https://www.atrie.de/produkt/frequenzteiler-dt11

 

[holgermaik]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Chris
zu Harald seinen Fragen noch 2 weiter:
welchen Controller hast du?
mit was programmierst du?

Holger

 

[chrisdutz]

Hallo Rayk,

Ok .. danke schon mal für die Pointer. Da werde ich mal recherchieren, wie ich das hinbekomme.

Als Zusatz info, habe ich hier mal die spec für die Encoder gefunden:
https://content.ugfischer.com/cbfiles/fischer/Zulassungen/ft/144643-Encodermotor24V.pdf
https://content.ugfischer.com/cbfil...ft/554868_Lernfabrik4.0_24V_Belegungsplan.pdf (Seite 98)

Hier steht, dass der Encoder pro Umdrehung 61,2 Impulse raus gibt und der Motor eine Maximale Drehzahl von 200 U/Min hat ... daraus würde sich dann also ergeben 11240 Impulse/Minute = 204 Impulse/Sekunde also kommt alle 4,9ms ein Impuls ... Beim wälzen der Specs meiner Eingangsmodule, habe ich allerdings festgestellt, dass mein 4 Kanal Eingangsmodul nur 10ms Auflösung zu haben scheint (https://www.wago.com/us/controllers-bus-couplers-i-o/4-channel-digital-input/p/753-440) Allerdings habe ich wohl für das 8 Kanal Eingangsmodul ein besonders flottes erwischt. Das scheint eine Auflösung von 0,2ms zu haben (https://www.wago.com/de/io-systeme/8-kanal-digitaleingang/p/750-437), was mehr als ausreichend sein wird. Ich werde also die einfachen Anschlag-Taster und die Encoder vertauschen. Ich denke ein Referenzschalter kann ruhig die 10ms vertragen.

Vielleicht geht ja dann auch schon mein kleines Programm. Werde berichten.

Viele Grüße,
Chris

 

[PN/DP]

Na, der Encoder hat ja eine erfreulich niedrige Auflösung, doch ganz so unkritisch ist es auch nicht. 200 Impulse/Sekunde bedeutet eine Periodendauer von 5ms - also 2,5ms ist das Signal 1 und 2,5ms ist das Signal 0, und 90° versetzt dazu ist die B-Spur. Du müsstest beide Signale (A + B) alle 1 ms abfragen, um sicher jeden Signalwechsel zu erfassen. (Oder versuchen bei den schnellen Drehzahlen mit Doppelschrittzählung zu arbeiten.) Du müsstest den Programmteil mit der Encoderauswertung in eine 1ms Task legen. Dann wäre es möglich den Encoder per Software auszuwerten. Ich kenne die Wago nicht - ist es da möglich die Eingänge der einen Eingangskarte alle 1ms einzulesen?

Harald

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Oder vielleicht einen frequenzteiler damit alles langsamer wird wie z. B. ...

Das Geld dafür würde ich nicht in FrequenzTeiler investieren, zumal wir zwei "zu verlangsamende" Signale haben (A und B) UND die Phasenlage dieser beiden wichtig ist.
Durch je einen Frequenzteiler für A und B, die unabhängig voneinander vor sich hin teilen, gehen wichtige Informationen verloren.

Hier steht, dass der Encoder pro Umdrehung 61,2 Impulse raus gibt und der Motor eine Maximale Drehzahl von 200 U/Min hat ... daraus würde sich dann also ergeben 11240 Impulse/Minute = 204 Impulse/Sekunde also kommt alle 4,9ms ein Impuls ...

Also sollte die ZyklusZeit < 2ms betragen, wenn 1 oder 2 Flanken pro A-B-Signal-Periode oder < 1 ms, wenn 4 Flanken pro A-B-Signal-Periode ausgewertet werden sollen.

 

[PN/DP]

Oder vielleicht einen frequenzteiler damit alles langsamer wird wie z. B. https://www.atrie.de/produkt/frequenzteiler-dt11

Das wird so nicht funktionieren.

Also sollte die ZyklusZeit < 2ms betragen, wenn 1 oder 2 Flanken pro A-B-Signal-Periode oder < 1 ms, wenn 4 Flanken pro A-B-Signal-Periode ausgewertet werden sollen.

Um mit 2ms Zykluszeit hinzukommen: Bei 2 Flanken Auswertung nimmt man beide Flanken vom Signal A, und den Zustand von Signal B bei den A-Flanken?

Harald

 

[Heinileini]

Um mit 2ms Zykluszeit hinzukommen: Bei 2 Flanken Auswertung nimmt man beide Flanken vom Signal A, und den Zustand von Signal B bei den A-Flanken?

Ganz genau, Harald.
Oder steigende und fallende Flanken nur von B und dabei den Zustand von A auswerten.

Aber nicht vorrangig, um mit einer grösseren ZyklusZeit auszukommen, das ist nur der angenehme NebenEffekt.
Der eigentliche Grund ist, den logischen Fehler zu vermeiden, der bei der Auswertung von A-B-Signalen so gerne gemacht wird und der einen dann dazu treibt, aussichtslos mit Tiefpässen und SchmittTriggern zwecks "Entstörung" zu kämpfen.
In beiden Richtungen müssen immer dieselben Flanken ausgewertet werden, aber was in der einen Richtung eine positive Flanke ist, ist (oh Wunder ) in umgekehrter Richtung eine negative Flanke!!!
Wer sich überlegt, z.B. nur die positiven (oder nur die negativen) Flanken von A (und/oder) B auszuwerten, der läuft prompt in diese Falle.
Bei der Auswertung von 4 Flanken pro A-B-Signal-Periode muss man nichts beachten, aber wenn man nur 1 oder 2 [oder 3] Flanken auswerten will: Vorsicht Falle!
Ein weiterer Grund, bei Auswertung von 2 Flanken pro Periode, sich auf die Flanken nur eines der beiden Signale A bzw. B zu beschränken, ist der gleichmässige zeitliche Abstand der ausgewerteten Flanken von 1/2 Periode (im Gegensatz zu abwechselnd 1/4 und 3/4 Periode, was eine kürzere ZyklusZeit erforden würde).

Gruss, Heinileini

 

[chrisdutz]

Zuviel Werbung?
-> Hier kostenlos registrieren

Vielen dank für euren input ... ich lerne dadurch sehr viel ... danke nochmal

Ich glaube momentan würde es mir ja genügen, wenn es einfach nur an der einen Flanke checkt was gerade das zweite Signal ist ... ich weiß, dass ich mit so einer 4-Zustände Logik auch erkennen würde, dass mitten zwischen zwei pulsen die Richtung geändert wurde darauf kann ich allerdings in diesem Fall gerne verzichten, wenn es mir im Gegenzug erspart 500-600€ für zwei Encoder-Eingänge ausgeben zu müssen. Es handelt sich hier um ein Fischertechnik Hochregal-Lager ... zur not synchronisiere ich immer wieder mal um sicher zu sein, indem ich wieder in die Nullstellung fahre. Hier handelt es sich ja nicht um eine micrometer genaue CNC Fräse ... es soll vielmehr eine Demo Platform für unser open-source Projekt Apache PLC4X sein ... da muss sich nur irgendwas bewegen und alles einigermaßen klappen ;-)

Ich habe die Anlage umgeklemmt, sodass die encoder Signale nun an dem WAGO 750-430 angeschlossen (Welcher ja eine Auflösung von 0,2ms haben sollte). Wie genau kann ich im CodeSys die Zykluszeit einsehen und ändern?

 

[PN/DP]

Wenn Du von einem Signal die steigende und die fallende Flanke auswertest, dann kann es eigentlich gar nicht zu einer falschen Position kommen, auch wenn sich die Drehrichtung ändert (solange schnell genug abgetastet wird). Es gibt eigentlich keinen Grund und keinen Vorteil, nur eine Flanke auszuwerten.

Harald

 

[chrisdutz]

Ich dachte hier eher daran, dass wenn die abtast-rate ein problem wäre, dass ich auch mit weniger auskommen würde ... allerdings habe ich immer noch nicht rausgefunden, wie ich die Zykluszeit im CodeSys runter setze :-/

 

[chrisdutz]

Zuviel Werbung?
-> Hier kostenlos registrieren

Habe es gefunden ... Muss mich noch ein wenig an die Konventionen gewöhnen, die hier verwendet werden (Das mit dem "Download" habe ich mich schon dran gewöhnt) ... man muss also den Task auswählen: Device/SPS-Logik/Applikation/Taskkonfiguration/MainTask (Hier allerdings nicht über das Kontext-Menü in die Einstellungen, sondern mit einem Doppelklick öffnen. Hier kann ich jetzt die Zyklus-Zeit einstellen (Sie war per default auf 20 ms eingestellt, was meine Probleme erklären könnte

 

[sps_21]

Beim wälzen der Specs meiner Eingangsmodule, habe ich allerdings festgestellt, dass mein 4 Kanal Eingangsmodul nur 10ms Auflösung zu haben scheint (https://www.wago.com/us/controllers-bus-couplers-i-o/4-channel-digital-input/p/753-440) Allerdings habe ich wohl für das 8 Kanal Eingangsmodul ein besonders flottes erwischt. Das scheint eine Auflösung von 0,2ms zu haben (https://www.wago.com/de/io-systeme/8-kanal-digitaleingang/p/750-437), was mehr als ausreichend sein wird. Ich werde also die einfachen Anschlag-Taster und die Encoder vertauschen. Ich denke ein Referenzschalter kann ruhig die 10ms vertragen.

l
Das eine ist ein 230 V AC, dass andere ein 24 VDC-Modul - das fällt mir vor allem auf

Ganz allgemein halte ich die Auswertung von Encodern ohne schnelle Zähler od. dedizierte Karten für eine bescheidene Idee, da es das System direkt an die Schmerzgrenzen bringt...
Der K-Bus des PFC wird standardmäßig alle 10 ms aktualisiert, also umparametrieren ist da notwendig. Und Synchronisierung vmtl.