borg

Es gibt zwei Möglichkeiten die "Geräuschlage" zu verbessern: 1. Du schreibst dein Programm so, das jedesmal disable aufgerufen wird wenn der Motor anhält (dies geht nur wenn der Motor nichts zu halten hat im stehenden Modus). Alternativ kannst du im Stillstand auch den Motor Current verringern. Das hilft auch gegen ungewünschte Geräusche. 2. Du aktivierst Synchronous Rectification und spielst mit dem Decay herum. Am meisten Leistung erreichst du nach unseren Tests mit einem Decay von ~10000. Der Ton im Stillstand wird aber angenehmer desto höher der Decaywert ist (das ist natürlich Ansichtssache).

Ein Schrittmotor hat einen schnelleren "Stromanstieg" wenn er mit einer höheren Spannung betrieben wird. Oder anders: Ein Schrittmotor wird mit einem Konstantstrom betrieben. Dieser Strom wird aber desto schneller erreicht, desto höher die Spannung ist. Dadurch sind dann mehr Schritte pro Sekunde möglich. Siehe diese Grafik hier aus dem Blogeintrag: http://www.schrittmotor-blog.de/wp-content/uploads/2011/04/motorstrom.jpg (Die rote Linie ist eher am Maximum als die grüne). So ist mein Verständnis davon. Man korrigiere mich wenn das Blödsinn ist . Das es einen Zusammenhang zwischen maximaler Drehzahl und Spannung gibt kannst du aber ganz einfach ausprobieren: Nimm einen Schrittmotor ohne Last und betreibe ihn mit einem Labornetzgerät mit 5V und drehe die Drehzahl langsam hoch bis der Schrittmotor aussetzt. Dann betreibe ihn mit 30V (alles andere bleibt gleich, nur die Spannung hochdrehen am Labornetzgerät). Jetzt wird der Schrittmotor erst bei einer höheren Drehzahl aussetzen.

OK, Firmware 2.3.3 ist veröffentlicht. Das Problem hing irgendwie mit dem Initialzustand der SPI-State-Machine nach der ersten Enumerierung zusammen. Der Bug war an der Stelle schon immer da, irgendeine der Änderungen in 2.3.2 muss das Timing so geändert haben, das es dort jetzt zu Problemen kam. Einen Zusammenhang mit unterschiedlichen Hardware Versionen gab es nicht, das hat einfach zufällig funktioniert oder nicht funktioniert und bei meinen Tests gab es mit den Master 2.1 die ich hier hatte gerade zufällig keine Probleme. Das hatte mich erst auf die falsche Fährte gelockt .

Firmware: Master Brick 2.3.3 Reinitialisiere SPI-State-Machine nach dem ersten Stack Enumerate (Fix für Bug in Stack Kommunikation aus Firmware 2.3.2) Download: Master Brick

Firmware: Master Brick 2.3.3 Reinitialize SPI state machine after initial stack enumerate (Fixes stack communication bug that was introduced in 2.3.2) Download: Master Brick

Mh, das sieht ja so aus als wären Bitfehler auf der Leitung. Welche Bricklet Kabel verwendest du? Kannst du mit kürzeren Kabel testen?

Kannst du da mal vor dem register_callback ein t.set_i2c_mode(t.I2C_MODE_SLOW) einbauen? Hilft das?

Oh, in der Tat. Gut aufgepasst!

Kannst du auch einmal bitte die 2.3.3-beta1 Firmware testen aus diesem Thread http://www.tinkerunity.org/forum/index.php/topic,3132.0.html? Danke!

Der Unterschied zwischen Master Brick 2.1 und 2.0 ist lediglich in der Schutzbeschaltung, hat nichts mit der Stapelkommunikation zu tun . Könnt ihr einmal bitte die Firmware im Anhang testen? master-brick-2.3.3-beta1.bin

Mh, have you tried one of the recommended baudrates? http://www.tinkerforge.com/en/doc/Hardware/Bricks/RED_Brick.html#rs485-extension The A10s processor on the RED Brick can unfortunately only reach a few baudrates precisely.

1) Ein Schrittmotor sollte optimalerweise immer mit der maximalen Spannung betrieben werden die der Schrittmotortreiber kann: http://www.schrittmotor-blog.de/die-sache-mit-der-spannung/. Im Falle des Stepper Bricks 38V. Die 24V Stromversorgung die wir im Shop haben ist aber auf jeden Fall gut geeignet (wenig Über-/Unterschwingungen unter Last etc) . 2) Edit: Du musst als "motor current" in der API 0.4A einstellen (nicht 0.8A) 3) Ja. 4) Gute Idee, fügen wir ein . 5) Ja. 6) Das hängt natürlich von der Last ab. Wir haben in Tests 60000 1/8 Schritte pro Sekunde erreicht. Das entspricht (60000*60)/(8*200*27) = 83 U/min?

Huch? Ich könnte schwören das ich sogar einen Stack der Größe 9 getestet hab. Es gab auch zwei Monate lang eine Beta Version der Firmware: http://www.tinkerunity.org/forum/index.php/topic,2580.msg18819.html#msg18819. Die scheint das Problem nicht gehabt zu haben. Ich kann es reproduzieren, aber nur wenn 2.1 und 2.0 gemischt sind im Stapel. Ich bin gerade die letzten Diffs durchgegangen im GIT, da gibt es nichts was das erklären könnte. Sehr mysteriös, ich gucke mir das morgen genauer an.

Wir arbeiten gerade an einem neuen Schwung Bricklets (13 Stück). Eines davon ist ein Moisture 2.0 welches kapazitiv misst . Die Leiterplattenbestellung für die neuen Brickelts ist gerade diese Woche rausgegangen. Wir brauchen dann noch Schablonen und da es eine Erstbestückung ist muss natürlich ein Bestückungsprogramm erstellt werden usw. Wenn die Bricklets hier sind müssen wir sie Fotografieren und Shopfertig machen (flashen, testen). Wenn nichts großartig schief läuft sollten die neuen Bricklets dann in 5-7 Wochen bei uns im Shop sein .

Rein technisch funktioniert das wie folgt: Die Bricklets haben ein "Firmware-Plugin" auf ihrem EEPROM gespeichert. Dieses Plugin wird vom Brick beim starten ausgelesen und in den eigenen Flash geschrieben. In jedem Plugin gibt es eine Funktion an definierter stelle die in äquidistanten Abständen 1x pro ms vom Brick aufgerufen wird. D.h. das Plugin des Industrial Digital In 4 Bricklet kann 1x pro ms (also 1000x pro Sekunde) eine Flankenänderung feststellen und eine entsprechenden Callback auslösen. Daher ist eine Abtastrate von 1000Hz in der Tat möglich, aber auch das Maximum. Diese 1000 Nachrichten pro Sekunde sind auch das Maximum welches USB 2.0 übertragen kann. Daher ist diese Abtastrate von 1000Hz nur dann erreichbar, wenn zum einen der PC die Ressourcen hat um 1000x pro Sekunde USB zu pollen und zum anderen keine anderen Nachrichten über USB laufen. An einem normalen PC (kein embedded Board o.ä.) mit dem aufbau PC -> USB -> Master Brick -> Industrial Digital In 4 Bricklet würde ich erwarten das die Abtastrate von 1000Hz in der Tat durchgängig möglich ist.

IMO ist das Bricklet dann defekt. Ich würde vermuten das die Antenne im Bricklet nicht in Ordnung ist und dass das hier beim testen nicht aufgefallen ist . Melde dich bei info@tinkerforge.com mit der Bestellnummer, wir schicken ein neues NFC Bricklet raus.

Firmware: Master Brick 2.3.2 New USB hotplug support (independent of USB detect) Fix "false-positive-ack" bug in SPI communication Add magic number for unflashed Bricklet detection Firmware: Stepper Brick 2.3.1 Update state if only one step is set Add magic number for unflashed Bricklet detection Download: Master Brick, Stepper Brick

Firmware: Master Brick 2.3.2 Neue USB Hotplug-Unterstützung (unabhängig von "USB detect") Fix "false-positive-ack"-Bug in SPI-Kommunikation "Magic Number" zum erkennen ungeflashter Bricklets hinzugefügt Firmware: Stepper Brick 2.3.1 Aktualisiere "State" auch wenn nur ein Schritt gefahren wird "Magic Number" zum erkennen ungeflashter Bricklets hinzugefügt Download: Master Brick, Stepper Brick

As far as i understand it you have to rename the ".c" files to ".cpp" with VS, otherwise VS will interpret them as C89 files. Did you do that? http://www.tinkerforge.com/en/doc/Software/API_Bindings_C.html#visual-studio

Entschuldige für die späte Antwort! Wenn du etwas implementieren möchtest was über die Nagios-Unterstützung im Brick Viewer hinaus geht ist es vermutlich am einfachsten das direkt über eine eigene Nagios-Konfiguration zu machen. Ich würde die check_tinkerforge.py kopieren und darauf aufbauen. Deine eigene Konfiguration und die Einstellungen im Brick Viewer können ja Problemlos parallel laufen. Eine parametrisierte Programmierung über den Brick Viewer wäre natürlich hübsch, stelle ich mir aber sehr Aufwändig vor. Dies direkt über eine .cfg und eine kleine .py zu machen ist mit Hilfe der Beispiele die dafür bereits existieren vergleichsweise einfach machbar .

Es liegt zwar keine SPI-Hardwareeinheit auf den Bricklet-Anschlüssen, es stehen aber genügend digitale Datenleitungen zur Verfügung um SPI zu "bitbangen". Bricklets die SPI nutzen: * Industrial Analog Out Bricklet * Industrial Dual Analog In Bricklet * NFC/RFID Bricklet * PTC Bricklet * Remote Switch Bricklet Da sollte also genug Beispielcode vorhanden sein auf dem man aufsetzen kann. Siehe z.B. hier https://github.com/Tinkerforge/industrial-analog-out-bricklet/blob/master/software/src/analog-out.c die Funktionen * spibb_transceive_byte * dac7760_read_register * dac7760_write_register

Das kommt ganz drauf an. Möchtest du eine Funkstrecke zwischen zwei Stacks aufbauen (wie damals mit der Chibi Extension)? In dem Fall müsstest du eine Master Extension bauen. Ansonsten kannst du ein Brick oder Bricklet machen. Die Frage ist dann: Passt die Firmware dafür in 4kb Flash mit 256 byte RAM? Falls ja wäre ein Bricklet das richtige. Falls nein muss es ein Brick werden . SPI/I2C Kommunikation mit einem Bricklet ist kein Problem, das machen die meisten unserer Bricklets. Ich hab gerade ganz kurz ins Datenblatt geguckt: Das sieht definitiv so aus als könnte man es per Bricklet steuern. Darf ich fragen was der eigentliche Anwendungszweck ist? RFID?

Wir arbeiten gerade noch ein einem anderen kleinen Bugfix in der SPI-Kommunikation den ich in das Release mit reinmachen möchte. Wenn das komplett durchgetestet ist gibt es das 2.3.2 Release .

Die aktuelle Master Brick Firmware unterstützt kein Hotplug, siehe diesen Thread hier für mehr Infos dazu: http://www.tinkerunity.org/forum/index.php/topic,2580.0.html Im selben Thread gibt es auch eine master-brick-2.3.2-beta2.bin Firmware (hier: http://www.tinkerunity.org/forum/index.php/topic,2580.msg18819.html#msg18819). Damit sollte Hotplug wieder gehen . Die Firmware wird in den nächsten paar Tagen auch offiziell veröffentlicht.

Was hast du denn für einen Aufbau? Den gleichen wie in dem anderen Thread? Falls ja probier es mal mit nur einem Master Brick und dem NFC/RFID Bricklet, nicht das es auch mit der Spannungsversorgung zusammenhängt. Du könntest auch überprüfen ob evtl einer der Pinne im Bricklet Stecker (vom Bricklet oder vom Master) krumm ist und dadurch ein Kurzschluss o.ä. entsteht? Ansonsten definiert der NFC Standard eine maximale Reichweite von 10cm. Die Antenne ist dafür ausgelegt diese exakt zu erreichen. Bei unseren Tests mit den Karten und Schlüsselanhängern funktioniert das auch mit 9cm Entfernung noch. Bitte schreibe eine Email mit der Bestellnummer an info@tinkerforge.com falls die beiden Vorschläge oben keine Verbesserung bringen. Wir tauschen das Bricklet dann aus.