StefanP

Moin Nic,

für Prototypen und Einzelstücke ist das machbar. Da haben wir auch einige Auszubildende oder Praktikanten, die Löten lernen müssen 

Zum Thema EMV:

Wir haben hier in der Firma ein EMV-Labor, da unsere Eigenentwicklungen für den Bereich Bus/Bahn/Luftverkehr alle abgenommen werden müssen.

Da kann man bei Bedarf mal messen...

Masterbrick direkt neben POE Extension mit 1,5cm "Brücke" als Verbindung sollte aber problemlos sein.

Gruß

  Stefan

Hallo,

aus Platzgründen würde ich Masterbrick und POE Extension gerne nebeneinander anstatt übereinander montieren.

Hat das schonmal jemand gemacht?

Gibt es da etwas Fertiges?

Gruß

  Stefan

Hey Nemo,

es müssen mechanische Tasten sein. Touch fällt daher flach.

Meine Alternative wäre - wie Du schon sagst - ein IO Bricklet mit Tastern z.B. von RAFI.

Gruß

  Stefan

Hallo,

ich überlege gerade, für eine Teststellung einen Hardwareprototypen mit TF Komponenten aufzubauen. Das Gerät bekommt acht Tasten, das wären also vier Dual Button Bricklets. Da die Teststellung im Rahmen einer Ausschreibung erfolgt, wird neben den Funktionen auch Optik und Mechanik beurteilt.

Jetzt zur Frage:

Können am Dual Button Bricklet Tastenkappen verbaut werden?

Wenn ja, wo bekomme ich die?

Wenn nein, wie sorge ich dafür, dass der Nutzer "vernünftig" große Tasten vor sich hat?

Gruß

  Stefan

Disconnect->Connect hat nicht funktioniert.

ABER:

Neustart der VM war erfolgreich!!!

Jetzt sehe ich Master Brick und angeschlossene Bricklets im Viewer.

Besten Dank

Der Brick ist im Gerätemanager zu finden.

Allerdings war er als unbekannte Hardware eingetragen (Siehe Brick1.png).

Ich habe dann nach einem Treiber suchen lassen, der wurde auch installiert (Siehe Brick2.png).

Leider "sieht" der Brickviewer den Brick noch immer nicht.

Bin weiter offen für alle Ideen, habe aber parallel noch eine Ethernet Extension im Zulauf, sollte morgen hier ankommen...

Quick Update:

Nach Installation des BrickDaemon 2.0.9 meldet VMware keine Treiberfehler mehr. Das ist aber auch alles - erkannt wird der Master-Brick weiterhin nicht. Wenn ich im BrickViewer auf "Connect" klicke, dann sehe ich keine Geräte. Allerdings bekomme ich auch keine Fehlermeldung, dass der Verbindungsaufbau fehlgeschlagen wäre. Auch nicht nach langem Warten, also auch keine Timeouts.

Hm, es gibt zwar ein paar Einstellungsmöglichkeiten bei VMware's virtuellem USB-Controller, die habe ich jetzt aber alle durch - ohne Erfolg.

Ich glaube, bevor ich noch ewig weitersuche, kaufe ich noch eine Ethernet Extension für mein Testsystem :-)

Das kommt meine Firma billiger als meine Arbeitszeit beim Fehlersuchen und steigert euren Absatz -> Win-Win-Situation

USB-Port ist 2.0

Andere Geräte wie

- USB-Massenspeicher

- USB-Serial Adapter

- USB Soundkarten

- USB-Dongle

usw. funktionieren alle.

Der VMware KB Artikel scheint nicht relevant, da es nur um USB 3.0 geht.

Danke für die doch recht kurze Antwortzeit ;-)

Hallo!

Meine Entwicklungsumgebung läuft in einer virtuellen Maschine, die von VMware Workstation 9.0.2 bereitgestellt wird. Der Host verwendet Windows 7 64bit, in der VM ist Windows XP SP3 installiert.

Sowohl auf dem Host als auch in der VM sind BrickD und BrickV in der jeweils aktuellen Version installiert. Auf dem Host erkennt BrickV sowohl MasterBricks, die per USB angeschlossen sind als auch solche, die per Ethernet Extension verbunden werden. In der virtuellen Maschine kann ich nur die per LAN angeschlossenen MasterBricks sehen.

VMware zeigt bei den verfügbaren USB-Geräten einen "Grautec Master Brick" an. Wenn ich den mit der virtuellen Maschine verbinden will, um ihn innerhalb der VM zu nutzen, dann meldet VMware "The connection for the USB-Device 'Grautec Master Brick' was unsuccessful. Driver Error."

Der BrickViewer meldet nach Klick auf "Connect" nur "Please check host, check port and check if the Brick Daemon is running".

Testweise habe ich schonmal den BrickDaemon auf dem Host deinstalliert, das hat der VM aber nicht geholfen...

Hat schon jemand das Problem gehabt und vielleicht auch gelöst?

Gruß

  Stefan

Das Gute vorweg:

Nachdem nun alle Events nur noch ein PostMessage() zum Mainthread machen, läuft es bislang stabil.

Zum Thema Threadsafety:

Ich kenne es von vielen kommerziellen Bibliotheken, das Komponenten (Klassen) ihre Events in dem Threadkontext generieren, in dem die Klasse per Create() instantiert wurde. Sie übernehmen also intern die Synchronisierung, falls im Hintergrund Workerthreads verwendet werden.

Will sagen: Wenn ich meine Bricklets im Mainthread instantiere, dann werden auch ihre Events im Mainthread generiert.

Stefan

Das mit der Threadsynchronisierung bzgl. VCL ist bekannt - ich mach das schon ein paar Jahre...

Daher die Frage. Dann ist die Sache klar, werde eine thread-sichere Queue einbauen.

Steht dazu irgendwo etwas in der Doku? Habe nix gefunden - lediglich einen Eintrag hier Forum, der aussagt, dass C/C++ Bindings threadsafe sind.

Gruß

  Stefan

Moin!

Siehe Topic. Ich habe das Gefühl, dass einige Events nicht threadsafe sind. Die Applikation hängt, sobald ich innerhalb eines Events (Callback) wie

- TBrickletPtc.OnTemperature

- TBrickletTemperature.OnTemperature

- TBrickletAmbientLight.OnIlluminance

- TBrickletDistanceIr.OnDistance

eine Textzeile zu einem TMemo zufügen will, um den Event zu protokollieren.

Wenn ich das Programm dann im Debugger stoppe, dann bekomme ich als Callstack

> :7c91e460 ntdll.KiUserCallbackDispatcher

  :76af4e31 ; C:\WINDOWS\system32\winmm.dll

  :7c80b729 ; C:\WINDOWS\system32\kernel32.dll

Hier mal ein Beispiel:

procedure TfrmMain.TfOnDistanceIrChanged(Sender: TBrickletDistanceIr;

                                        const Distance: Word);

begin

  // The following (TLabel) seems to work always or almost always

  lblDistanceIrCurrent.Caption := 'Distance: ' + IntToStr(Distance) + ' mm';

  // The following (TMemo) makes the app unresponsive and hang

  aMemo.Lines.Add('Distance: ' + IntToStr(Distance) + ' mm');

end;

Nein, meine 2Y0A02.txt besitzt keine BOM am Anfang. Geht mit 0x23 0x20 los.

Naja, neuer BrickViewer funktioniert, Thema abgeschlossen.

Hm, werde morgen nochmal nachsehen, ob mein Editor (PS-Pad) in der Hex-Ansicht eine BOM "schluckt". Gesehen habe ich dann nämlich keine BOM.

PS: Die Anzeige des "Analog Value" stimmt jetzt auch im Viewer. Well done!

Jawoll!!!

Mit der neuen Version des Brick Viewers funktioniert es!

Habe die Werte mal ausgelesen, entspricht jetzt den von Dir gezeigten Werten.

Was ärgerlich ist: Ich hatte mir die 2Y0A02.txt im Hex-Viewer angesehen, die 0x23 0x20 am Anfang habe ich aber geflissentlich übersehen :-(

Der Download erfolgte übrigens nicht mit dem IE, sondern mit Firefox. Entweder gibt es da dasselbe Problem oder die Datei liegt schon mit BOM auf eurem Server...

Naja, Hauptsache Problem gelöst.

Danke für den Support sagt

  Stefan

Die Dateien hatten CR LF als Zeilenumbruch.

Habe jetzt mal nur CR bzw. nur LF probiert.

Nur CR: Da passiert gar nichts

Nur LF: Verhält sich wie mit CR LF

Windows 7 Pro, habe es auch von einer Windows XP Pro Installation versucht.

Sowohl über USB als auch über Ethernet Extension.

Datei sieht normal aus, siehe unten:

# cm: analog value

150: 518

140: 555

130: 599

120: 647

110: 694

100: 766

95: 790

90: 838

85: 885

80: 930

75: 998

70: 1058

65: 1140

60: 1234

55: 1355

50: 1472

45: 1632

40: 1812

35: 2068

30: 2337

25: 2652

20: 2959

15: 3230

Update:

Habe das Bricklet gerade neu geflasht.

Danach hat es wieder gelebt. Allerdings so, als wenn ein GP2Y0A21 (10cm-80cm) wäre.

Wenn ich dann die vermeintlich korrekte Umrechnung aus 2Y0A02.txt einspiele, dann ist das Problem wieder da. Nur 15cm oder 150cm. Voll digital sozusagen :-(

Da scheint etwas mit der Datei oder der Übertragung nicht zu stimmen.

Was nun?

Danke für die Infos.

Aber irgendwie habe ich dann die Doku falsch verstanden.

Der AnalogValue (der, den ich per API abfragen kann) ist doch ein einheitenloser 12-Bit Wert, der die Entfernung mit höherer Auflösung repräsentiert.

Dagegen sind die Werte in 2Y0A02.txt doch Spannungswerte des Sensors. Steht so zumindest in der Doku als Spannung/Distanz Abbildung.

Anders gesagt: Aus den Spannungswerten werden die AnalogValues (0..4095) UND die Distanz-Werte (20-150cm) berechnet, indem die aus den Stützwerten berechneten Korrekturfaktoren "draufmultipliziert" werden.

Oder nicht?

Stecker und Kabel habe ich optisch geprüft -> OK

Master-Brick und Kabel getauscht -> Gleiche Problematik

Hier eine Übersicht:

Real / angezeigt / AnalogValue

0cm / 150cm / 0

0,5cm-20cm / 15cm / 2-32, anfangs nicht stetig steigend

20cm-150cm / 15cm / 32-5, stetig fallend

Alle Werte "mit der Hand" gemessen, Messwerte stammen von Brick Viewer 2.0.7. Die Tendenz ist aber so und immer eindeutig wiederholbar.

Habe fast das Gefühl, die IR-Diode ist defekt.

Was meinst Du?

Gruß

  Stefan

Hallo!

Habe gerade ein Distance IR Bricklet mit Sharp 2Y0A02 (20-150cm) in Betrieb genommen. Dazu habe ich, wie auf

http://www.tinkerforge.com/de/doc/Hardware/Bricklets/Distance_IR.html#distance-ir-bricklet

beschrieben, die für den Sensor gedachte Datei mit der Spannung<->Distanz Tabelle heruntergeladen und mit dem Brick Viewer auf das Bricklet gesichert.

https://github.com/Tinkerforge/distance-ir-bricklet/raw/master/software/calibration/2Y0A02.txt

Anschließend - wie gefordert - Reset.

Leider bekomme ich nur zwei Werte im Viewer. Entweder 150cm oder 15cm. Die "Analog values" wackeln zwischen 0 und 32. Mehr nicht.

Was habe ich falsch gemacht?

Gruß

  Stefan