reckewell

Super!

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

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...

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...

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

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...

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 ;-)

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

Ist passiert...

Danke für die gute Unterstützung - ist nicht selbstverständlich!

greetz

Carsten

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

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

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

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

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

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!)

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

Ah cool - danke!

Irgendwie fehlt mir die Suchfunktion - und die Geduld, mehr als 4 Pages tief alles durchzulesen ;-)

Moin!

Da der Physikunterricht schon ein paar Jahre zurück liegt...

Welches Bricklet / bzw. welche Bricklet/Hardware-Kombination würdet ihr mir empfehlen, um das Anliegen einer "normalen" 240V-Wechselspannung zu überwachen?

Hintergrund: Ich habe ein Gerät, dass im eingeschalteten Zustand zwei Betriebsstundenzähler (für verschiedene Komponenten des Geräts) ansteuert... schlauerweise mit 240V Wechselspannung. Nun würde ich diese beiden Zähler gerne auch per Tinkerforge überwachen.

greetz

Carsten

Moin!

Sorry - ich hatte viel um die Ohren, daher die späte Rückmeldung.

Ich bin eigentlich der Ansicht, dass die Bricks fest aufeinander gesteckt waren. Ursprünglich waren die sogar ganz normal verschraubt. Ich hatte den Stapel zerlegt, nachdem das Netzwerk mehrfach weg war (übrigens immer nach längerer Zeit - ich hatte schon einen Energiesparmodus oder ähnliches in Verdacht, konnte dazu aber nichts finden).

Ich habe dann den Stack komplett zelegt und wieder zusammen gebaut - gleiches Phänomen, nur diesmal schon nach sehr kurzer Zeit (übrigens same RED, other Master).

Dann habe ich den Stack umgesteckt - und seitdem läuft das einwandfrei.

Klar kann man ein Steckproblem nicht ausschließen - allerdings hätte ich das dann zweimal zufällig sehr identisch produziert - aber wer kennt schon Murphy.

Aber gut zu wissen, dass die Reihenfolge erstmal grundsätzlich egal ist. Ich plane grad an einem anderen Stack - und da ist es nämlich bautechnisch relevant an welcher Stelle das Netzwerkkabel sitzt ;-)

Danke

Carsten

Moin!

Gibt es eigentlich Einschränkungen zur Reihenfolge von Komponenten im Stapel - und viel wichtiger: ein Dokument dazu?

Beispiel (jeweils von links nach rechts = von unten nach oben):

A) RED [1.5] > Master > Ethernet(nonPoE): läuft nicht zuverlässig

B) RED [1.5] > Ethernet(nonPoE) > Master: läuft

Kombination A) verliert bei mir andauernd die Netzwerk-Connection... - sprich: Der RED ist (fest vergebene IP) nach unterschiedlich langen Zeitspannen nicht mehr per Brickviewer oder Ping im Netzwerk erreichbar.

Noch interessanter: An dem Master hängen 3 Bricklets - eines davon, ein Remote Switch Bricklet, läuft sich in Kombination A) bei jedem Schaltvorgang tot. (Sprich: Die Buttons werden grau - und das bleiben sie dann auch).

In Kombination B) geht das jetzt (zumindest mit dem neuen Image).

Gibt es da etwas, das ich überlesen habe?

greetz

Carsten

Wäre erstmal eine gute Notlösung (wobei ich das für die Anwendung etwas overdone finde - beonders, weil ich dafür extra einen zweiten Master stacken muss, weil auf dem anderen alle 4 Ports belegt sind ;-)

Werd ich da mal einbauen und schauen wie's geht - danke für den Hinweis!

Die Idee mit einer "erweiterten" Step Down Power Supply finde ich eigentlich total nice... Vielleicht könnte man damit dann auch das Problem mit der vergessenen Zeit nach Stromausfall lösen? (Habe dazu einen separaten Thread angestoßen).

greetz

Carsten

Ich habe gerade eine Schaltung fertig gemacht, die zwei Pumpen nach verschiedenen Kriterien steuert. Das funktioniert hier sehr gut (Software auf Red-Brick, 1 Master Brick, 2 Relaisschaltungen, etc...)

Das einzige Problem hier ist: Das Ganze soll eine zeitgesteuerte Komponente bekommen... und da sich die gesamte Steuerung in einem Kasten im Garten befindet, und man dort keine Netzwerkanbindung bekommt... habe ich ein Problem mit der "Zeitlosigkeit" des RED Bricks. Sprich: Stromausfall = Problem.

Ich kann mir vorstellen, dass auf dem Mini-Teil kein Platz mehr für eine Knopfzelle war ;-) Trotzdem...

Hat dazu jemand eine Idee?

Könnte man ein Bricklet bauen, das die Zeit der Atomuhr ausliest und einspeist?

Oder macht das vielleicht in Zusammenhang mit der von mir angesprochenen "Mini-USV" Sinn? Eine kleine Platine, die man wie eine Step Down Power Supply unten drunter klicken kann und die dann neben einem Akku vielleicht auch eine "Uhr" besitzt, die nach dem Stromausfall ihre Zeit behält? Dann hätte man 2 Fliegen mit einer Klappe geschlagen und der Stapel würde überschaubar klein bleiben.

greetz

Carsten

Ich fahre das im Moment auch mit einer kleinen USB-Powerbank.

Nur teilt die dem Brick über USB leider nicht mit, wenn sie fast leer ist, so wie jedes Handy heute seinen Akku-Ladestand kennt. Damit könnte man den RED dann gezielt herunter fahren und nicht warten, bis er aus Strommangel unkontrolliert abstürzt.

Oder habe ich etwas übersehen?

greetz

Carsten

Jetzt mit dem RedBrick bekommt das Thema Stromversorgung eine neue Qualität...

Einen Stack mit Hilfe einer Batterie zu versorgen - das bekommt man recht einfach hin.

So richtig genial wäre natürlich eine Art Mikro-USV - per USB anschließbar (vielleicht optional stapelbar) über das nicht nur die Stromversorgung eines Stapels erfolgen kann (vorzugsweise gleich so aufgebaut, dass man es per USB laden kann und der Stapel dann transparent "dahinter" hängt) - sondern auch optional mit dem RedBrick kommunizieren und ihn bei niedrigem Akkustand sauber herunter fahren kann....

So als Idee: "Normale Akkus" sind recht günstig zu haben - alternativ gibt es deutlich kleinere Teile, die dann meist etwas teurer sind... Wenn man das Ganze so aufbauen würde, dass man (so ähnlich wie bei dem neuen Relais-Bricklet) die Wahl zwischen "Standard-Akku" und "Mini-Akku" hat, dann wäre das natürlich noch ein echtes Plus.

Schon in RedBrick Festlaune...

Carsten