Nachrichten

61

PC WorX / Konflikt zwischen SMTP_CLIENT und SPIDER_ACCESS

« am: 26. September 2013, 20:36:40 »

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

62

PC WorX / Re: SPIDER_ACCESS: Lesen von SAIA nach Phoenix ILC

« am: 26. September 2013, 20:08:33 »

Hallo peewit,

tut mir Leid dass ich so lange nicht von mir hören ließ, zu viel andere, vordringliche Arbeit! Nun wollte ich mich gerade wieder mit Feuereifer auf dieses Problem stürzen und den von Dir vorgeschlagenen Test durchführen, allerdings tauchte nun ein neues Problem auf, das zunächst geklärt werden muss, bevor ich an dieser Baustelle weiter arbeite, siehe mein neuer Post "SPIDER_ACCESS"!

Gruß,

Rainer

63

oscat.lib fuer Step 7 / Re: ACTUATOR-3P Ansteuerung!

« am: 25. September 2013, 14:37:05 »

Hallo Matthias,

für das Mischer-Hin-und-Her gibt es verschiedene Abhilfen

1) Anderer Regler
Der Oscat-Regler hat leider keine Totzone, mit der sich derartiges Getanze des Analog-Ausgangssignals verhindern lässt

2) Anderer (eigener) Actuator-3P
Wegen deines Problems, Versuchen mit falscher oscat_basic_lib  und einiger anderer Unzufriedenheiten mit Phoenix-PC-WORX und Oscat-Actuator habe ich mir selbst einen geschrieben, der eine einstellbare Totzone hat, bei kleinen Änderungen  des Analog-Stellsingals innerhalb der Totzone werden die Ausgänge nicht geschaltet.

3) Hysterese- (Totzonen-) Baustein zwischen Regler und Actuator
Keine Ahnung, ob es da etwas passendes gibt, Anleitung von "DEAD_BAND", "DEAD_ZONE"  habe ich nicht verstanden, so dass ich mir eine eigene FU geschrieben habe.

4) Filter
Schnelle Verbesserung,  aber kaum befriedigende Abhilfe könnte ein Filter aus dem Oscat-Sortiment bringen ("FILTER_I" oder was gerade für dich passt). Damit wird das Analogsignaltanzen zumindest gemildert.

Gruß

Rainer

64

PC WorX / Re: SPIDER_ACCESS: Lesen von SAIA nach Phoenix ILC

« am: 22. August 2013, 19:22:21 »

Hallo peewit,

diese Form des Zugriffs hatte ich vor längerer Zeit schon mal ausprobiert und nun noch mal bestätigt, funktionierte an eine existierenden Anlage mit
<http://172.16.202.117/cgi-bin/readVal.exe?PDP,,R2248,d>, was das Register 2248 ausliest und als dezimale Ganzzahl auswirft.

Der Schreibzugriff <http://172.16.202.117/cgi-bin/writeVal.exe?PDP,,R2244,d+31>, der den Registerinhalt von R2244 von 30 auf 31 änderte, funktionierte auch.

Brauchst du noch irgendetwas von mir?

Gruß

Rainer

65

Modulentwicklung / Re: Multi-Mail-Versand - erledigt

« am: 18. August 2013, 11:11:45 »

So, habe gestern jede Menge Tests durchgeführt, funktioniert, schön.

Damit ist die Limitierung auf 2-4 Mails bei den Phoenix ILC 1xx (Speicherbedarf) erledigt. Falls jemand Lust hat, darüber nachzudenken, das in eine professionelle OSCAT-Form zu bringen:

• Beschreibung ist angehängt
• Demoprogramm MailVorrang_30O.zwe hier http://www.bielefeldundbuss.de/OSCAT/MailVorrang_30O.zwe

Gruß

Rainer

[gelöscht durch Administrator]

66

Modulentwicklung / Re: Multi-Mail-Versand

« am: 15. August 2013, 23:13:16 »

So, ich habe heute mal wieder mein Hobby weiter verfolgt, und wie angekündigt den Meldungs-Handler so abgewandelt, dass nur noch einer benötigt wird, um eine große Anzahl verschiedener Emails (wenn es sein muss, auch im Rahmen der Arbeitsgeschweindigkeit des SMTP_CLIENT quasi "auf einen Schlag") abzusetzen. Meine 3er-Test-Anordnung funktioniert, der neue Baustein führt dem SMTP_CLIENT für gleichzeitig ausgelöste E-Mails der Reihe nach alle Texte zu und veranlasst den sequentiellen Versand. Ich will noch ein paar weitere Tests mit dieser übersichtlichen Anzahl machen, dann teste ich den vollständigen geplanten Ausbau mit bis zu 100 Meldungen.

Das sollte mit einer ILC 130 funktionieren, während bei simpler Verwendung von je einem SMTP_CLIENT je Meldetext schon bei 3-4 verschiedenen Meldungen Schluss ist, da jeder grob 30 KB (habe die genaue Zahl nicht mehr im Kopf) Speicher belegt, und etwas Anwendungsprogramm muss ja auch noch 'rein passen

Gruß

Rainer

67

PC WorX / Re: SPIDER_ACCESS: Lesen von SAIA nach Phoenix ILC

« am: 13. August 2013, 19:21:22 »

Das klingt seeeehr gut!

Mit Wireshark kenne ich mich nicht allzu gut aus.
Der "ip.src == 172.16.202.117" Filter, den ich beim Ansehen drin hatte, sollte dich ja sicher nicht behindert haben (der sollte beim neu Öffnen gar nicht aktiv sein), dass ich nur den VPN-Tunnel als Gateway gewählt hatte dürfte eigentlich nichts unterschlagen. Wenn  du doch noch irgendetwas vermisst müsstest du mir noch mal einen Tipp zu Wireshark-Einstellungen geben, ich wüsste momentan nicht, was ich da ändern sollte. Oder ob das eine Eigenart der Einstellungen bei Saia ist?

Bei Tests helfe ich natürlich gern,

Gruß

Rainer

68

PC WorX / Re: SPIDER_ACCESS: Lesen von SAIA nach Phoenix ILC

« am: 13. August 2013, 07:08:38 »

das problem ist aber das zuviel anders ist, und es keine schnelle lösung gibt/geben kann

Hallo, hatte mir schon so etwas gedacht, aber wo dicke Bretter gebohrt werden kann's halt auch schon mal etwas dauern.

Ein weiteres Wiresharkprotokoll, diesmal vor der Visu gestartet und deshalb etwas länger, habe ich beigefügt.

Gruß

Rainer

[gelöscht durch Administrator]

69

PC WorX / Re: SPIDER_ACCESS: Lesen von SAIA nach Phoenix ILC

« am: 12. August 2013, 20:59:05 »

> alternativ dazu, habe ich ja auch die net_var bausteine geschrieben

Hallo, ich weiß, setze ich auch ein. Das ist natürlich die effizientere Lösung, aber der Charme der SPIDER_ACCESS-Lösung ist, dass man mal spontan auf einen Wert einer anderen SPS zugreifen kann, ohne dass man das Programm auf der Datenquellen-SPS anfassen muss - was ja auch gar nicht immer möglich ist.

Insbesondere die SAIA-SPS ist aus einer ganz anderen Welt, da ist's nichts mit net_var Baustein 'reinpfriemeln. Und meine Möglichkeiten würde es halt sehr erweitern, wenn ich von einer Phoenix-ILC aus einfachen Zugriff auf jeweils wenige Daten in einer SAIA-SPS hätte.

Zum beiliegenden Wireshark-Protokoll:

Meine Mini-Visu hatte eine Alarmlampe, die auf ein Flag (Bool) mit Symbol-Namen "Druck.SM.StoerK1" mit der Maschinenadresse "F2981" (ausgelesen aus der SPS) reagiert.

Außerdem habe ich 2 Buttons, die ein anderes Flag mit Symbolnamen "Allgemein.Dummy" und der Maschinenadresse "F03067" jeweils per Schreibzugriff in die SPS auf 1 oder 0 setzen.

Dieser Schreibzugriff (aus Sicht der Visu) war leicht im Protokoll zu finden, siehe z.B. Eintrag 53 im Wiresharkprotokoll.

Ich hoffe, die Aufzeichnungen helfen Dir weiter,

Gruß

Rainer

[gelöscht durch Administrator]

70

PC WorX / Re: SPIDER_ACCESS: Lesen von SAIA nach Phoenix ILC

« am: 11. August 2013, 23:03:59 »

Hallo, danke für die schnelle Reaktion, ich kümmere mich schnellstmöglich (morgen). Wenn ich Dich richtig verstanden habe benötigst du eine Saia-Visualisierung mit irgendeinem Wert (ich nehme mal einen Temperaturmesswert) und einen Binärwert, ich denke, ich nehme einen Button, der per Button (mous-down, mouse-up) zwischen Binär-0 und Binär-1 wechselt, das ganze als Wireshark-Mitschnitt.

Hinsichtlich Struktur müsstest Du vielleicht noch mal nachfragen wenn du erste Ergebnisse hast, ich bin im Augenblick nicht sicher, ob ich verstanden habe, was du meinst, aber schau'n wir mal.

Viele Grüße

Rainer

71

PC WorX / SPIDER_ACCESS: Lesen von SAIA nach Phoenix ILC

« am: 11. August 2013, 18:24:11 »

Hallo,

nachdem das Verfahren zwischen Phoenix ILC problemlos funktioniert, wollte ich nun mal probieren, aus einer SAIA PCD3.M2130V6 über Netzwerk mit SPIDER_ACCESS zu lesen. Leider erst mal Prellbock, "No Such Component Found" (Error-Ausgang von SPIDER_ACCESS bleib aber 0). Hatte so etwas bei http://www.oscat.de/community/index.php/topic,2017.msg10521.html#msg10521 schon befürchtet.

Nun  ist die spannende Frage woran es liegt. Man muss wissen dass sich die Bedeutung von "für den Webzugriff freigegeben", "Instanz-Variable", "Globale Variable" grundlegend von der IEC 61131 (PC WORX) Welt unterscheiden.

Variablennamen
Findet man in einer Saia eine Variable "RLT1.AUSSENTEMPERATUR", Bedeutet "RLT1" nicht wie bei PC WORX, dass die Variable zu einem Arbeitsblatt  "RLT1" gehört. Vielmehr bietet die SAIA-Programmierumgebung die Möglichkeit einer Art Baumstruktur in der Namensgebung. Ich kann also "einfach so" für meine Anlage "RLT1" eine Gruppe "RLT1.Istwerte" mit einer Ganzzahlvariablen "RLT1.Istwerte.Außentemperatur" anlegen.  "RLT1.Istwerte" hat aber keinerlei Bezug zur Programmstruktur, sondern ist wie gesagt nur eine komfortable Möglichkiet, Variablennamen zu verwalten, einen neuen Varablensatz  für gleichartige Funktion eines gleichartigen Anlagenteils zu erzeugen ("RLT2.Istwerte"), mit denen sich dann sehr einfach ein Programmteil für diesen anderen Anlagenteil "RLT2" erzeugen lässt.

Globale Varablen
Hat in der SAIA-Welt eine andere bedeutung. Ein (FUPLA-) Programm kann jede menge Programmbausteine (Zyklisch abgearbeitete COB, bedingt abgearbeitete PB usw usw usw enthalten, die aber alle auf die gleichen mit "Local" gekennzeichneten Variablen zurückgreifen.
Nur bei Verwendung mehrerer Funktionsplan-Dateien (Heizungsanlage.fup und Lueftung.fup, die am Schluss zu einer Maschinencode-Datei zusammengelinkt werden, müssen globale Variablen definiert werden, die dann in allen .fup mit derselben Bedeutung verwendet werden.
Evtl. ähnlich ist das bei der Erstellung einer Web-Visualisierung, die SAIA-SpiderControl-Lösung setzt überhaupt Globale Variablen ("Public") voraus, alles andere wird beim Build mit "Unresoved EXTERNALs" als Fehler gebrandmarkt. Ein "PDD-Flag" wie bei PC WORX gibt es nicht.

Variablennamen in der Saia-WebVisu
Im Visu-Editor werden dieselben Variablennamen wie im FUPLA-Programm benutzt, die verwendeten sind eh alle Global. Heißt, fpr mein Register "RLT1.Zul.Is.B_TmpAussen0"  (Public) aus dem Fupla heißt der PPO im Visu-Editor für das WEBVISU.prj auch "RLT1.Zul.Is.B_TmpAussen0". Allerdings muss beim SAIA-System vor dem Build des Programms für die SPS noch ein Compilierungsvorgang durchgeführt werden, der eine Datei webserver.wsc erzeugt. Nur mit diesem Vorgang funktioniert der Datenaustausch zwischen der Visu und dem SPS-Programm. Was immer das bedeutet, ich habe mal ein Dateibeispiel angehängt, das auch die o.g. Variable enthält, die ich für meine Tests auch ausprobiert habe.

Ich hatte schon mal bei http://www.sbc-support.ch/faq/item/item.detail.php?it_index=101574&search_for=excel&back_url=%2Ffaq%2Fitem%2Fitem.search.php%3Fcmd%3DSEARCH%26category%3D0%26search_for%3Dexcel%26send_form.x%3D0%26send_form.y%3D0%26sort_order%3D-1%26search_area%3D0%26items_per_page%3D10%26frame%3Dresult%23idx101574 nachgelesen in der Hoffnung, dass mir das neuer Einsichten bringt, leider vergeblich.

Hat jemand schon mal Variablen aus einer SAIA mit SPIDER_ACCESS gelesen? Oder wie können wir mal systematisch ermitteln, wie der Zugriff funktionieren kann?

Viele Grüße

Rainer

[gelöscht durch Administrator]

72

Modulentwicklung / Re: Multi-Mail-Versand

« am: 04. August 2013, 09:58:54 »

So, das funktioniert, woweit ich das sehen kann, zunächst schon mal fehlerfrei. Die Notwendigkeit, den Handhabungs-FB für jede denkbare Meldung im Programm haben zu müssen ist ja doch sehr hässlich. Das Ziel ist, dass der FB eine Struktur mit folgenden Elementen verwaltet

BODY[Nr].String(250)    für Mail-Body,   Fix-Werte (Texte als Initialisierungwerte)
BODY[Nr].String(80)      für Mail-Body,   Fix-wert
SENT[Nr].BOOL             Flag für erfolgreichen Mail-Versand, wird gesetzt nach "Done" zur mail, rückgesetzt
                                   wenn entsprechende (Stör-) Meldung nicht mehr ansteht
ERROR[Nr].BOOL          Ist einfach das Flag, das mit einer Störmeldung gesetzt wird und anzeigt, dass     
                                   zu eben dieser Störungsnummer der Fehler gerade ansteht, wird nicht vom
                                   FB bearbeitet

Grob-Funktion weiter wir in vorigem Kommentar beschrieben, nur dass nun statt des Schrittketendurchlaufs der Index "Nr" passig zum Geschehen hochgezählt wird:

a: bei Auftauchen der ersten Meldung "Nr" hochzählen, bis zugehöriges ERROR[Nr] gesetzt ist
b ... d: Sinngemäß wie gehabt
e: SENT[Nr] für diese Störmeldung wird gesetzt
f: Nr := Nr + 1
g: Wenn Nr = 100 Nr := 0
    Erneuter Durchlauf für Nr=0 to Nr = 100, solange noch irgendeine Störmeldung ansteht.

Ist eigentlich nicht allzu kompliziert.

Rainer

73

Modulentwicklung / Re: Multi-Mail-Versand

« am: 31. Juli 2013, 22:23:53 »

Sieht nicht so aus ... .
Ich habe trotzdem mal angefangen. Über die Textzuordnung zu den Stör-Flags mache ich mir später Gedanken, jetzt habe ich mir erst mal eine 3er-Schrittkette, die nach Abschluss der Tests auf die von mir angepeilte Größe von 100 möglichen Meldungen / CPU (keine Prinzipelle Grenze) ausgedehnt werden kann.

Die Schrittketten-Struktur erlaubt bei Verwendung nur eines SMTP_CLIENTs beliebig viele gleichzeitig auftretende Meldungen nacheinander abzuarbeiten und so im Sekundentakt (grob) eine Meldung nach der anderen abzuarbeiten, bis alle Meldungen 'raus sind.

Das funktioniert schon ganz gut.

In der Schrittkette sind Instanzen des immer selben Funktionsbaustein aneinandergereiht. Erscheint die Notwendigkeit einer E-Mail-Sendung (Sammelstörung) wird der 1. Funktionsbaustein (1. Schritt) mit einem Zyklus-Impuls angetriggert.
a: Der Baustein überprüft, ob seine Aktivierungseingang auf 1 gesetzt ist ("Seine" Störung aktiv ist.
   Wenn nicht, triggert er sofort den nächsten Schritt per Impus an.
b: Wenn doch, überprüft der Baustein, ob "Seine" Meldung bereits erfolgreich gesendet wurde.
    Wenn ja,  triggert er (auch) sofort den nächsten Schritt per Impus an.
c: wenn nicht, gibt er "Seine" Störungsnummer 'raus, die dann aus 2 String-Arrays Body und Subject für
    SMTP_CLIENT zuordnet.
    Eine Störungsnummer <> 0 aktiviert SMTP_CLIENT für Störungsversand
d: Schrittkette bleibt so lange in diesem schritt, bis "Done" vom SMTP_CLIENT
e: Der FB für diesen Schritt speichert den erfolgreichen Versand, solange Störmeldung ansteht (für 'b')
f: FB triggert nächsten Schritt an, Dieser erledigt 'a' ... 'f' für "Seine" Störumeldung.

Der letzte Baustein in der Reihe gibt wieder einen Start-Trigger-Impuls an den ersten Schritt, der wieder
'a' ... 'f' durchführt, die Schrittkette wird wieder abgearbeitet, wenn sich eine Störmeldung erledigt hat wird die Speicherung von 'e' im entsprechenden Baustein zurück gesetzt, wenn eine neue Störung aufkam, verschickt der zugehörige Baustein seine Meldung.

Geht  SMTP_CLIENT auf "Error" veranlasst die Beschaltung alle x (5) Minuten einen Sendeversuch, die Schrittkette verharrt in diesem schritt bis die Mail erfolgreich abgesetzt wurde. Das ist ein Risikofaktor, was, wenn die Störung beispielsweise durch einen fehlerhaften String (unzulässiges Zeichen) für diesen Schritt verursacht wurde? Dann ist der Mailversand tot, das muss ich überdenken.
 
Gerade fiel mir auch auf, dass der Kreislauf weiter geht, auch wenn keine Sammelstörmeldung mehr ansteht, das heißt bei nächster Störung haben wir 2 aktive Bausteine in der Kette, das darf nicht sein, muss ich unterbinden.

So teste ich gerade alle Eventualitäten, die mir einfallen, es wäre toll, wenn jemand mit macht, und vielleicht auch Ideen kommen, wie man meine  "Testschaltung" in eine elegante OSCAT Lösung umwandeln könnte. Programm (Phoenix) stelle ich bei Interesse gern zum Download bereit.

Grüße

Rainer

74

Modulentwicklung / Re: SMTP Client Werte versenden

« am: 31. Juli 2013, 09:41:15 »

Hallo,
oder noch etwas weiter aufgedröselt: Wie Du Deinen Body-String zusammenbaust ist dem SMTP_CLIENT völlig egal. Ich z.B. baue Fehlermeldungen aus Standard-Schnipseln mit der IEC 61131 String-Funktion CONCAT zusammen, das sieht dann sinngemäß so aus:
Textstring := 'Motorstoerung'
MotorStromWertSting  ...  musst du mit INT_TO_STRING oder ähnlich aus dem Zahlenwert erzeugen

BodyString := CONCAT(Textstring,' ',MotorStromWertSting,' A')

ergibt dann als BodyString etwas mit Inhalt wie 'Motorstoerung 122 A'

BTW, ich hatte schon mal die Überlegung, ob nicht mal die vielen Tipps und Tricks hier (und noch viele schlummernde) auf http://de.wikibooks.org/ Systematisch geordnet als eine Art Handbuch
"OSCAT in der Praxis" aufbereitet werden sollten. Dafür braucht man aber natürlich Zeit, Freiwillige und ein Konzept.

Gruß

Rainer

75

oscat.lib fuer TwinCAT/CoDeSys / Re: Timer : ONTIME

« am: 20. Juli 2013, 11:10:17 »

And, of course more elegant for an application where you only want to have a runtime counter: The function ONTIME in OSCAT 333

Rainer