Jump to content

gmu

Members
  • Gesamte Inhalte

    22
  • Benutzer seit

  • Letzter Besuch

Posts erstellt von gmu

  1. Hallo,

    ich habe mit einem PI4 in Phython das vorgegebene Beispiel für den Callback verwendet.

    Funktioniert wunderbar und ich erkenne das Auflegen und Abnehmen des Chips.

    Bleibt der Chip aber auf den RFID-Leser liegen, dann kommen sporadisch (manchmal nach 7 Stunden, manchmal in kürzerer Zeit) innerhalb einer Sekunde zwei Ereignisse, dass der Chip abgenommen wurde und wieder aufgelegt wurde.

    Es wurde bereits ein anderer Brick und NFC Bricklet mit dem selben Ergebnis getestet.

    Gibt es hierzu Erkenntnisse, Lösungen?

    Ein Workaround wäre, diese Ereignisfolge binnen einer Sekunde zu ignorieren. Aber eigentlich würde ich eine echte Lösung einem Workaround vorziehen.

    Danke.

     

  2. Hallo M4ST3R,

     

    das kann man sich File für File schon ziehen:

    tfsoftwaretest~tinkerforge-sourcecode - Revision 2: /VisualLibraryTest/ShapeSample/src/org/netbeans/shapesample

    ..

    Bundle.properties

    GraphSceneImpl.java

    LabelTextFieldEditor.java

    MyNode.java

    ShapeTopComponent.form

    ShapeTopComponent.java

    palette/

     

    SSD - ich bin noch ein ein Gegner davon.

    Hoffe Du kannst da noch was rausholen von den Daten.

    Schon mal probiert die SSD wo anders reinzustecken?

     

    Gruß

     

    gmu

  3. Hallo,

     

    habe eben meine Lieferung bekommen.

     

    2 x Masterbrick + Chibi-Masterextension + Temperatur-Bricklet.

     

    Beide Versuchsaufbauten (Master, Temp und Chibi) an verschiedenen PCs per USB angeschlossen und konfiguriert.

     

    Der eine Chibi ist Master mit Adresse 1, Slave 2 eingetragen.

    Der andere Chibi ist Slave mit Adresse 2.

    Frequenz und Kanal ist gleich.

     

    Da müsste ich doch auf einer Seite des Masters mit dem Viewer das Temperaturmodul des Slaves sehen?

    Sehe ich aber nicht.

     

    Komisch ist auch, dass bei der Chibi-Extension auf beiden PCs im Viewer folgendes angezeigt wird:

     

    Stack Voltage: 0V

    Stack Current: 0mA

    Signal Strength: 0dBm

     

    gmu

     

  4. Hallo FabianB,

     

    nein, das mit dem Quellcode erstellen ist wirklich simpel.

     

    Das kann sogar soweit gehen, dass man wahlweise nur das reine Programm ohne grafischen Schnickschnak erzeugen läßt und somit ein schlankes Progrämmchen hat, dass nur die Bibliothek von TinkerForge benötigt.

    Ein Einsatzgebiet dafür wäre z.B. ein Aufbau mit eigenem Display (wenn wieder lieferbar;) ).

     

    gmu

     

  5. Der Punkt 6 von borgs Post ist sehr interessant und wäre ne coole Sache.

     

    Das Problem ist aber, dass der Brick z.B. keine EMails versenden kann.

     

    Der Ansatz von M4ST3R ist ganz gut und zeigt, dass man mit NetBeans durchaus auf dem richtigen Weg ist.

     

    Einen Quellcode in Java aus einem zusammengezeichneten Programm zu erzeugen ist simpel.

    Der Ansatz sollte aber m.E. sein, die Brickmodule visuell darzustellen, Programmlogiken per Drag'n'Drop zu erstellen und erweiterte Funktionen wie z.B. EMail, SMS etc zu realisieren.

    So kann sich der Anwender eine Art Schalttafel zusammenziehen und diese auch entsprechend Anwenden (Temperaturanzeige, Knopf drücken für Ein/Ausschalten, Relais schalten, Eingänge/Ausgänge anzeigen, und und und).

     

    So eine Schalttafel könnte dann z.B. so aussehen (Bild ist willkürlich ausgesucht worden und soll nur einen optischen Eindruck vermitteln):

     

    inco_bri.gif

     

    gmu

  6. Hallo M4ST3R,

     

    Du hast Dir da ja schon mal richtig Arbeit gemacht.

    Das finde ich ganz toll, wenn jemand aktiv an Ideen arbeitet.

     

    Ob Netbeans für den "Anwender" dann das richtige ist, bezweifle ich.

    Oder habe ich das falsch verstanden und Du wolltest uns Entwickler einen Einblick geben.

     

    Für die Umsetzung sehe ich Java (gerne auch mit NetBeans) absolut als Favorit.

     

    Der Anwender, soll nur noch seine Module zusammenstecken und dann per Drag'n'Drop sich seine Symbole für die Anzeige und seine Logic für den Ablauf zusammenziehen. Ggf. den ein oder anderen Parameter noch hinzufügen, aber das muß es für diese Art Anwender dann schon gewesen sein.

     

    Ich seh schon, da könnte tatsächlich was draus wären. Ich liebe dieses Forum  ;)

     

    gmu

  7. Hallo Matty,

     

    freut mich, wenn es gebraucht werden kann.

     

    Test-Email mache ich diese Woche rein. Das ist eine gute Idee. Ich schimpfe auch immer wenn sowas bei Druckern fehlt :-)

     

    Internationalisierung mache ich dann auch gleich noch rein, damit die Texte über ein Textfile oder so geändert werden können.

     

    Aktuell muß man die Dialog-Resourcen und die Textkonstanten dazu abändern.

     

    gmu

  8. Hallo borg,

     

    das Rad muß man sicherlich nicht neu erfinden.

    Aber gewisse Teile muß man neu machen.

    Wiederverwenden kann man z.B. Grafiktools, die die Bricklets schön darstellen (LED-Anzeige, Thermometer, Meßkurve im Grid, Analoganzeige, etc).

     

    Als Plattform bietet sich Java an, da dies auf nahezu allen Betriebssystemen lauffähig ist und einiges für GUI mitbringt.

    Ja, Python auch, aber mit beschränkten Lizenzbestimmungen (z.B: bei Verwendung vom pyQt).

     

    Vorgestellt habe ich mir folgende Bausteine:

     

    Der GUI-Editor

    Damit wird ein Projekt mit den einzelnen Bricklets grafisch zusammengestellt und grafisch dargestellt.

    Hier soll eine Grundklasse definiert werden, die eine Verbindung zu ipcon bekommt und sich selbst (falls diese sichtbar sein soll) darstellen kann.

    Die Grundklasse soll dann schon das verschieben im Editor beherschen, so dass sich der Bricklet-Klassen-Programmierer nur noch um die Eigenschaften seines Modules und ggf. deren inhaltliche Anzeige kümmern muß.

     

    Logik-Editor

    Mit diesem Editor soll man einfach die Ablaufsteuerung grafisch umsetzen können.

    Dazu gehört das Setzen oder Abfragen von Variablen, die die Bricklet-Klassen bieten.

    Schleifen und Verzweigungen.

    Threads und Timer.

    Sonderfunktionen wie Mailversand und Dateilogging.

     

    Viewer (Runtime)

    Das mit dem GUI- und Logik-Editor erstellte Programm kann dann als Standalone mit dem Viewer weitergegeben werden.

    Der Viewer arbeitet die Logik ab und stellt die als sichtbar definierten Bricklets entsprechend dar.

     

    Soweit die Theorie.

     

    gmu

  9. Die Idee "grafisch" zu Programmieren finde ich sehr gut.

     

    Müsste man ggf. in Java machen, damit auch viele Plattformen abgedeckt werden.

     

    Dazu braucht man die Definition einer Klasse mit Grund-Methoden, von der alle visuellen Bricklet-Module dann abgeleitet werden.

    Einen Editor, mit den man diese grafischen Elemente einpassen kann.

    Dann noch ein Workflow-Generator für die Programmlogik und schon ist die Sache fertig.

     

    Wenn Tinkerforge die Hardware kostenfrei bereit stellt und sich noch ein, zwei Leute für die Entwicklung finden würden ... ich wäre dabei.

     

    Sowas habe ich früher schon mal in TurboPascal für eine Gruppe von Meßkarten realisiert. Das macht wirklich Spaß!

     

    gmu

  10. Hallo,

     

    schön wenn es gefällt.

    Ich werde voraussichtich bis zum Wochenende das Logging einbauen.

    Dann gibt es auch den Quellcode (MS Visual Studio 2010, C#).

    Das Logging (in eine Textdatei) ist wichtig, weil man damit natürlich die Nachvollziehbarkeit (Temperaturanstieg und -abstieg) hat und dieses ggf. in Excel oder auf einer Webseite grafisch auswerten kann.

     

    gmu

×
×
  • Neu erstellen...