Netzwerk-Funktionen laufen 'ewig' auf Eckelmann-SPS

Begonnen von MKr, 27. Oktober 2011, 16:32:48

Vorheriges Thema - Nächstes Thema

0 Mitglieder und 1 Gast betrachten dieses Thema.

MKr

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

peewit

#1
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...


MKr

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

peewit

#3
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 .....

MKr

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

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]

peewit

stelle man dein kleines testprojekt online, wo nur der teil mit der ethernet kommunikation drinnen ist !


MKr

OK, kleiner ging's nicht.

[gelöscht durch Administrator]

peewit

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]

MKr

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!


EMV-Fuzzi

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...

peewit

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

EMV-Fuzzi

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]

peewit

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

EMV-Fuzzi

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]