könnte man durchaus machen, aber villeicht bin ich ja nur ein Sonderfall, so das der Aufwand nicht lohnt
![Verlegen :oops:](./images/smilies/icon_redface.gif)
Nee, genau dafür haben die Kolegen das ja eingebaut. Nur sollte das dann imho halbwegs selbsterklärend ablaufen. Du hast ja durchaus recht, wenn Dir nicht klar ist, warum diese Frage kommt. Sie soll verhindern, dass irgendjemand fremdes Deinen TXT via Internet kapert solange kein Passwort gesetzt ist. Wenn Du ein Paswort gesetzt hast kann sich niemand fremdes mehr einloggen, also braucht man diese Abfrage auch nicht mehr.DerInder hat geschrieben: könnte man durchaus machen, aber villeicht bin ich ja nur ein Sonderfall, so das der Aufwand nicht lohnt
MasterOfGizmo hat geschrieben:Wie waere es wenn man noch 'never ask again' auswaehlen koennte?
Könnte man als kurzfristigen Workaround machen. Fragt sich nur, ob man das in intuitiv verständlich auf dem zur Verfügung stehenden Platz auf dem TXT-Display unterbekommt.MasterOfGizmo hat geschrieben:Oder einen kleineren Text unten drunter wie 'set a user password to get rid of this request'?
Genauer: Das passiert beim SSH-Login und beim Aufruf von sudo (jeweils egal durch wen), wenn der entsprechende Benutzer (bei SSH der, der sich einloggt, bei sudo derjenige, der es aufruft) kein Passwort gesetzt hat.MasterOfGizmo hat geschrieben:Edit: Das passiert immer beim Login und wenn der FTC-User sudo benutzen will?
Prinzipiell ja (und das wäre auch die schönste Lösung).MasterOfGizmo hat geschrieben:Könnte man dann nicht jeweils auf der Console den Text 'Please acknowledge this operation on your TXTs touchscreen for security reasons. You can set a user password to get rid of this request.' einblenden.
Ich baue Euch mal was, dass ihr da kleinere Schrift für nutzen könnt. Aber irgendwas sollten wir machen, da das wirklich nicht intuitiv ist.richard.kunze hat geschrieben: Könnte man als kurzfristigen Workaround machen. Fragt sich nur, ob man das in intuitiv verständlich auf dem zur Verfügung stehenden Platz auf dem TXT-Display unterbekommt.
Der Launcher versteht nun ein paar Escape-Sequenzen in dem String des Confirmation-Dialog. Zum einen kann man "\n" verwenden, um eine neue Zeile zu beginnen. Und wenn am Anfang einer Zeile "\s" steht wird sie "small" gezeichnet und wenn dort "\t" steht wird sie "tiny" gezeichnet.richard.kunze hat geschrieben: Könnte man als kurzfristigen Workaround machen. Fragt sich nur, ob man das in intuitiv verständlich auf dem zur Verfügung stehenden Platz auf dem TXT-Display unterbekommt.
Code: Alles auswählen
echo "confirm Bitte bestaetigen\n\sKleiner Zusatz\n\tDies ist sehr klein und bricht um, weil es recht lang ist" | nc txt 9000
Wenn das jemand hinbekommt, dann Hut ab...richard.kunze hat geschrieben: Sobald ich damit fertig bin werde ich aber mal versuchen, die Motorplatine direkt (also ohne den aktuellen verwendeten Umweg über die Binaries aus der originalen Firmware) anzusteuern. Falls mir niemand anders dabei zuvorkommt
Vielleicht hab ich mich da missverständlich ausgedrückt: Mit "Motorplatine direkt ansteuern" war gemeint, ftrobopy (oder eigene C-Programme) direkt mit der (Original-)Firmware auf der Motorplatine "reden" zu lassen (über die interne serielle Schnittstelle, über die die beiden "Hälften" des TXT kommunizieren) statt wie bisher den Umweg über "TxtMainControl" aus der originalen Linux-Firmware zu nehmen. Nicht die Firmware der Motorplatine zu ändern (das könnte irgendwann auch mal kommen - aber definitiv später. Viel später).chehr hat geschrieben:Wenn das jemand hinbekommt, dann Hut ab...richard.kunze hat geschrieben: Sobald ich damit fertig bin werde ich aber mal versuchen, die Motorplatine direkt (also ohne den aktuellen verwendeten Umweg über die Binaries aus der originalen Firmware) anzusteuern. Falls mir niemand anders dabei zuvorkommt
Kommt drauf an, was genau Du mit "zugänglich" meinst - die Möglichkeit die Firmware zu ändern oder den Zugang zum Quellcode. Die Firmware flashen geht von der Linux-Seite aus per Software (das hat unter anderem das letzte RoboPro-Update auch gemacht), dazu muss man nicht an der Hardware basteln. Und die Quellen sind zwar nicht öffentlich zugänglich, aber ich und ein paar andere hier haben sie von Fischertechnik bekommen.chehr hat geschrieben:Ist der Programmcode vom ARM Cortex M3 welcher vermutlich die beiden MC33879 mit den H-Brücken ansteuert überhaupt zugänglich oder muß man da ein EPROM o.ä. ändern?
Das werde ich heute abend mal testen. Wenn der Webbrowser geht, dann geht auch der Rest. Mal sehen, wo der Fehler liegt.Andy42 hat geschrieben:Ich habe nach einiger Zeit tatsächlich einen neuen link gefunden, um eine Kommunikation über USB mit ftc-TXT zu ermöglichen:
http://www.java-online.ch/lego/index.ph ... ws.inc.php
Dieses klappte unter Verwendung der Treiber-Version Win7 zusammen mit WinXP. Über einen web browser kann man nun auf den TXT zugreifen. Ein Zugang über ssh (PuTTY oder Cyberduck) klappte allerdings nicht. Aber immerhin.
die nächste ftrobopy Version wird einen "direct"-Modus haben, der die Motorplatine direkt über den internen seriellen Port des TXT ansteuert, ohne den Umweg über die TxtMainControl und die Sockets. Eine reine Python-Lösung habe ich allerdings nicht hinbekommen. Ich musste eine kleine Hilfslibrary in "C" schreiben, die mit "import ftrobopydirect" eingebunden wird und dann die Kommunikation mit der Motorplatine übernimmt. Abhängigkeiten von irgendwelchen Libraries der ft-Originalfirmware gibt es aber nicht mehr.richard.kunze hat geschrieben: Sobald ich damit fertig bin werde ich aber mal versuchen, die Motorplatine direkt (also ohne den aktuellen verwendeten Umweg über die Binaries aus der originalen Firmware) anzusteuern. Falls mir niemand anders dabei zuvorkommt
Das klingt wirklich sehr gut!Torsten hat geschrieben: die nächste ftrobopy Version wird einen "direct"-Modus haben, der die Motorplatine direkt über den internen seriellen Port des TXT ansteuert
Gehört das wirklich in ftrobopy? Für das alles gibt es ja bereits Standard-Python-Bindings. Und nichts davon läuft über den Motorcontroller. Selbst für den Sound ist der Moiorcontroller ja nicht mehr als ein DA-Wamdler und die Kommunikation läuft über einen separaten SPI-Kanal. In Kamera und I2C ist der Motorcontroller gar nicht involviert. Die Signale laufen zwar teilweise über die Motorplatine, kommen aber nicht beim Motorcontroller an.Torsten hat geschrieben: I2C, Camera und Sound sind noch nicht verfügbar
Das Programm gibt (wie die meisten anderen auch) Debug-Informationen auf der Konsole aus. Das ist ganz knapp auch im Wiki beschrieben unter:Hompi hat geschrieben: Hat jemand eine Idee wo der Fehler liegen könnte?