Nachrichten

106

PC WorX / Re: SMTP_CLIENT arbeitet unzuverlässig

« am: 20. März 2013, 08:04:37 »

So, nun ging's endlich weiter in meinem Projekt und ich bin gezwungen, die Stör-E-Mails zu realisieren. Deshalb habe ich gestern den angekündigten Test mit dem original Phoenix '"SMTP_Client_V1_16" aus der Phoenix "IT_Library_V1_29" durchgeführt.
Dazu habe ich in einer Kopie meines Demo-Programms den OSCAT-SMTP-CLIENT gelöscht und mit den erforderlichen minimalen Anpassungen den Phoenix Client eingebaut. Anschließend Test-halber
a) 10 Mails mit dem Taktgeber über den Mail-Service meines Providers an mich geschickt, alle problemlos angekommen.
b) Sicherheitshalber denselben Test mit dem Testprogramm und Oscat-Client durchgeführt, nur 6 Mails kamen an, das bekannte Muster: mit
    einiger Zuverlässigkeit bleibt jede 2. hängen
c) um ganz sicher zu gehen Test a wiederholt: Es kamen wieder alle Mails an.

Das Problem liegt also eindeutig beim OSCAT- SMTP_CLIENT, der zwar in der Demo-Umgebung korrekt arbeiten mag, in (m)einer "Real Life" Umgebung aber versagt.

Wie kann ich helfen?

107

Bestehende Module / Existing Modules / "TIMER_1" Doku Fehler

« am: 26. Februar 2013, 16:10:07 »

Hallo,
im mir vorliegenden oscat_building100_de.pdf (2.8.2012) gibt es einen kleinen Fehler: Der Ausgang "STOP" von "TIMER_1"  ist weder im Screenshot zu sehen, noch in der Beschreibung erwähnt. Könntet Ihr das ergänzen?
Bei der Recherche fiel auf, dass die Downloads nicht aktuell sind. Ich habe (vermutlich aus dem letzten Paket) den oben genannten Änderungsstand, während auf der Downloadseite http://www.oscat.de/downloadmanager/viewdownload/5-oscatbuilding/54-oscatbuilding100de.html noch der Sachstand 21.10.2011 angeboten wird (der in den Dokumenteigenschaften Erstellt 6.2.2011 ohne Änderung anzeigt), was etwas verwirrend ist.
Seid Ihr so nett und stellt die aktuelle Version ein?

[gelöscht durch Administrator]

108

PC WorX / Re: SMTP_CLIENT arbeitet unzuverlässig

« am: 15. Februar 2013, 16:50:30 »

So, als erstes habe ich meine Test-ILC 130 mal auf Firmwarestand 3.91 gebracht, nicht ganz unerwartet ohne Verbesserung. Ich habe dann meinen Minutentaktgeber mal 3h durchlaufen lassen, die Statistik "Nur die Hälfte kommt durch" scheint fast perfekt, und die Regelmäßigkeit scheint grob bei 90% zu liegen, nur gelegentlich funktionieren mal 2 Sendungen hintereinander, dafür bleibt dann anderweitig mal eine doppelte Lücke. Diese Regelmäßigkeit scheint mir doch etwas zu ausgeprägt für eine äußere Ursache. Ich probiere jetzt mal die Original Pohenix-Lib., mal sehen, was dabei heraus kommt

109

PC WorX / Re: SMTP_CLIENT arbeitet unzuverlässig

« am: 14. Februar 2013, 13:25:42 »

werde ich erst mal machen, bin bis Ende der Woche in einer Anlage mit mehreren anderen ILC

Hallo,

hat etwas länger gedauert, heute kam ich dazu, den versprochenen Test zu erledigen. Die Vermutung einer Problemursache "Netzwerk/Hardware" möchte ich derzeit eher ausschließen, im anderen Netzwerk mit anderer SPS (ILC155 ETH 2.0.5.9062, Firmware 3.70.04 /09/30/10 HW01) sehe ich genau dasselbe Problem, es geht fast zuverlässig nur jede 2. Mail 'raus. Ich habe es sowohl mit "Meiner" Mail-Konfiguration als auch mit dem OSCAT-Test-Mailserver probiert; Du solltest bei 'oscat@gmx.net' eine Reihe Mails von 'oscat@gmx.net;Station_01' grob 2013-02-17 12:15:00 UTC sehen. Die Mails werden von einem Minuten-Taktgeber angesteuert, und du solltest die "Zahnlücken" mit einiger Regelmäßigkeit bei jedem 2. Sendeversuch sehen. Ich sehe hier als Ursache stets "Error_T=1 und ERROR_C=FD000000". (Habe aber nicht immer hingesehen). Bist Du so nett und probierst das mal mit einer ILC an? Das Test-Projekt liegt noch bereit. Bei Bedarf kann ich natürlich gern jede Test-Unterstützung leisten.

110

PC WorX / Re: SMTP_CLIENT arbeitet unzuverlässig

« am: 04. Februar 2013, 13:54:46 »

du solltest mal deine sps in einem völlig anderen netzwerk und router testen

Hallo,

werde ich erst mal machen, bin bis Ende der Woche in einer Anlage mit mehreren anderen ILC (wo ich das Programm mal teste) und ein paar freien Netzwerkanschlüssen (wo ich mein Schreibtisch-Starterkit mal anstöpseln kann), ich melde mich bis nächstes Wochenende mit Ergebnissen.

Und danke für die modifizierte netlib121x, spiele ich morgen Früh auf meine Rechner!

111

PC WorX / SMTP_CLIENT arbeitet unzuverlässig

« am: 04. Februar 2013, 09:23:52 »

Hallo, mit
SPS: Phoenix ILC 130 ETH 2.0.5.9062  Firmware V3.70.04 09/30/10 HW 01
Programmiersoftware: PC WORX EXPRESS 6.20.331
OSCAD: NetLib121 (und andere mehr, da funktioniert alles).
Netzwerk: SPS Teil meines Home-Hetzwerks (Via Netgear Router) mit fester IP,

habe ich das Problem, dass der E-Mail-Versand via OSCAT SMTP_CLIENT sehr unzuverlässig ist.
Wenn ich glück habe scheitern ca. 20% aller Sendeversuche, wenn ich Pech habe 80% oder mehr mit
Error_T=1 und ERROR_C=FD000000
oder
Error_T=2 und ERROR_C=FD000000

1. Versuch
Für erste  Versuche starte ich den Versand jeweils durch Forcen der Eingangsvarialben an ACTIATE. Normaler Weise ist dann der Baustein ca. 1s BUSY, dann kommt DONE.
Im Fehlerfall kommt ziemlich blitzartig der Fehlercode, nachdem BUSY auf 0 ging

Für diesen Versuch machte ich 10x hintereinander, immer ACTIVATE → Auf 1 und wenn ein Ergebnis vorliegt auf 0 und nach 1s wieder auf 1. Längeres Warten vor dem nächsten Versuch scheint nichts zu bringen

Beteiligt schien zunächst die Netzwerkqualität. Hängt die SPS über einen Billig-Switch (Store-and-Forward ) am Netzwerk habe ich ca. 50% Ausfall, hängt sie direkt am Router beim diesen Versuchen nur 20%. Beim 2. Versuch hat sich dieser Verdacht aber zunächst nicht bestätigt.

Da ich aber sonst keinerlei Netzwerkprobleme habe wundert mich doch sehr, dass ein SMMTP Mailversand so problematisch sein soll.

2. Versuch
Ich habe eine Testprogramm erstellt, das in Minutenabstand 10x ein 1-Zyklus-Signal auf ACTIVATE des SMTP-Servers gibt.

Ergebnis: Egal was ich anstelle (mit oder ohne Switch in der Leitung, Debug Modus von PCWORX EXPRESS während des Versuchs aktiv oder nicht), ich habe stets ca. 50% Ausfall. Details in beiliegender Tabelle. Die Erste Sendung klappt dem Augenschein nach immer, danach fehlt dann öfters mal eine (Abstand zwischen 2 Mails >> 1 Minute)

Natürlich könnte das auch ein Problem der SPS-Hardware oder -Firmware sein, allerdings scheint mir  der recht regelmäßige Ausfall-Rhythmus doch eher auf ein Kommunikations-Problem zwischen OSCAT SMTP_CLIENT und ILC(-Firmware) hinzuweisen. Zunächst wäre es hilfreich, wenn ich wüsste, was die Quelle oben genannter Fehlermeldungen ist und was sie bedeuten, dann könnte ich das Problem bei Phoenix parallel weiter verfolgen.
Das Testprojekt kann hier http://www.bielefeldundbuss.de/OSCAT/Emailtest_n_taktgeber.zwe heruntergeladen werden.

Wer weiß Rat?

[gelöscht durch Administrator]

112

BECKHOFF / Re: Smtp_client Fehler

« am: 03. Februar 2013, 21:10:54 »

Hallo,
danke für die Forschung, die schnelle Abhilfe mit eigenhändiger Änderung bleibt mir leider verwehrt, mit dem zu PCWORX EXPRESS mitgelieferten Funktions-Beschränktem WORX darf ich anscheinend nur angucken, nicht anfassen ;-)

113

BECKHOFF / Re: Smtp_client Fehler

« am: 02. Februar 2013, 23:14:10 »

Hallo,

> Ich glaube ich muss das nochmals erklären

nein das ist soweit schon klar, es geht hier auch nicht um ein paar Sekunden.

Wie du in der Tabelle siehst, liegt die Zeit im Mailheader für positive DTI_OFFSET um ca 19:12:00 minus  DTI_OFFSET gegenüber der korrekten Zeit in der Zukunft. Bei mir klingelt da (oder bei anders 1092 Minuten) nichts, naheliegend wäre ja irgendein-Zahlenformats-Umrechnungs-Wasweißich-Fehler.

Bei negativen DTI_OFFSET erscheint im Mail-Header eine korrekte Zeit.

Ist jetzt kein allzu großes Problem, ich kann ja einfach die Eingabe an DTI passend manipulieren, damit die Zeitangabe im Mailheader stimmt, aber schöner wäre natürlich eine korrekte Funktion bei Nutzung der vorgesehenen Korrekturfunktion.

Hier die Angaben:
PS: Phoenix ILC 130 ETH 2.0.5.9062  Firmware V3.70.04 09/30/10 HW 01
Programmiersoftware: PC WORX EXPRESS 6.20.331
OSCAD: NetLib121

114

BECKHOFF / Re: Smtp_client Fehler DTI_OFFSET

« am: 02. Februar 2013, 19:35:57 »

Hallo,
ich habe noch mal alles überprüft und kann bezüglich der Zeitkorrektur DTI_OFFSET finden. Ich habe mein Testprogramm etwas erweitert, so dass mir die aktuelle Zeitkorrektur in Minuten sowie die Systemzeit in den Mailbody geschrieben werden. Dann habe ich ein paar mal ACTIVATE per Hand gesetzt und dann die Mailbodies und die Angegebene Zeit im empfangenen Mailheader in eine Tabelle eingetragen. Das Ergebnis:

Systemzeit                                    Mail-Zeit          Differenz
-------------------------------------------------------------------------
02.02.2013 17:20:08          Korrektur   0   02.02.13 18:20   00:59:52
02.02.2013 17:27:03      Korrektur   0   02.02.13 18:27   00:59:57
02.02.2013 17:27:36      Korrektur   -1   02.02.13 18:28   01:00:24
02.02.2013 17:30:19      Korrektur   -2   02.02.13 18:32   01:01:41
02.02.2013 18:11:08      Korrektur   0   02.02.13 19:11   00:59:52
02.02.2013 18:11:47          Korrektur   -60   02.02.13 20:11   01:59:13
02.02.2013 18:12:29          Korrektur   -120   02.02.13 21:12   02:59:31
02.02.2013 17:21:40          Korrektur   60   03.02.13 11:33   18:11:20
02.02.2013 17:22:04      Korrektur   30   03.02.13 12:04   18:41:56
02.02.2013 17:24:24          Korrektur   5   03.02.13 12:31   19:06:36
02.02.2013 17:25:27          Korrektur   2   03.02.13 12:35   19:09:33
02.02.2013 17:25:56          Korrektur   1   03.02.13 12:37   19:11:04

Oder anders: Für negative DTI_OFFSET ist die Korrektur wie zu erwarten,für Positive passiert irgend etwas merkwürdiges.

Wenn du's nicht mit einem eigenen Programm reproduzieren kannst schicke ich Dir gern mein Programm. Ich habe die Tabelle noch mal als .csv (ISO 8859-1, Semikolon) beigepackt

Bei meinen Tests fiel mir ein anderes Problem auf, das ich zunächst noch selbst etwas weiter untersuchen will (ohne dass ich mir viel davon verspreche): Der E-Mail-Versand arbeitet sehr unzuverlässig, vorgestern gelegentlich, heute mit geändertem Programm) meistens wird keine Mail verschickt, der Versuch endet mit
Error_T=1 und ERROR_C=FD000000
oder
Error_T=2 und ERROR_C=FD000000

Wollen wir das hier im Beckhoff-Hilferuf weiter erörtern oder lieber an besserer stelle einen neuen Thread öffnen?


[gelöscht durch Administrator]

115

BECKHOFF / Re: Smtp_client Fehler

« am: 30. Januar 2013, 15:48:22 »

Hallo,
LÄUFT!

• dns_ip4: Sorry, mein Fehler, ich im Programm die IP-Adresse des einen vom Provider angebotenen DNS-Servers verwendet, hier in der Diskussion aber die andere aufgeführt. Das hatte aber keinen Einfluss, und auch mit der 8.8.8.8 hatte ich kein Glück habe dann erst mal aufgegeben
• Heute habe ich mir dann mal das Beispiel ans der Lib. angesehen. Import habe ich versucht, aber mein PCWORX Express hatte dann keine Variableninhalte mehr und Variablentypen waren teilweise falsch. Also händisch Variablennamen, Inhalte und Typen übertragen, und mit dem GMX-Testaccount probiert, funktionierte! Meinen Provider-Mailserver etc eingesetzt, lief! Wirklich Unkontrolliert geändert hat sich eigentlich nur der Zeiteingang, habe mir die Konstruktion für das Umwandeln der Systemzeit eingebaut, den Rest habe ich von den gleichen Quellen wie bei meinen gescheiterten Anläufen in die Variablen kopiert, der einzige Unterschied, der mir deutlich auffiel, waren andere String(-Längen)-Typen. Die Vorstellung erscheint mir zwar merkwürdig, aber kann es theoretisch sein, dass die Wahl der korrekten Stringlängenvorgabe funktionswichtig ist? Wenn ja, sollte das auf jeden Fall in die Doku übernommen werden. Momentan habe ich aber wenig Zeit, das noch mal in Ruhe auszuprobieren.
• Zeitzonenkorrektur verstehe ich noch nicht. Bei "0" zeig die Empfangene Mail Merkwürdiger Weise UTC +2h, obwohl mein DT UTC+1 = MEZ ist. Bei DTI_OFFSET= +1: ca 20h zu viel. Bei "60" gut 19h zu viel. Bei -60 Wird die Sendezeit 1h Hochgesetzt. Könntest Du dazu noch mal etwas sagen?

Zumindest für einen Umsteiger aus einer ganz anderen SPS-Welt wären folgende Dokumentationsergänzungen sehr hilfreich:

• Wirkung von DTI_OFFSET (welcher Wert bewirkt welche Änderung?)
• DNS_IP4: Hinweis auf IP4_DECODE  und Beschreibung der manuellen Umrechnung, in etwa : "Um eine IP-Adresse in die das erforderliche Doppelwort umzuwandeln muss jeder Teil der Adresse einzeln in 2 Hex-Digits umgewandelt werden. Beispiel: IP-Adresse 192.168.1.32 in Hex wäre C0,A8,01,20 und wird das DW C0A80120" 

Vielen Dank für Deine Hilfe und Geduld!

116

BECKHOFF / Re: Smtp_client Fehler

« am: 29. Januar 2013, 20:08:18 »

Hallo peewit,
danke für die Rückmeldung!
dns_ip4: als Doppelwort mit hex-Gruppen bin ich nicht drauf gekommen, habe ich eingetragen. Das Ergebnis sollte 81.14.243.9 darstellen, das habe ich der Routerkonfiguration meines Netzwerks entnommen. Mein Eintrag ist zumindest gültig, ich hatte mich vorher vertippt und hatte dann eine Dauerfehlermeldung vor dem ersten Versand.
Mailserver: Vermutlich war das Bild wegen der unkenntlich gemachten Authentifizierung schwer zu deuten: Der mailserver ist "mail.bielefeldundbuss.de", die Variable enthält username:password@mail.bielefeldundbuss.de:110 (den Port hatte ich heute Vormittag noch nicht mit drin).  Die Daten sind erprobt, ich habe den Mailaccount auch auf meinem PC eingerichtet, das funktioniert.
Standard-Gateway: ist in der SPS hinterlegt

Weitere Variableninhalte:
DTI = 25. September 2008 um 10:01:00 per FSTRING_TO_DT mit #D. #N #Y #h:#m:#s = 48DAD4BC
sWhatFiles leer

Zwischenstand: Nun habe ich nach dem Ablauf von Busy Error_T=1 und ERROR_C=0000FF00. Wenn ich das richtig sehe also eine DNS-Client-Meldung. Wenn da nur 00 relevant wäre würde das ja "erfolgreich" heißen, aber ich habe keine Mail  an die angegebene postmaster-Adresse bekommen.
Beim nächsten Versuch im laufenden Betrieb (diesmal an info@bielfeldundbuss.de) verschwanden die Errormeldungen mit dem Busy=1, kamen aber nach Timeout zurück und ebenfalls ohne dass ich eine Mail bekommen hätte. Irgendetwas scheine ich also noch falsch zu machen, gibt Dir der nächste Screenshot Aufschluss?

Ich schaue mir zunächst mal das Beispiel gemäß deiner Anleitung an.

[gelöscht durch Administrator]

117

BECKHOFF / Re: Smtp_client Fehler

« am: 29. Januar 2013, 13:11:15 »

Hm, ich komme gerade mit demselben Problem nicht weiter, ich hoffe, Ihr seid einverstanden, dass ich mich trotz anderer SPS und Programmierumgebung mal einklinke.

Ich habe in einem ansonsten funktionierenden Textprogrämmchen SMTP_CLIENT eingebaut, um einen kurzen Betreff und Body an meine normale E-Mail-Adresse auf dem PC zu schicken.

Wenn ich über Debug-Umgebung manuell ACTIVATE auf 1 setze geht der Baustein für TIMEOUT (60s) auf BUSY, anschließend sehe ich 2 Störmeldungen, bekomme aber keine mail.

ERROR_T: 5
In der mir vorliegenden Beschreibung am Baustein nicht erklärt, Tabelle fehlt offensichtlich (lerrer weißer Bereich). Ob ich die Beschreibung von DLOG_FILE_TO_FTP? Übernehmen dar? Dann wäre es "Störung: ABLAUF – TIMEOUT" (so sthet's auch im Handbuch Netlib131)
ERROR_C: 655360 (Dezimalanzeige)
Das sagt mir leider nichts

Habe ich mal eine DNS_IP angegeben, wobei mich das DW verwunderte, ein DW ist ja doch sehr anders als eine IP Adresse. Wie mag der Baustein das auseinanderpulen? Ist so eine Angabe 81142439  auch ohne Punkte dazwischen eindeutig? Keine Ahnung! Verhalten ändert sich nun, ERROR_T: 0, ERROR_C: 65280 gleich von Anfang an.

Also lieber wieder weg damit.

Liegt's an einem falschen DTI? Ich habe keine mir Verständliche Angabe zum geforderten Format gefunden

sWhatFiles ist einfach leer.

SPS: Phoenix ILC 130 ETH 2.0.5.9062  Firmware V3.70.04 09/30/10 HW 01
Programmiersoftware: PC WORX EXPRESS
OSCAD: NetLib121 (und andere mehr, da funktioniert alles).
Netzwerk: SPS Teil meines Home-Hetzwerks (Via Netgear Router) mit fester IP,
Bausteinbeschaltung: Siehe Anlage

Das Demo hätte ich mir gern angesehen, verstehe aber nicht recht, wie ich den Inhalt des Ordners einbinden kann.

Wer kann mir helfen?

[gelöscht durch Administrator]

118

Bestehende Module / Existing Modules / Limitierung für FILTER_I bei großen Zeitkonstanten

« am: 16. Januar 2013, 09:12:26 »

Hallo,
In einer Heizungsregelanlage bin ich auf eine im Nachhinein nicht ganz überraschende, aber doch unschöne Limitierung des Bausteins FILTER_I (in einer Phoenix ILC 130) gestoßen. Ich habe den Baustein Verwendet, um das Signal eines Außen-Temperaturfühlers drastisch zu glätten, die Heizkreise sollen nicht auf jede vor der Wintersonne vorbei ziehende Wolke reagieren, sondern einem trägen Mittelwert folgen. Dafür habe ich Filter_I mit einer Zeitkonstante von 3600 Sekunden für das INT Rohsignal (= Messwert in °C x 10) versendet. Leider funktioniert das für die relativ kleinen Signalwerte nicht. Ich schätze mal, dass das Problem ist, dass irgendwann bei der Integration von kleinen Signalwerten die Änderungen kleiner als 1 werden, damit nicht mehr berücksichtigt werden, und dann bleibt der Ausgangswert stehen. Besonders lästig ist, dass bei Annäherung an 0 (Nach einem Sprung des Eingangssignals auf 0) der Ausgangswert 0 nicht erreicht werden kann. Letztlich kein Bug im FB, sondern eine durch das Zahlenformat vorgegebene Begrenzung, aber wer denkt schon im Eifer des Gefechts an so etwas?

Meines Erachtens sollte dieser Zusammenhang zwischen Signalgröße und Zeitkonstantengröße in der Dokumentation erwähnt werden, so in etwa in der Art "Bei Zeitkonstanten > xxxs Arbeitet der FB für kleine Eingangssignale nicht mehr zuverlässig, ggf. sollt für solche Problemstellungen der Baustein "FT_PT1" benutzt werden".

An anderen Stellen bei ähnlicher Verwendung (Fühlersignalglättung) mit Zeitkonstante 5s tritt das Problem erwartungsgemäß nicht auf, da wird der 0-Ausgang problemlos durchfahren.

"FT_PT1" habe ich natürlich auch gleich noch ausprobiert, aufgrund der bei REAL viel kleineren möglichen "Schrittweite" für die aufintegrierten Änderungen tritt das Problem da nicht auf.

Beigefügtes PNG vergleicht die Filter-Arbeit ca. 25 Minuten nach einem Sprung des gemeinsamen Eingangssignals von 0 auf 20. Während die Filter_I am Ausgang unverändert "0" zeigen ist das Ausgangssignal am "FT_PT1" nicht auf.

Grüße

Rainer

[gelöscht durch Administrator]

119

SPS-Programmierung / Re: Steuerung eines Mischventils über Halbleiterrelais

« am: 03. Januar 2013, 17:02:18 »

... werd das mal so versuchen.

Hallo, wie ist's denn ausgegangen?

120

Modulentwicklung / OSCAT-NETWORK-LIB 1.30 Release Candidate 1

« am: 13. November 2012, 07:36:34 »

Moin,
zu Funktionstests mit PC WORX / Phoenix ILC  komme ich erst Ende der Woche. Doku habe ich schon mal angefangen zu lesen, mir fiel ein kleines Handhabungsproblem auf, "irgendwie" sind die Links des Inhaltsverzeichnisses "zerschossen", führen nicht zum Thema. Beispiele:

Click auf                   führt nach
---------------------------------------------------------------------------------------------------------
2.1. Ziele                  Inhaltsverzeichnis, es wird nur gescrollt, bis Ausgangslink am oberen Bildschirmrand
4.11. us_TN_MENU     Inhaltsverzeichnis, es wird nur gescrollt, bis Ausgangslink am oberen Bildschirmrand
5.1. ELEMENT_COUNT Inhaltsverzeichnis, es wird nur gescrollt, bis Ausgangslink am oberen Bildschirmrand
9.13. MD5_AUX          s.o.

Grüße

Rainer

Peewit:
Danke für deine Information
Die PDF-Datei habe ich neu generiert und die genannten Fehler sollten nicht mehr vorhanden sein
Dokumention.zip steht in aktualisierter Form wieder zum Download bereit