Hi,
I used the logic in the demo programs to build world weather functionality in my application. However, I figured out, that after a while and some queries the communication stops: no further queries are possible. The error code is 16#00FFFF00 / a DNS error. So, I separated a sample DNS test program:
PROGRAM PLC_PRG
VAR
strHost : STRING := 'www.bme.hu';
IP_C : IP_C;
S_BUF : NETWORK_BUFFER;
R_BUF : NETWORK_BUFFER;
IP_CTRL : IP_CONTROL;
DNS_CLIENT : DNS_CLIENT;
END_VAR
IP_CTRL (
IP_C := IP_C,
S_BUF := S_BUF,
R_BUF := R_BUF,
TIME_OUT := T#5s,
IP := DWORD_OF_BYTE(10,1,2,1)
);
DNS_CLIENT (
IP_C := IP_C,
S_BUF := S_BUF,
R_BUF := R_BUF,
DOMAIN := strHost
);
After starting the program and triggering variable DNS_CLIENT.ACTIVATE, the query was successful. But, the next query (reset and set ACTIVATE) failed with timeout. After some investigation with the IP?C structure, I noticed, that IP_C.C_MODE does not reset to 0 - after doing this, another DNS query was possible...
So without further and deeper investigations, I added the following quick fix to solve this:
DNS_CLIENT line 118:
99: R_BUF.SIZE := UINT#0; (* Empfangslänge rücksetzen *)
ip_state := BYTE#4; (* Abmelden *)
IP_C.C_MODE := 0;
state := 00;
It seems to work fine, but I don't know, if it's correct... Ideas?
can you give me your test program with the error
on which system do you work ?
which version of the libraries you use ?
It's CoDeSys 2
X-Soft Codesys by Microinnovation - Moeller - Eaton
Platform XV-101
The library versions are the latest:
codesys_network_112.lib
oscat_basic_332.lib
The test program above produces the error itself: as described for the second ACTIVATE event (I do this directly in Online mode, by changing the ACTIVATE value TRUE / FALSE). Do you need a project export?
hello strucc
The network.lib 1.12 is tested with Codesys 2.3.9.25 and Codesys SP PLCWinNT v2.4 and WAGO 750-841
on these platforms, there is no problem
I think this problem is present only on your hardware
your solution probably works randomly
but if it solves your problem, then make it so
Did you try to run the above test program in itself?
The preogram in the DEMO folder works fine for me as well.
And in my application, there was no trouble, when other FBs (HTTP_CLIENT, SNTP_CLIENT) were using IP_C as well - they reset the status themselves. But somehow, DNS_CLIENT does not.
Your test program works without any problems (Codesys SP PLCWinNT v2.4 and WAGO 750-841)
you can make the test with Codesys SP PLCWinNT v2.4 (soft-plc) ?
In my case the DNS_CLIENT kind of got caught in state 30. IP_C never gave an Error and the FB has no Timeout like FTP_CLIENT does.
i helped myself with this workaround:
30: IF IP_C.ERROR <> DWORD#00 THEN
ERROR := IP_C.ERROR;
state := 99;
(*#################### DEBUG-MESSAGE ###################################*)
(*IF _debug_enable THEN
LOG_CL.NEW_MSG := 'DNS: S30 ERROR ~1';
LOG_CL.PRINTF[1] := DWORD_TO_STRING(ERROR);
LOG_MSG();
END_IF;*)
(*########################################################################*)
ELSIF NOT ACTIVATE THEN (* WORKAROUND WORKAROUND WORKAROUND WORKAROUND*)
state := 99; (* WORKAROUND WORKAROUND WORKAROUND WORKAROUND*)
ELSIF (S_BUF.SIZE = UINT#0) AND (tid = R_BUF.BUFFER[1]) AND (R_BUF.SIZE >= INT_TO_UINT(34 + url_length)) THEN (* prüfe ob antwort telegramm die richtige Transaction-ID und mindestlänge hat *)
ERROR := BYTE_TO_DWORD(R_BUF.BUFFER[3] AND BYTE#2#0000_1111); (* prüfe Return code der Flags. 4 bits *)
IF ERROR = DWORD#00 THEN
anc := R_BUF.BUFFER[7]; (* Anzahl der Answer-RR *)
IP_C.R_OBSERVE := FALSE; (* Datenempfang ueberwachen *)
state := 40;
ELSE
state := 99;
END_IF;
END_IF;
i think DNS_CLIENT needs some kind of timeout or reset
hallo
prinzipiell sollte der imp_control immer die fehlermeldungen produzieren
und mittels timeouts die abläufe überwachen
welchen version des ip_control ist hier in verwendung ?
wir haben erst vor ein paar wochen nochmals die network.lib für codesys nachgebessert
lade dir nochmals die neueste version runter, und binde sie ein
mache wieder deine tests mit den original bausteinen
wenn es wieder probleme gibt, würde mich ein wireshark mitschnitt sehr interessieren, von dem zeitpunkt wo der
dns_client ausfällt
habe die IP_Contol aus der codesys_network_hf1 mit version 1.9 vom 26. Feb. 2012. Datenpakete mitschneiden wird schwierig. Im Anhang ist habe ich einen Screenshot von der Bausteininstanz wenn sie hängt.
[gelöscht durch Administrator]
Hängt sich der DNS_CLIENT evtl. auf, weil der IP_C1 im FTP_CLIENT doppelt verwendet wird? zuerst für Namensauflösung und danach für den FTP Steuerkanal. Wenn die FTP Verbindung an einem blöden Zustand wegen Timeout abbricht...?
das der doppelt verwendet wird, ist absicht, damit man speicher spart
im prinzip sollte immer vom ip_control eine fehlermeldung kommen
was bei dir hier passiert gilt es heraus zufinden !
deine lösung behebt zwar die problem , aber nicht die ursache
das beste wäre hier natürlich ein datenmitschnitt
ich versuche das morgen nochmal durchzuspielen wie der Baustein in die missliche Lage kommt...
Wann liefert der IP_CONTROL denn einen ERROR wegen Empfangsüberwachung?
Der FTP_CLIENT muss den DNS_CLIENT irgenwie abgewürgt haben sonst wäre der C_ENABLE nicht auf FALSE, denke deswegen greift auch keine Überwachung.
Der DNS_CLIENT kommt von alleine nicht mehr aus der Sache Raus.
evtl. könnte man das so schreiben:
(* Domain Name System (query) *)
IF ACTIVATE AND NOT activate_last THEN (* auf positive Flanke GET warten *)
DONE := FALSE;
ERROR := DWORD#0;
state := 5;
END_IF;
CASE state OF
05: IP4 := IP4_DECODE(str:=DOMAIN); (* prüfe ob domain schon eine IP4-Adresse ist *)
...
dann würde der Baustein auf jeden Fall neu anfangen wenn eine Flanke auf ACTIVATE kommt.
das grundproblem steckt im ip_control
hier passiert etwas was nicht mit einer fehlermeldung erkannt wird
das gilt es zu finden und zu beheben.
alle anderes lösungen sind und bleiben workarounds
ziemlich alle anderen bibliotheken verwenden die dns-client funktion des betriebsystems.
wir benutzen natürlich (plattformunabhängig) unseren eigenen dns_client
aber das sollte alles kein grund für irgendein problem sein
wenn es wieder mal stehen bleibt wären screenshots von dem variablen der ip_control instanz ziemlich wichtig
wireshark wäre auch gut, aber wenn du es nicht machen kannst, dann eben nicht ....
ich werde die zum wochenende eine ip_control version geben, die debug_meldungen ausgibt
dann finden wir eventuell das problem schneller. ...
hallo arsh0r
entferne mal deine workarounds und benutze den ip_control im anhang
dieser erzeugt debug_meldungen in den globalen variablen in der network.lib
nachdem der fehler wieder aufgetreten ist, schaust du bei den globalen variablen nach (wie im bild im anhang)
und machst eine bildschirmhardcopy dieser datenstruktur
dazu wäre auch dein variablen dump vom ip_control ganz gut !
[gelöscht durch Administrator]
habe ich letzten Freitag eingespielt und seither warte ich darauf das es wieder passiert...
Bei den zwei Wago Cpus mit denen ich getestet habe trat der Fehler das letzte mal nach 1-3 Tagen auf. damals hatte ich auch ein Problem mit meinem FTP Server. warten wir mal ab...
hat ein bisschen gedauert... Im Anhang der Screenshot vom LOG und IP_C1
ich habe mit einer Flanke auf
F_FT_ERR(CLK:=DLOG.FILE_TO_FTP.FTP_CLIENT.IP_C1.C_ENABLE = FALSE AND DLOG.FILE_TO_FTP.FTP_CLIENT.DNS_CLIENT.state = 30 , Q=> );
IF F_FT_ERR.Q THEN
MSG:=LOG_CL.MSG;
END_IF;
das Log kopiert zu Zeitpunkt des Problems. seit dem hat sich im Log nicht weiter getan d.h. IP_CONTROL hängt komplett.
als ich beim DNS Client
ip_state := BYTE#4; (* Abmelden *)
state := 00;
gesteurt habe lief der upload wieder weiter
[gelöscht durch Administrator]
ein Kollege von mir hat wegen einer anderen Geschichte mit DNS_CLIENT mal bei Wago nachgefragt. Es passiert wohl das sich der TCP Stack der Wago Controller aufhängt, deshalb kriegt das der IP_CONTROL das wohl nicht mit. bei ihm half das Verstellen der MTU. Ich verfolge das jetzt nicht weiter bei mir funktioniert der Workaround.