OSCAT Forum
network.lib => Codesys 2 => Thema gestartet von: axalom am 09. Februar 2010, 15:18:08
-
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.
-
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 ?
-
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 ???
-
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
-
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. ::)
-
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.
-
was für eine plattform verwendest du genau: software/hardware ?
-
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]
-
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
-
Hab jetzt die kleine Änderund mit der IF send Abfrage übernommen -- und jetzt geht es :)
Also war das Problem doch bei mir :(
Vielen Dank
-
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 .....
-
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.
-
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
-
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.
-
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
-
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.
Hallo,
ich bin auch ziemlich neu in der CoDeSys Programmierung und hänge am selben Problem. Nach einem Reset kriege ich keine Verbindung mehr zustande:
IP_C1.C_STATE ist dann 0 und IP_CONTROL.state springt zwischen 0 und 251.
Ich muss die Steuerung immer von Netz trennen, damit es wieder läuft.
Hier wird von einem Systemcall gesprochen, mit dem man die Sockets wieder schließen kann. Aber wie geht das? Beziehungsweise wie kann man sonst noch die Sockets schließen, damit man eine neue Verbindung aufbauen kann?
Bedanke mich schon mal im Voraus.
MfG
-
hallo
1. welches plattform verwendest du (hardware,software)
2. deine vorgangsweise kann ich so nicht ganz nach vollziehen
was für einen reset machst du und warum
3. ip_control.state wechselt zwischen 0 und 251
da ist sicher noch ein andere state dazwischen denn du vielleicht nicht siehst
was wird denn bei ip_control.error ausgegeben ?
und welche verbindungsparameter verwendest du
4. systemcall ? wo steht das , wer sagt das
5. schicke mir dein projekt , dann kann ich vielleicht schon etwas feststellen
6. es kann sein das dein anwenderprogramm die sockets nicht mehr schliessen kann, weil du durch einen reset oder ähnliches die
variablen zerstörst, und somit bleiben die ip/port blockiert
darum muss er geklärt werden wodurch dein zustand ausgelöst wird.
läuft die applikation ansonsten problemlos , bzw ab wann treten probleme auf
-
Sorry, hatte vollkommen vergessen dir noch mehr Infos zu geben :)
1. Benutzt wird eine auvis.box der Firma solvimus GmbH mit eingebautem BECK IPC@CHIP.
Programmiert wir mit CoDeSys 2.3.9.19.
2. Wenn ich den Quellcode bearbeite und diesen dann in die Steuerung lade, dann kommt ein "automatischer" Stop der box, da z. Z. kein Online Change möglich ist mit dieser.
3. IP_CONTROL.error sehe ich hier nicht, aber bei IP_CONTROL.IP_C.ERROR steht 0, also kein Fehler vorhanden.
Parameter sind wie folgt eingestellt:
IP_PARAMETER.C_ENABLE := TRUE;
IP_PARAMETER.R_OBSERVE := TRUE;
IP_PARAMETER.TIME_RESET := TRUE;
IP_PARAMETER.C_MODE := 3;
4. 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.
5. Siehe Anhang.
6. Beim starten der box (Spannung an) und mit einem bereits erzeugtem Bootprojekt, läuft alles ohne Probleme.
Ich kriege eine Verbindung und kann Telegramme hin und her schicken.
Ändere ich allerdings etwas am Quellcode und lade es in die box, dann wird die Steuerung gestoppt, weil ein Online Change noch nicht möglich ist.
Starte ich dann die box, dann wird als Status "Verbindung abgebaut" (IP_CONTROL.IP_C.C_STATE ist dann 0) angezeigt.
Dasselbe Verhalten gibt es, wenn ich auf Online/Reset gehe und dann wieder auf Start.
Vielleicht ist es noch interessant zu wissen, dass IP_CONTROL.socket verschiedene Werte anzeigt bzw. immer zwischen verschiedenen Werten hin und her springt.
Hoffe, die Informationen helfen dir weiter.
MfG
[gelöscht durch Administrator]
-
hallo
versuche doch mal bevor du eine online-änderung durchführst
IP_PARAMETER.C_ENABLE := FALSE zu machen, damit wird die bestehende verbindung gezielt beendet und alle socket geschlossen
dann sollte das online ändern ohne auswirkung möglich sein, danach kannst du wieder die verbindung freigeben
da ich leider keine möglichkeit habe mit deinem system zu testen, ist alles etwas schwierig
aber du solltest mal "axalom" fragen was er denn genau hier macht, um das problem zu beheben
-
Wenn man die Verbindung manuell schließt und öffnet, dann klappt das.
Hab mir überlegt wie man das ganze eigentlich automatisch realisieren kann, dass ich nicht ständig manuell den Wert ändern muss. Bin da auf eine Lösung gekommen bzw. habe ich es dank diesem Beitrag zustande bekommen: http://forum.3s-software.com/viewtopic.php?t=521&highlight=&sid=966eeea78ce908ab8842af88e4138042
Ich habe eine ResetCallback Funktion erstellt mit folgendem Quellcode:
FUNCTION ResetCallback : DWORD
VAR_INPUT
dwEvent:DWORD;
dwFilter:DWORD;
dwOwner:DWORD;
END_VAR
VAR
END_VAR
.
.
.
IF dwEvent = EVENT_BEFORE_RESET THEN
SysSockClose(UDP.IP_CONNECTION.server_socket);
SysSockClose(UDP.IP_CONNECTION.socket);
END_IF;
Und im Hauptprogramm steht folgendes:
PROGRAM UDP
VAR
.
.
.
bInit: BOOL;
END_VAR
.
.
.
IF NOT bInit THEN
SysCallbackRegister(INDEXOF(ResetCallback), EVENT_BEFORE_RESET);
bInit := TRUE;
END_IF;
Somit werden, vor jedem Reset, die Sockets automatisch geschlossen und ich kann wieder eine neue Verbindung aufbauen.
Danke für die Hilfe.
MfG
-
Hoffe der Doppelpost geht in Ordnung :)
Da die obere Variante bei mir nur ab und zu mal funktioniert hat, habe ich eine andere Lösung gefunden:
Ein Programm erstellt: ResetCallback (PRG) (keine Variablen nötig)
SysSockClose(UDP.Send_UDP.server_socket);
SysSockClose(UDP.Send_UDP.socket);
SysSockClose(UDP.Receive_UDP.server_socket);
SysSockClose(UDP.Receive_UDP.socket);
Und unter Ressourcen -> Taskkonfiguration -> System-Ereignisse beim Event before_reset unter aufgerufene POU das Programm ResetCallback eingefügt.
Seit dem funktioniert alles super. Ich glaube das meinte axalom mit Systemcall :)
-
Hallo,
ich würde auch gerne den FB Ip_Control testen.
Würde den Test auf dem Wago Kontroller 750-880 ausprobieren.
Der Kontroller hat 1024kByte Programmspeicher und 1024kByte Datenspeicher.
Wenn ich mein Projekt nur mit den benötigten Libs einspielen möchte, bekomme ich das die Daten zu groß sind auf der Steuerung.
Ein anderes Projekt von mir was wesentlich mehr Code hat lässt sich einloggen.
Woran kann das liegen ???
MacToolz
-
Hallo
es liegt wahrsceinlich nicht am speicher selber , sondern an der summe an bausteine die im projekt vorhanden sind
probiere doch mals die oscat_basic_micro.lib
(enthält nur die benötigten bausteine)
[gelöscht durch Administrator]
-
Hi
Normaleweiseläuft das mit einem 750-880.
Erhöhe die Bausteile auf "1364".
Gib mir doch mal deine Werte in der "Speichereinteilung".
Gruß Karl
-
Hi,
die Anzahl der Bausteine habe ich schon erhöht.
Die Speicherverteilung ist die Original Einstellung wenn das Target ausgewählt wird.
Selbst wenn ich ein Projekt von mir mit ca. 350kB einlogge hat er keine Probleme.
Woran liegt das jetzt seit dem nur die Lib in einem neuem leeren Projekt eingebunden ist. ???
MacToolz
-
Hi
Mach doch mal einen Screen von der Fehlermeldung.
Oder lege hier ein kurzes Projekt bei der der Fehler auftritt hier herein.
Was steht bei dir im Web-Base-Management --> Disk Info
Gruß Karl
-
Hi,
das ist der Stand nachdem das Projekt gerade läuft.
A 1868 KB 524 KB 1344 KB FAT
S 3860600 KB 5480 KB 3855120 KB FAT
MacToolz
-
Hi
Sollte eigentlich reichen.
Sicherheitshalber mal formatieren und extrahieren.
Hast du dann noch Probleme ?
Falls ja, bitte Screenshoot oder Projekt.
Gruß Karl