Konflikt zwischen SMTP_CLIENT und SPIDER_ACCESS

[rrbd]

Hallo,

ich habe für eine "echte Anwendung" ein Programm für eine Phoenix ILC 131 ETH erstellt, das sowohl den SMTP_Client für E-Mail nutzt (siehe auch mein Posting "Multi-Mail-Versand" hier im Forum), als auch SPIDER_ACCESS nutzen soll, im Prinzip zur Kommunikation zwischen Phoenix ILC erprobt, hier im besonderen Fall zum Datenaustausch mit SAIA PCD3 vorgesehen, was aber noch nicht recht funktioniert, siehe "SPIDER_ACCESS: Lesen von SAIA nach Phoenix ILC", ebenfalls hier im Forum.

Das neue Problem ist, dass die Verwendung von SPIDER_ACCESS den E-Mail-Versand stört, eigentlich sogar unmöglich macht. Während normalerweise meine Multimail-Funktion im Testbetrieb mit SMTP_CLIENT problemlos 60 verschiedene Mail-Meldungen im 3-Sekunden-Takt "'rausrotzt" (vielfach getestet, gerade eben wieder 5 60er-Läufe problemlos im um SPIDER_ACCESS erleichterten Anwendungsprogramm), schafft die gleiche Anordnung in der Regel nur wenige (manchmal gar keine) E-Mail. Störmeldung: ERROR_T = 1   ERROR_C = Hex 53000000.
In anderer Testumgebung auch Error_T =001E0000  -  Error_C=05


Bei Verwendung des Phoneix- SMTP-Clients:
wDiagCode = C303, Fehler aus der TCP Schicht SMTP IP_Connect
wAddDiag=EF01 Der Verbindungsaufbau zum SMTP Server hat länger als 12 sec. gedauert und wird dann vom FB abgebaut und wiederholt. Wenn dies dreimal nacheinander passiert, kommt dieser Fehler.
Insgesamt scheint die Fehleruqote höher bei mehr Netzwerkverkehr an der ILC, beispielsweise Vebvisualisierungszugriff auf die SPS (bisher kein Problem bei E-Mails ohne SPIDER_ACCESS im Programm.

Für einen Test habe ich aus dem Anwendungsprogramm mit dem Email-Porblem den Spidercontrol-POE gelöscht, schon lief alles wunderbar (5 Durchläufe, s.o.!), nach wieder-hereinkopieren des POE wieder das gewohnte Bild, 1 Durchlauf (60 mails) erfolgreich dann im 2. Testdruchlauf Error mit Fehlermeldung wie oben beschrieben.
Spider_Access wieder 'raus, Problem beseitigt, noch mal 3 Testläufe ohne Error .

Ich werde morgen das ILC-Testprogramm zum Download bereit stellen, helfe natürlich auch gern bei weiteren Tests.

Alle meine Tests habe ich bei laufendem Debugging in PC WORX Express und aktiver Webvisualisierung (ohne Bedieneingriffe, auf  dem Debugging-PC) durchgeführt

Gruß

Rainer

[peewit]

hallo

welche sps hast du
welche hardwarerevision und firmware hat die sps
welche oscat bibliothek versionen nutz du

[rrbd]

Hallo,

Das gepackte Testprogramm mit allen Libs. integriert findet sich hier http://www.bielefeldundbuss.de/OSCAT/ZSVA_WS_130926_12OSCAT.zwe

• SPS: ILC 131 ETH wie erwähnt
• ILC 131 ETH gibt's m.W. bisher nur mit 1 Firmware, ILC 130 ETH miz 3.91 (ich teste, sobald ich Zeit habe, auch 3.64), für Details Screenshots im Anhang
• Lib: pcworx_network_130, Stand ca. 2013-06-21

Gruß

Rainer

[gelöscht durch Administrator]

[peewit]

hi
ich habe mal kurz drüber geschaut
und habe keinen fehler entdeckt, der irgendeiner verbindung, abhängigkeit vom spider und email baustein zeigen würde
die beiden bausteine wissen sozusagen nichts von einander ...... und sollten / können eigentlich keinerlei allergien zueinander entwickeln...

der einzige punkt wo die zwei zusammentreffen ist die firmware .....


ERROR_T = 1   ERROR_C = Hex 53000000.
das heisst das alle verbindungen belegt sind .....
und sollte unter normalen bedinungen nicht auftreten
eventuell gibt es probleme mit undefinierten abbrüchen, sodass bestehende verbindungen noch im system belegt sind

kannst du mal dafür sorgen das zwischen dem senden vom email zu email eine wartepause reinkommt
normalerweise sollte das keine rolle spielen, aber vielleicht hilft das als notlösung ......

der programm ist schon zu kompliziert um fehler zu finden
folgender vorschlag

nimm nur das spider_access und smtp_client demoprogramm aus der network.lib und lasse nur diese beiden gleichzeitig arbeiten, und dann schauen wir mal was passiert

[rrbd]

Hallo,

mein instinktiver Verdacht geht auch Richtung Firmware und dass dort die Netzwerkszugriffswünsche nicht geordnet abgearbeitet werden, wobei es allerdings natürlich sein könnte, dass die ILC irgendeine kleine Sonderbehandlung im Baustein fordert, die bei andern Systemen nicht erforderlich ist. Werden wir sehen.

Aus Einfachheitsgründen werde ich erst mal Firmware 3.94 auf der ILC 130 testen, dort wurde lt. Aussage Phoenix ein Bug bei den Spidercontrolzugriffen gefixt, auch wenn es mir schwerfällt, da einen Zusammenhang zu konstruieren - man kann ja auch mal Glück haben.  Wenn nicht erstelle ich ein simplifiziertes Programm, das sich evtl auch ohne Mühe auf einem anderen System testen lässt.

Längere Pausen habe ich schon probiert (ich hatte ja auch Einel-Mail auf Eingansbefehl hin), hilft nix.

Gruß

Rainer

[rrbd]

So, nun weiß ich schon mal, dass Firmwareupdate bei ILC 130 ETH von 3.91 auf 3.94 das Problem nicht behebt.

Als Schnellabhilfe habe ich eine Fehlerabfangroutine in mein Programm gebaut, die bei Fehler alle 30s versucht, dieselbe Mail erneut abzusetzen, "bis dass das klappt". Tatsächlich werden mitunter grob geschätzt 5 Versuche benötigt, aber dann klappt es.

Damit kann ich mich erst mal wieder der weiteren Forschung im Thread "SPIDER_ACCESS: Lesen von SAIA nach Phoenix ILC" zuwenden, hier melde ich mich aber (voraussichtlich zum Ende des Wochenendes) mit einem Demo-nahen Testprogramm ohne zu viel Ballast für einen "Expertentest".

Gruß

Rainer

[rrbd]

Hm, habe ich mich wohl zu früh gefreut! Eine 3-Fach-Meldung (Real-Life: Unplausible Schalter-Rückmeldung, die 3 beteiligten Schalter werden einzeln per E-Mail bekannt gemacht) fiedelte SMTP_CLIENT an den ersten beiden grob geschätzt jeweils 5x 'rum (ich habe die Wartezeit nach Fehler auf 30s reduziert), an der 3. Meldung hängt die Meldung nun ein einer fast Endlosschleife (seit 1/4h alle 30s Fehlversuch, aber nach knapp 1/2h hat er die Meldung endlich draußen.).

SMT_CLIENT geht auf "Busy" und sofort erscheint wieder
ERROR_T = 1
ERROR_C = 53000000 (Hex), dieselbe Fehlernummer sehe ich übrigens auch am SPIDER_ACCESS

Das wundert mich etwas, laut meinem PDF zur Net-Lib 1.30 (Stand 14.11.2012) Stehen Details zu ERROR_T = 1 bei Störung: DNS_CLIENT, aber da finde ich diese Störung nicht. Plausibler erscheint mir eigentlich eine Zuordnung zu IP_CONTROL "Systemspezifische Störmeldung - Alle Leitungen belegt". Verstehe ich da etwas falsch?

Eine Weitere Beobachtung: Wenn ich ein Anwenderprogramm in die SPS geladen habe, funktioniert der E-Mail-Versand erst mal problemlos. Je länger das Programm läuft (der SPIDER_ACCESS meldet die ganze Zeit FF000000, da ich hier keine 2. SPS habe), desto häufiger kommt es zu Fehlern.

BTW, in der PDF-Dokument-Version ist ein Schönheitsfehler bei Beschreibung SMTP_CLIENT, die Zeile
"ERROR_T : BYTE (Fehlertype)"
ist unter das Baustein-Schaubild gerutscht.

Gruß

Rainer

[peewit]

Eine Weitere Beobachtung: Wenn ich ein Anwenderprogramm in die SPS geladen habe, funktioniert der E-Mail-Versand erst mal problemlos. Je länger das Programm läuft (der SPIDER_ACCESS meldet die ganze Zeit FF000000, da ich hier keine 2. SPS habe), desto häufiger kommt es zu Fehlern.

da ich hier keine zweite sps habe
was meinst du damit ?

[rrbd]

da ich hier keine zweite sps habe
was meinst du damit ?

Hallo,
Das E-Mail-Problem habe ich bisher in 2 Anwendungen getestet

• Schreibtisch-SPS, da gehen die Kommunikationsversuche von SPIDER_ACCESS mangels einer 2. SPS ins Leere
• Eine tatsächliche Anwendung, da existiert zwar die SPS mit der IP-Adresse, von der gelesen soll, allerdings gibt es dort die Probleme gemäß SPIDER_ACCESS: Lesen von SAIA nach Phoenix ILC , also auch ein eher schwieriger Anwendungsfall.

Letztlich dürfen beide Sonderfälle eigentlich keine Störung des E-Mail-Verkehrs bewirken, aber wenn ein Problem mit SPIDER_ACCESS den Netzwerkport überlastet, können wir natürlich lange nach SMTP_ACCESS-Problemen suchen. Deshalb will ich erst noch einmal eine SPS-Landschaft mit problemlos funktionierender SPIDER_ACCESS-Kommunikation testen.

Gruß

Rainer