Beispiel zum Funktionsbaustein IP_Control

[axalom]

Hi,

ich bin nicht so ganz der CoDeSys-Profi und versuche gerade das kleine Beispiel zum IP-Control aus der Doku zum Laufen zu kriegen.
Ich scheitere allerdings beim Zugriff auf die IN_OUT Variablen des IP_FIFO.

Hier kommt beim Übersetzen immer die Fehlermeldung 4062 "kein Zugriff auf VAR_IN_OUT Parameter von IP_FIFO von außen.

Hier das kleine Programm dazu:

VAR
   IP_C1:IP_C;
   IP_FIFO1:IP_FIFO;
   IP_State:BYTE;
   IP_ID:BYTE;
END_VAR

IP_FIFO1(FIFO:=IP_C1.FIFO,STATE:=IP_STATE,ID:=IP_ID);
IP_C1.FIFO:=IP_FIFO1.FIFO;
IP_STATE :=IP_FIFO1.STATE;
IP_ID:=IP_FIFO1.ID;

Warum geht das nicht ?
Wie kann man sonst IN_OUT Variablen abfragen ?

Würde mich über Hilfe sehr freuen.

[axalom]

Habe gerade gesehen, dass bei meiner Steuerung " Var_IN_OUT als Referenz" fest aktiviert ist - hängt eventuell damit zusammen. Aber was macht man in dem Fall ?

[axalom]

Habe jetzt fast den Eindruck, dass die Abfrage irgenwie Quatsch ist, da sich die übergebene Variable ja selbst ändert.
Aber wieso steht das so in dem Programmierbeispiel

[peewit]

hallo axalom

nach dem ich nun mal genauer hingeschaut habe , ist mir dein problem klar geworden

das problem ist der mitunter grosse unterschied zwischen den verschiedene iec plattformen

das was du in der doku siehst ist ein programmier-beispiel für pcworx/multiprog (da die network-lib auf dieser plattform entwickelt wurde)

dort ist es so, das alle in_out var nach aufruf des bausteins wieder manuell rückgeführt werden müssen
(was eigentlich ziemlicher schmarrn ist, ist aber so)

das brauchst du bei codesys natürlich nicht !
da reicht es wenn du folgendes schreibst

IP_FIFO1(FIFO:=IP_C1.FIFO,STATE:=IP_STATE,ID:=IP_ID);

wir werden in der nächsten doku-release diesen unterschied vermerken...

(schau dir die demo-programm in der lib auch an !!)

mfg peewit

[axalom]

Hallo peewit

vielen Dank für die schnelle Antwort. Kann das Beispiel jetzt übersetzen und rüberladen. Bin aber noch am rumbasteln - mal sehen wann das erste Bit ankommt.

[axalom]

Hallo peewit, habe jetzt für erste Tests folgendes kleines Programm geschrieben:

PROGRAM IP_TEST1
VAR
   IP_CONTROL1:IP_CONTROL2;
   IP_C1:IP_C;
   S_BUF1: NETWORK_BUFFER_SHORT;
   R_BUF1: NETWORK_BUFFER_SHORT;
   IP4_Adr:DWORD;
END_VAR

S_BUF1.BUFFER[0] := BYTE#16#1B;
S_BUF1.SIZE :=1;
IP_C1.C_MODE := 3;
IP_C1.C_ENABLE := TRUE; (* Verbindungsaufbau freigeben *)
IP_C1.R_OBSERVE := TRUE; (* Datenempfang überwachen *)

IP4_Adr:=IP4_DECODE('192.168.001.157');
IP_CONTROL1(IP:=IP4_Adr ,PORT:=1024 ,TIME_OUT:=T#1s,IP_C:= IP_C1,S_BUF:=S_BUF1, R_BUF:=R_BUF1 );


Nach Anschauen der Beispiele sollte dies genügen um mit UDP was zu senden oder oder zu emfangen - allerdings totale Funkstille. Stell mir die Sache wahrscheinlich etwas zu leicht vor. Mann kann Online sehen, daß der Port immer schön geöffnet und geschlossen wird, IP_....s_start,.s_aktive,....new_connection sind allerdings immer FALSE ?
Der UDP Partner sendet immer schön von der angegeben Adresse.
Zur Not muss ich mir mal den IP_Control aus Biblio holen und beim Debugen schauen wo es hängt.

[peewit]

was für eine plattform verwendest du genau: software/hardware ?

[peewit]

hallo axalom

ich habe dein testprogramm mit kleiner anpassung ausprobiert, es läuft korrekt !!
im anhang sieht du auch den mitschnitt mit etherreal

sag mir mal wie dein netzwerk aussieht

welche ip's hast du in deinem netzwerk
welche hardware/software ?

---------------------------
PROGRAM eeee
VAR
   IP_CONTROL1:IP_CONTROL2;
   IP_C1:IP_C;
   S_BUF1: NETWORK_BUFFER_SHORT;
   R_BUF1: NETWORK_BUFFER_SHORT;
   IP4_Adr:DWORD;
   send : BOOL;
END_VAR

IF send THEN
   S_BUF1.BUFFER[0] := BYTE#16#1B;
   S_BUF1.SIZE :=1;
   IP_C1.C_MODE := 3;
   IP_C1.C_ENABLE := TRUE; (* Verbindungsaufbau freigeben *)
   IP_C1.R_OBSERVE := TRUE; (* Datenempfang überwachen *)
   IP4_Adr:=IP4_DECODE('192.168.001.157');
   send := FALSE;
END_IF;

IP_CONTROL1(IP:=IP4_Adr ,PORT:=1024 ,TIME_OUT:=T#1s,IP_C:= IP_C1,S_BUF:=S_BUF1, R_BUF:=R_BUF1 );


[gelöscht durch Administrator]

[axalom]

hallo peewit,

vielen Dank für die viele Mühe. Ich hab jetzt ein etwas schlechtes Gewissen weil ich vielleicht etwas eher hätte schreiben sollen, dass ich ein noch nicht getestetes System verwende.

Ich verwende eine TLCC Steuerung V3 von Schneider/Berger Lahr und programmiere mit CoDeSys Version 2.3.9.0.

Die Info zum Betriebsystem der Steuerung sieht so aus:

rts version: 2.4.6.0
OS version: Linux 2.4.20-rtl3.2-pre2 [runtime port v3 (2.4.6.0)]
uses IO driver interface
rts api version: 2.408
3 driver(s) loaded
driver 1: TLCC3, device interface version: 2.403
driver 2: TLCC3_Multimaster, device interface version: 2.403
driver 3: 3S HilscherDPM driver, device interface version: 2.403
TLCC3: V3024
Hilscher driver
1 devices (total):
0: DP Slave, Device info: 0x3130, DPM address 0x000D6000, Size 8192 Bytes Flags: 00000083

Ich schau mir jetzt auch mal mit Etherreal an ob ich was erkennen kann. Auf jeden Fall weiss ich jetzt, dass ich das Problem nicht bei mir liegt - dafür noch mal besten Dank

[axalom]

Hab jetzt die kleine Änderund mit der IF send Abfrage übernommen -- und jetzt geht es 
Also war das Problem doch bei mir 
Vielen Dank

[peewit]

hallo axalom

beachte aber trotzdem das du die network.lib auf einer nicht getesteten plattform benutzt.

Bekanntes Problem:
Plattform: Codesys SP PLCWinNT 2.4 + syslibsockets.lib
UDP Client + Server = läuft
TCP SERVER = läuft
TCP CLIENT = läuft nicht !

es ist leicht möglich das das auf deiner Plattform auch so ist

Leider sind die verschiedenen Plattformen trotz gleicher syslibsockets.lib nicht voll kompatibel
wir arbeiten an einer lösung .....

[axalom]

Na ich hab noch ein wenig gespielt - mein Programm funktioniert natürlich auch. Das Problem liegt doch eher in der Steuerung.
Auffällig ist, das nach Programmänderung ( Reset ) "state" vom IP_Control ständig zwischen 251 und  31 wechselt - als ob der Socket nicht geschlossen werden kann. Nach Neustart funktioniert alles wieder einwandfrei.

[peewit]

auf 251 kommt er doch nur wenn eine funktion einen schweren fehler meldet, oder jemand das ENABLE wegnimmt

prüfe mal wieso dieser überhaupt dorthin kommt

[axalom]

Vielen Dank noch mal für die Unterstützung - ich konnte jetzt mit IP_Control alle Probleme mit der Kommunikation lösen.
Dieses merkwürdige Verhalten nach Reset hat mich jetzt nicht so gewundert weil ich es bisher auch nicht anders kannte. Wenn man vor Reset mit einen Systemcall die Sockets noch schließt dann funktioniert es wunderbar.
Ich hatte vorher recht große Probleme weil ich in meinen Programm mit syssockselect gearbeitet habe. Dies hat irgendwie zu unglaublichen Verzögerungen (Jitter) von gut 100ms geführt. Ich habe gesehen, daß der IP_Control ohne select arbeitet und damit wesentlich schneller ist. Wäre für mich natürlich interessant ob dieses select generell zu Problemen führt oder nur zufällig nicht im IP_Control verwendet wurde.

[peewit]

der ip_control arbeitet absichtlich ohne select, und betreibt die socket-schnittstelle auch im "non-block" mode , damit man halbwegs
vernünftige zykluszeiten zu bekommen.

die meisten code-sample die herum geistern, benutzen die syslibsocket im block-mode, das heisst das eine system-funktion aufgerufen wird, 
und abhängig des aktuellen status dauert es kurz bis ewig bis die ablaufkontrolle wieder an das anwenderprogramm zurückgegeben wird.
darum muss man solche programme als extra-task ausführen, da ansonsten das anwenderprogramm nicht konstant abgearbeitet wird.
(für eine sps eine katatrophe !!!)


was funktioniert bei dir den nun , wie gut oder schlecht ?
und wie gelöst