Jump to content

CChris

Members
  • Content Count

    109
  • Joined

  • Last visited

Community Reputation

0 Neutral
  1. Hallo Zusammen, ich habe gerade noch einmal ein paar Tests gemacht, und möchte hier kurz die Ergebnisse ausführen... vielleicht sollte in den Dokumentationen erwähnt werden, welche Kombinationen NICHT möglich sind, bzw. dass zwingend eine bestimmte Reihenfolge der Extensions eingehalten werden sollte. Testaufbau: 1x MasterBrick 2.1 FW: 2.4.7 1x Ethernet w/o PoE 1.0 1x Wifi 1.0 1x Wifi 2.0 1x Chibi ---- TestRun 1 ---- 1) Ethernet 1.0 (w/o PoE) + MasterBrick oben drauf: Sowohl MasterBrick, wie MasterExtension werden erkannt 2) Wifi 1.0 + MasterBrick oben drauf: Es wird NUR der MasterBrick erkannt, die MasterExtension jedoch nicht 3) Wifi 2.0 + MasterBrick oben drauf: Es wird NUR der MasterBrick erkannt, die MasterExtension jedoch nicht 4) Chibi + MasterBrick oben drauf: Es wird NUR der MasterBrick erkannt, die MasterExtension jedoch nicht ------------------- ---- TestRun 2 ---- 1) MasterBrick + Ethernet 1.0 (w/o PoE) oben drauf: Sowohl MasterBrick, wie auch MasterExtension werden erkannt 2) MasterBrick + Wifi 1.0 oben drauf: Sowohl MasterBrick, wie auch MasterExtension werden erkannt 3) MasterBrick + Wifi 2.0 oben drauf: Sowohl MasterBrick, wie auch MasterExtension werden erkannt 4) MasterBrick + Chibi oben drauf: Sowohl MasterBrick, wie auch MasterExtension werden erkannt ------------------- ---- TestRun 3 : Combination of different MasterExtensions ---- 1) MasterBrick + Ethernet 1.0 (w/o PoE) + Wifi 1.0 Nur MasterBrick wird Erkannt MasterBrick startet immer wieder neu 2)MasterBrick + Ethernet 1.0 (w/o PoE) + Wifi 2.0 keines der Geräte wird erkannt MasterBrick startet immer wieder neu 3) MasterBrick + Ethernet 1.0 (w/o PoE) + Chibi Alle drei Geräte werden korrekt erkannt MasterBrick startet immer wieder neu 4) MasterBrick + Wifi 1.0 + Chibi Alle drei Geräte werden korrekt erkannt Kein Reboot des MasterBricks zu erkennen 5) MasterBrick + Wifi 2.0 + Chibi keines der Geräte wird erkannt MasterBrick startet immer wieder neu --------- Vielleicht / Hoffentlich sind diese Infos hilfreich - zum einen um ggf. die FW Versionen weiter zu optimieren - oder aber in den Dokumentationen auf mögliche inkompatibilitäten untereinander hin zu weisen. Mir ist klar, dass einige (die meisten) der hier getesteten Kombinationen vermutlich wenig Sinn im Einsatz ergeben werden - dennoch sollte der Master z.B. nicht einfach neu starten - oder mal die eine oder gar keine Extension, oder schlicht selber nicht mehr im BrickV auftauchen Egal, wie "unverständlich" die Kundenkonfiguration zu diesem Zeitpunkt vielleicht sein mag :) Grüße, Chris
  2. Hi Zusammen, ich wollte mal nachfragen, ob es auch für bereits ab gekündigte Master-Extensions noch Korrekturen in der Firmware geben wird, oder eher nicht mehr... Bzw. gibt es irgendwo eine Liste, welche Extensions miteinander kombinierbar sind und welche nicht, bzw. wie viele Extensions genau in einem Stapel eingesetzt werden können? Zu meiner Situation: Ich habe jetzt insgesamt: 2x Master Brick 1.0 2x Master Brick 2.0 1x Master Brick 2.1 1x WiFi Extension 2.0 1x WiFi Extension 1.0 2x Chibi Extension 1x Ethernet w/o PoE Alle Bricks und co. sind auf dem aktuellen Firmwarestand. Master Brick + WiFi 2.0 + Chibi -> führt zu einem regelmäßigen Neustart des Stapels, es kann keine Verbindung zum Stapel aufgebaut werden. Ziel wäre es hierbei jetzt gewesen, per WLan eine Verbindung zum Stapel 1 herzustellen, und dieser wiederum per Chibi (Master) zu einem weiteren Stapel mit Chibi (Slave) zu verbinden. Somit könnte man zwei Stapel voneinander Getrennt wie einen stapel behandeln, die Kommunikation zwischen PC und Stapel 1 wäre dann aber ebenfalls noch Kabellos möglich. Dies kann mit dem WiFi 2.0 wenn ich es in der Dokumentation jetzt richtig gesehen habe nur via MESH Netzwerk realisiert werden, richtig? Gruß, Chris folgendes Verhalten ist mir aufgefallen:
  3. Pixel 2 von Google... sollte, wenn ich mich nicht täusche über NFC verfügen... stimmt, habe auch schon daran Gedacht, das mit dem Smartphone zu testen... nur habe ich eher weniger Aussichten darauf, dass das erfolgreich sein könnte. Aber ja, werde es mal versuchen (btw.: habe die Karte auch hier in der Firma mal vor ein Lesegerät gehalten - wurde auch nicht erkannt ... somit sinkt die Wahrscheinlichkeit, dass die Karte i.O. sein wird nochmals.)
  4. Hi Zusammen Ich habe hier kürzlich ein Paket mit älterer TF Hardware erstanden - darunter war auch ein NFC / RFID Bricklet enthalten, sowie eine Keyring Chip und eine MiFare Classic Karte. Den KeyRing Chip erkennt das Modul ohne Probleme, die MiFare Karte jedoch nicht. Testweise habe ich dann mal versucht, meine Kreditkarte, sowie meine Bankkarte zu lesen (beide bieten Sie Kontaktloses Bezahlen) - und hier wird auf jeden Fall etwas gelesen. Ich denke daher mal, dass die Karte Ihren Geist aufgegeben haben wird - aber gibt es ggf. noch eine Möglichkeit, das SICHER fest zu stellen? Gruß, Christoph
  5. Danke - auch für den Ausschnitt aus dem IPConnection! Werde mir deine Vorschläge - und auch die anderen Callbacks mal genauer anschauen... Wie gesagt, werde es mal probieren, mit dem BeginInvoke() ...
  6. Hallo Zusammen, aktuell schafft es mein Programm, darauf zu reagieren, wenn an einem MasterBrick a) der USB Stecker gezogen wird und b) der Release-Knopf gedrückt wird. In diesem Fall wird mir meine Liste mit verbinundenen Bricks durch eine erneute Enumerierung neu aufgebaut. Allerdings würde ich ganz gerne eine Ausgabe schaffen, die dem Benutzer mitteilt, warum sich die Software quasi "neu" mit dem Stapel verbunden hat. In den Events ConnectedCB und DisconnectedCB habe ich folgende Ausgaben aus der Doku übernommen: //============================================================================================================= // Callback handles reconnection of IP Connection private void ConnectedCB(IPConnection sender, short connectReason) { switch (connectReason) { case IPConnection.CONNECT_REASON_REQUEST: MessageBox.Show("Connected by request"); break; case IPConnection.CONNECT_REASON_AUTO_RECONNECT: MessageBox.Show("Auto-Reconnected"); break; } try { ipcon.Enumerate(); } catch (Exception ex) { d_Logger.CreateLogFile(ex.Message, "[8]"); } } //============================================================================================================= // Callback handles disconnections of IP Connection private void DisconnectedCB(IPConnection sender, short disconnectReason) { switch (disconnectReason) { case IPConnection.DISCONNECT_REASON_REQUEST: conn_status = false; MessageBox.Show("Disconnected by request"); break; case IPConnection.DISCONNECT_REASON_ERROR: MessageBox.Show("Disconnected by error"); break; case IPConnection.DISCONNECT_REASON_SHUTDOWN: MessageBox.Show("Disconnected by shutdown"); break; } if (conn_status == true) { try { ipcon.Enumerate(); } catch (Exception ex) { d_Logger.CreateLogFile(ex.Message, "[8]"); } } } Diese funktionieren auch wunderbar, wenn ich die Verbindung via ButtonClick aufbaue und trenne, oder wenn ich z.B. den BrickDeamon Dienst neu starte... Aber gibt es auch eine Möglichkeit, zu ermitteln, wenn z.B. das USB Kabel gezogen wurde, oder der Release Knopf gedrückt wurde? Wie könnte ich am besten auf solche Ereignisse reagieren und zurück geben?
  7. Hi, Danke nochmal für deinen Vorschlag. Leider steht "Dispatcher" nicht zur Auswahl für das ListView Element zur Verfügung. Das "invoke" dient schon dem Thread-Übergreifenden Zugriff auf das Steuerelement ListView. Sonst hätte er hier direkt eine Exception geworfen.
  8. OK. Ich habe jetzt nochmal in die Debug-Ausgabe von Visual Studio geschaut. Folgende Exceptions werden ausgegeben, sobald ipcon.Disconnect() aufgerufen wird... Allerdings habe ich mein Ziel nun auf anderem Wege erreicht - und ich glaube, dieser ist sogar die bessere Wahl Danke jedenfalls für deinen Input... vielleicht ist diese Info aber dennoch relevant und hilfreich für jmd. anderen ? --- Da in der zwischenzeit noch die Antwort von Marvin dazu kam, werde ich den Vorschlag noch aus testen, um zu sehen, ob es daran lag oder nicht Vielen Dank auch hier
  9. das ist es ja... im Visual Studio habe ich nichts wirklich erkennen können... werde das aber heute Abend / morgen Früh noch einmal versuchen. In den Tinkerforge Bindings ist ja ein mdb file für debug meldungen mit vorhanden... aber ehrlich gesagt, weiß ich nicht, wie ich damit umgehen sollte um ggf. die Bindings mit zu debuggen. Das Verhalten ist aber definitiv reproduzierbar, sobald der Code im DisconnectCB aufgerufen wird... Könnte es an den bindings liegen? Wie kann ich diese ggf. mit ins debug bekommen? (direkt die CS files einbinden?)
  10. sieht danach aus... an seinem Namen hängt ein seltsam wirkender Link...
  11. einen direkten Download-Link finde ich prinzipiell auch nicht schlecht. BrickV kann ja ermitteln, dass eine neue Datei vorhanden ist - und aus dieser Info ließe sich, bei entsprechender Dateiablage, auch direkt ein Link generieren. Andere Software schafft dies ja auch - und mit den FW Images für die Bricklets klappt das im Grunde ebenfalls. btw.: wie könnte man eine solche Info denn in seinem eigenen Programm mit einbinden? Also wie ist die URL um die aktuelle FW Version eines Bricklets bei Euch abzurufen? Ich möchte in meiner Anwendung quasi ein paar der Infos aus BrickV versuchen nach zu bauen... so z.B. eben auch, wenn für ein Bricklet eine neue FW Version verfügbar ist. (Ob ich dann auch versuche, das Downloaden und Flashen um zu setzen steht jetzt mal auf einem anderen Blatt Papier)
  12. hm... das ist ja mein Original-Beitrag hier 1:1 rein kopiert?? o.O Aber danke, dadurch habe ich die Lösung für das gleiche Problem nach langer abwesenheit direkt wieder gefunden Und ab jetzt schreib ich mir das irgendwo auf...
  13. hm... Ich hab zwar aktuell auch nur wenig Zeit... und weiß noch nicht wirklich, was ich mit all den Modulen anfangen sollte... aber ich glaube, ich greife hier mal zu... sind auf jeden Fall einige Interessante Dinge dabei und mit dem Rest wird mir vielleicht auch noch etwas einfallen ^^ PayPal akzeptiert?
  14. Hallo Zusammen, ich habe aktuell leider ein kleines Problem mit meinem Source-Code und weiß ehrlich gesagt nicht, wo ich mit dem Debuggen ansetzen soll :-( Vielleicht kann mir ja einer von Euch hier weiter helfen? Problembeschreibung: Ich fülle im EnumerationCallback eine ListView mit den angeschlossenen Bricks. Wenn ich nun die Verbindung trenne, dann soll diese Liste abgelöscht / geleert werden. Dies funktioniert auch - wenn ich den Aufruf listView1.Items.Clear() direkt in der TFConnect Methode aufrufe (diese wird im Eventhandler Button_Click aufgerufen Und es funktioniert auch, wenn ich die Liste im ConnectCallback leere. Sobald ich den Aufruf aber im DisconnectCallback durchführe, egal an welcher Stelle, hängt sich das Programm auf und reagiert nicht mehr. Nachfolgender Code wird nicht mehr ausgeführt. Alles, was vor dem Aufruf von listView1.Items.Clear() im DisconnectCallback passiert (was derzeit noch nicht viel ist) funktioniert ohne Probleme. Der Code läuft auch nicht in eine Exception hinein... //============================================================================= private TFConnect(string ConnectionCommand, string ConnectionString) { string[] connections; connections = ConnectionString.Split(':'); string HOST = connections[0]; int PORT = Convert.ToInt16(connections[1]); switch (ConnectionCommand) { case "connect": try { if (ipcon.GetConnectionState() != IPConnection.CONNECTION_STATE_CONNECTED) { ipcon.Connect(HOST, PORT); // TinkerForge IPConnection.Connect d_Logger.CreateLogFile("Connected to TinkerForge @ " + comboBox1.Text, "[3]"); // write LogOutput "Connected" } } catch (Exception ex) { d_Logger.CreateLogFile(ex.Message, "[8]"); } break; case "disconnect": try { if (ipcon.GetConnectionState() == IPConnection.CONNECTION_STATE_CONNECTED) { ipcon.Disconnect(); // TinkerForge IPConnection.Disconnect try { listView1.Invoke(new Action(() => listView1.Items.Clear())); // An dieser Stelle leert das Programm auch wie gewünscht die Liste ab... } catch (Exception ex) { MessageBox.Show(ex.Message); } d_Logger.CreateLogFile("Disconnected from TinkerForge", "[3]"); } } catch (Exception ex) { d_Logger.CreateLogFile(ex.Message, "[8]"); } break; } } //============================================================================= // Callback handles reconnection of IP Connection private void ConnectedCB(IPConnection sender, short connectReason) { switch (connectReason) { case IPConnection.CONNECT_REASON_REQUEST: MessageBox.Show("Connected by request"); break; case IPConnection.CONNECT_REASON_AUTO_RECONNECT: MessageBox.Show("Auto-Reconnected"); break; } try { listView1.Invoke(new Action(() => listView1.Items.Clear())); // Auch an dieser Stelle wird die ListView wie gewünscht abgelöscht } catch (Exception ex) { MessageBox.Show(ex.Message); } ipcon.Enumerate(); } //============================================================================= private void DisconnectedCB(IPConnection sender, short disconnectReason) { switch (disconnectReason) { case IPConnection.DISCONNECT_REASON_REQUEST: MessageBox.Show("Disconnected by request"); break; case IPConnection.DISCONNECT_REASON_ERROR: MessageBox.Show("Disconnected by error"); break; case IPConnection.DISCONNECT_REASON_SHUTDOWN: MessageBox.Show("Disconnected by shutdown"); break; } try { listView1.Invoke(new Action(() => listView1.Items.Clear())); // sobald die listView1.Items.Clear() aber im DisconnectedCallback Event aufgerufen wird, hängt sich das Programm auf und reagiert nicht mehr. // Es wird auch keine Exception aufgeworfen. // Auch, wenn ich hier eine neue Methode aufrufe, in welcher dann die ListView abgelöscht werden soll, zeigt sich das gleiche Verhalten. // Code direkt vor dem Aufruf von listView1.Items.Clear() wird hier auch noch ausgeführt. (Testweise war eine MsgBox ausgabe enthalten. } catch (Exception ex) { MessageBox.Show(ex.Message); } } //============================================================================= private void EnumerateCB(IPConnection sender, string UID, string connectedUID, char position, short[] hardwareVersion, short[] firmwareVersion, int deviceIdentifier, short enumerationType) { if (enumerationType == IPConnection.ENUMERATION_TYPE_CONNECTED || enumerationType == IPConnection.ENUMERATION_TYPE_AVAILABLE) { //Baue ListenItems auf string[] myItems = new string[6]; myItems[0] = deviceIdentifier.ToString(); myItems[1] = UID; myItems[2] = connectedUID; myItems[3] = position.ToString().ToUpper(); myItems[4] = firmwareVersion[0] + "." + firmwareVersion[1] + "." + firmwareVersion[2]; myItems[5] = hardwareVersion[0] + "." + hardwareVersion[1] + "." + hardwareVersion[2]; // Neues ListView Item initiieren ListViewItem LVItem = new ListViewItem(myItems); try { listView1.Invoke(new Action(() => listView1.Items.Add(LVItem))); } catch (Exception exceptionMsg) { MessageBox.Show(exceptionMsg.Message, "Fehler!", MessageBoxButtons.AbortRetryIgnore, MessageBoxIcon.Error); } } }
  15. Hallo Zusammen, ich bin gerade wieder ein bisschen am herum Programmieren und dabei ist mir aufgefallen, dass ein MasterBrick ggf. keinen Wert für GetConnectionType zurück gibt. Mein Stack (von unten nach oben): 1. RedBrick 2. MasterBrick Hw-Rev. 2.1 (UID = 6wwS7d) 3. MasterBrick Hw-Rev. 2.0 (UID = 6m9VR4) Verbindung des RedBrick via USB: Verbindung 1. Brick im Stapel (Redbrick) per USB: --> beide nachfolgende MasterBricks liefern für GetConnectionType 2 (SPI Stack) zurück Verbindung 2. MasterBrick (1. MasterBrick im Stack, HW-Rev. 2.1) per USB: --> ich bekomme nur für diesen überhaupt einen Wert von GetConnectionType zurück. Im BrickViewer wird mir der zweite auf diesem MasterBrick aufgesteckte MasterBrick (Hw-Rev 2.0) nicht angezeigt. Verbindung 3. MasterBrick (2. MasterBrick im Stack, HW-Rev. 2.0) per USB: --> LEDs gehen an, wird aber im BrickViewer nicht erkannt Tausche ich jedoch die Reihenfolge der MasterBricks im Stapel, also: 1. RedBrick 2. MasterBrick Hw-Rev. 2.0 3. MasterBrick Hw-Rev. 2.1 und wiederhole den oben stehenden Versuch (ohne den RedBrick), komme ich zu folgendem Ergebnis: Verbindung 2. MasterBrick (1. MasterBrick im Stack, HW-Rev. 2.1) per USB: --> MasterBrick 1: USB --> MasterBrick 2: Stack --> Beide MasterBricks werden mir in BrickViewer angezeigt Verbindung 3. MasterBrick (2. MasterBrick im Stack, HW-Rev. 2.0) per USB: --> LEDs gehen an, wird aber im BrickViewer nicht erkannt Ich habe die Dokumentation jetzt gerade nicht parat, aber ist es "gewollt" oder Technisch bedingt der Fall, dass in der Reihenfolge 2.1 -> 2.0 nur der unterste Brick erkannt wird (wenn die Initialisierung nicht über einen RedBrick erfolgt) ? Ich glaube eher weniger... oder?
×
×
  • Create New...