Posts by haemse

Also: Habe nun die Kabel für die Hall Sensoren zum GPIO zum debuggen komplett gewechselt. Zuvor waren es Litzen eines 5m langen, eingebauten Netzwerkkabel. Nun hab ich 1m lange Kupferdrähte genommen.

Genau das selbe Spiel.

Neue Erkenntnis ist aber, dass es von der Lage des anderen Motors, bzw. dessen Magnetrades welches die Hall Sensoren triggert - abzuhängen scheint, ob dieser auch mitzählt, obwohl er still steht. Manchmal zählt der inaktive Motor mit, manchmal nicht ... und das in beiden Fällen.

Würdet ihr sagen, dass die Verkabelung laut Schema eigentlich passt? Oder sind hier Interferenzen zu erwarten?

Ich verstehe das und natürlich ist ein Microcontroller da besser geeignet. Nur bei mir kommt es nicht auf so eine krasse Genauigkeit an. 1. läuft der Motor ohnehin zwischen 20-80 Schritten nach dem Stoppen weiter durch das vorhandene Drehmoment und zweitens ist 1 Mio events/s noch mit viel Luft bestückt, auch wenn es „up-to“ ist. Ebenso beziehen sich die Angaben auf das npm Package.

Ja, wenn es mir im microsekunden geht und exaktes timing, wäre dieses Setup nicht meine Wahl. Bei mir geht es nur darum, dass der Motor mit gearbox einen Schlüssel dreht und ungefähr an einer Position halten muss.

Hat aber alles - für mich zumindest nicht nachvollziehbar - mit meinem Problem zu tun.

Quote from dreamshader

Unter Linux ... na klar, und das absolut verlässlich

Ne, sorry, aber so einen Unsinn kann ich einfach nicht unkommentiert stehen lassen. Das könnte noch jemand glauben und sich dann auch noch auf der Forum berufen ...

ciao und viel Erfolg noch,

-ds-

Das ist nicht das um was es bei meinem Problem geht, daher möchte ich darüber nicht streiten. Du hast dich ja leider eh schon von der Diskussion verabschiedet. Es geht mir nicht um das genaue timing der interrupts, dass aber über tausend pro s ankommen hab ich halt direkt vor mir auf dem Screen, wenn ich den Motor übersteure ... aber wie gesag, das ist nicht das Thema.

Sry, schreibe vom Handy. Ja an den Zwei Sensorkabeln wenn von GPIO 17 u 27 abgesteckt.

interessant ist auch, dass bei bestimmten Stellungen des Magnetrades von Motor 2, an dem die Hall Sensoren angebracht sind, die Durchgangsprüfung zwischen Sensor Kabel von Moto 1 und Motor 2 postitv ist - das Multimeter gibt den Pipston von sich.

Quote from Gnom

Wo steckst du den Sensor ab? Klemmst du das Kabel direkt am Pi-GPIO ab? Dann häng mal ein langes Kabel an den Pi - ohne Sensor. Vielleicht sind es Störsignale von den Motoren. Du schreibs "brushed" - also Bürstenmotoren... die produzieren doch ständig Störfunk...

Veränder mal die Position der Motoren oder schirme sie mit nem Blech gegeneinander ab, um zu sehen, ob das Verhalten sich ändert.

ja, direkt am RPi

Quote from Bernd666

Moin haemse,

hier mal ein Auszug von der dfrobot-Seite

Das machst du ja auch. Ich denke das aus dem encoderausgang auch 5Volt kommen.

Aber die Pins der GPIO dürfen nur 3,3Volt!!!

Hast du pull-up/down angeschlossen? Oder bist du dir sicher, das der Encoderausgong auf einem bestimmten Pegel gehalten wird. Ein paar Fragen fallen mir bestimmt noch ein...

Aber eigentlich ist das alles egal, weil der dreamshader schon alles geschrieben hat.

Gruss Bernd

Display More

nein, Encoder stecken an 3,3V - geht auch mit einem Motor ganz gut.

Die Impulse spielen sich im Millisekundenbereich ab, das sollte auch das Node Script hinbekommen - tut es auch

Node.js mit npm package pigpio, im wesentlichen (zusammengesetzt aus größerem Prj):

const Gpio = require('pigpio').Gpio;

...

//config hall sensor gpio port - one of two sensors of this motor that counts rotation
settings.apt_door.motor_1.hall_sensor.sensor_gpio_obj = new Gpio(settings.apt_door.motor_1.hall_sensor.pin, {
    mode: Gpio.INPUT,
    pullUpDown: Gpio.PUD_DOWN,
    edge: Gpio.RISING_EDGE
});

//config hall sensor gpio port - one of two sensors of this motor that counts rotation
settings.apt_door.motor_2.hall_sensor.sensor_gpio_obj = new Gpio(settings.apt_door.motor_2.hall_sensor.pin, {
    mode: Gpio.INPUT,
    pullUpDown: Gpio.PUD_DOWN,
    edge: Gpio.RISING_EDGE
});

...

motor.hall_sensor.sensor_gpio_obj.on('interrupt', (level) => {
        //gpio input detection level
        if (level == 1){
            //count steps
            motor.hall_sensor.cur_pos = motor.hall_sensor.cur_pos + dir;
            log.info(motor.name + " new pos: " + motor.hall_sensor.cur_pos);


            //Timing
            let now = stall_detection.setTick();
            let diff = now - prevTick;

            /*
            //stall detection
            if (diff>=settings.stall_detect_ms && !settings.apt_door.motor_1.stopped){
                log.info("STALL STALL STALL ------------- detected in interrupt event");
                stall_detection.detention(dir*-1);
            }
            */

            //log.info("up signal occured - ", "curr_pos:", motor.hall_sensor.cur_pos, "setPos:", pos, "dir:", dir, "tickDiff:", diff);

            //check if pos reached
            if ((pos - motor.hall_sensor.cur_pos) * dir <= 0 ) {
                //log.info(motor.name + ":", "POSITION reached");
                //send stop motor signal only once
                if(!motor.stopped){
                    log.info(motor.name + " - POSITION REACHED -", " pos: ", motor.hall_sensor.cur_pos);
                    stop_motor(motor);
                }else{
                    //motor is already stopped
                    motor.hall_sensor.step_error_count = motor.hall_sensor.cur_pos - pos;
                    log.info(motor.name + " - OVERRUN -", " pos: ", motor.hall_sensor.cur_pos, " posError: ", motor.hall_sensor.step_error_count, " tickDiff: ", diff); //bitshift for 2^32 bit int shiftover - correct diff
                }
            }

            //set current tick to previous
            prevTick = now;
        }
    });

Ja, dein punkt ist definitiv valide. Dennoch, es funktioniert mit einem Motor blendend und das ist auch keine Erklärung, weshalb er an dem anderen GPIO Impulse mitzählt obwohl sich der Motor nicht bewegt. Für das brauch ich eine Lösung.

Wenn ich einen Sensor abstecke wird dort auch nicht mitgezählt.

Hallo,

ich habe zwei DC brushed Motoren [Anzeige] mit Encoder (2 Hall Sensoren) an meinen Raspberry Pi angeschlossen.

Der Encoder benötigt Vin, GND und hat zwei Signalausgänge, von jeweils zwei Hall Sensoren (mit zwei ließe sich auch die Drehrichtung bestimmen).

Etwas genauere Angaben zu den Sensoren gibt es hier.

Ich verwende nur jeweils ein Hall Sensor pro Motor um die Umdrehungen über die GPIOs am Raspberry Pi zu erfassen. (Die Drehrichtung kenne ich ja, da auch von RPI über Treiber definiert)

Die Vin der Encoder hängen am 3,3V des RPi, ebenso die GNDs. Jeweils von einem Motor/Encoder hängt ein Signalausgang an einem GPIO Port (also zwei insgesamt)

Für mich nicht verständlich, interferieren die Signale irgendwie. An den GPIOs zähle ich die Signalimpulse mit meinem Script mit (GPIO interrupts). Seltsamerweise detektiert es öfters an beiden GPIO Ports Signalimpulse, auch wenn sich nur ein Motor dreht. Wie kann das sein? Das Setup ist ja eigentlich ziemlich simple. Jeweils ein Hall Sensor von einem Motor an einen GPIO Port ...

Es scheint definitiv die Hardware-Installation zu sein, nicht die Software.

Bin dankbar für sämtliche Ideen, da ich momentan mit meinem Latein am Ende bin.

Danke für die Antworten, ist einiges wichtiges dabei. Weit entfernt ist - um es klar zu stellen - genau 5m.

adjar: Das unterschiedliche Platinen unterschieldiche i2c Spannungen verwenden, das ist ja klar, dass man dabei ins Datenblatt gucken muss, wohl auch ... die Frage hier ist ja, was ist üblicher - so in Summer - 3,3V oder 5V?

RFTM - der Stackoverflow link ist sehr, sehr schlüssig! Danke

VeryPrivat - ja, scheint mir auch so, nur wie würde man sowas in node.js machen ...

Hallo,

ich habe eine Setup mit einem Raspberry Pi (der I2C mit 3,3V verwendet) und einem Arduino Micro (der I2C 5V verwendet). Diese kommunizieren miteinander. Dazwischen habe ich ein level up/down modul um die Signale zwischen 3,3V und 5V zu tranferieren.

RPi und Arduino sind über ein eingezogenes Kabel weit auseinander verbaut. Daher kann ich nun den Leveler beim RPi oder bein Arduino installieren, abhängig davon, ob I2C mehr mit 3,3V oder 5V benutzt wird. Denn wenn ich es beim Arduino einbaue und ich noch weiter Sensoren, Actuatoren oder beliebige andere Module einbauen will, diese aber alle auf 5V sind, kann ich keine mehr in der Nähe des Arduinos verbauen, da dort nur 3,3V I2C Schaltkreis präsent ist - und das Ganze natürlich auch umgekehrt.

Daher die Frage: Gibt es so subjektiv, von erfahrenen Hasen gesehen, mehr 3,3V I2C Geräte, oder mehr 5V?

Danke für euer Wissen,

lg

Danke, ein großes Bild vom I2C hab ich mittlerweile eh, nur bei einigen Punkten hab ich halt Verständnisprobleme. Daher ist es etwas obsolet den Wiki Artikel eines komplexen Themas zu posten, wenn man dazu spezifische Fragen hat, auch wenn ich den Unterton verstehe.

Bsp. zu 3. (ad fred0815) hab die Beschreibung der jeweiligen Methoden natürlich gelesen. Nur kann ich mir zB. kein Bild machen, was denn der Unterschied zwischen sendByte, writeByte und writeWord sein soll. Send Byte scheint sich durch das fehlen des CMD Parameters abzuheben, während writeByte und writeWord beide die gleichen Parameter haben nur, dass beim einen der datenparameter vom Typ Byte ist und beim aderen vom Typ Word ... wenn ich aber bei den Datentypen unten in deinem Link nachlese, dann ist sowohl Word, als auch Byte beide angegeben als Byte Length Number:

Was solle denn da bitte noch der Unterschied sein?

lg

PS: Very Private - danke für die individuellen Antworten, haben mir sehr geholfen.

Hallo,

ich hätte da drei Fragen bzgl. dem I2C Bus. Habe recherchiert, aber die Infos nicht alle gefunden, bzw. nicht ganz verstanden.

1. wie ist beim I2C Bus eigentlich definiert wer Master und wer Slave ist? Muss das bei den Geräten individuell konfiguriert werden, oder machen die sich das im I2C Netz automatisch aus? Wie verhält sich da der RPi

2. kann eigentlich spontan ein Slave dem anderen Daten senden? Oder kann das jeweils nur der Master initiieren?

3. was ist eigentlich kurz und bündig der Unterschied zw. den allgemein gängigen i2c funktionen "sendByte, writeByte, writeWord und writeI2CBlock?

Vlt. kann der ein oder andere eine der Fragen beantworten,

lg und danke

Arduino kann ich nicht testen, weil ich keinen zur Hand hab. Kann davon ausgehen, dass es dort funktioniert.

ok, das ist ein punkt.

aber eine I2C implementierung an einem atmega8 müsste doch 3.3V auch als high bit erkennen?

Hallo an alle,

Ich versuche ein Grove I2C Motor Treiber Board über den I2C Bus am Raspberry Pi 3 mittels Node Script zum laufen zu bringen.

Aber es möchte sich ums Verrecken der Motor einfach nicht drehen

Ich hab dazu auf StackOverflow einen detailierten post gemacht, der aber leider keine Antwort bekommen hat, vermutlich weil er einfach zu spezifisch und hardwarelastig ist:

https://stackoverflow.com/questions/5310…rry-pi-i2c-writ

Aber vlt seid Ihr ja besser.

Im Zuge dessen habe ich festgestellt, dass ich eigentlich auch das Selbe Problem aus diesem Thread hier haben:

https://forum.dexterindustries.com/t/grove-i2c-mo…ith-grovepi/744

Nämlich dass:

pi@raspi:~/i2c_tests $ i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- 0f
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

immer nur beim ersten mal die Adresse findet. Hernach dauert der Scan bei jedem Schritt deutlich länger und es wird das Gerät nicht gefunden, bis ich das Treiber Board wieder resette.

Ich möchte das unbedingt lösen, zumal es eigentlich ein gutes Board zu sein scheint. Nur wenige Pins im vergleich zu klassischen H-Bridges opfern zu müssen und dort sogar noch viel mehr Geräte anhängen zu können ist sehr attraktiv.

Doch an was könnte es liegen? Mir scheint alles richtig verkabelt zu sein V3.3, SDA, SLC und GND auf den jeweiligen Port ...

Kann es an I2C Frequenzeinstellungen liegen, oder was habt ihr für Ideen???

Im offiziellen Arduino Code auf Github scheint zumindest eine Frequenz gesetzt ... ob das allerdings I2C freq ist?

https://github.com/Seeed-Studio/G…_Driver.cpp#L55

...
    this->_i2c_add = i2c_add;
    // Set default frequence to F_3921Hz
    frequence(F_3921Hz);
}

Naja, das muss ja auch nicht das Problem sein ... keine Ahnung.

Quote from jar

es gibt 2(3) Möglichkeiten

1. Klingelspannung erfassen an der Klingel, einfach weil man auch dort in der Nähe Saft für den PI hat)

2. Klingelstrom zur Klingel (meiner Meinung nach von Vorteil wenn man nur an die Tasterzuleitungen kommt)

AC muss auf jeden Fall gleichgerichtet und geglättet werden.

Ich habe genau dieses hier schon mal ausführlich beschrieben, nur noch nicht für jeden!

Naja, Gnom meint der hier tuts auch AC ... dann müsste ich demnach nichts glätten.

RPi Zero hat schon Strom über ein 5V Netzteil und ist auch schon im Klingelgehäuse eingebaut. Verwende ihn bereits mit einem Relais und Webhook um die Haupttüren zu öffnen ... geht daher auch über Siri Shortcuts und Alexa etc. ... ok back to topic.

Mit dem erwähnten Koppler müsste es demnach völliig ohne gleichrichten und glätten etc. gehen?

Hallo,

ich erstrebe über den GPIO meines eingebauten RPi Zero W das Klingeln an meinem Klingelsystem zu detektieren und dann im Script zu IFTTT, Alexa und oder eine Push Notification aufs Handy zu senden.

Ich brauche ein paar Tips zur Schaltung um die 12V AC am 3,3V GPIO zu erfassen. Ich denke an einen Optokoppler.

Eigentlich sollte eine Schaltung wie diese hier funktionieren?

Ich habe halt ein 12V! AC Signal. Was müsste ich dafür an dieser Schaltung anpassen?

Ich nehme an dieser Koppler hier wäre passend?

https://www.conrad.at/de/on-semicond…dc-1265996.html

Was würdet ihr ändern? Was sind eure Gedanken?

lg

Danke für die Tips - ich hab nache des Schlosses schon einen RPi am laufen ... aber diese ESP Dinger klingen echt interessant.

Hat sonst noch jemand Hardware Vorschläge ... vor allem bzgl. Motor / Mount etc. ?

Quote from Kelvin

genau