Jump to content

reckewell

Members
  • Gesamte Inhalte

    31
  • Benutzer seit

  • Letzter Besuch

reckewell's Achievements

Newbie

Newbie (1/14)

  • Conversation Starter
  • Week One Done
  • One Month Later
  • One Year In

Recent Badges

0

Reputation in der Community

  1. Moin! Ich habe mir am Wochenende mal die Pascal/Delphi-Bindings angeschaut und mit Delphi 11 & 12 getestet. Für Windows und OSX lief alles einwandfrei - Linux, IOS und Android brachten einige Compilerfehler. Ich habe mir das Ganze mal angeschaut und korrigiert, so dass alles für alle unterstützten Plattformen compiliert (und mit meinem Testprojekt auch einwandfrei auf Windows, Android (32&64), IOS, OSX und Linux funktioniert. Glücklicherweise haben Embarcadero und ihr gute Vorarbeit geleistet... Alle Systeme, die nicht funktionierten waren "Unix"-Systeme. Ich habe daher an einigen Stellen aus "DELPHI_MACOS" ein "DELPHI_NONWIN" gemacht. Geändert werden mussten dabei nur die TimedSemaphore.pas und die IPConnection.pas. Einfach gesagt wird in beiden Dateien aus: {$ifdef FPC} {$mode OBJFPC}{$H+} {$else} {$ifdef MACOS}{$define DELPHI_MACOS}{$endif} {$endif} ganz banal ein: {$ifdef FPC} {$mode OBJFPC}{$H+} {$else} {$ifndef MSWINDOWS}{$define DELPHI_NONWIN}{$endif} {$endif} (Denn alle Zielplattformen außer "MSWINDOWS" sind Unixbasiert und werden ähnlich behandelt.) MSWINDOWS wird in Delphi schon seit Anbeginn der Ewigkeiten definiert, so dass mir das als einfaches Unterscheidungskriterium erscheint... Als Folge müssen natürlich die ConditionalDefines in der Datei angepasst werden... von {$ifdef DELPHI_MACOS} zu {$ifdef DELPHI_NONWIN} Dank der sauberen Implementation ist das dann auch schon alles - und alle Zielplattformen lassen sich compilieren. IPConnection.pas TimedSemaphore.pas
  2. Das scheint ein Problem des 2.3.2er BrickDaemon zu sein... Auf meinem alten PC tritt das Problem ebenfalls auf - installiere ich die 2.3.1, dann funktioniert das auf beiden PCs...
  3. Leider nein... Hätte ich dazu sagen sollen... Der Dienst ist nicht gestartet und wenn ich ihm manuell starten will, dann sagt Windows: "Dienst "Brick Daemon" wurde auf "Lokaler Computer" gestartet und dann angehalten. [usw.] Das ist leider reproduzierbar dauerhaft so...
  4. Moin! Ich habe das Problenm, dass der aktuelle BrickDaemon auf meinem neuen Windows 10 (64 bit, 1809) nicht startet. Der PC ist relativ neu und vorgestern wurde das aktuelle Build von Windows drauf geworfen. Heute habe ich dann den aktuellen BrickDaemon (2.3.2) installiert. Als mein BrickViewer (auch aktuelle Version, heute installiert) dann meinte, dass er auf "localhost" nichts finden würde, habe ich mal genauer nachgeschaut: Im Eventlog stehen die folgenden Meldungen mit der Quelle BrickDaemon: Leaking generic event source (handle: 628, name: hotplug, events: 0x0001) at index 0 Could not get USB device list: LIBUSB_ERROR_OTHER (-99) Ich habe auch mal das Log des Daemons angeschaltet... Da dies die erste Installation auf dem neuen PC ist, kann ich leider nicht sagen, ob es Seiteneffekte mit der Hardware gibt - was ich sagen kann ist, dass der Update-Treiber sauber funktioniert (ich also Bricks mit aktueller Firmware versorgen kann). Viele Grüße Carsten brickd.log
  5. Ich hab etws ähnliches mit (je) einem DualRelais Bricklet umgesetzt - allerdings schalte ich damit auch direkt die 240V der Rolladenmotoren... Vielleicht ganz interessant für deine Softwareumsetzung - und unabhängig von der Hardware: Ich habe mir den Algorithmus für Sonnenauf- und Untergangszeit in die verwendete Programmiersprache übersetzt (in diesem Fall Delphi/Pascal). Das funktioniert erstklassig - und ist schön Jahreszeitangepasst ohne dass ich etwas ändern muss...
  6. Wenn du mal schaust, wie dicht der RED gepackt ist, wüsste ich auch nicht, wo die Jungs da noch einen Ethernetport unterbringen sollten - da würde ja der Stecker die halbe Platine belegen ;-)
  7. So - das Ersatzbricklet ist da. Und meine Tests haben dazu geführt, dass ich meine Erfahrung mal hier im Forum kundtun muss, denn bis bei mir der Groschen gefallen ist hat echt gedauert. Lange Rede... das neue Bricklet zeigte exakt das selbe Verhalten wie das alte. Ich habe das Ganze wie folgt getestet: Auf meinem Ikea-Schreibtisch liegt meine schwarze Ikea-Kunstleder-Schreibunterlage. Darauf hatte ich ein Blatt Papier gelegt (kann man auf den Fotos ungefähr erkennen. Und: Nein - nicht Ikea). Darauf habe ich den ganzen Aufbau getestet. Böser Fehler! Wie sorgt Ikea bei diesem Unterlagen für die nötige Steifheit? Richtig! Man arbeitet eine dünne Metall(!!!)platte mit ein. Und was ist nur gerne dazu bereit, die Energie elektromagnetischer Wellen "aufzusaugen"? Also: Kleiner Tipp an alle. Wenn ihr mal ein NFC-Bricklet testen wollt: Stellt sicher, dass das nicht auf einer Metallmatte, -kiste oder sonstwas macht, das den Versuch des Bricklets einer Induktion in den Chip stark vermindert. ...da soll mal einer drauf kommen.... [Nochmal danke für die schnelle Hilfe - wir klären die Details per Mail.] Viele Grüße Carsten
  8. Ist passiert... Danke für die gute Unterstützung - ist nicht selbstverständlich! greetz Carsten
  9. Moin! Ja, ursprünglich hatte ich den PI2 und an den Anschlüssen eine Tastatur, das Display und den Master mit NCF Bricklet (alles andere hatte ich schon abgehängt). Das Netzteil war ein "Pi-Netzteil" mit 5V-2A. Da ging das dann wie gesagt gar nicht. Wenn ich den Masterbrick an den PC anschließe (und dann nur mit RFC Bricklet), dann habe ich das beschriebene Verhalten sprich: Ich bekomme die beiden Chipkarten mühsam zum Laufen (wenn ich sie direkt mittig auf das Bricklet lege). Zwischenzeitlich hat sogar einmal einer der Chips "gezuckt" - aber nicht reproduzierbar :-( Ich habe mal 3 Fotos angehängt, damit ihr sehen könnt, was ich meine. Nur auf "works" wird das Tag gelesen. In den beiden anderen Fällen halte ich den Chip nichtmal einen Zentimeter über das Bricklet - da wird dann kein Tag mehr erkannt. greetz Carsten
  10. Ah okay - das erklärt es... Werde ich die Tage mal testen, sobald die Augen nicht mehr so tränen... Mistvirus ;-) Viele Grüße Carsten
  11. Hallo nochmal! Ich bin derzeit dabei, eine intelligente Schaltkonsole für meinen Kompressor aufzubauen. Grundsätzlich besteht das Ganze aus einen Raspberry Pi 2 mit dem 5" Adafruit Touchscreen, einem angesteckten Masterbrick mit folgenden Bricklets: Rotary Encoder, Industrial Dual 0-20mA, NFC/RFID Anfangs habe ich die Komponenten über ein 5V/2A Netzteil durch den Raspberry versorgt. Wenn man nun mit dem NFC/RFID-Bricklet scannt, bricht die Spannung am Display so zusammen, dass es resettet (und ich habe das Dual 0-20mA noch nicht mal mit angeschlossen). Nun kann ich das Display nicht einfach von woanders mit Spannung versorgen, da über den USB-Bus ja auch der Touchscreen läuft... Ich habe mir nun die Spezifikationen der StepDown Power Supply durchgelesen und folgendes versucht: StepDown unter den MasterBrick... Am 5V-Ausgang hängt nun der Raspberry. (Okay - an diesem hängt wiederum per USB der MasterBrick - aber das lässt sich ja schlecht vermeiden.) Das funktioniert nun mit einer Einschränkung: Versorge ich das System mit Spannung (12V= 3,33A Netzteil), dann startet der Master Brick und der Raspberry bootet vollstänig. Das Einzige was nicht geht: brickd... Sprich: Der Master wird nicht erkannt... egal, ob ich versuche, ihn remote anzusprechen oder den BrickViewer lokal starte - keine Chance. Es wird nichts angezeigt. (Wobei brickd läuft - er registriert nur den Master nicht). Drücke ich jetzt am Master die Resettaste, dann wird direkt nach dem Neustart der Master erkannt und ich kann ihn nutzen. Hat da vielleicht jemand eine Idee? Das kann gerne ein anderer Aufbau der Spannungsversorgung sein - oder eine Softwarelösung... (Kann ich eventuell das Display direkt mit 5V versorgen, in dem ich die Spannungsversorgung von den beiden Signalleitungen des USB trenne und nur die beiden letzteren aus dem Pi ziehe? Oder gibt das andere elektrische Probleme?) Das ist jetzt ja kein wirklich großer Stapel - und wie ich das sehe, müsste das Problem eigentlich öfter auftreten, wenn man ein System mit dem 5" Display kombinieren will... Viele Grüße Carsten
  12. Moin! Ich bin gerade am Testen meiner letzten Lieferung. Dabei macht mir das NFC/RFID-Bricklet ziemlich zu schaffen (alle Komponenten auf aktuellem Firmwarestand): Das Lesen aller Tags (ich habe 2 Karten, 5 Chips und 5 Aufkleber getestet) funktioniert entweder gar nicht (Kleber) oder nur sehr sehr selten. Ab Besten gehen noch die Karten - richtig herum gehalten, ganz exakt an einer Stelle. Ich habe Kabel und Brick getauscht - es liegt definitiv am Bricklet oder am Kabel. Ein einziges Mal habe ich übrigens auch einen der Chips lesen können... und dann nie wieder. (Schon beim erneuten Klick auf "scan for tag" las er nichts mehr, obwohl ich das Tag nicht wirklich bewegt hatte) Hat jemand Erfahrung mit diesem Bricklet? Ist das Bricklet eventuell defekt? Viele Grüße Carsten
  13. Moin! Danke für die Info. Werde ich so umsetzen, wenn ich mal dazu komme, den Rest der Hardware in Betrieb zu nehmen. greetz Carsten
  14. Nein... ich schreib das jetzt lieber nicht... Das Schlüsselwort war nicht was fehlte. Eher das konsequente überlesen von "SEARCH" oben auf der Seite (AU!)
  15. Hallo nochmal! Ich überlege, den Druck an meinem Kompressor (bis 250bar) abzugreifen. Dazu bietet sich z.B. Der Druckmessumformer Wika A-10 halbwegs günstig an. http://de-de.wika.de/upload/DS_PE8160_D_1594.pdf Es gibt ja nun einige Bricklets mit denen man die verschiedenen möglichen Ausgangssignale messen kann (z.B. Voltage/Current, zukünftig Industrial Dual Analog In). (Ich würde da jetzt z.B. 0-10V messen und gemäß Datenblatt in Druck übersetzen)... Meine Frage: Welches Bricklet liefert die größte Genauigkeit für diese Aufgabe? Danke und viele Grüße Carsten
×
×
  • Neu erstellen...