FlyingDoc

Hallo TF Team. Seit ich meinen neuen Schlepptopf habe, macht der Brick Deamon beim Systemstart Probleme. Oder bessr gesagt eins. Er kann keine Verbindung zum Brick herstellen. Das funktioniert erst wenn ich den Dienst stoppe und neu starte. Dann ist alles wie gewohnt. Hab euch mal aus der Windows Eventlist den entsprechenden Eintrag angehangen. Could not read from USB ready pipe: WSAECONNRESET (71010054) Könnte auch noch dazu gehören. Durch die Berechtigungseinstellungen für "Anwendungsspezifisch" wird dem Benutzer "NT-AUTORITÄT\SYSTEM" (SID: S-1-5-18) unter der Adresse "LocalHost (unter Verwendung von LRPC)" keine Berechtigung vom Typ "Lokal Aktivierung" für die COM-Serveranwendung mit der CLSID {8D8F4F83-3594-4F07-8369-FC3C3CAE4919} und der APPID {F72671A9-012C-4725-9D2F-2A4D32D65169} im Anwendungscontainer "Nicht verfügbar" (SID: Nicht verfügbar) gewährt. Die Sicherheitsberechtigung kann mit dem Verwaltungstool für Komponentendienste geändert werden.

Den Brick Deamon baruchst du nur wenn du USB benutzt. Er ist sozusagen die Brücke zwischen USB und Netzwerk. Er setzt die USB Verbindung auf TCP Netzwerkverbindung um. Du musst statt "localhost" nur die IP Adresse deines Stacks angeben. Diese musst du vorher auf dem Stack konfigurieren. Dann klappt die Verbindung wie gewohnt.

Du kannst auch beruhigt mehrere Master in einem Stapel betreiben. Du musst dann nur den USB des untersten Masters im Stapel benutzen. Alles andere wie gehabt ganz normal.

Gugsd du ==>hier !!!

Lade sie einfach in dein Quellcodeverzeichnisses deones Programmes auf dem RED mit hoch. Dann wird er sie finden.

Um dein Programm auf dem RED laufen zu lassen musst du es auch auf dem RED compilieren. Auf dem RED läuft kein Windows sonder ein Linux. Genau gesagt Debian Linux. Du musst dein Programmprojekt im BrickViewer auf den RED hochladen und dann compilieren. Siehe hier.

Ich habe ganz einfach alle Dateiendungen ".c" der Includes einfach in ".cpp" umbenannt. Schon wird alles aktzeptiert.

Ich würde den RED Brick nehmen. Ist zwar teurer als der RP, sitzt aber direkt im Stapel. Ist ja auch ein vollständiger Linux Rechner mit Debian. Die Daten kannst du ja auf der SD Karte speichern. Das Programm dazu kannst du auf dem RED laufen lassen.

Ich programmiere meine Programme unter Windows im QT und teste sie auch da. Dieses gibt es auch unter Linux. Ist also eine Multiplattform die es auf beiden Systemen gibt. Meine Programme lade ich dann mir dem Brickviewer hoch und compiliere sie direkt auf dem RED-Brick. Ich benutze bei beiden den selben Compiler. So sehe ich beim Compilieren auch gleich wenn Fehler auftauchen. Als Compiler verwendet QT den MinGW. Diesen gibt es sowohl für Windows als auch für Linux. Zu deiner ersten Frage. Der Rotary gibt Impulse aus je nach Drehrichtung. 24 für eine volle Umdrehung. Diese kann man zählen. Das übernimmt der Masterbrick der den Zählerstand dann als Callback an dein Programm weitergibt. Du musst also nur den Counter beim Start auf 0 setzen und dann mit Callback auslesen. Der Rotary schafft aber nur 250 Schritte/sek. Da wird die Sprungantwort deines Servos aber warscheinlich höher liegen.

Schreib doch mal den Aufbau deines TF Stacks. Benutzt du einen RED oder nur einen Master?

Hallo photron, gibt es inzwischen neue Erkentnisse beim RS232 Fehlverhalten? Im Moment setze ich den Master zurück wenn mein Programm feststellt das die Kommunikation nur noch Müll zustande bringt.

Die grafische Darstellung im BrickViewer ist gemeint.

Ich meinte das man dann die vorhanden Achse (20 sek?) in der Darstellung strecken kann und hin und her scrollen kann. Dann könnte man eventuell mehr Feinheiten erkennen, wie einzelne Impulse die sonst untergehen in der Darstellung.

So. Heute mal das Thinkerforge Team auf der CeBit etwas genervt. Haben sich trotzdem Zeit genommen und sind freundlich geblieben. Haben da ja ihr ganzes Sortiment ausgestellt und ein paar Beispiele. Was mir noch eingefallen ist wegen dem Grafikplot. Wenn der Plot angehalten ist wäre vielleicht noch eine Spreizung der X-Achse über Button interessant inclusive Scrollbalken.

Da müsste ich erst schnell ein Progrämchen schreiben. Aber das Programm das auf dem Rechner läuft und gesteuert wird, Antwortet auf die Steuerbefehle wenn diese richtig sind. Die Kommunikation ist also in beide Richtungen. Und da wo es im Einsatz ist, wird es 24h am Tag benutzt.

Das sind ja mal gute Neuigkeiten. Wie setzt ihr den Brick zurück?

Wo testest du. Im Haus oder außerhalb? Geh vieleicht mal an Fenster. Ich selber hab eine externe Antenne angeschlossen. Im Haus ist halt schlecht. Im Auto kein Problem.

Hallo TF Team. Ich schlage am Dienstag bei euch auf. Aber erst so kurz nach dem Mittag. Hab ne lange Anreise. Freu mich schon euch mal persönlich zu treffen. Wer von eurem Team ist denn da? P.S. Wenn es klappt komm ich geflogen. Muss dann nur schnell vom Flughafen zur CeBit und zurück kommen.

Für Adminrechte musst du dich als root einlogen. Einfach in der Console sudo s eintragen. Dann wirst du nach dem Passwort gefragt. Eingeben und fertig. Beim Passwort kann ich dir jetzt aber nicht helfen. Das steht irgendwo auf der Raspberry Pi Seite zum Img dazu.

Als Programmiersprache würde ich dir Python vorschlsgen. Aber warum nimmst du nicht den RED Brick dtatt den RP? Ist zwar teurer aber dafür direkt im Stapel integriert und hat alles schon installiert was du brauchst.

Heute wieder festgestellt das die RS232 nur Müll sendet. Der RED lief ohne Neustart ein paar Tage. Programmneustart hat nichts gebracht. Erst nach dem Neustart des RED Brick konnte ich wieder über die Schnittstelle ordentlich Daten schicken.

Einstellungen der RS232. 9600,Even,1,8,HFC unf SFC auf off Der Fehler tritt sowohl bei einer OnBoard Com Schnittstelle (Com1) als auch mit einer USB Com Schnittstelle auf. Die Kabellänge ist egal. Mein Testkabel ist gerade mal knapp 2m.

Nein kann ich nicht. Es kann sowohl schon beim Programmstart als auch irgendwann mitten im Betrieb passieren. Die Anwendung ist dafür ausgelegt 24h am Tag/ 365 Tage im Jahr zu laufen.

Am Müll den er sendet. Hab auf der Gegenstelle mit einem Terminalprogramm geprüft. Da ich genau weiss was ich sende weiss ich ja auch was ankommen müsste.

Ich hake mich hier mal mit ein. Bei mir tritt das Problem der defekten Daten ebenfalls auf. ABer nicht immer. Die Schnittstelle wird zur Komunikation mit einem PC-Programm genutzt. So wie ich es bis jetzt mitbekommen habe kommt es ab und zu dazu, das die Schnittstelle nicht mit den korrekten Einstellungen arbeitet obwohl diese beim Auslesen korrekt sind. Wenn ich dann das Programm noch einmal neu starte funtioniert dann alles korrekt. Hab es getestet in dem ich an der Gegenstelle ein Terminalprogramm hab laufen lassen und geschaut hab was empfangen wird. Es scheint mir fast ein API Problem zu sein. Ich nutze die C++ API da mein Programm in C++ geschrieben wird und auf dem RED läuft. Tante Edit sagt: Es ist auch aufgetreten das die Einstellung mitten drin weg sind. Also wärend des Betriebes.