Jump to content

photron

Administrators
  • Content Count

    2666
  • Joined

  • Last visited

  • Days Won

    11

photron last won the day on October 23

photron had the most liked content!

Community Reputation

12 Good

About photron

  • Rank
    Tinkerforge Staff

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Das über eine Datenbank zu vereinheitlichen ist eine gute Idee. Deine Regeln sind aber komplexer formuliert als sie müssten. Da würde ich die Zustände/Stellwerte der Ausgänge mit zu den Eingaben der Regeln nehmen. Das erlaubt dir dann Sensor 0 > 30C° und Sensor 14 < 50°C and Systemmodus = “no Errors” then Schalte Motor1 ein bis Sensor 0 < 10°C so zu formulieren if Sensor0 > 30C° and Sensor14 < 50°C and Systemmodus = “no Errors” and Motor1 aus then schalte Motor1 ein if Sensor0 < 10°C and Motor1 an then schalte Motor1 aus Dadurch kannst du dieses
  2. photron

    LED Strip

    Also, du hast in Brick Viewer den richtigen Chip Type ausgewählt. Ich habe gerade auch eine Rolle frisch aus den Lager getestet, um zu sehen, dass wir da auch das richtige verkaufen. Was wir tun, die Rolle funktioniert einwandfrei. Du hast das Channel Mapping auf BGR stehen, es müsste aber GRB sein, dass kann aber nur falsche Farben erklären, teste trotzdem ob das was ändert. Auf deinem Foto ist nicht zu erkennen, ob du Daten- und Minusleitung richtig angeschlossen hast. Dein Adapterkabel zwischen Bricklet und LED Strip scheint 2 grüne Leitungen zu haben. Du könntest Daten und Minus
  3. Die Anfrage sieht also auf dem Oszilloskop identisch aus, egal ob aus Matlab oder aus Brick Viewer gesendet, sprich der Sensor kann das nicht unterscheiden. Aber es kommt in Brick Viewer und Matlab nur eine Antwort an, wenn Brick Viewer die Anfrage gestellt hat, aber nicht wenn Matlab die Anfrage stellt. Das verwirrt mich weiterhin sehr. Interessant wäre jetzt noch zu sehen, was mit der Antwort laut Oszilloskop ist. Ob der Sensor sie wirklich nicht sendet. Ich nehme an auf dem RS485 Bricklet ist die aktuelle Firmware 2.0.5 drauf. Falls nicht, updated bitte mal über Brick Viewer.
  4. photron

    LED Strip

    Die Datenleitung ist nach dem Reset 4.8V, weil das Bricklet dann noch nichts sendet und die Leitung High hält. Sobald du in Brick Viewer das Bricklet etwas senden lässt, sendet das Bricklet dann dauerhaft Daten auf der Datenleitung und dein Multimeter misst da einen Mittelwert von 1.25V, so weit so gut. Darauf dass die 1.25V sich nicht ändern würde ich nichts geben, dass heißt nicht, dass das Bricklet kaputt ist, sondern nur dass ein Multimeter hier nicht das richtig Werkzeug ist. Da kommst du nur mit einem Oszilloskop oder Logic Analyzer weiter, um zu erkennen ob das Bricklet da das richtige
  5. photron

    LED Strip

    Klinkt alles nach Wackelkontakt bzw schlechtem Kontakt, vor allem wenn du schon sagst DATA sähe mit dem Multimeter komisch aus. Ich würde als nächstes mal die Lötverbindung zwischen Anschlusskabel und Strip überprüfen/nachlöten.
  6. Sehr komisch. Da habe ich keine gute Idee zu. Das initiale Programm sollte einfach funktionieren, abgesehen von den 4 Writes direkt nacheinander. Für mein Verständnis: Aus Brick Viewer heraus funktioniert alles wie erwartet. Wenn die Anfrage gesendet wird kommt eine passenden Antwort darauf. Wenn ihr das aber aus eurem Programm heraus macht kommt keine Antwort. Wenn aber euer Programm läuft und ihr parallel dazu in Brick Viewer die Anfrage sendet, dann kommt eine passenden Antwort in eurem Programm und in Brick Viewer an. Habe ich das so richtig verstanden? Was passiert wenn Bri
  7. Okay, um einmal meine Verwirrung zu klären. Der Sensor den du da verwendest sprichst Modbus ASCII und das was du da schickst sieht auch nach korrektem Modbus ASCII aus, daher auch die 7 Bit. Die Modbus Funktionen des Bricklets sind für Modbus RTU, meinen Ratschlag das zu nutzen kannst du ignorieren, das funktioniert nicht. Es sieht auf den ersten Blick so aus als hättest du dein Vorgehen von Brick Viewer korrekt in dein Programm übertragen. Eine Unterschied könnte noch sein, dass du in Brick Viewer zwischen den 4 Anfragen die du schickst etwas Zeit vergeht, weil du händisch die Anfrage we
  8. Ich fürchte der Modbus Modus des Bricklets für 7 Bit ist ungetestet. Daher jetzt eine Rolle rückwärts 😜. Da es mit Brick Viewer funktioniert müssen wir jetzt nur finden was in deinem initialen Programm nicht passt. Was genau hast du in Brick Viewer als Anfrage eingeben? Und hast du dabei das Encoding auf "ASCII" oder "Raw (Hex Bytes)" gestellt?
  9. Was mich auf den ersten Blick stutzig macht ist die Wordlength von 7 Bit, üblich wären 8 Bit. Auf den zweiten Blick kommt die Frage warum du in deinem Programm das Bricklet im RS485 Modus verwendest und händisch Modbus versuchst zu sprechen, wenn du im Brick Viewer erfolgreich das Bricklet mit Modbus Master Modus verwendest mit der Read Holding Registers Funktion. Du solltest nicht auf das Loopback Beispiel aufsetzten, sondern auf das Modbus Master Besipiel: https://www.tinkerforge.com/de/doc/Software/Bricklets/RS485_Bricklet_MATLAB.html#modbus-master-matlab Und dieses von modbusMaste
  10. Das Beenden müsste dein Programm selbst machen. Zum Beispiel den Wert time.time() beim Start des Programm speichern, dann in der Schleife mit dem aktuellen time.time() Wert vergleichen und nach 8h (28800s) das Programm beenden. Das Starten kannst du über den Scheduler machen. Dort den Cron Modus wählen mit "0 8 * * *", damit das Programm jeden Tag um 8 Uhr gestartet wird.
  11. Das ist ein Python 2 vs 3 Problem. Du verwendest auf deinem PC Python 3, auf dem RED Brick aber Python 2. In Python 2 hängt der Typ einer Division von den Operanden ab: 2 / 3 ergibt eine Integer-Division 2 / 3.0 eine Float-Division. In Python 3 macht der normale Divisions Operator / immer eine Float-Division und für eine Integer-Division muss man // verwenden. In deinem Fall betrifft dieser Unterschied die alpha Berechnung: alpha = (count*360)*10/1000 Alle Operanden darin sind Integer, dadurch passiert dort eine Integer-Division, obwohl du eine Float-Division erwartest
  12. Dann würde ich provokant sagen, dass du eben dein Programm so schreiben musst, dass es die "Signale" pro Sekunde und nicht pro Umdrehung ausgibt 😜 Sorry, aber da musst du mal genauer beschreiben, was du da machst. Mir ist unklar was du da genau misst und wie, so kann ich dir da keine sinnvolle Antwort zu geben. Wenn möglich zeigt auch mal dein Python Programm vor.
  13. There is not precompiled library you could link against. You need to include ip_connection.c and brick_imu_v2.c from the API bindings into your Visual Studio project, as the documentation explains.
  14. Schon komisch. Da das Hotplug Flashen geklappt hat muss der I2C Bus okay sein, da das Flashen über den I2C Bus läuft. Da ist mir jetzt unklar wo das Problem steckt. Hast du schon versucht den Master Brick neu zu flashen?
×
×
  • Create New...