AuronX

Wenn die Erzählungen stimmen muss man ein ziemlich großes Binärformat generieren ^^

Möglicherweise gibt es ja eine Bibliothek mit der man die Dinger programatisch erstellen kann? Das würde das Generieren denke ich erst erschwinglich machen...

Das meinte ich ja mit Grenzbereich

Es gibt halt keine TF-Werte die oberhalb von 16k so viele Nachkommastellen brauchen ^^

Aber ich persönlich nehm eigentlich auch immer double.

Ich denke sowas hier kann er noch: http://www.tinkerunity.org/forum/index.php/topic,423.0.html

Bisschen Galgenhumor muss sein

Ist das eigentlich nur Quellcode oder sind da auch Bilder mit bei? Weil 1 MB wären 10.000 Zeilen Code wenn jede Zeile 100 Zeichen lang ist...

Ich denke das sinnvollste wäre externes Hosting (GitHub oder Rapidshare oder eigener Webserver).

Ints sind schon ziemlich praktisch, obwohl ich das mit dem Parsen nicht verstanden habe ^^

Wegen Float vs. Double: Ich denke Float sollte eigentlich überall reichen, da ja die Werte nie in nem Grenzbereich sind (also sehr groß oder sehr viele nachkomma-stellen).

Mein double in den Beispielen war jetzt eher Gewohnheit

P.S.: Die Variante die nen bool als Parameter kriegt finde ich komisch... wenn ich da false übergebe habe ich ja das schlechte beider Welten: Ich muss Dividieren und halte keinen int in der Hand...

Lässt du dir Fehler anzeigen? Normalerweise wirft der Konstruktor der IPConnection Exceptions wenn was schiefgeht, das müsstest du sehen wenn dein PHP Fehlermeldungen ausgibt.

Zu Fuß gehts aber auch:

Frei nach w3schools:

try
{
  $ipcon = new IPConnection($host, $port);
}
catch(Exception $e)
{
  echo 'Message: ' .$e->getMessage();
}

Wenn Interesse besteht kann ich die Quellen dann über das Tinkerforge-Repository im Github bereitstellen.

Wenn du das eh vorhast würde ich dir empfehlen einfach jetzt schon das TF-Repo zu forken, dort den Unterordner für LabView zu erstellen und die Sourcen via github hosten (gibt ja auch Download für Source-Code). Dann kann dir potenziell auch schnell jemand helfen wenn ihm ein Fehler auffällt und du kannst irgendwann nen großen Pull Request an TF stellen

Lustig ist, dass ich heute früh beim Aufstehen darüber nachgedacht habe

Also ic denke die Motivation wird es sein, dass du im int oder uint keinen Präzisionsverlust hast, bei float und double könnte sowas passieren.

Dennoch fände ich skalierte Werte auch schöner, da ich auch oft ziemlich durcheinander komme. War Humidity jetzt Faktor 10 oder 100? Ich müsste nachschauen.

Hier wäre mein Masterplan:

In der Config der Bricks wird je Element eine Spalte für das Scaling eingeführt. So zum Beispiel:

com['packets'].append({
'type': 'function',
'name': ('GetIlluminance', 'get_illuminance'), 
'elements': [('illuminance', 'uint16', 1, 'out', 0.1)],
'doc': ['bm', {
'en':
"""
This is only the doc of the Bricklet...
""",
'de':
"""
"""
}]
})

(neu ist die letzte Spalte bei elements

Bindings sind jetzt frei wie sie diese Spalte ausnutzen wollen (bzw. TF darf frei wählen was sie anbieten wollen):

public double GetScaledIlluminance()

1.Option: Eine zusätzliche Methode anbieten die skalierte Werte ausgibt (also 20.0 statt 200), die alte bleibt unter altem Namen zusätzlich bestehen wegen der Kompatibilität und Präzision.

public double GetRawIlluminance()

2.Option: Die Methode mit altem Namen skaliert per default, aber es gibt noch immer eine "Raw"-version mit voller Präzision und ohne Umrechnung, ähnlich dem Ansatz mit GetAnalogValue().

public double GetIlluminanceScaleFactor()

3.Option: Die Bindings bieten wenigstens eine Möglichkeit an zu erfahren mit welchem Scale-Faktor der aktuelle Wert arbeitet.

Weiterer Mini-Vorteil: Die bisher nur im Fließtext zu erfahrende Skalierung könnte ebenfalls automatisiert Dokumentiert werden ^^

Eine Dimension wäre auch ganz gut glaube ich...

also braucht man 100 Besteller, 1000 oder 10000 damit es lohnt? Ich könnte mir alles davon vorstellen ^^

Ich habe gerade mal bei einem bekannten Online-Auktionshaus nach "Tinkerforge" gesucht. Gab zwar leider keine Treffer, aber mir wurde als ähnlicher Suchbegriff Arduino angeboten

Wäre auch dafür, den Privathandel über die bekannten Wege zu lenken.

Also ein Linuxer/Macer würde nichts von einer Eingabeaufforderung schreiben, da drüben nennen die meisten das Konsole oder Terminal ^^

Aber du hast natürlich recht, ich habe nur geraten...

Hmmm Java und JavaScript teilen sich eigentlich nur den Anfang des Namens und die geschweiften Klammern

Also der Brickd sollte als Service laufen, also unsichtbar.

Kannst du schauen:

Start->Rechtsklick auf Computer->verwalten->Dienste und Anwendungen->Dienste

Dort nach Brickd suchen, es sollte "Gestartet" dranstehen.

Dann noch eben zur Klarstellung: Du spielst im Normalfall nichts auf deine Bricks auf. Die hängen an deinem Rechner und können von deinem Rechner aus gesteuert werden (also Text auf LCD anzeigen, Temperatur an PC ausgeben usw). Sie können also nicht ohne weiteres OHNE PC betrieben werden.

Ansonsten einfach mal die Examples von Tinkerforge aufsuchen, denke die sind nen guter Einstiegspunkt.

Kann mal einer von euch versuchen zuerst auf eine der Flaggen zu klicken?

Wenn ich zuerst auf die Flagge und dann auf Blog klicke dann geht es

Allerdings habe ich das mit dem Multi-Touch bisher anders verstanden

Wegen des Callbacks mache ich mir keine Sorgen. Das wird doch nur ausgelöst, wenn der Schalter betätigt wird, und das geschieht erst dann, wenn der Motor sich dreht, und der dreht sich erst, wenn die Hauptroutine so weit durchgelaufen ist. Oder irre ich mich?

Im normalfall hast du recht, aber was wäre wenn ^^

Beispiel:

Während des Einschaltens kommt jemand gegen den Schalter (oder der Motor ist während des Einschaltens am Schalter), jetzt kommt der Callback noch WÄHREND du alles initialisierst und durch die nicht initialisierte variable stürzt der callback-thread ab. Jetzt läuft die initialisierung weiter, startet den Motor, aber weil der Callback-Thread tot ist wird nciht auf den Schalter reagiert und alles fängt an zu brennen! (dramatisiert)

Kurz: Wenn sich ein Fehler schon Software-seitig ausschließen lässt sollte man ihn schon dort ausschließen.

Dein Code entwickelt sich ja auch weiter, manches wird verschoben und kopiert und schon bald hast du vergessen, dass das dort ausnahmsweise in der Reihenfolge ging weil ...

LG

Jan

Am Ende ist ja die Frage ob der Magnet darauf so reagiert wie man es erwartet. Also das Prinzip von PWM ist ja, dass average(0V, 12V) = 6V oder average(0V, 0V, 12V) = 4V.

So weit so toll, aber was wenn das eine Vereinfachung ist die auf Elektromotoren anwendbar ist, aber bei Elektromagneten nicht funktioniert (aus elektrotechnischen Gründen die ich nciht kenne).

Will sagen: Ohne Ahnung sagt dir das Multimeter auch nichts hilfreiches Entweder es kommt noch jemand der es wirklich WEIß oder du musst einfach ausprobieren was passiert

Danke, du hast mich daran erinnert, dass das auf meinem Android auch nicht geht.

Aber wenn ich mich recht entsinne, dann funktionieren Deep-Links:

versuche mal: http://de.blog.tinkerforge.com/2012/5/11/versand-ab-sofort-mit-dhl

Wie auch immer, wenn man mit Android (und offenbar auch iOS) kommt landet man auf: http://None.blog.tinkerforge.com

dann kannst du am Collector eine Spannung zwischen 7 und 12 Volt einstellen.

Da ich deine Ausführung noch nicht ganz verstanden habe: Heißt das, dass er am Ende  die Ausgangsspannung nur zwischen 7 und 12 Volt einstellen kann?

Weil er auch meinte, dass es ihn stört, dass das DC-Brick erst ab 6V beginnt.

@Thomas: Habe mich auch gefragt ob PWM da nicht reicht, aber leider auch zu wenig Ahnung um zu antworten

Nein, er will die Spannung fließend regulieren können um so unterschiedliche Hubkräfte aufbauen zu können. Zumindest hat er das geschrieben ^^

Ich vermute, dass ein IO4 genauso gut geeignet sein müsste, kannst du ja mal schauen, wäre ein wenig günstiger ^^

Beim Timing weiß ich nciht ob man per USB mit einer besseren Auflösung als 1ms klarkommt. Also selbst wenn ich das Signal auf 0.1ms genau "losschicke", weiß ich nicht, ob die Latenz zwischen senden und empfangen immer die gleiche ist. (oder ausreichend gleich)

Ich denke auch, dass die sicherste Variante eine eigene Firmware auf dem Brick wäre, allerdings ist das halt viel schwerer umzusetzen.

@Paul (Off-Topic):

Hast du schon irgendwo dokumentiert wie du deine DSLR ansteuerst? Wäre an einem entsprechenden Wiki-/Foreneintrag sehr interessiert.

Chibi soll tatsächlich sterben: http://www.tinkerunity.org/forum/index.php/topic,283.0.html

Ich kann den Zweck von chibi gegenüber WLAN aber nicht einschätzen.

Aus meiner Sicht könnte Chibi dort wo man draußen ist und Reichweite will gut sein (ferngesteuerte selbst-bewegte Dinge).

Beim Anwendungsfall "Funkthermometer für andere Räume" ist oftmals der Funkraum durch einen WLAN-AP bereits erschlossen und deswegen kein chibi nötig.

Habe bisher nie in VB programmiert, sonst hätte ich dir noch nen Ansatz geben können.

Ansonsten gibt es halt keinen Beispielcode usw. weil es noch nciht offiziell unterstützt wird.

Hier kann man über die nächste Programmiersprache abstimmen, PHP-Bindings gibt es ja inzwischen sogar schon.

Möchtest du in VB bis 6.0 oder in VB.NET programmieren?

VB bis 6.0 wird derzeit nicht unterstützt, VB.NET wird auch noch nicht offiziell unterstützt, aber ein bisschen geht es doch über die C#-Bindings.

Das Problem bei den C#-Bindings und VB.NET ist, dass VB.NET z.B. keine unsigned Typen kennt, diese werden aber in manchen Methoden der C#-Bindings als Parameter erwartet. Diese Methoden kannst du dann nicht ordentlich rufen. Wenn du aber experimentierfreudig bist, solltest du das versuchen.

Das Display scheint auch besonders empfindlich gegenüber ESD zu sein, da gabs ja schonmal nen Thread wo es darauf hinauslief: http://www.tinkerunity.org/forum/index.php/topic,222.msg965.html#msg965

Der Threadersteller hat dort das Problem (in meiner Erinnerung) einschränken können, indem er das Kabel zum Display geschirmt hat. Möglicherweise ist es bei dir gar kein ESD, sondern das Display liegt nur zu nah am (magnetisch schaltenden(?)) Relais...

Ich habe bei mir im Moment auch Pappkarton-betrieb, da kann sowas schnell sehr dicht beisammen liegen.

Wenn auch sicherlich langsam einen eigenen Thread wert:

Sofern jumperbar/schaltbar sich so leicht realisieren ließe, dann wäre das definitiv die von mir favorisierte Lösung.