Nic

Alle 10ms den getter, das ist dann aber nur eine Notlösung, optimaler wäre ein CB Threshold wie z.B. beim VoltageCurrent Bricklet: http://www.tinkerforge.com/de/doc/Software/Bricklets/VoltageCurrent_Bricklet_Delphi.html#TBrickletVoltageCurrent.SetCurrentCallbackThreshold Oha, den würde ich mir aber auch für den Stepper Brick wünschen Den VoltageCurrent zw. Motor und Stromquelle anbinden wäre keine Option?

Ich habe den getter noch nie benutzt, stattdessen über den Callback allData gibt es auch die aktuelle Stromaufnahme: http://www.tinkerforge.com/de/doc/Software/Bricks/Stepper_Brick_Java.html#BrickStepper.AllDataListener

Eine kleiner Erfahrungsbericht nach knapp 7 Wochen RTC Einsatz: Zu Beginn hatte ich die Zeit manuell über den BrickV eingestellt. Referenz war eine Funkuhr. Vergleiche ich die RTC Zeit heute mit der Funkuhr würde ich schätzen, dass RTC etwa 1/4 sec nachgeht. Bis heute ohne Kalibrierung und ohne weitere manuelle Korrektur.

Ich kann mir nicht vorstellen, dass die 85° erreicht oder überschritten wurden, dann müssten vorher einige Materialien sich sichtbar verformt haben. Ich würde den Ambient woanders hinlegen und nochmal messen ob das gute Stück noch betriebsfähig ist. Halbleiter Sensoren haben eine oft noch eine ausgeprägte IR Empfindlichkeit jenseits der 700nm. Ev. ist der IR Anteil so hoch, dass die Messwerte verfälscht werden. U.U. ein Schutzglas vor den Ambient montieren oder alternativ ev. das Temp.-IR Bricklet verwenden.

Falls die Tests erfolgreich sind, müsste man als Kunde dann nochmal plus 4 +/- Wochen rechnen bis das gute Stück im Shop ist?

Zum stupiden Daten sammeln, gibt es alternativ noch den Brick Logger: http://www.tinkerforge.com/de/doc/Software/Brick_Logger.html#brick-logger

Ok, letzte Frage dazu: Nehmen wir als Beispiel eine CB-Periode von 5min: Aggregiert sich die Abweichung von Takt zu Takt, oder würde das Callback Event mal mehr (5,2min) oder nur etwas weniger (5,07min) später ausgelöst? PS: Habe zum ersten Mal die RTC Zeit manuell (localtime) angelegt, und anschl. mittels rtc_time.py Script wird zwar die Systemzeit des RED synchron. aber abhängig von der (vermutl. vom NTP vorher gesetzte) Zeitzone umgerechnet

Mit Bereichen meinst du den jetzt gesamten Messbereich von Betriebsstart bis -ende des CBs, oder die Periode?

Das es im Zusammenhang mit der Ungenauigkeit eines Brick-Timers zu tun hat, ist mir nicht aufgefallen. Mit ist das auch neu, dass die internen Timer eines Brick generell nicht so genau sind. Habe ich hier im Forum oder Doku das übersehen? Mit welchen Abweichungen hat man i.d.R zu rechnen? Gilt die Ungenauigkeit auch für die Monoflop-Timer?

Wird das periodische Auslösen unter Angabe der MillSec nicht schon abgedeckt durch den OnDateTime Callback? Meinte Equinox doch diesen...

Ja eine Repeat Angabe wäre prima, ev. könnte man mit diesem Wert auf 0 den CB grundsätzlich abschalten, eine Auslösung einmalig mit 1 usw. Wie gebe ich die dauerhafte Wiederholung an? Max (int) ? Du (noch) nicht, aber vielleicht andere User, da fragst du besser wehnerc Aber der Vorteil von Callbacks generell ist klar, oder? Warum soll ich für u.U. banales Monitoring von Werten extra Infrastruktur progr.? Auf einem Single-Core ARM und node.js muss ich das nicht unbedingt haben.

Ich würde generell eine 0 statt -1 setzen um etwas abzuschalten, so haben wir das bisher auch bei Callbacks gemacht. Und dann eine public Konstante in die API ev. hinzufügen die genausowas beschreibt FLAG_NOOP(=0) oder so ähnlich. Dann muss ich bei der Anwendungsprogrammierung nicht mehr drüber nachdenken: war das jetzt eine 0 oder xyz sondern setze statt einem Zahlenwert diese Konstante. Mir würde es erstmal reichen, wenn es noch geht, könnte man auch optional jeden Werktag setzen, da wäre dann quasi so universell wie bei einer Schaltuhr, jeden Montag und Samstag um 15.38 Uhr. Also ev. über ein Array oder Flags (rtcMonday || rtcSaturday) ... Aber nur wenn das ohne zusätzl. Aufwand geht. Wäre schön wenn diesbzgl. auch mal andere User ihre Meinung abgeben könnten... Bevor dann wieder der Katzenjammer in der Community anfängt "Öh so blöde Fkt. kann ich ja gar nicht verwenden...".

Ok, prima und danke. Und meine flüchtigen Gedanken musst du nicht immer so genau unter die Lupe nehmen set_alarm: Ich würde empfehlen erstmal nur ein simplen Callback(int8_t month, int8_t day, int8_t hour, int8_t minute, int8_t second) implementieren solange nicht hier aus der Community noch weiteres Feedback/Wünsche kommen.

Stirnrunzel Es gibt im RTC überhaupt noch keinen Callback! Es reicht aber zumind. einen Callback zu haben wie z.B. im GPS OnDateTime etc. Alles andere vergiss was ich geschrieben habe. Und genau dafür will ich es nehmen, für einen 20 Euro teuren Bricklet kann ich erwarten, dass da einfache Callbacks drin sind, mit dem ich mir z.B. einfach die aktuelle Uhrzeit in die Anwendung triggere. Wenn der poppelige IO4 einen Timer-gesteuerten Monoflop hergibt verstehe ich nicht warum dass im RTC ein OnDateTime nicht machbar wäre. Gut setzt aber woraus das ich noch eine eigene Routine schreiben muss um den richtigen Tag zu berechnen. Aber egal ein einfaches setAlarm tut es auch.

Nur eine kleine Ergänzung: Die Variable "speed" war im Haupt(main)code nicht definiert und daher unbekannt. Diese war nur innerhalb des Callback-Aufrufs bekannt und auch nur dort nutzbar. Mit z.B. start = 0 wird die Variable "start" erst definiert und erhält eine Wertzuweisung. Es kommt aber darauf an wo (=scope: https://de.wikipedia.org/wiki/Variable_%28Programmierung%29#G.C3.BCltigkeitsbereich_von_Variablen_.28Scope.29) man diese festlegt.

Ja erstmal als "Standard" wie beim GPS, z.b. über SetDateTimeCallbackPeriod würde man das Interval in ms eintragen zu dem der Callback periodisch auslöst. Damit könnte man z.B. als Photograph Intervallaufnahmen steuern. SetAlarm wäre hilfreich den RTC als Schaltuhr für Zeitsteuerung zu verwenden. Ich würde dann aber auch noch den relativen Bezug ermöglichen, also z.B. wiederholend jeden Samstag um 15.36 Uhr. Natürlich vorausgesetzt dass der IC das hergibt.

Ein wenig seltsam ist das mit dem RTC, ich finde nicht eine einzige Callback-Fkt.! Ich möchte in meinen Anwendungen eig. schon die aktuelle Zeit über einen Callb. erhalten können, ohne Umweg über einen zusätzlichen Timer und Polling! Also ein simpler CB/Listener wie z.B. http://www.tinkerforge.com/de/doc/Software/Bricklets/GPS_Bricklet_Java.html#BrickletGPS.DateTimeListener sollte schon drin sein.

Ich würde noch weiter gehen und der Darstellung operativer Daten noch mehr Platz gönnen: Die Labels im Kopfbereich "Channel 0: 0.005V" etc. entweder auf 1 Zeile nebeneinander stellen oder über die Buttons "Channel 0" positionieren. Ebenfalls Platzverschwendung ist das Control "Show/Edit Calibration" über die gesamte Fenterbreite zu ziehen. Das ist vielleicht für Tablet-PCs ganz toll, weil man dann sicher den Button per Touch trifft In die "Fußzeile" würde ich nebeneinander anlegen: Samp.Rate, Einh. ggf. abkürzen, CHL Btn "0", "1", "Clear", "Calibration". also alle zusammen und zentral. Weißer Bereich zeigt ausschl. die operativen Daten: Min/Max würde ich ev. rechts auch im Klartext angeben. Ebenso die jeweils aktuellen Werte von C1/2 würde ich von der Headline an die rechte Kante verlagern. Als Goodie vielleicht (später mal) einen "Save Plot" als PNG. Der Canvas müsste das eig. hergeben - auch in Python. Als wesentliche Verbesserung wäre mir noch die horizontale Dehnung der Historie wichtig. Darum gings doch eig. PS. Weitere Inspirationen könnten die Charts auf dem Aktienportal OnVista geben. Die Gruppierung eines Plots nach dem Zeitraum in 5Tage/1Mon/... ist gar nicht mal so schlecht.

Ja, in der Tat: ein größeres Zeitfenster als jetzt mit den 20 sec wäre sehr praktisch. Und vielleicht eine Markierung des Max/Min Wertes zum schnelleren Überblick.

Ich würde empfehlen zu Beginn die Beispiele aus der Dok. zu verwenden, und diese nach und nach zu variieren. So bekommt man ein wenig Erfahrung über das TF-System und seine Bausteine/API. Um einen Fehler durch den Setter zu bekommen vorher diese Funktion callen: http://www.tinkerforge.com/de/doc/Software/Bricklets/DualButton_Bricklet_CSharp.html#BrickletDualButton::SetResponseExpected__byte.b

Ah, prima, ich warte schon drauf. Es ist nicht ganz klar, was ihr mit Grafikplot meint? Ist das ein Beispiel-Aufbau speziell auf der Cebit gezeigt oder der Plot im BrickV?

Habe es gerade auf einem Lubuntu 15.10 x64, BrickV 2.3.3, Image 1.7 getestet, da geht alles prima. ich erinnere mich in ganz seltenen(!) Fällen auch eine Fehlermeldung bekommen zu haben, vermutlich wenn die Synchr. zw. BrickV und RED noch nicht vollst. zu Beginn geklappt hatte. Beim nächsten DataCollect verschwand das aber. Ich würde den RED vom Kabel trennen, die SD-Karte vorsichtig nochmals einstecken, manchmal kann die verkanten. Prüfen ob der USB-Port genügend Spannung liefert, ev. an einen anderen PC anschl. USB-Kabel wechseln. Ev. Y-Kabel mit zusätzl. Spannung nehmen. Blinkt die grüne LED regelm.? Tritt das Problem auch unter Windows bzw. anderen Host auf?

Danke für die Impressionen. Aha jetzt verstehe ich was mit der Bemerkung im Blog gemeint war "...nutzte uns sogar..." Also im Grunde das Sortiment was wir schon kennen, und sonst keine Prototypen? Hast du das RTC-Bricklet gesehen?

@kwally You asked this question exactly 1 year before: http://www.tinkerunity.org/forum/index.php/topic,3011.msg18840.html#msg18840 If you do NOT need a shield or any proprietary hardware build specially for the raspi then you can (most likely) exchange the raspi by the RED. Both runs a Debian distro and an ARM cpu. Depends which raspi do you have, the RED has slightly less performance/memory. At the RED there is a GPIO interface but I assume it will never be supported by drivers or adapters. TF has removed the description about it from documentation. A raspi has lots of GPIOs a better support of several interfaces e.g. I2C. On a RED you have to solve it by the wide range of existing bricklets. On a certain raspi you can have Ethernet and more USB connectors onboard. For the RED you need an ethernet extension and a USB hub. PS: Finally RED supports "only" a lower version (3.4) of the kernel in opposite to the rasp (4.1). Means some hardware connected to the RED could be not supported because of missing drivers in kernel. If you are an expert in Linux you can try to recompile the kernel with embedded drivers. But I think you cannot really compare a Rasp with the RED. For me the RED is more a super brick providing us a "ondevice programming" without any need of a desktop/host pc on very small form factor, smaller than the raspi.

Ja BrickD als "Router" brauchst du für die Bricks/Bricklets, oder alternativ die WIFI/Ethernet-Extension. Der BrickD für Windows ist nur auf den Intel/AMD-x86x64 Plattformen lauffähig. WIN IOT für Raspi dürfte aber nur ARM kompatibel sein. Für diese Architektur müssten die Sourcen neu kompiliert werden. Interessant wäre hier der Aspekt der neuen Universal Apps von M$. Wenn ich richtig verstanden habe, müsste dann so eine App auf allen Win.Plattformen laufen !? Ref: https://en.wikipedia.org/wiki/Universal_Windows_Platform PS: Wußte noch nicht, dass Win IOT schon ausgeliefert und lauffähig ist