TwinCAT 3 Sensor-Signale zusammenfassen

Die Drehzahl wird relativ gering sein. Momentan sind maximal 30 U/min geplant
Das überrascht mich nicht wirklich, denn das "unwuchtige" Aussehen des Teils war ja ein Teil des Problems (das Fehlen der Plätze für die Magnete im ausgesparten Sektor).
Wie sieht es denn aus, wenn der Rotor zwischen zwei Positionen steht? Ist dann gewährleistet, dass kein Sensor meldet?
Wenn ja, dann sollte man die Anzahl der meldenden Sensoren zählen und nur dann die Sensoren für die Positionsbestimmung auswerten, wenn das jeweilige Maximum erreicht ist.
D.h. konkret, man würde - sobald die Anzahl Bits erstmalig abnimmt - den vorherigen Zustand auswerten.
Zugegeben, das klingt nach einer "viel-zu-spät-Erkennung" der Positionen - ich würde dies aber als KontrollInstanz zusätzlich zur eigentlichen - wie auch immer realisierten - PositionsErkennung vorsehen. Zumindest in der TestPhase.

Gruss, Henileini
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Eine Lücke zwischen den Positionen, in der alle Sensoren 0 melden, wäre natürlich schön. Dann bräuchte man die Anzahl der meldenden Sensoren auch gar nicht extra zählen, sondern könnte mit dem durch die Sensoren gebildeten Zahlenwert arbeiten. Mit 0 die nächste Auswertung starten, solange er größer wird, speichern, und wenn er wieder kleiner (oder wieder = 0) wird, den gespeicherten Max.-Wert übernehmen. Wenn es keine Lücke gibt, z. B. weil die Sensorfläche zu gross ist, wird es wohl nicht anders gehen, als die Excel-Tabelle in die SPS zu übertragen und den Istwert mit dem laut Tabelle erwarteten Wert zu vergleichen.
Laut der Skizze sind die Lücken zwischen den Magneten ungefähr so gross wie die Magnete selbst (ohne Brille bewertet). Wenn die Sensoren das in etwa abbilden können, hätte man bei 30 Umdr./min je knapp 7ms Signal und Lücke. Sicher nicht unmöglich, aber man kann auch nicht einfach jede Hardware einsetzen, die gerade im Regal liegt.
 
@Structured...
(Trash verkneife ich mir mal wieder, passt nicht zu Dir) Du hast natürlich Recht - wirklich zählen muss man die Bits nicht. Ein 1-Bit mehr - egal an welcher Position (Hauptsache höchstwertiges bleibt auf 0) - erhöht den Wert.
Und 7ms sind durchaus recht "sportlich", insbesondere, wenn man hofft, damit auch die ersehnten Nullen zwischen den Positionen zu erwischen und ausserdem noch an reichlich Reserve zum "Entprellen" denkt.
Eine DatenTabelle wird man zur Dekodierung in jedem Fall benötigen. Ich würde sie (in Excel) nach Werten sortieren, um in der PLC zeitsparend binär suchen zu können.

Gruss, Heinileini
 
Zuletzt bearbeitet:
Eine DatenTabelle wird man zur Dekodierung in jedem Fall benötigen.

Da hast Du Recht, ohne Tabelle wird es nicht gehen. Bei 12 Sensoren = 12 Bit könnte man ein ARRAY[0..4095] OF INT nehmen und mit dem durch die Sensoren gebildeten Zahlenwert als Index darauf zugreifen. In die Arrayfelder, deren Index eine gültige Rotorposition beschreibt, trägt man die Rotorposition 0..143 ein, in die übrigen einen ungültigen Wert, z. B. -1. Dann braucht man nicht suchen, und die 8 kB für das Array tun dem Beckhoff PC nicht weh.
Die 7ms für Signal bzw. Lücke machen mir mehr Sorgen. Jetzt kommt es erstmal auf die Hallsensoren an. Wie groß ist ihre Schaltfläche, können sie die Lücke zwischen den Magneten sicher erkennen? Und wie sauber sind die Signalflanken?
Eine Beckhoff Standard-DI-Klemme hat einen Eingangssignalfilter von 3ms. Das wäre mir schon zu lang. Ich würde lieber eine EL101x mit 10µs nehmen und den Filter in die Software legen. Dann aber nicht mit einem Standard-Timer-FB, der nur eine Auflösung von 1ms hat, sondern mit einer Zykluszählerlösung, und die Zykluszeit für die Positionserfassungstask deutlich unterhalb 1ms wählen (250,125 oder gar nur 100µs). Ich gehe mal davon aus, dass das Programm noch anderes zu tun hat als nur die Rotorposition zu erfassen. Dafür bräuchte man dann eine zweite, langsamere Task. Da würde ich schon mindestens einen Dual Core-PC, vielleicht den CX5130 oder ein vergleichbares Modell in anderer Bauform ins Auge fassen. Wobei mein Liebling allerdings der Quad Core-CX5140 ist. Das kleine Kerlchen ist eine Wucht, und für den Mehrpreis gegenüber dem CX5130 braucht man nur auf eine Grillparty verzichten.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Okay, das mit der Tabelle in Form eines Arrays, leuchtet mir ein. Allerdings müsste ich es auf [0..32767] vergrößern, um mit den Positionen aus dem Excel-Sheet hinzukommen.

Ich würde es dann über eine niedrige Zykluszeit filtern, indem ich schaue welche Werte über mehrere Zyklen vorkommen und diese dann weiter verwenden.

Die Sensoren Schaltfläche der Sensoren ist 2,03mm breit. Wie sauber das Signal rauskommt kann ich leider immer noch nicht sagen. Hier ist das Datenblatt zu den Sensoren.

https://www.buerklin.com/medias/sys...al-data-sheet-cherry-mp101402-de-20160311.pdf

Als Hardware haben wir den von dir genannten CX5130 und als DI-Klemme die EL1018, somit sollte das eigentlich auch passen. Nächste Woche ist dann auch alles soweit angeschlossen, dass man es mal testen kann.
 
Allerdings müsste ich es auf [0..32767] vergrößern, um mit den Positionen aus dem Excel-Sheet hinzukommen.
Nicht wirklich … umgekehrt geht auch … ExcelSheeet an die Anzahl Sensoren anpassen: 2^12 = 4096.
Also die belegten Bits zusammenschieben, d.h. die BitPositionen der nicht vorhandenen Sensoren für die belegten nutzen, damit die 4 höchstwertigen Bits zusammenhängend unbenutzt sind.

Schönes WE!

Gruss, Heinileini

Noch kürzer, wie bereits angesprochen (sortiert nach Werten):
Anhang anzeigen 144x2,5°_SortedByValue.pdf

Code:
// Vorgegebenen Wert (<>0) in aufsteigend sortiertem Array mit 144 Elementen suchen.
// (in Excel VBA getestet und hier die Excel-spezifischen Dinge eliminiert und ...
// ... bei WertZuweisungen '=' in ':=' geändert) 
xVal& := ... // zu suchenden Wert einlesen
xAnf& := 1   // Untergrenze: IndexNr des 1. Eintrags
xEnd& := 145 // Obergrenze : IndexNr des letzten Eintrags + 1
xCnt& := 0   // SchleifenZähler (EndeKriterium bei "nicht gefunden"!)
xAbb& := -1  // Abbruch bei "nicht gefunden" (nach Wert 0 wird gar nicht erst gesucht!)
xIdx& := 0   // SuchIndex
xTmp& := 0   // eingelesene "StichProbe" von Element laut SuchIndex
Do While xTmp& <> xVal&
    xIdx& := Int((xAnf& + xEnd&) / 2) // Index "Mitte" zwischen Unter- und Obergrenze
    xTmp& := Array(xIdx&) // Wert "StichProbe" laut Index einlesen
    xCnt& := xCnt& + 1 // SchleifenZähler inkrementieren
    xAbb& := xCnt& > 8
    If xAbb& Then 
        Exit Do // SchleifenAbbruch weil gesuchter Wert im Array nicht vorhanden
        End If
    If xVal& > xTmp& Then // wenn gesuchter Wert > StichProbe, dann ...
        xAnf& := xIdx& // neue Untergrenze auf Index von StichProbe setzen
    Else // ... sonst ...
        xEnd& := xIdx& // neue Obergrenze auf Index von StichProbe setzen
        End If
    Loop
// xAbb& = 0  : xIdx& zeigt auf den ListenPlatz, auf dem der Wert gefunden wurde
// xAbb& <> 0 : gesuchter Wert ist in der Liste NICHT vorhanden
Beispiele für binäres Suchen in der Liste von 144 aufsteigend sortierten Elementen:
Anhang anzeigen BinarySearch_144.pdf
 
Zuletzt bearbeitet:
Hallo Yannik!

Bin kürzlich beim Surfen in Sachen GrayCode über etwas gestolpert, das mich irgendwie an diesen Thread erinnert:

Animated_Graycode.gif

Wie gefällt Dir das? Wahrscheinlich kennst Du es schon und es hat Dich zu Deiner Aufgabenstellung inspiriert?
Hier geht es um 30 x 12° ==> 5 Bit GrayCode.

Schönes RestWochenEnde!

Gruss, Heinileini
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

es ist nun alles angeschlossen und ich konnte erste Versuche machen.

Die Sensoren erkennen Leerstellen zwischen zwei nebeneinanderliegenden Magneten, also funktioniert die Positionserkennung an sich, wie es geplant war.
Wie erwartet bekomme ich aber beim Wechsel von einer Position zur nächsten noch andere Positionen zwischenrein, da nicht alle Bits gleichzeitig "umklappen".
Ich habe es dann so gemacht, dass ich die Position nur hoch- bzw runterzähle, wenn sich diese um +-1 ändert. Da ich jede Position von 1-144 zuverlässig erkenne, funktioniert es so dann ziemlich gut als "Filter", ohne dass ich über die Zykluszeit oder ähnliches gehen muss.

Mehrere Tasks sind momentan nicht nötig, da die Auslastung des CX ohnehin nur im einstelligen Prozentbereich ist.

Die 5 Bit Gray Code Variante kenne ich, es gibt sogar auch noch eine mit 7 Bit. Allerdings konnte ich es, als ich mich damit beschäftigt habe, nicht auf meinen Fall anwenden, da ich konstruktionsbedingt schon extrem eingeschränkt war.

Die weitere Verwendung der Position um die Ventile anzusteuern, war dann kein großes Problem mehr.

Momentan tun die Nanotec Schrittmotoren noch nichts, aber das ist eine andere Baustelle, die nicht ganz hier her passt.

Vielen Dank für eure Hilfe, ohne eure Tipps wäre ich noch Ewigkeiten beschäftigt.

Viele Grüße
Yannik
 
Zurück
Oben