Standart PC Software für Mobile Roboter

[MrNiemand]

mehrere Versionen sind eine sehr gute Idee aber zumindest die Grundsoft sollte meiner Meinung nach einheitlich sein, sonst wird es evl. zu verzweigt. Alternative zwei Grundsofts die dann sogut wie gleich sind bis auf die Sprache
@Johannes:kannst ja gerne mal ne grundsoft uppen dann können wir mal vergleichen was bei jdem gut und was schlecht ist!

betreff tcp: ich würde fast vorschlagen das TCP am besten bei Numberfive liegt bisher von den aktiv beteiligten im Thread, denn er hat da ja schon mehr gemacht.
wie wär es wenn ich auf meinem webserver ne db aufmach in der ihr dann eure soft testen könnt? einfach ne tabelle für jeden user oder so?
dann können wir das format der db direkt vergleichen.
oder schlägt jemand auch was anderes als eine sql db vor?

[Johannes]

So, jetzt bin ich wieder auf dem Laufenden. Ich kann euch beiden nur zustimmen. Nur, ich bin mir noch nicht sicher, ob ein Master sinnvoll ist, jedenfalls passt er nicht unbedingt in mein Schema. Denn, wie ich schon geschrieben habe, wäre es theoretisch möglich, dass man bei einer WLan-Verbindung den TCP-Bus direkt an dem Gateway anpackt und nicht über ein Addon. Das würde aber bedeuten, dass nicht mehr klar ist, wo der gemeinsame Master ist.

Also, der Kontrollrechner und der Roboter haben beide ja einen eigenen TCP-Gateway. Wenn jetzt aber die Gateways zusammengelegt werden, was ich befürworte, dann ist ein gemeinsamer Master nicht mehr logisch.

Es sei denn, man unterteilt den Kram in Ebenen. Also, wenn ein Addon des Roboters mit einem des Pc "reden" möchte, ginge die Nachricht erst zum Master des Roboters, dann zum Master des PCs und dann zum anderen Addon. Ist logisch, aber vielleicht kapazitätenfressend. Würde man eine direkte Kommunikation zwischen Addons erlauben, könnte ein Addon des Roboters auch direkt mit dem des PC kommunizieren.

Versteht ihr, was ich meine? Sonst sagt Bescheid und ich probiere es nochmal.

Gruß
Johannes

[Johannes]

So, schon wieder eine neue Nachricht...

@MrN*
>@Johannes:kannst ja gerne mal ne grundsoft uppen dann können wir mal vergleichen was bei jdem gut und was schlecht ist!
Im prinzip ja, aber kann noch dauern, da ich noch etwas Einarbeitungszeit in TCP brauche.

[MrNiemand]

ich versteh es ehrlich gesagt nich (schief zum bier nebenan kuck

[Johannes]

Also, du bist ja gerade online, dann probiere ich es nochmal.

Also es gibt ja zwei Möglichkeiten, entweder können generell Addons untereinander kommunizieren oder immer nur über einen Master. OK?

[MrNiemand]

hast du icq dann können wir des da bereden mei nummer 120040916

[Johannes]

OK, ich schicke dir mal so nen Request...

[NumberFive]

So leute muß erstmal nach lesen was ihr so gepostet habt.

matern du bist leider von dem folgende ein wenig ausgeschloss da ich den mail adresse nicht habe.

So ein Prebeta habt ihr bekommen. nur um einfach zu zeigen das es geht
gleich vorweg es sind nicht alle befehle drin und dir komunikation ist nur zur remote per tcp. Die anderen zwei reden über com mit einander
aber das war auch auf mein bild so.

Der SensorCatch habe ich zu test tool umgebaut Das heist der hat
auch eine eingabe zeile damit man die telegramm rein schreiben kann zu testen des weiteren kann er von der RS232 folgendes lesen
A2byteE wenn er dast verstanden hat schreibt er A255 als byt wert 2xE
zurück also der controller geht eigendlich auch schon dran.

Die RemteControl (RoboClient.Exe) kann zur zeit nur einen befehl schicken
(HOLD) an sonsten zeig die inbisschen was an.

der MessagesCatcher stellt alles zu verfügung. konfiguriert wird alles
per ini dateien die werden bei ersten starten erstellt.

Starten MessageCatcher
SensorCatcher

und wen ihr was sehen wollt Roboclient
wird aber für die funktion nicht benötigt.

Tabellen und so finden ihr in der zeiten mail da ist auch der script drin den er inter pretiern kann.

EDit: damit man es besser lesen kann

[Johannes]

Moin Numberfive,
ich werde mir in der nächsten Woche einen SQL-Server beschaffen, damit ich dein Programm ausführen kann.

Habe gerade deine Mail bekommen und werde jetzt mal durchlesen und antworten.

Gruß
Johannes

[ads]

Anbei nun das programm das interpretiert werden kann:

insert into PrgCode (RunningNumber,Code) values ( 0,'IF SENSOR01 = 01');
insert into PrgCode (RunningNumber,Code) values ( 1,'Trace war gleich');
...

Hallo,

ist diese Methode noch aktuell? Wenn ja, würde mich interessieren, warum du das so umständlich handhabst und jede Zeile einzeln in die Datenbank wirfst.

Zum einen sind Änderungen nur sehr schwer und unübersichtlich zu realisieren (Zeilen löschen, umnumerieren, alle Zeilen anzeigen lassen ect.), Erweiterungen des Programms noch umständlicher einzufügen und zum anderen benötigst du doch sowieso einen Parser, um die Befehle zu erkennen. Warum diesen Parser dann nicht um die Kleinigkeit erweitern, das er freien Text erkennen kann?

Apropos, bei dem von mir gequoteten Beispiel oben, die zweite Zeile ... was soll der Parser damit anfangen? Da steht kein Befehl drin, nur etwas Text, was er wohl ausgeben soll ...

Just my 2 Cent

Andreas