Beispiel zum Funktionsbaustein IP_Control

Begonnen von axalom, 09. Februar 2010, 15:18:08

Vorheriges Thema - Nächstes Thema

0 Mitglieder und 4 Gäste betrachten dieses Thema.

Terya

#15
Zitat von: axalom in 26. Februar 2010, 18:19:35
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

peewit

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


Terya

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.
Zitat von: axalom in 26. Februar 2010, 18:19:35
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]

peewit

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




Terya

#19
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

Terya

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 :)

mactoolz

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

peewit

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]

gravieren

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

mactoolz

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


gravieren

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

mactoolz

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

gravieren

Hi

Sollte eigentlich reichen.


Sicherheitshalber mal formatieren und extrahieren.
Hast du dann noch Probleme ?

Falls ja, bitte Screenshoot oder Projekt.


Gruß Karl