fischertechnik community forum

Hallo zusammen,

nach vielen Jahren habe ich meine Fischertechnik-Box wieder geöffnet und dort u.a. zwei von den alten Intelligent Interfaces gefunden, sowie eine CD mit LLWin 2.1.

Ich kann das Interface im Active Mode auch erfolgreich programmieren, indem ich ein in DosBox installiertes Windows 3.1 benutze und einen USB-Seriell-Adapter.

Das ist zwar schön, aber die Bedienung von LLWin 2.1 in der DosBox nervt. Also habe ich mir gedacht, ich nehme das Protokoll und das Dateiformat auseinander und baue die Programmierung des Active Modes in Python nach. Bis jetzt läuft es noch nicht, aber ich glaube, dass da nicht mehr viel fehlt. - Beim Auseinanderpflücken habe ich die Namen von ein paar Bausteinen in dem Interface gefunden, die zumindest von LLWin 2.1 anscheinend nicht benutzt werden. Dem Namen nach geht es um Arithmetik, sprich die vier Grundrechenarten und ein Bitshift. Wie man diese Bausteine genau anspricht, bzw. ob diese Bausteine überhaupt voll funktionsfähig sind, ist mir derzeit noch nicht klar.

Was mich interessieren würde:

• Ich ,meine, ich habe irgendwo gelesen, dass LLWin 3.0 mehr Funktionen mitbringt als LLWin 2.1. Ich habe es nie besessen. Ist dem so und wenn ja, was sind das für Funktionen?
• Angenommen, ich mache weitere Fortschritte und schaffe es, bspw. in Python den Active Mode nutzbar zu machen. Könnte ich das überhaupt der Community zugänglich machen (sodenn überhaupt noch Interesse an diesen alten Dingen besteht)? Ich bin kein Jurist, aber es könnte vermutlich Lizenzrechtlich schwierig sein? So wie ich das sehe, sind Fischertechnik und iCon-L zumindest damals nicht dagegen vorgegangen, als der Passive Mode die Python-Unterstützung bekommen hat - aber die Interna, die ich in meiner Analyse offengelegt habe und benutze, sind beim Active Mode doch noch einmal ein paar mehr.

Hallo...
Wenn nicht schon bekannt...
Schau mal auf: https://www.ftcommunity.de/ftComputingF ... hdlls.html

BTW iCon-L (Original) unterstütze in deren Versionen noch eine Zeit lang das ft-Interface weiter. Schon lustig, wenn man eine Software hat, die ein Kraftwerk steuern kann und dann ein ft-Interface damit betreibt.

Ich gebe zu, ich habe zwar das Interface, aber ich glaube ich habe seit 10 Jahren damit nichts mehr gemacht.
Mit freundlichen Grüßen
Holger

Hallo Holger,

danke für deine Antwort. Ja, ich habe FischFace schon gesehen, aber ehrlich gesagt noch nicht ausporbiert. So wie ich das verstehe, kann damit "nur der Passive Mode verwendet werden, was besonders bei den Modellen aus dem Baukasten Mobile Robots sehr schade ist.

Dass LLWin und iCon-L sich so wenig unterscheiden, war mir damals gar nicht bewusst. Das ist toll, wie nah die Fischertechnik-Modelle damals an echten industriellen Anlagen angelehnt waren.

Viele Grüße
Matthias

Meine bisherigen Erkenntnisse, was beim Klicken auf "Active Mode" in LLWin 2.1 geschieht:

1. Zunächst wird eine Datei TMP.Q erzeugt, die das graphische Programm in einer Art Assembler-Sprache enthält. Es ist eine Textdatei die prinzipiell menschenlesbar ist, aber es hat mich viel Zeit gekostet, das Format einigermaßen zu verstehen.
2. Dann wird vom Interface das Speicherlayout abgefragt und in einer Datei TMP.ATT gespeichert. Da das Speicherlayout für die Übersetzung der TMP.Q-Datei benutzt wird, findet man hier alle internen Funktionsbausteine des Interfaces mit deren Namen sowie die Namen der Eingänge, Ausgänge, Variablen, Nachrichten, usw.
3. Die Speicheradressen aus der TMP.ATT-Datei werden benutzt, um das Programm zu bauen. Dies wird in der Datei TMP.MVL abgelegt. Zudem wird ein Error-Log in die Datei TMP.ERR geschrieben.
4. Gab es einen Fehler, wird dieser als Meldung ausgegeben. Andernfalls wird das Programm aus der .MVL-Datei über die serielle Schnittstelle an das Interface übertragen
5. Die TMP-Dateien werden gelöscht.

Der Trick, um das alles zu verstehen, war es einerseits, die Kommunikation am Serial-Port mitzulesen, indem ich 3 USB-Serial-Adapter verwendet habe. COM0 ist in der DosBox angeschlossen, der Adapter ist hardwaretechnisch einfach mit COM1 zusammengesteckt. Auf COM1 lese ich mit Python alles mit und schreibe es nach COM2. COM2 steckt dann am eigentlichen Interface. Und andererseits kopiere ich die TMP-Dateien aus dem TMP-Verzeichnis von LLWin heraus, bevor sie gelöscht werden.


Ich bin nach einigem Probieren jetzt so weit, dass ich mich prinzipiell in der Lage fühle, diese TMP.Q-Dateien manuell zu erstellen für ein von mir angedachtes Programm. Alles danach (Download der ATT-Datei, Auflösen der Adressen und Übertrag zum Interface) habe ich bereits mit Python automatisiert. Es scheint soweit zu funktionieren, aber ich habe noch keine komplexen Programme geschrieben. Dazu möchte ich erst die Erstellung der TMP.Q-Dateien mit Python vereinfachen.

Folgende Bausteine habe ich in der TMP.ATT-Datei gefunden. Das fand ich sehr interessant, weil dort u.a. anscheinend die vier Grundrechenarten definiert werden, die zumindest LLWin2.1 nicht kann. Und ich fand interessant, dass Bausteine, die auf dem Interface im Active Mode nicht funktionieren, dort trotzdem abgebildet sind, wie z.B. DISPLAY, MELDUNG und BEEP.

• ABS - wird zur Ablaufsteuerung verwendet, um die Transitionen ("Pfeile") aus LLWin abzubilden. Der Baustein ENDE wird dabei implizit mitabgebildet.
• APR8
• JPZ
• NOP
• BEG - steht einmal am Anfang der Q-Datei und definiert insb. die Zykluszeit. Dies ist NICHT der START-Baustein.
• END - steht einmal am Ende der Q-Datei und scheint das Gegenstück von BEG zu sein. Dies ist NICHT der ENDE-Baustein.
• Init
• VRZF - Bildet den Baustein POSITION ab
• SMOT - Bildet die Bausteine MOTOR und LAMPE ab.
• SVAR - Bildet die Bausteine VARIABLE und DISPLAY ab.
• IVAR - Bildet die Bausteine INCVARIABLE und DECVARIABLE ab.
• CMW - Bildet den Baustein VERGLEICH ab.
• EVF - Bildet den Baustein WARTE ab.
• T2D - Bildet den Baustein MELDUNG ab.
• Inif - Bildet den Baustein START ab.
• Not - Bildet den Baustein EINGANG ab.
• FD10 - Bildet den Baustein FLANKE ab.
• ABB - Bildet die Bausteine NOTAUS und RESET ab.
• ADDW
• SUBW
• DIVW
• MULW
• SCHW
• AND
• OR
• CMPW
• FD01
• FFR
• FFS
• BGW
• AWW
• ABW
• AWB
• TON - Bildet den Baustein BEEP ab.

Das TERMINAL wird dadurch abgebildet, indem die bei Programmerstellung eingestellten Werte als Konstante in den Speicher geschrieben werden.

Die Befehle, bei denen keine Anmerkung dahinter steht, scheinen in der Q-Datei nicht direkt genutzt zu werden.

Unterprogramme werden nicht durch Bausteine abgebildet. Bei der Programmerstellung wird ihr Inhalt einfach an alle Stellen kopiert, an denen sie aufgerufen werden.

Hallo...
OK, ich habe Jahrelang das Inteligent-Interface unterschätzt. Im Grunde, war klar, das da irgendein Interpreter drinn sein sollte, um den Offlinemodus ablaufen zu lassen. Bislang habe ich mir keine weiteren Gedanken darum gemacht.
Scheint aber weiter zu gehen als gedacht...
Das dürfte aber viel Arbeit sein, dass alles mitzuscheiden.
Hut ab.
Mit freundlichen Grüßen
Holger

Guten Abend Matthias,

malacoda hat geschrieben: ↑

26 Sep 2024, 12:45

So wie ich das verstehe, kann damit "nur der Passive Mode verwendet werden, was besonders bei den Modellen aus dem Baukasten Mobile Robots sehr schade ist.

sofern Deine Software die Funktionalität sowohl als Interface als auch als Controller wiederherstellt, erhöht das den Wert der alten Geräte wieder.

Allerdings habe ich mein Geld lieber in die modernen Controller gesteckt, weil die etwas mehr können, obwohl deren Firmware es nach der in https://tarma.com/embedded/txt4book von David Adams durchgeführten Analyse mit der Qualität nicht gerade übertreibt.

Mit freundlichen Grüßen
Lars

thkais hatte mal einen "memorizer" entwickelt, der playback von Programmen in das II macht. Vielleicht kann man davon auch was lernen:

https://web.archive.org/web/20100228080 ... orizer.htm

Hier findet ihr den aktuellen Stand der Entwicklung: https://github.com/esoteric-programmer/FTI

Derzeit habe ich noch Probleme mit dem Warte-Baustein. Außerdem ist noch nicht alles vollumfänglich getestet.

[Edit] Der Warte-Baustein sollte jetzt funktionieren.