Kommunikation TXT zu TXT

[Pinot]

Hallo Bjoern,

ich habe alleine vier Bewegungsachsen (ohne "Zulieferinfrastruktur"). Eine der Bewegungsachsen (Hub der Last) wird ueber drei Motore angetrieben. Alle drei Motor haben individuelle Steuerungen. Also bin ich schon bei sechs Motoren. Wie gesagt, ohne Zuliefersysteme. Die vier Bewegungsachsen haben gegenseitige Restriktionen, die waehrend des Betriebs abgeprueft werden muessen. Sprich: da sammelt sich schnell was an. Dazu kommen verschiedene, Timer und gesteuerte Lichtsysteme.

Und das scheint, zumeinem grossen Erstaunen, das Gesamtsystem schon an den Rand seiner Faehigkeiten zu bringen. Evtl. verursacht die IR-Steuerung eine Menge Overhead. Mit einer "kabelgebundenen" Steuerung hab ich's noch nicht probiert, da die doch recht aufwaendig werden wuerde.

Wenn man natuerlich einzelnen Controllern, egal of TXT oder ftduino, dedizierte Tasks geben koennte, waere das riesig. Aber ich schaetze das geht dann nur mittels Python et al, aber keinesfalls mit RoboPro. So wie ich meine momentane Implementierung jetzt verstehe laeuft der Code auf dem Laptop und die beiden TXTs sind lediglich Ein- und Ausgabe-Geraete, rechnen selbst aber nichts.

Unterm Strich wuerde ich sagen, dass ein antiker 8032 mit der Steuerungsaufgabe voellig unterlastet waere. Das momentane Gesamtkonstrukt ist zwar mit RoboPro hoechst elegant zu programmierun und einzurichten. In der Summe aber eben von suboptimaler Effizienz. Die im anderen Thread beschriebene Absolutwertbildung bringt die Steuerung schon zum Zusammenbrechen. Da hab ich jetzt erstmal kraeftig abgespeckt, damit die vier Achsen wieder geschmeidig reagieren und ich meine Mechanik auskonstruieren kann. Und dann sehen wir weiter ...

Gruesse, Thomas

[Bjoern]

Hallo Thomas,

du scheinst dir eben ein wenig auf die Fahrne geschrieben zu haben, also für ein normales "Spielzeug" angedacht ist.
Aber liegt in so einer Sache nicht die Herausforderung? Das Salz in der Suppe?
08/15 kann jeder aber das hier ist dann schon eine andere Nummer.

Es kann natürlich sein das du mit RoboPro ans Ende kommst. Die SW empfinde ich als leistungsfähig, aber eben auch limitiert.
Du arbeitest da vermutlich schon mit verschiedenen Threads.

Wenn es so nicht klappt, wäre doch eine Option eine Unteraufgabe an einen externen Controller abzugeben.
Das kann ja durchaus ein ftDuino sein. Die Übergabe könntest du noch per RoboPro machen, da du den ftDuino so einbindest. Du müsstest dann nur das Sketch entsprechend erweitern und dann dort die weitere Auswertung machen. Wäre dann kein Phyton sondern Arduino C++. Vielleicht ein Ansatz.

Oder du kannst einen Teil deiner notwendigen Funktionalität auf TXT1 laufen lassen und einen Teil auf TXT2.
Ok, die müsstest du natürlich wieder syncrhonisieren, aber auch dafür findet sich bestimmt etwas.

Die Simulationsmodelle von ft nutzen ja auch mehrere TXT. So ein Setup ist ja schon eine schöne Designübung.

Und mal ehrlich, wer so ein Riesenmodell hat, der kann auch nicht erwarten das die Ansteuerung Kindergeburtstag ist

Und spätestens an der Stelle gibt es doch immer einen User mit folgendem Hinweis: Das schreit doch geradezu nach einem ft:pedia Artikel

Björn

[Pinot]

Hallo Bjoern,

danke fuer Deine Einschaetzung! Dann liegt's wohl doch nicht an meinen (mangelnden) RoboPro-Kuensten.

"Du arbeitest da vermutlich schon mit verschiedenen Threads." -> klar doch

"Oder du kannst einen Teil deiner notwendigen Funktionalität auf TXT1 laufen lassen und einen Teil auf TXT2." -> kann man das in RoboPro realisieren? Die Threads sind/werden recht segmentiert sein und teilweise keine Synchronisation benoetigen.

"Die Simulationsmodelle von ft nutzen ja auch mehrere TXT. So ein Setup ist ja schon eine schöne Designübung." -> hattest Du dafuer mal nen Link, wo man sich das anschauen kann?

"Das schreit doch geradezu nach einem ft:pedia Artikel" -> schon in Arbeit, aber fuer ein rein elektrotechnisches Thema, was natuerlich auch mit dem Kran zu tun: wie verhelfen ich den kraftlosen TXT-Ausgaengen zu Schmackes

Gruesse, Thomas

[sven]

Hallo!

RoboPro kann doch mehrere Tasks und es ist auch möglich alle an USB angeschlossenen Interfaces einzeln anzusprechen.
6 und mehr Motoren sind doch für RoboPro kein Problem.

Gruß
sven

[MasterOfGizmo]

RoboPro kann doch mehrere Tasks und es ist auch möglich alle an USB angeschlossenen Interfaces einzeln anzusprechen.

Das geht aber nur online. Es scheint, als würde er seine Anlage aber vor allem gerne ganz autonom laufen lassen, nur über die IR-Fernbedienung kontrolliert. Da kommt er nicht weiter, denn ohne PC kann er nicht mehrere Controller über USB ein gemeinsames RoboPro-Programm ausführen lassen.

Und ja, natürlich kann er später Dinge auf die ftDuinos auslagern. Gerade so einfache Dinge wie "fahre die Motoren so und so und melde wenn's fertig ist". Die TXT's werden dann sehr entlastet. Aber dazu muss er die ftDuinos in C/C++ programmieren. Wenn er das vermeiden will ist er auf die bestehenden I2C-Sachen für die ftDuinos beschränkt und die wesentliche Intelligenz bleibt in seinen TXTs.

[Bjoern]

Hallo Thomas,

du siehst hier entseht eine rege Diskussion. Gut so!

"Oder du kannst einen Teil deiner notwendigen Funktionalität auf TXT1 laufen lassen und einen Teil auf TXT2." -> kann man das in RoboPro realisieren? Die Threads sind/werden recht segmentiert sein und teilweise keine Synchronisation benoetigen.

Das war so gemeint das du für jeden TXT ein eigenes RoboPro Programm hast. Damit reduzierst du die Last im Optimalfall um 50%. Durch Synchronisationsthemen natürlich weniger. Aber wenn du schon 2 hast und jeder etwas autark machen könnte...

Link für eine Designübung habe ich erst mal keine. Wie bist du bisher vorgegangen?
Hast du dir schon mal top down Gedanken gemacht?

Anderer Ansatz wäre eben auch dir die Funktionsblöcke mit den Abhängigkeiten aufzuzeichnen. Dann schauen ob du Teilbereiche separieren kannst und ob diese dann auch autark funktionieren können. Oder welchen Datenfluß du dort noch hast.
Ist ja nachher nichts anderes als dein komplexes Problem zu zerlegen und somit die Komplexität zu reduzieren.
So kommst du langsam aber sicher zu einem System Design.

Könntest du dich denn mit C/C++ auf den ftDuinos anfreunden?

Du musst dich am Ende entscheiden wo läuft die Intelligenz. Nur auf dem TXT oder wie oben noch mal ergänzend beschrieben auf den beiden oder kannst du dir weiter auslagern auf die ftDuinos. Das ist natürlich auch eine Design Entscheidung.Oder auch wie wichtig ist dir RoboPro.

Irgendwie scheint mir das ein sehr gutes Beispiel für die geplanten ftSwarm von Stefan zu sein. Denn da finden sich einfach mehrere Einzelsystem zu einem Schwarm zusammen und kommunizieren untereinander. Damit würdest du dein Problem mit Sicherheit viel einfacher lösen können.

Wie gesagt erzeuge doch einfach mal eine Übersicht was du alles an Aktoren so brauchst und poste die ruhig hier. Kannst mir auch ne PM schreiben.
Dann gemeinsamen Nachdenken und im Endeffekt ist es evtl. ein System Design in großer Runde erstellen. Aus dieser Problemstellung können sicherlich viele am Ende etwas mitnehmen. Auch wenn es nur ein Teil davon ist.
Auch das SW Design deines Projektes ist mehr als tauglich für die ft:pedia. Du hattest glaube ich mal bis zu 20 Ausgänge geschrieben. Da wärest du durchaus am Ende bei 5 Controllern. So viele Projekte in der Größenordnung hatten wir hier noch nicht.

Björn

[Bjoern]

Hallo Thomas,

eines hatte ich noch vergessen. Wären Schrittmotoren evtl. eine ALternative gewesen?
Die haben mehr Power und du könntest die Intelligenz für deren Ansteuerung z.B. auf den ftPwrDrive auslagern. Das ginge auch über RoboPro.
Da sagst du dann nur noch fahre so viele Schritte und gut ist es. Den Rest macht deren Firmware.

Du siehst es mag noch mehr Optionen geben....
Ist wie mit dem Weg nach Rom, da gibt es ja auch nicht nur einen

Björn

[fishfriend]

Hallo...
OK, es ist noch etwas früh heute Morgen, aber so ganz verstehe ich das Problem noch nicht ganz.
Kannst du mal Grob das Modell beschreiben, was du bauen möchtest?
Ich sag mal auch 20 Motoren zu steuern, ist jetzt nicht sooo ganz das Problem.

Es gibt auch noch andere Ansätze wie Endabschaltung über Dioden... So hat man keine Zeitbeschränkung.

Worüber man auch mal nachdenken sollte, wo man welche an I2C einsetzen kann. Ob nun ein, zwei... ftduinos und/oder UNOs mit Motorshield 2.3 mit Schrittmotor, normalen Motor..., Servotreiber mit Servos...

Dann noch ein Masterprogramm mit Notaus und viele Teilprogramme.
Wenn der selbe Ablauf da ist ob man dann über einen PC mit CSV-Datei es evtl. einfacher ablaufen lassen kann.
und und und...
Mit freundlichen Grüßen
fishfriend
Holger Howey

[Pinot]

Hallo Holger und Bjoern,

ich versuch mal Euren Input zusammenzufassen. Also Schrittmotore sind keine Option fuer nen Kran. Koennte man sich vielleicht bei der Laufkatze vorstellen, ist aber ein wenig von hinten durch die Brust in's Auge. Also bleib ich bei meinen XS-Mots, die sich an einer Zahnstange entlanghangeln. Und natuerlich sind Endschalter mittels der bekannten Diodenschaltung realisiert.

IMG_5083 (002).jpg (134.85 KiB) 4537 mal betrachtet

Allerdings haette ich gerne noch eine Rueckmeldung aller Schalter fuer ein Statuspanel. Dazu braeuchte es dann doch wieder Abfragen, die gegen die Performance gehen ...

Aber Ihr bringt mich auf eine coole Idee ... Ich koennte getrennte RoboPro-Programme fuer den TXT1 und den TXT2 erstellen, die getrennt auf die beiden Controller runterladen und die Controller ueber eine parallele oder serielle Verbindung synchronisieren. Die Verbindung koennte ich ueber zwei PCF8574 implementieren, wovon jeder einem TXT zugeordnet ist. Das Ganze liese sich sogar auf n TXTs/ftduinos erweitern im Sinne einer Daisy-Chain.

Frage: gibt's irgendwo ne Implementierungsidee fuer ein serielles Protokoll, das man per Bitbanging in einem TXT implementiert? Das faende ich originell

Viele Gruesse

Thomas

PS: den Satz "Wenn der selbe Ablauf da ist ob man dann über einen PC mit CSV-Datei es evtl. einfacher ablaufen lassen kann." hab ich auch nach ausreichendem Genuss bewusstseinserweitender Drogen, die meinem Nickname gerecht werden, nicht verstanden ...

[fishfriend]

Hallo...
Ist immer eine Frage wieviel der User kann und kennt.
OK, du hast schon Ahnung vom Programmieren.

Wenn man einen sagen wir mal automatischen Ablauf haben möchte, bietet es sich an dieses Ablaufprogramm in eine CVS-Datei auszulagern. Das ist eine normale Textdatei, die man auch von Excel machen kann. Wenn man was ändern möchte, kann man "einfach" den Wert oder eine Null durch eine Eins ändern. OK man muss natürlich die Daten einlesen und verarbeiten. Die CVS kann aber nur online eingelesen werden und nicht als Download auf den TXT gespeichert werden. Es ist die Frage was Vorteilahfter ist oder wie groß das alles wird.

Man kann fertige Kommunikation nehmen, würd ich aber hier nicht machen. Es wohl einfacher z.B. über BT Daten von TXT zu TXT zu übertragen und dann auszuwerten. Man kann auch Variablen setzen und als Flags nutzen. So etwas wie "A" wird dann VAR-A auf 1.

Wenn du aber einen Verschiebebahnhof mit Sortierung von Wagons mit Signalen machen möchtest - dann kann es schnell zur Lebensaufgabe werden - das zu programmieren.

Von den Bildern her ist es aber noch recht Übersichtlich. Ich würde mich erstmal durch die RoboPro Hilfe zu BT arbeiten. Ich denke da wird vieles klarer wie das gehen kann. Wenn so verschiedene Roboter miteinander sprechen können sollte es für dein Projekt auch gehen.
Mit freundlichen Grüßen
fishfriend
Holger Howey

[Bjoern]

Hallo Thomas,

Aber Ihr bringt mich auf eine coole Idee ... Ich koennte getrennte RoboPro-Programme fuer den TXT1 und den TXT2 erstellen, die getrennt auf die beiden Controller runterladen und die Controller ueber eine parallele oder serielle Verbindung synchronisieren

Ich merke du hast mich nie richtig verstanden. genau das hatte ich dir doch vorgeschlagen....

Wie man die synchronisiert ist eine andere Sache. Da stellt sich ja auch erst mal die Frage ob du die überhaupt syncen musst. Deswegen erst mal überlegen was du auf die beiden TXT legen könntest. Und jeder von denen bekommt dann evtl. noch Support von einem ftDuino.

Deswegen hatte ich ja mal geschrieben das du 2 RoboPro Programme brauchst.

Björn

[jodeka]

Hallo:

ad) Frage: gibt's irgendwo ne Implementierungsidee fuer ein serielles Protokoll, das man per Bitbanging in einem TXT implementiert? Das faende ich originell.

Das Protokoll für eine asynchrone serielle UART nachzubilden ist nicht gerade einfach.

Aber es gibt einen Schnittstellenbaustein für solche Probleme:
SC16S750 (I2C auf UART)

Du sprichst den Chip über I2C die Register an und er verwaltet Dir eine UART-Verbindung.
Der Chip hat auch einen Empfangs- und Sendepuffer, sodass die Gefahr nicht besteht, dass
Daten verloren gehen.

Den Chip auf einem Modul gibt es bei banggood, Ebay, usw. zu kaufen. (einfach danach googeln)

Ich habe sehr gute Erfahrungen damit gemacht.

Du kannst auch einen Arduino (auch ftduino) oder teensy verwenden, um selbst einen solchen "Umsetzer"
selber zu programmieren. Die I2C-Slave Libraries dazu funktionieren sehr gut.
Für Phyton habe ich noch keine Erfahrung gemacht. (bei Adafruit habe ich schon i2c-slave unter core gefunden)

LG DJ

[Pinot]

"über BT Daten von TXT zu TXT" ... ahh, das hatte ich noch gar nicht auf dem Zettel. I.d.T. kann das eine elegante Loesung sein. "SC16S750 (I2C auf UART)" ... es wird immer besser. "Da stellt sich ja auch erst mal die Frage ob du die überhaupt syncen musst." ... i.d.T. ist "synchronisieren" zu hoch gegriffen, da muessen keine Statemachines synchron gehalten werden. Eine paar Statusbits und Semaphoren sollten ausreichen. Ich glaub ich geh jetzt mal wieder in's Studierzimmer um mich auf den Denkstein zu begeben. Lauter coole Ideen von Euch

@Bjoern: "Ich merke du hast mich nie richtig verstanden.". Auweia, den Spruch kenn ich eigentlich nur aus meiner Jugend ... vom anderen Geschlecht. Da gab es doch hin und wieder Inkompatibilitaeten mit dem Kerl, der am liebsten sein Hameg mit in's Bett genommen haette. Zusammen mit der selbstgeschnitzten C64-Porterweiterung zur AD-Wandlung . Scheinbar entwickle ich mich wieder zurueck ... aber meine Frau hat's wohl noch nicht gemerkt

[Bjoern]

Hallo Thomas,

C64 hatte ich in der Jugend auch. Mir scheint wir liegen im ähnlichen Alter.

Und du hast jetzt massig Input für dein Vergnügen auf dem Denkstein...
Wenn du nicht viele Inputs hast, dann reicht vielleicht auch ein Port zum syncen aus. Da du natürlich auch einen Ausgang brauchst, würde das wieder deine Ausgänge reduzieren.
Also vielleicht doch eher I2C oder BT. Oder aber du erkennst das du keine Semaphore brauchst. Wer weiß...
Bitbanging ist ja auch ok, aber dann stellt sich die Frage ob die Geschwindigkeit überhaupt ausreicht.

Du hast auf jeden Fall ein schönes Projekt mit ein paar Herausforderungen. Das sind die Dinger, die mir dann immer Spaß machen. Alles andere ist ja keine wirkliche Herausforderung

Björn

[fishfriend]

Hallo...
Der große Vorteil bei BT ist, dass man keinen Ausgang opfern muss. Somit hast du einen M mehr.
Momentan würde ich z.B. 8 Variablen für Augänge und 8 für Eingänge nehmen. Die werden auf den anderen TXT übertragen. Da ist die Zuweisung genau andersrum. Übertragen werden z.B. 16 Bit. Es ist auch die Frage was man braucht/will. Im Grunde brauchst du bei deinem Modell nur 1 und 0.
"Synchron" ist eh nur relativ.
Mit freundlichen Grüßen
fishfriend
Holger Howey