OSCAT Forum
network.lib => Codesys 2 => Thema gestartet von: MKr am 27. Oktober 2011, 16:32:48
-
Liebe Leute,
Nachdem die OSCAT-Basis-Bibliothek auf unseren Eckelmann-SPSen problemlos läuft, versuche ich nun,
auch die Netzwerk-Bibliothek zum Laufen zu kriegen.
Die dafür nötige Sockets-Bibliothek ist vorhanden; sie entspricht lt. Hersteller dem, was bei CoDeSys da
üblich ist; lediglich könne es in Einzelfällen vorkommen, dass ein Return-Wert oder ein Parameter-Wert
anders ist als 'erwartet', da 3S das hin und wieder offen ließe.
Die nötige Datei-Bibliothek ist nicht vorhanden; der Hersteller hat da etwas eigenes, ähnliches implementiert.
Ich habe eine 'Zwischenschicht' erstellt, die die Aufrufe so umsetzt, dass nun trotzdem alles da ist. Ich kann
allerdings die Hand nicht dafür in's Feuer legen, dass auch genau das passiert, was die
OSCAT-Netzwerk-Bibliothek erwartet.
(Allerdings glaube ich nicht, dass die Anpassungsschwierigkeiten im Bereich der notwendigen Datei-
Bibliotheken mit meinem momentanen Problem zu tun haben, aber ich kann mich auch täuschen...)
Problem ist: Welche Funktion aus dem Bereich "Netzwerk" ich auch laufen lasse (IP2GEO, GET_WAN_IP,
SNTP_CLIENT, YAHOO_WEATHER...) es passiert stets folgendes: Unmittelbar nach der FALSE-->TRUE-
Flanke am Eingang "Activate" geht "Busy" auf TRUE und bleibt dann ewig so. Da passiert dann nüscht mehr.
Gäbe es irgend eine Art von Fehlermeldung, wüsste ich vielleicht, wonach ich schauen müsste, aber so ist
es etwas schwierig.
Weiß jemand, woran das liegen könnte? Was sollte ich als nächstes tun, um den Fehler einzukreisen?
Vielen Dank schon mal im Voraus,
MKr
-
hallo
tja, wenn das alles so einfach wäre....
wenn du schon eine "kompatibilitätslayer" machst, musst du aber auch sicherstellen das einzelfunktionen sich 1:1 verhalten
deine fehlermeldung ist leider sehr unpräzise...
wir verwenden ein paar wichtige basisfunktionen der syslibsockt.lib
wenn du nun eine adaption erstellt hast, dann musst du aber auch alle einzeln testen...
das ist eine sehr aufwändige und schwierige arbeit
da ich ganau sowas in der network.lib für pcworx,codesys und beckhoff gemacht habe...kenne ich die problematik nur zu gut
aber ohne deine lösung gesehen zu haben, bzw. ohne einer realen hardware zum testen .... sehe ich wenig chancen das dir hier jemand anderer helfen kann...
du müsstest mal die basisfunktionen des baustein ip_control mal einzeln durchtesten, so hat das eher was mit glückspiel zu tun.
arbeiten deine routinen im synchron oder asynchron modus ?
stelle mal deine adaption online ... ist sehe es mir gerne an.... vielleicht ist es nur ein kleines problem...
aber wirklich testen werde ich es ohne der hardware nicht können .
aber schauen wir mal...
-
Vielen Dank für die sehr schnelle Reaktion!
Was meinen "Kompatibilitätslayer" angeht, hätte ich mich präziser ausdrücken müssen. Hier nochmal kurz und knapp:
Die „SysLibSockets.lib“ ist vorhanden und soll lt. Hersteller auch funktionieren. Da war ich gar nicht bei.
Die „SysLibFile.lib“ ist nicht vorhanden; hier musste ich um etwas ähnliches, was der Hersteller bereitstellt,
den "Kompatibilitätslayer" bauen, damit es überhaupt kompiliert. Mehr soll dieser Layer momentan auch
gar nicht für mich tun. Zwar glaube ich, dass damit eine Datei geöffnet, gelesen und geschlossen werden
kann, aber ich habe es bislang nicht probiert und bin auch selber skeptisch.
Nur: Bei meinem momentanen Problemchen sollte es ja wohl eigentlich keine Rolle spielen, was mit
Dateizugriffen los ist; hier geht es dann ja wohl ausschließlich um die „SysLibSockets.lib“. Und da, wie
gesagt, war ich ja gar nicht bei.
Viele Grüße
MKr
-
die von dir genannten bausteine benutzen ja nicht einmal das dateisystem
du hast zwar die syslibsockets.lib , aber trotzdem klappt es anscheinend überhaupt nicht
du müsstest mal einen der bausteine im debug modus tracen, damit wir hinweise bekommen was das passiert
z.b. baustein sntp_client ,mal aktivieren und dann eine bildschirmhardcopy der lokalen var machen
und auch von der ip_control instanz
wenn die ewig laufen, dann kann z.b. schon reichen wenn die umschaltung auf non-block modus nicht funktioniert
aber da gibt es ohne detailinfos einfach zuviele möglichkeiten .....
-
Ja genau, davon ging ich ja auch aus.
Nee, klappt nicht, genau.
Sobald ich wieder Zugriff auf die betroffene Hardware habe, werde ich so einen Screenshot mal machen!
Dauert leider noch ein paar Tage, so lange ist erst mal Ruhe.
Vielen Dank schon mal!
MKr
-
So, da bin ich wieder. Anbei der Screenshot. Wie gesagt: keinerlei Bewegung, alles tot, was da zu sehen ist; einzig in der von mir markierten Zeile wird die Zahl hochgezählt (anscheinend in ms).
Bin halt ratlos, was hilft's.
[gelöscht durch Administrator]
-
stelle man dein kleines testprojekt online, wo nur der teil mit der ethernet kommunikation drinnen ist !
-
OK, kleiner ging's nicht.
[gelöscht durch Administrator]
-
hallo
das bei deinem programm überhaupt nichts passiert hat einen gewichtigen grund
das herzstück fehlt nähmlich
alle bausteine die eine IP_C Datenstruktur als parameter haben, benötigen einen nachgeschaltenen
IP_CONTROL baustein
dieser baustein kapselt den hardware/plattformspezifischen zugriff auf die ressource
der vorteil von dieser lösung ist, das sich mehrere bausteine eine ressource teilen können
der nachteil ist, das es viele nicht verstehen
die ip-adresse beim ip_control ist die des verwendeten dns-servers
das kann eine internet-adresse sein ,aber auch der eigenen router (wenn er dns-server funktionalität hat)
wenn du aber mit fixer ip-adresse den sntp_client betreibst, dann ist die dns_ip nicht relevant
wichtig ist auch noch das du eine korrekte gatway-adresse in deinen sps-netzwerk-einstellungen vorgegeben hast, wenn teilnehmer ausserhalb des lokalen netzwerks liegen.
-------------
in der network.lib im baustein-ordner "demo" findest du unter anderen das beispiel "DNS_SNTP_SYSLOG_DEMO"
wo mehrer funktionalitäten mit immer dergleichen ressource realisiert werden.
im anhang ist das exemplarisch ergänze beispiel-programm
[gelöscht durch Administrator]
-
Also erstmal eines vorweg:
Bei manch einem kommerziellen Produkt würde ich mir wünschen, dass die Unterstützung auch nur halb so gut wäre wie hier. Vielen Dank dafür!
Das Konzept mit dem "nachgeschalteten IP_CONTROL-Baustein" war überhaupt noch nicht in mein Bewusstsein gedrungen. Ich muss auch zugeben: Ich habe die zugehörige Doku einmal kurz Quergelesen (da kam (mir) das irgendwie nicht vor...) und die Beispiele hatte ich mir noch gar nicht gegönnt.
Mit dieser Info bewaffnet wird es nun sicher besser gehen. Habe jetzt erstmal wieder ein paar Tage Pause, danach probiere ich es und melde mich wieder.
Danke nochmals und einen schönen Abend!
-
n'abend!
Ich habe Zugriff auf eine aehnliche PLC wie MKr und beobachte das gleiche Phaenomen:
Es passiert einfach nichts auf der Netzwerk-Leitung, wenn ich das ueberarbeitete Beispiel von peewit benutze!
Die SysLibSockets.lib, die mitgeliefert wurde, ist SEHR alt (05.08.2002) und ich bin gar nicht sicher, ob auf den
Controllern aus dem Hause ueberhaupt Netzwerkdienste ausser "Netzwerkvariablen" unterstuetzt werden.
(in der LIB fehlen z.B. auch Angaben zu SOCKET_FD_SETSIZE und MAX_SOCKET_FD_SETSIZE, die ich in den
globalen Variablen einfuegen musste)
In dem Beispielprogramm bleibt der Ablauf innerhalb von SNTP_CLIENT im CASE-Schritt 30 haengen:
In IP_C.ERROR steht konstant eine 0 (erste IF-Abfrage, um den Schritt 30 zu verlassen),
S_BUF.SIZE wird nicht geringer und R_BUF.SIZE bleibt bestaendig auf 0 (ELSIF um Schritt 30
verlassen zu koennen)!
Kann ich irgendwie herausfinden, ob diese Steuerungen ueberhaupt fuer Netzwerkdienste zu
gebrauchen sind? Mich wuerden naemlich Modbus/TCP-Funktionen interessieren...
-
hallo
zuerst wäre es nicht schlecht das jeder mal für seine sps klärt (notfalls beim hersteller) ob die syslibsocket.lib überhaupt
vorhanden ist bzw was funktionieren sollte und was nicht.
die syslibsocket.lib sollte auf allen plattformen wo sie auch vorhanden ist, ziemlich die gleichen ergebnisse liefern !
wenn die offiziell dabei ist, und du sie nicht einfach von wo anders genommen hast, sollte dies auch so sein
wenn sntp_client im schritt 30 ohne fehlermeldung stehen bleibt, so ist das meistens ein zeichen
das die ip_c datenstruktur nicht mit einer IP_CONTROL instanz verbunden ist !
bei user "MKr" war dies ja auch so
notfalls stelle doch bitte dein projekt online, und ich schaue nach
bzw. mache einen bildschirmhardcopy von den ganzen lokalen und instanz variablen
-
Hallo peewit!
Ich habe dein Beispiel aus diesem Thread (Antwort #8) genommen
und mit minimalistischen Mitteln zum kompilieren gebracht. (vgl.
Screenshot im Anhang) Es sollte nichts fehlen, da es ohne Fehler
und Warnungen kompiliert!
SNTP_CLIENT bleibt im CASE-Schritt 30 ohne Fehlermeldung stehen,
obwohl die ip_c Datenstruktur mit einer IP_CONTROL Instanz
verbunden ist! (siehe Screenshot)
Im Anhang habe ich zusaetzlich die Bausteine, Datenstrukturen und
globalen Variablen der mitgelieferten SysLibSockets.lib als Bilder
bzw. Text-Datei angefuegt.
Es bleibt immer noch die Frage, ob ich irgendwie herausfinden kann,
ob und wenn ja welche Netzwerkfunktionen unterstuetzt werden. Die
Doku vom Hersteller laesst hier leider sehr zu wuenschen uebrig!
@MKr:
Wie weit bist Du mit Deinen Tests?
Vielleicht bringen die ein wenig Licht in die Dunkelheit...
[gelöscht durch Administrator]
-
hallo
das ist schon nicht schlecht , aber zuwenig
nur im ersten bild sind brauchbare informartionen enthalten ,aber das ist zu wenig
ich brauche mindestens noch die zustände von der datenstruktur IP_C und von der Bausteininstanz IP_CONTROL
deine sps:
gib es denn für deine sps keine einzige bibliothek oder beispielprogramm das mit ethernet arbeitet ?
der hersteller/lieferant muss doch wissen , ob das geht oder nicht
-
Hallo peewit!
Die heutigen Screenshots zeigen die Zustaende des IP_CONTROL,
der ja auch die Datenstruktur IP_C beinhaltet. Die beiden Arrays
IP_C.FIFO.X und IP_C.FIFO.Y habe ich nicht extra aufgeklappt, da hier
jeweils nur der erste Eintrag mit "1" belegt ist - sonst alles "0".
IP_C.MAILBOX ist komplett mit "0" beschrieben, in S_BUF steht die
SIZE auf 16#30 und der erste Eintrag ist 16#1B, R_BUF ist wiederum
komplett mit "0" gefuellt.
Die Doku zur Steuerung beschreibt an genau einer Stelle die
Verwendung der SysLibSockets.lib: Beim Nutzen von Netzwerkvariablen
wird die Lib mit eingebunden und es werden auch Daten ins Netz
geschrieben. Also geht es grundsaetzlich...
[gelöscht durch Administrator]
-
hallo
ich hoffe du hast ein wenig geduld und wille, damit wir das gemeinsam lösen
meiner meinung nach passiert beim IP_CONTROL etwas mit dem ich nicht gerechnet habe (tja, ist meistens so)
ich glaube das der ip_control im prinzip zyklisch versucht die verbindung aufzubauen, aber immer scheitert weil
etwas nicht geplantes passiert.
damit du dies genauer bestimmen kannst, musst du am besten die network.lib zu einem normalen projekt machen
und damit deinen test machen , damit du den ip_control auch debuggen kannst.
am besten du nimmst gleich die zukünftige network.lib v1.20 (siehe anhang)
in zeile 74 beim ip_control solltest du einen breakpoint setzen
73 UDP_INIT: (* UDP_CLIENT + SERVER *)
74 socket := SysSockCreate(SOCKET_AF_INET, SOCKET_DGRAM, SOCKET_IPPROTO_UDP);
75 IF socket < 0 THEN
76 c_status := 1; (* SysSockCreate failed *)
77 state := C_CLOSE;
78 ELSE
79 SysSockSetOption(socket, SOCKET_SOL, SOCKET_SO_BROADCAST, ADR(dint_true), SIZEOF(dint_true)); (* allow broadcast *)
80 SysSockIoctl(socket, SOCKET_FIONBIO, ADR(dint_true)); (* put socket in non-blocking mode *)
81 sockaddr.sin_family := SOCKET_AF_INET;
82 sockaddr.sin_port := SysSockHtons(c_port);
83 sockaddr.sin_addr := SEL(c_mode = 1, SOCKET_INADDR_ANY, SysSockNtohl(c_ip));
84
85 IF c_mode >= 2 THEN (* SERVER Mode *)
86 IF SysSockBind(socket, ADR(sockaddr), SIZEOF(sockaddr)) THEN
87 c_ready := TRUE; (* Connected *)
88 state:= C_WAIT;
89 ELSE
90 c_status := 2; (* SysSockBind failed *)
91 state := C_CLOSE;
92 END_IF;
93 ELSE
94 c_ready := TRUE; (* Connected *)
95 state:= C_WAIT;
96 END_IF;
97 END_IF;
(* ---------------------------------------------- *)
der normaler ablauf wären folgende zeilen
74
79-83
94-95
mich würde interessen welchen verlauf das programm an dieser stelle nimmt , und du mir das dann möglichst gut beschreibst
weiters wäre es dann auch interessant was dann im Abschnitt C_CLOSE (zeile 196-209) passiert
(weiteren breakpoint setzen)
irgendwas löst ein beenden der verbindung aus, ohne eine fehlercode zu setzen
ist dein sntp-server im selben netzwerk ?
wenn nicht , hast du eine korrekte gateway adresse eingestellt ?
[gelöscht durch Administrator]
-
Hallo peewit!
Ich beobachte hier ein interessantes Phaenomen!
Fakt ist, dass kein Socket angelegt werden kann:
Der Returnwert von SysSockCreate(...) steht auf "-1" = "16#FFFFFFFF"
(vgl. Screenshot im Anhang)
und jetzt das Kuriose:
Wenn ich vor Aktivieren des Programms mit xTrigger in Zeile 74 einen
Breakpoint setze und mich dann per F10 (Einzelschritt ueber) durch
das Programm hangele, kommt irgendwann der Timeout
(SNTP.Error = 16#FF000000)
Hier die Liste der Zeilen, auf denen ich wieder F10 druecke:
74, 75, 76, 77, 78, 97, 213, 228, 246, 250, 256, 308, 309, 365,
395, 396, 397, 398, 399, 401, 402, 403, 406, 410, 413, 416, 420, 455,
IP_CONTROL wird verlassen -> F5 (Start) -> TimeOut-Fehlercode
Wenn ich beim Breakpoint auf Zeile 74 F5 (Start) druecke, dann habe ich
eine Endlosschleife aus der er sich nicht befreien kann.
Wenn ich jetzt den Breakpoint auf Zeile 73 aendere, bemerke ich, dass der
"state" nach jedem Druck auf F5 den Wert von 16#1F auf 16#FB wechselt.
Der Ablauf hier ist aehnlich, wie vorher:
73, 74, 75, 76, 77, 78, 97, 213, 228, 246, 250, 256, 308, 309, 365,
395, 396, 397, 398, 399, 401, 402, 403, 406, 410, 413, 416, 420, 455,
IP_CONTROL wird verlassen -> F5 (Start) -> Breakpoint (state = 16#FB)
73, 101, 120, 145, 168, 189, 196, 197, 198, 203, 208, 213 (state = 0), 228, 246,
250, 256, 308, 309, 365, 395, 406, 410, 411, 413, 416, 420, 455,
IP_CONTROL wird verlassen -> F5 (Start) -> Breakpoint (state = 16#1F)
Da es sich hier scheinbar um ein Timing-Problem beim Erstellen des Sockets
handelt, habe ich testweise mal einen weiteren Schritt in die CASE-Anweisung
eingebaut:
CASE state OF
UDP_INIT: (* UDP_CLIENT + SERVER *)
socket := SysSockCreate(SOCKET_AF_INET, SOCKET_DGRAM, SOCKET_IPPROTO_UDP);
state := UDP_INIT_2;
UDP_INIT_2:
IF socket < 0 THEN
c_status := 1; (* SysSockCreate failed *)
state := C_CLOSE;
ELSE
Mit dieser Aenderung kommt bei Ausfuehrung sofort der Fehlercode
16#01000000 (SysSockCreate nicht erfolgreich ausgefuehrt) und ich
kann wiederholt das Programm mit xTrigger aktivieren.
Es scheitert also bereits beim Erstellen des Socket und somit ist es
auch irrelevant, daß sich alle Geraete im Netzwerk im selben Subnetz
befinden.
[gelöscht durch Administrator]
-
hallo
ich muss mir das erst alles in ruhe ansehen, um das eigentliche problem zu finden
warum es zu keiner stabilen fehlermeldung kommt, bzw. diese nicht bleibt
aber das eigentliche problem ist trotzdem das man keinen socket einrichten kann
du könntest mal probweise im sntp_client eine andere port nummer probieren (z.b. 15000)
-
hallo
denke das grundproblem gefunden zu haben , was die instabile fehlermeldung betrifft
1. beim socket initialisieren wird auch ein IP_C.TIME_RESET = TRUE ausgelöst
der alle fehlermeldungen rücksetzen soll
2. mitten im baustein wird im ersten zyklus sofort ein fehler erkannt
und fehler 0x 01000000 ausgegeben, was richtig ist
3. weitere schritt ist das schliessen aller socket
4. zum ende des bausteins kommt der IP_C.TIME_RESET = TRUE zu tragen und löscht alle fehler ab
5. nach socket schliessen, ist durch den ablauffehler kein fehler mehr gesetzt, und das ganze fängt wieder von vorne an
wenn du das ganze im debugging mode durchläufst , dann dauert der durchlauf so lange, das ein timeout aufgrund der zeit
erkannt wird.
also theoretisch ist mir nun alles klar
was bleibt ist das grundproblem das kein socket eingerichtet werden kann..
werde mir bis morgen einen patch einfallen lassen, damit wir wenigstens eine korrekten fehlermeldung bekommen.
aber soweit so gut .... immerhin konnten wir schon einen bug finden
danke...
-
probiere doch mal diese codezeile einzeln aus
diSocket:=SysSockCreate(SOCKET_AF_INET, SOCKET_DGRAM, 0);
und schau ob das überhaupt funktioniert
das wird bei den netzwerkvariablen auch genauso verwendet
solange das alleine schon nicht geht, hat alles andere sowieso keinen sinn !
-
Hallo peewit!
Das:
PROGRAM PLC_PRG
VAR
diSocket: DINT;
xFlanke: R_TRIG;
END_VAR
xFlanke(clk:=%IX0.12);
IF xFlanke.Q THEN
diSocket:=SysSockCreate(SOCKET_AF_INET, SOCKET_DGRAM, 0);
END_IF
funktioniert!
Dabei hat diSocket Werte ab 0x0081F0AC + n * 0xB0 angenommen.
Nach ca. 20 Versuchen habe ich abgebrochen...
Schoen! Wir machen Fortschritte!
-
dann probiere das auch aus
ist eigentlich genau das gleiche, so wie im ip_control baustein verwendet
socket := SysSockCreate(SOCKET_AF_INET, SOCKET_DGRAM, SOCKET_IPPROTO_UDP);
-
Hallo peewit,
Jetzt habe ich mal alle Protokolle aus der Variablenliste von SysLibSockets.lib
durchprobiert und komme zu dem Schluss:
Schei..e - da funktioniert ja nur die "0" Fehlerfrei!
Muss mir die Sache mit den Sockets abschminken oder gibt es Kombinationen,
der per Definition nicht funktionieren koennen?
-
hallo
ich habe mal eine neue version der ip_control bausteine erstellt, bei der nun ein korrekter Fehlercode
ausgegeben werden sollte.
(ip_control.exp und ip_control2.exp)
also importieren und testen, nun solltest du dann immer den fehler 0x01000000 bekommen
----------------------------------------------
das bei dir nur die 0 funktioniert, ist vielleicht gar nicht so schlimm
dazu habe ich auch eine testversion erstellt
wieder die bausteine importieren
(ip_control_(test).exp und ip_control2_(test).exp)
nun sollten alle socket mit wert 0 erstellt werden
momentan habe ich keine hardware und zeit , es auch zu testen.
probiere es einfach aus.... mehr als nicht funktionieren kann es eh nicht
[gelöscht durch Administrator]
-
Hallo peewit,
nachdem ich nun dazu gekommen bin, ein wenig zu spielen, hier das Ergebnis:
Wie erwartet, bekomme ich beim neuen "ip_control" sofort einen Fehler gemeldet.
Bei der Testversion aus "ip_control_(test).exp" tut sich was auf der Netzwerkleitung!
... und zwar dauerhaft! Die beiden Teilnehmer tauschen fleissig Daten untereinander
aus und beim Errorcode des SNTP-Bausteins erscheint eine 0x0000FE00. Der
Datenverkehr geht auch weiter, wenn die Aktivierung des Bausteins weggenommen
wird und kommt erst zum Erliegen, wenn ich den Baustein erneut aktiviere. Nun steht
der Errorcode auf 0x00000000 und ich bekomme am UDT-Ausgang das Datum/Uhrzeit
des vorigen Aktivierungs-Zyklus. Dies kann ich dann beliebig wiederholen -- es kommt
als Ergebnis immer die Uhrzeit vom vorigen Aktivieren.
Ich habe den Traffic zwischen den beiden Teilnehmern mit tcpdump mitgeschrieben und
als PCAP-Datei hinten angehaengt. Vielleicht kannst Du daraus schlau werden, was hier
schief laeuft...
Ich bin aber schon mal soweit zufrieden, dass ich ueberhaupt mit der Steuerung am
Netzwerk teilnehmen kann! Den Rest kriegen wir auch noch! ;)
[gelöscht durch Administrator]
-
hallo
also am netzwerk selber sieht es super aus
daten werden korrekt gesendet und es gibt auch ein passendes antwort telegramm
trotzdem gibts noch ein problem
ich vermute das sich das datensenden nicht beendet
---------
um auszuschliessen das die letzte änderung (verschluckte fehlermeldung) die ursache ist
habe ich dir einen weiteren ip_control testbaustein angehängt
bitte einmal damit testen, und dann wieder entfernen ausser es klappt dann
----------
so, wie geht es weiter
für solche heikle probleme habe ich eine debug funktion vorgesehen
du öffnest den ip_control baustein du schaust bei den variablen
dort ist dieser auskommentierte block, den du wieder scharfschalten musst
(*LOG_MSG : LOG_MSG;
_debug_enable : BOOL := TRUE;
debug_index : INT;
debug_ID : INT;
debug_lasterror : DWORD;
debug_last_id : INT := 255;
state_last: BYTE;*)
und im programmcode selber , gibt es einige stellen die folgend aussehen
die musst du auch wieder alle scharfschalten , indem du die kommentierung entfernst
(* ---------------------- Debug-Message ----------------------------*)
(*IF _debug_enable THEN
LOG_CL.NEW_MSG := 'IP_SEN SEND_COUNT ~1 -IP_ID ~6';
LOG_CL.PRINTF[1] := DINT_TO_STRING(s_cur_size);
LOG_CL.PRINTF[6] := INT_TO_STRING(debug_ID);
LOG_MSG();
END_IF;*)
(* -----------------------------------------------------------------------------*)
wenn du dann deinen testbaustein wieder laufen lässt
werden einträge in die globalen daten gemacht
online modus: ressource -> globale variablen -> LOG_CL.MSG findest du dann die einträge
diese einträge würde ich gerne haben !!
unter globale contstanten LOG_MAX : INT := 40;
kannst du noch die anzahl der möglichen meldungen einstellen (ist eine frage des gesamtspeichers)
dann sehen wir weiter .....
[gelöscht durch Administrator]
-
Hallo peewit,
leider hat die Aenderung noch nicht das gewuenschte Ergebnis:
Ich musste die Debug-Meldungen einschalten!
Im Anhang findest Du die gewuenschten 40 Eintraege als Screenshot.
(kann man sowas eigentlich als Plain-Text aus CoDeSys herausbekommen?)
[gelöscht durch Administrator]
-
hallo
ich sehe du bist immer noch sehr fleissig !
1. das der erste test nichts brachte , sehe ich als positiv , weil das bestätigt das die letzte korrektur keinen nebeneffekt verursacht hat
2. die msg_option brauchst du nicht dokumentieren , nur die msg texte
3. extra test: verwende eine sntp_server ip-adresse die nicht existiert, somit werden nur telegramme versendet und
keine empfangen und wiederhole deinen test
stelle wieder die debug.msg online
----------------------------------------
4. beim datenempfang habe ich zumindest schon mal eine vermutung
bislang werden folgende zustände vom baustein verarbeitet
-1 = keine daten vorhanden (da ich im non-blcoking mode arbeitet)
0 = verbindungsabbruch vom partner
>0 = anzahl der empfangenen daten
so wie es aussieht kommt bei deiner sps aber -5
dies wird falsch interpretiert, und führt zu einem virtuellen datenempfang
im anhang ist wieder eine adaptierte version die du auch testen solltest
verwende nun wieder eine sinnvolle sntp_server ip-adresse
ergebnissse (debug-texte) wieder online stellen
5. könntest du auch einmal einen breakpoint auf zeile 277 setzen , und schauen was bei bytes_received ankommt
als kontrolle !
-> 277 bytes_received := SysSockRecvFrom(socket, ADR(R_BUF.BUFFER), r_count, 0, ADR(sockaddr), SIZEOF(sockaddr));
wenn ich die sps bei mir hätte , wäre vieles einfacher...
[gelöscht durch Administrator]
-
Hallo peewit,
anbei der Screenshot der LOG_CL vom "extra-test". Das Array MSG
ist bis zum Ende mit dem selben Text gefuellt (Zwischenablage01.png).
Obwohl niemand geantwortet hat, meint der Baustein zu viele
Daten erhalten zu haben: ErrorCode = 0x0000FE00
Nachdem ich die Testversion 4 importiert hatte, habe ich versehentlich
zuerst die Debug-Funktion nicht wieder aktiviert und musste feststellen,
dass nun bei jedem Tastendruck (ich habe xTrigger mit einem digitalen
Eingang verknuepft!) eine Zeit vom Server kommt!
Auch beim ersten Aktivieren!
Trotzdem gibt es selbstredend die Debug-Meldungen in Zwischenablage02.
Ich habe den Baustein mehrfach aktiviert - deswegen gibt es mehrere
Eintraege im Array. Ab Position MSG[25] steht nix mehr drin...
Da die Zeile 277 immer ausgefuehrt wird, steht da immer ein Wert drin,
und zwar meistens 0xFFFFFFFA. Wenn ich zwischendurch mal "druecke",
kommt ein paar Zyklen spaeter eine 0x30 an, die spaeter wiederum mit
0xFFFFFFFA ueberschrieben wird.
... und jedes mal die richtige Zeit am Ausgang von SNTP! :-) :-) :-)
Es sieht so aus, dass wir auf genau der richtigen Spur sind!!!
[gelöscht durch Administrator]
-
hallo
also laut debug meldungen würde ich sagen das es mit testversion 4 (zwischenablage02) funktioniert
und anscheinend kommt bei dir auch was vernünftiges beim baustein raus
somit dürften wir die erste hürde überwunden haben
es gibt aber noch mehr zum testen !
udp client <---- dürfte nun laufen
udp server <---- noch ungetestet
tcp client <---- noch ungetestet
tcp server <---- noch ungetestet
ich werde mir die restlichen sachen noch durchschauen und überlegen wie wir es testen !
also irgendwelche einfachen test-programme basteln....
was ist das den überhaupt für eine steuerung ?
hast du eine genaue typbezeichnung
-
nächster test - udp server
zu nimmst die bausteine im anhang
das testprogramm nutzt den sntp_server
programm starten und baustein freigeben
rufew dann deine windows-uhr auf und gehe auf einstellungen
internetzeit - einstellungen änder und trägst als sntp-server die ip-adresse deiner sps ein
dann sollte sich windows normalerweise die uhrzeit von der sps holen
ansonsten die schon bekannten sachen machen .... debug meldungen etc...
[gelöscht durch Administrator]
-
Hallo peewit,
wie zu erwarten, will mein "Fensterchen" die Uhrzeit von KEINEM Server uebernehmen!
Fuer solche Faelle sind dann Pinguine SEHR zuverlaessige Partner!
Was soll ich sagen?!?
Es funktioniert:
~$ rdate -n -p steuerung.local.net
Wed Nov 9 12:22:33 CET 2011
~$
(Der Pinguin rechnet in localtime um, deswegen 1h Unterschied)
Zwischenzeitlich habe ich die "test4" - Version in IP_CONTROL2
umgebaut und das MODBUS_Client - Demo aus der network.lib
ausprobiert: Auch das funktioniert - ich bekomme richtige Daten!
Das sollte doch den "TCP-Client" - Test abdecken, oder?
Alles weitere nicht mehr heute...
-
modbus client = tcp client test
modbus server = tcp server test
ansonsten , probiere mal möglichst vieles der demoprogramme aus....
und gib dann wieder mal bescheid ...
-
Hallo peewit,
inzwischen konnte ich ein wenig weiterbasteln.
Dies habe jeweils ich mit den Versionen test4 und test5 getestet:
- SNTP-Client: funktioniert!
- SNTP-Server: funktioniert!
- Modbus-Client: funktioniert!
- Web-Seiten mit HTTP_Get holen: funktioniert!
- SMTP-Client: funktioniert! (vgl. anderer Thread)
Fuer den Modbus-Server musste ich erkennen, dass ich mich da noch
einlesen muss, damit ich den zum Laufen bekomme...
Koennte es noch mehr Leute als mich geben, die z.B. von einer DBox per
netcat Aktionen auf der Steuerung ausloesen moechte?
Wie saehe ein einfacher "Empfangs-Baustein" fuer diesen Zweck aus?
Die "eierlegende Wollmilchsau" muesste das meines Erachtens gar nicht sein:
Im einfachsten Fall koennte auf einem einstellbaren Port gelauscht werden,
nur das erste empfangene Byte wird als Bitfolge interpretiert (alle anderen
Bytes des IP-Pakets verwerfen!) und an binaeren Ausgaengen dargestellt.
Das bedeutet allerdings, dass die IP des Absenders ueberprueft werden muss,
damit z.B. Broadcast-Nachrichten, Portscans, etc. keine Aktionen ausloesen
koennen. (Waere schon bloed, wenn ein Broadcast vom "Fensterchen" die
Rollaeden herunterfahren laesst...)
-
hallo
na das hört sich ja schon gut an.
ich würde sagen ziel erreicht !
die anpassungen die wir für dein system in den ip_control gemacht haben, werden wir in den standard übernehmen
somit kannst du die nächste network.lib 1.21 ohne anpassung verwenden.
kommt ca. ende november !
-----------------------------------------
du willst daten empfangen
1. du brauchst eine IP_CONTROL instanz die zyklisch aufgerufen wird.
2. dann musst du die schnittstelle einrichten (nicht zyklisch beschreiben !)
IP_C.C_PORT := WORD#123; (* Portnummer eintragen *)
IP_C.C_IP := DWORD#00; (* IP eintragen *)
IP_C.C_MODE := BYTE#5; (* Mode: UDP+PASSIV+PORT *)
IP_C.C_ENABLE := TRUE; (* Verbindungsaufbau freigeben *)
IP_C.TIME_RESET := TRUE; (* Zeitueberwachung rücksetzen *)
IP_C.R_OBSERVE := FALSE; (* Datenempfang ueberwachen *)
S_BUF.SIZE := UINT#0; (* Sendelänge eintragen *)
R_BUF.SIZE := UINT#0; (* Empfangslänge rücksetzen *)
3. dann musst du nur auf R_BUF.SIZE schauen ob daten drinnen sind
wenn ja, dann daten verarbeiten und gleich wieder R_BUF.SIZE = 0
4. mehr ist es nicht !
-
hallo,
ich arbeite auch gerade an dem gleichen problem
modbus-client auf einer elc66 von eckelmann.
somit lässt sich auch alles übersetzten, nur der fehler "variable socket_fd_setsize nicht deklariert" besteht weiterhin.
irgendwie scheint das bei den obenstehenden projekten aber dennoch zu funktioniern, oder habe ich nur die lösung für dieses problem übersehen?
-
wenn du die syslibsocket.lib einbindest, so bringt diese bibliothek eigene globale variablen mit
auf manchen systemen ist anscheinend etwas ein wenig anders .... warum auch immer ....
wenn du glück hast reicht es wenn du die angehängten "original" globale variablen dieser lib dort einfügst bzw ergänzt
VAR_GLOBAL CONSTANT
SOCKET_INVALID:DINT:=-1;
(* AddressFamily *)
SOCKET_AF_UNSPEC:INT:= 0; (* unspecified *)
SOCKET_AF_LOCAL:INT:= 1; (* local to host (pipes, portals) *)
SOCKET_AF_UNIX:INT:=SOCKET_AF_LOCAL; (* backward compatibility *)
SOCKET_AF_INET:INT:=2; (* internetwork: UDP, TCP, etc. *)
SOCKET_AF_IMPLINK:INT:=3; (* arpanet imp addresses *)
SOCKET_AF_PUP:INT:=4; (* pup protocols: e.g. BSP *)
SOCKET_AF_CHAOS:INT:=5; (* mit CHAOS protocols *)
SOCKET_AF_NS:INT:=6; (* XEROX NS protocols *)
SOCKET_AF_ISO:INT:=7; (* ISO protocols *)
SOCKET_AF_OSI:INT:=SOCKET_AF_ISO;
SOCKET_AF_ECMA:INT:=8; (* european computer manufacturers *)
SOCKET_AF_DATAKIT:INT:=9; (* datakit protocols *)
SOCKET_AF_CCITT:INT:=10; (* CCITT protocols, X.25 etc *)
SOCKET_AF_SNA:INT:=11; (* IBM SNA *)
SOCKET_AF_DECnet:INT:=12; (* DECnet *)
SOCKET_AF_DLI:INT:=13; (* DEC Direct data link interface *)
SOCKET_AF_LAT:INT:= 14; (* LAT *)
SOCKET_AF_HYLINK:INT:=15; (* NSC Hyperchannel *)
SOCKET_AF_APPLETALK:INT:=16; (* Apple Talk *)
SOCKET_AF_ROUTE:INT:=17; (* Internal Routing Protocol *)
SOCKET_AF_LINK:INT:=18; (* Link layer interface *)
SOCKET_pseudo_AF_XTP:INT:=19; (* eXpress Transfer Protocol (no AF) *)
SOCKET_AF_COIP:INT:=20; (* connection-oriented IP, aka ST II *)
SOCKET_AF_CNT:INT:=21; (* Computer Network Technology *)
SOCKET_pseudo_AF_RTIP:INT:=22; (* Help Identify RTIP packets *)
SOCKET_AF_IPX:INT:=23; (* Novell Internet Protocol *)
SOCKET_AF_SIP:INT:=24; (* Simple Internet Protocol *)
SOCKET_pseudo_AF_PIP:INT:=25; (* Help Identify PIP packets *)
SOCKET_AF_MAX:INT:=26;
SOCKET_AF_INET_BSD:INT:=100; (* BSD-specific INET af *)
SOCKET_AF_INET_STREAMS:INT:=101; (* STREAMS-specific INET af *)
(* Level number for (get/set)sockopt() to apply to socket itself. *)
SOCKET_SOL:WORD:=16#ffff;
(* Socket options *)
SOCKET_SO_DEBUG:DINT:=16#0001; (* turn on debugging info recording *)
SOCKET_SO_ACCEPTCONN:DINT:=16#0002; (* socket has had listen() *)
SOCKET_SO_REUSEADDR:DINT:=16#0004; (* allow local address reuse *)
SOCKET_SO_KEEPALIVE:DINT:=16#0008; (* keep connections alive *)
SOCKET_SO_DONTROUTE:DINT:=16#0010; (* just use interface addresses *)
SOCKET_SO_BROADCAST:DINT:=16#0020; (* permit sending of broadcast msgs *)
SOCKET_SO_USELOOPBACK:DINT:=16#0040; (* bypass hardware when possible *)
SOCKET_SO_LINGER:DINT:=16#0080; (* linger on close if data present *)
SOCKET_SO_OOBINLINE:DINT:=16#0100; (* leave received OOB data in line *)
SOCKET_SO_REUSEPORT:DINT:=16#0200; (* allow local address & port reuse *)
SOCKET_SO_SNDBUF:DINT:=16#1001; (* send buffer size *)
SOCKET_SO_RCVBUF:DINT:= 16#1002; (* receive buffer size *)
SOCKET_SO_SNDLOWAT:DINT:=16#1003; (* send low-water mark *)
SOCKET_SO_RCVLOWAT:DINT:=16#1004; (* receive low-water mark *)
SOCKET_SO_SNDTIMEO:DINT:=16#1005; (* send timeout *)
SOCKET_SO_RCVTIMEO:DINT:=16#1006; (* receive timeout *)
SOCKET_SO_ERROR:DINT:=16#1007; (* get error status and clear *)
SOCKET_SO_TYPE:DINT:=16#1008; (* get socket type *)
SOCKET_SO_PROTOTYPE:DINT:=16#1009; (* get/set protocol type *)
(* TCPIP socket options *)
SOCKET_TCP_NODELAY:DINT:=16#01; (* don't delay send to coalesce packets *)
SOCKET_TCP_MAXSEG:DINT:=16#02; (* set maximum segment size *)
(* Socket types *)
SOCKET_STREAM:DINT:=1; (* stream socket *)
SOCKET_DGRAM:DINT:=2; (* datagram socket *)
SOCKET_RAW:DINT:=3; (* raw-protocol interface *)
SOCKET_RDM:DINT:=4; (* reliably-delivered message *)
SOCKET_SEQPACKET:DINT:=5; (* sequenced packet stream *)
(* Inet address definitions *)
SOCKET_INADDR_ANY:UDINT:=16#00000000;
SOCKET_INADDR_LOOPBACK:UDINT:=16#7f000001;
SOCKET_INADDR_BROADCAST:UDINT:=16#ffffffff;
SOCKET_INADDR_NONE:UDINT:=16#ffffffff;
(* Protocols *)
SOCKET_IPPROTO_IP:DINT:=0; (* dummy for IP *)
SOCKET_IPPROTO_ICMP:DINT:=1; (* control message protocol *)
SOCKET_IPPROTO_IGMP:DINT:=2; (* group management protocol *)
SOCKET_IPPROTO_GGP:DINT:=3; (* gateway^2 (deprecated) *)
SOCKET_IPPROTO_TCP:DINT:=6; (* tcp *)
SOCKET_IPPROTO_PUP:DINT:=12; (* pup *)
SOCKET_IPPROTO_UDP:DINT:=17; (* user datagram protocol *)
SOCKET_IPPROTO_IDP:DINT:=22; (* xns idp *)
SOCKET_IPPROTO_ND:DINT:=77; (* UNOFFICIAL net disk proto *)
SOCKET_IPPROTO_RAW:DINT:=255; (* raw IP packet *)
SOCKET_IPPROTO_MAX:DINT:=256;
(* Flags *)
SOCKET_MSG_OOB:DINT:=16#1; (* process out-of-band data *)
SOCKET_MSG_PEEK:DINT:=16#2; (* peek at incoming message *)
SOCKET_MSG_DONTROUTE:DINT:=16#4; (* send without using routing tables *)
(* Ioctl commands *)
SOCKET_FIONREAD:DINT:=1; (* get num chars available to read *)
SOCKET_FIONBIO:DINT:=2; (* set to non-blocking *)
(* For SysSockSelect() descriptors *)
SOCKET_FD_SETSIZE :DINT := 64;
MAX_SOCKET_FD_SETSIZE : DINT := 63;
END_VAR
-
wunderbar vielen dank
und schon läufts :-)
unten noch der code der umsetzung.
das ganze soll virtuelle ein und ausgänge lesen bzw schreiben.
gedacht habe ich mir das so das ich einfach zyklisch zwischen senden und empfangen umschalte. (sendenteil noch nicht implementiert)
ergibt das so sinn oder totaler nonsense?
konnte das leider noch nicht auf der hardware testen
PROGRAM MODBUS
VAR
IP_CONTROL2_1: IP_CONTROL2;
MB_CLIENT_1: MB_CLIENT;
IP_C: IP_C;
S_BUF: NETWORK_BUFFER_SHORT;
R_BUF: NETWORK_BUFFER_SHORT;
W_DATA_BITPOS: INT;
W_DATA_ADR: INT;
W_POINTS: INT;
W_ADDR: INT;
R_DATA_BITPOS: INT;
R_DATA_ADR: INT;
R_POINTS: INT;
R_ADDR: INT;
IP : DWORD;
FC : INT;
DATA: ARRAY[0..255] OF WORD;
DATA_IN: ARRAY[0..7] OF WORD;
DATA_OUT: ARRAY[0..7] OF WORD;
Send_state : UINT;
i: USINT;
END_VAR
IP := DWORD_OF_BYTE(192,168,178,001);
IP_CONTROL2_1.IP := IP;
IP_CONTROL2_1.PORT := 502;
IP_CONTROL2_1.TIME_OUT := t#5s;
IP_CONTROL2_1(IP_C := IP_C,S_BUF := S_BUF,R_BUF := R_BUF);
MB_CLIENT_1.DATA_SIZE := 8;
MB_CLIENT_1.UDP := FALSE;
MB_CLIENT_1(S_BUF := S_BUF,R_BUF := R_BUF,IP_C := IP_C,DATA := DATA);
CASE Send_state OF
0: (*READ virtual output, PILZ -> *)
FC := 3;
R_ADDR := 512;
R_POINTS := 8;
R_DATA_ADR := 0;
MB_CLIENT_1.ENABLE := TRUE;
Send_state := 1;
1:
IF NOT MB_CLIENT_1.BUSY THEN
FOR i := 0 TO 7 BY 1 DO
DATA_OUT[i] := DATA[i];
END_FOR;
Send_state := 2;
MB_CLIENT_1.ENABLE := FALSE;
END_IF;
2: (*WRITE virtual input*)
Send_state := 0;
ELSE
Send_state:= 0;
END_CASE;
MB_CLIENT_1.R_ADDR := R_ADDR;
MB_CLIENT_1.R_POINTS := R_POINTS;
MB_CLIENT_1.R_DATA_ADR := R_DATA_ADR;
MB_CLIENT_1.R_DATA_BITPOS := R_DATA_BITPOS;
MB_CLIENT_1.W_ADDR := W_ADDR;
MB_CLIENT_1.W_POINTS := W_POINTS;
MB_CLIENT_1.W_DATA_ADR := W_DATA_ADR;
MB_CLIENT_1.W_DATA_BITPOS := W_DATA_BITPOS;
MB_CLIENT_1.FC := FC;
-
schau dir das "MB_CLIENT_DEMO" Programm an das in der network bibliothek im ordner "demo" zu finden ist.
das nimmst du und parametrierst den baustein nach deinen bedürfnissen.
für was kopierst du die data_in und data_out noch extra hin und her, du kannst doch direkt mit data[index] daten lesen bzw. schreiben
und wo die lesen/schreib daten im DATA array liegen kannst du ja mit dem bausteinparametern vorgeben
wenn du mehr als einen befehlsblock brauchst , dann machst du einfach noch eine baustein instanz vom mb_client
die instanzen koordineren sich automatisch untereinander so dass alle der reihe nach arbeiten (zyklisch)
du kannst aber auch block lesen und block schreiben mit einem einzigen befehl bzw instanz erledigen (ist effektiver)
das mb_client.enable on/off solltest du nicht machen, da hierbei die tcp verbindung auch ständig auf/abgebaut wird
einfach freigeben und in ruhe lassen, solange du kommunizieren willst
-
Hallo peewit,
hallo inovent,
nach längerer Abstinenz möchte ich doch das Thema "Eckelmann-SPS und Netzwerk"
für mich zum Abschluß bringen:
Soweit ich inzwischen recherchiert, gelesen und getestet habe, sieht es für mich so aus,
daß diese Steuerungen NICHT für Netzwerk-Funktionen gemacht sind! Die haben dort
irgendwelchen proprietären Kram eingebaut, damit der Kunde darauf angewiesen ist,
ein PC-Programm von denen einzusetzen, wenn es darum geht die Steuerung mit der
Außenwelt zu verbinden.
Alle Netzwerk-Funktionen, die ich ausgetestet habe, laufen nicht dauerhaft stabil!
Es sieht immer so aus, daß das geht, aber wenn ich das dann im Produktivbetrieb habe,
bleibt die Steuerung irgendwann ohne Vorwarnung stehen.
Die einzige dauerhaft funktionierende Netzwerk-Kommunikation mit der Außenwelt
scheinen die Netzwerk-Variablen zu sein. Diese Variante habe ich allerdings nicht
weiter verfolgt, weil ich die Steuerung mit beliebigen anderen Komponenten (Web-
Browser, Mail-Server, Modbus-Clients, etc) verbinden und nicht nur Daten zwischen
Steuerungen hin- und herschieben wollte.
Wenn mich heute jemand fragen sollte, welche Steuerung ich für Home-Automation
einsetzen würde, die auch noch mit der Außenwelt kommunizieren soll/muß, so würde
ich "Wago" empfehlen! Die sind standardmäßig auf Netzwerk-Betrieb ausgelegt und
funktionieren! Damit habe ich inzwischen auch die Verbindung zwischen SAT-Empfänger,
mehreren PCs und der Steuerung ohne Probleme hinbekommen. Die sprechen alle
untereinander mit standardisierten Protokollen (HTTP, Modbus-TCP, SMTP, etc.).
-
Halllo
ich bin auch etwas weiter gekommen,
habe noch ein paar probleme mit der modbus verbindung, läuft wie bei emv-fuzzi beschrieben anscheiend stabil, dann bricht aber die verbindung teils ab.
teils heißt: nur eine richtung bleibt stabil bestehen, d.h. teils bricht das lesen, oder das schreiben auf den modbusteilnehmer ab. die bestehenden verbindungen bleiben dann aber stabil.
bei diesem vorgang bleibt mb_client in state 30 stehen.
allerdings hatte ich auch ein problem mit den codesys eigenen netzwerkvariablen, hier brach die verbindung öfters ab.
die lösung war die eigene implementierung einer udp verbindung durch ein beispielprojekt von eckelmann.
hier bleibt die verbindung seitdem stabil.
d.h. verbindungen nach außen ohne verwendung der netzwerkvariablen herzustellen ist möglich.
somit sollte also auch modbus möglich sein.
hier der code von eckelmann für senden und empfangen:
vielleicht hat jemand eine idee worin der unterschied zum mb_client besteht, oder wie man dem fehler näher kommen könnte
IF NOT Init_bit THEN
SysCreateConn('172.16.5.22', 1000, ADR(Connection_r));
Init_bit := TRUE;
END_IF
(* --------- Receive --------- *)
Result_di := SysSockRecvFrom(Connection_r.UdpSock_di,
ADR(Connection_r.RxMsg_r),
SIZEOF(Connection_r.RxMsg_r),
0,
ADR(UdpRecvAddr_r),
SIZEOF(UdpRecvAddr_r));
IF Result_di > 0 THEN
(* Check correct IP address *)
IF UdpRecvAddr_r.sin_addr = Connection_r.EseeSockAddr_r.sin_addr THEN
(* message received *)
END_IF
END_IF
(* --------- Send --------- *)
IF send THEN
SysSockSendTo(Connection_r.UdpSock_di,
ADR(Connection_r.TxMsg_r),
Connection_r.TxMsg_r.Header.Length,
0,
ADR(Connection_r.EseeSockAddr_r),
SIZEOF(Connection_r.EseeSockAddr_r));
END_IF
-
hallo
das ist alles ziemlich schwierig von der ferne ohne dieser hardware die sachlage zu beurteilen
das einzig sinnvolle wäre ein etherreal bzw. wireshark mitschnitt , damit könnte man erkennen welcher teil was macht oder nicht macht.....
anders werde ich euch nicht weiterhelfen können
die oscat modbus bausteine können auch im udp modus betrieben werden, natürlich müssen beide seiten das auch unterstützen
-
mal schauen ob ich irgendwie wireshark aufzeichnungen machen kann.
werde mich dann doch mal versuchen selbst durch den baustein durch zu hangeln.
an welchen stellen müsste ich denn ansetzten um die direkte ethernetverbindung von den allgemeinen oscat funktionen auf die eckelmannvorschläge umzubauen?
das müsste ja eigentlich alles rein im ip_control sitzen oder?
-
der code von eckelmann ist das was man selber in 5 minuten macht
wenn es so einfach wäre ......
leider gibt es allein bei den verbindungsarten schon client oder server und tcp oder udp modus
der beispielcode ist nur für udp-client kommunikation
es fehlt ja saogar die möglichkeit den socket wieder zu schliessen (SysSockClose)
ich würde ein für dich durchführbares oscat demo programm nehmen und laufen lassen
schauen wie lange es läuft, und optimal wäre in dieser zeit eine wireshark aufzeichnung zu machen...