Rnbfra Multi-Thread und Netzwerkfähig mit GUI im www, jetzt

Die Hürde ist genommen, war eine Denkblockade von mir. Der Hinweis Website Speichern hat weitergeholfen.

Netter Gruß

Als Erstes.
@all
Ein schönes neues Jahr für alle.

Als Zweites:
@PicNick:
Ich baue gerade ein Pseudo- Devise zum Loggen übers Netz.
Dabei taucht die Frage auf:
Wie Adressiere ich das?

Ich stelle mir das im Moment so vor:
Wenn z.B. ein Trackbar startet loggt er so lange in die eigene Tasche bis er Netzverbindung hat.
Ab dann loggt er mit Messages zum DEVICELOGG oder wie immer das heißen soll.

1- Wie sieht jetzt die Message aus?
2- Wie weis das DEVICELOGG von wem das kommt?

3- Das DEVICELOGG stelle ich mir als Datenbank vor. Würde das Sinn machen?

Netter Gruß

Prosit !

Ich hab' das bei mir so:
Beim Starten wird sowas wie "PROT-SETUP" aufgerufen,
der sieht im Register nach, ob es im Top-Directory die Parameter PROT_IP = x.x.x.x und PROT_PORT = nn gibt.
dann probiert er in Intervallen (einstellbar ~60 sec) dorthin Verbindung aufzunehmen.
klappt das, schickt er alle Messages, die er bis dahin gesammelt hat dorthin.
klappt das nicht oder waren keine Parameter da, sammelt er die Messages, allerdings maximal (einstellbar ~100) (Ältere haut er weg)
Die "Prot-Send" funktion/sub steht aber immer zur Verfügung, mit und ohne Verbindung
Die Message:
Target (Prot-device-code)
Source (PID, die gibt's immer)
MsgTyp
"DEFINE" ==> Hostname, Processname, etc.
"PROT"
==> StatusCode => facility, code, severity
==> Free Text

facility: das ist das Modul bzw. der Level (als code), der die Message verfaßt
code: Status text (enumerated)
severity 1 SUCCESS 2 WARNING 3 ERROR 4 FATAL

Der Unterschied ERROR/FATAL
ERROR ist ein Fehler, wo aber die Applikation noch sinnvoll weiterarbeiten kann (timeouts, parameterfehler, etc. )
FATAL ist üblicherweise die letzte meldung vor Absturz.

Man kann "Devicelog" für analysen in einer datenbank machen. ABER: Devicelog sollte immer so tief wie möglich im System angelegt sein, damit auch "Database-Corrupt" irgendwo hinheschrieben werden kann.

:-)

Danke für das schnelle Statement.
Das mit der Datenbank lege ich dann erstmal ins Regal für später.
Den Rest werde ich mal in einer einfachen Version angehen.
Was ich mich generell noch frage:

-Loggen die Kleinen eigentlich auch was übers Netz?
Sie plappern einerseits ja eh schon im Netz.

-Soll das Logdevice einen eigenen Log- Port aufmachen und Server spielen?
Ergänzend: Das Logdevice ist in meinen Überlegungen immer ein Eigenständiges Programm. In meinem Fall halt eine Instanz des RnWizard :-)

-Oder soll es Netz-Teilnehmer sein und am RnServer hängen?
Letzteres hatte ich aktuell im Auge.

-Hat das Logdevice eine Adresse im Rn- Adressraum TargetClass, TargetID?
Oder wie wollen wir das laufen lassen damit die Kleinen möglichst von diesen Sachen nicht behelligt werden?

Wir könnten ja für TCP zu TCP TargetClass und TargetID auf Null setzen, eine 1 im Command und die Adressierung folgt dann im Messageteil?


Kannst Du mal als Verständnis- bildende Maßnahme einen Demo String einer Message an das DeviceLog schreiben?
Damit wir Missverständnisse vermeiden was die Art der Adressierung angeht.

Netter Gruß

Datenbank: Ja, erstmal eine normale File erzeugen. Importieren in Excel oder Datenbank können wir immer noch, wenn wir z.B. mein heißgeliebtes CSV-Format verwenden.
Log-Device Stand-alone / embedded Program:
Ich wär für stand-alone bzw. ausprägung des Wizard. Soviel Extrawürste hat der garnicht. Er kriegt über sein Port was rein und schreibt es (vielleicht etwas aufbereitet wegen der Lesbarkeit) in eine File und aus.
Die üblichen Start-Parameter + Log-file / directory

Wenn wir ihn an RN-Server hängen, wärs gut, alle Protokoll-Willigen schicken an eine vereinarte (feste) Target ID. das kann RN-server gut routen, wenn sich das Logdevice also "LOG" + ID anmeldet.
Und auch die µC können da leicht mitspielen, ohne Extras.
Aber dann muß doch ein Absender (SourceID) da sein. Is aber eh' wie gehabt.

Wir brauchen Target- und Source-ID nicht herschenken. Weil sonst müßten wir was ähnliches im Commandteil schreiben, also was solls, doppelt gemoppelt muß nicht sein.

Also: normale TCP Message

Target-ID 3 (= LOG-DEVICE ID)
SOURCE-ID x Absender-ID, auch µC
CMD 1 = command
command-txt STATUS=nn,TEXT="Oh weh, ein TImeout"

Sowas kriegt also das Logdevice uns schreibt einen Record

hh:mm:ss ; Source-ID ; Status ; Text <CRLF>


Antwort gibt's keine, is ja keiner neugierig.

Fein, so machen wir das.

Netter Gruß

Hallo und ein frohes Neues,

ich habe da mal zwei Teile angefangen. Ein Protokolierer (Mysql) und einen Videoserver. Der Protkolierer soll alle telegramme die durch system gerand sind notieren und wieder holbar machen und werte für das netz speichern können. der Video server sendet standbilder im jpg vormat so das man die am Controlplanel anzeigen kann.

Leider finde ich nirgend die genaue beschreibung des TCP Telegrammes damit ich da mit meiner Sofware hin kann. Währe schön es mal zu finden dann würde ich eiventuell noch ein DLL für VB6 machen ohne Net frame work.

Gruß

Hi NumberFive,
Danke, Dir auch so

Ich habe hier mal den Aufruf wie ich ihn verwende.
Dort sind in der Deklaration die Typen mit benannt.
IpRef ist dabei nicht direkter Bestandteil der Message sondern was Programminternes.

Hier die Variante mit Lib:

Deklaration der Libfunktion sieht so aus:
Das ist eine Schreibweise die VB6 auch so haben sollte.

Declare Function RnComMsgSend Lib "rnregist.dll" (ByVal IpRef As Integer, ByVal Tgtcls As Byte, ByVal TgtIdn As Byte, ByVal SrcCls As Byte, ByVal SrcIdn As Byte, ByVal Cmd As Byte, ByVal data As String, ByVal datalen As Integer) As Integer


Der Aufruf in der Sub sieht so aus:

Private Sub blablabla()

Dim res As Integer

res = RnComMsgSend(IpRef, RnMsgTgtClass, RnMsgTgtIdent, RnMsgSrcClass, RnMsgSrcIdent, RnMsgCommand, RnMsgValue, RnMsgValLen)

End Sub

Weitere Docus habe ich unter:
http://www.marvins-lab.roboterbastler.de/
eingestellt.
An meiner Signatur ist am Ende auch der Link dahin.
Dort kannst Du Dir auch den RnWizard runterladen wenn Du sehen willst wie das im Original geschrieben ist.


Protokollierer:
Das ist ja verführerisch den auch zum Loggen zu nehmen. Aber ich werde trotzdem erstmal den einfachen Logger mit Dateiausgabe fertigmachen, so als Minimalaustsattung.
Für den Roboterbetrieb finde ich das super Spannend so ein Protokollierer zu haben.

Ich hoffe, dass ich jetzt das richtige für Dich rausgesucht habe. Ansonsten musst Du noch sagen was Du genau brauchst.

Netter Gruß

@PicNick:
Thema Logdevice:

Ich ringe hier mit einer Schlange.
Die ist aus der Gattung Warteschlange, im Volksmund auch unter Queue bekannt.
Eigentlich läuft das schon ganz gut solange ich den Inhalt der Queue in eine Datei schreibe.
Das sind Strings mit etwa 60 Zeichen, ca. 30 an der Zahl.
Wenn ich das selbe nun über den Server sende behauptet er ab der 17. Message(im Einzelschritt Debug nachgezählt) er hätte 1414483245 Messages übertragen und stirbt.
Da habe ich immer ein bisschen ein schlechtes Gewissen das ich irgendwie nicht nett zu ihm bin. Wo er doch sonst ein Muster an Geduld ist.
Meine Abwägung zwischen selber suchen und Pic fragen ist soeben zu Deinen Ungunsten ausgeschlagen da ich mir jetzt schon redliche Mühe gegeben hatte, würde ich gern mal einen Tipp von Dir haben.

Netter Gruß

Edit:
Hier kannst Du, wenn benötigt, den Übeltäter runterladen:
http://www.marvins-lab.roboterbastle...downloads.html
Er firmiert unter dem Namen Debug.
Man braucht nur den Start Button drücken. Dann verbindet er mit dem Server(127.0.0.1:42). wenn man jetzt noch bei Log ein Häckchen macht beginnt es den Inhalt der Queue zu senden.

Uiui, da mußt du mir helfen.
Ich mußte in den Sourcen die Ip-Adresse Ändern (127.0.0.1 mag meiner nicht, vermutlich wegen mehrere Netz-Karten)
Dann im Debug gestartet, Log angekreuzt und Start gedrückt.
Er mach das Logfenster auf (& schreibt rein), connected sich auch zu rn-server, aber sonst tut sich nix.

rudi ratlos ?