Themen

16

Bestehende Module / Existing Modules / Verbesserungsvorschlag für SETUP_HOLIDAY und HOLIDAY

« am: 05. Oktober 2013, 13:37:35 »

Hallo,

• Ich habe irgendwo gelesen SETUP_HOLIDAY sei gar kein so richtig offizieller OSCAT Baustein -  speziell für PC_WORX-Programmierung der Phoenix ILC 1xx ist er aber sehr praktisch.
• HOLIDAY scheint mir etwas schwer zu nutzen, da mir keine wirklich praktische Erzeugung passender Osterfeiertagstermine (logisch, mit Karfreitag, Himmelfahrt, Pfingsten) einfällt.
  

Mein Anliegen: wenn man den SETUP_HOLIDAY mit einem passenden Eingang für die Berechnung von EASTER ausstatten würde,  die Datumsteile der Variablen HD[03] aus diesen Eingängen berechnen und die Datumsanteile von  HD[02], HD[04], HD[06], HD[07], HD[08] ebenso generieren würde (Ist nicht völlig trivial aus HD[03] zu berechnen, die Monatsfindung ist lästig), dann wäre der Einsatz von HOLIDAY eine richtig runde Sache. In der gegenwärtigen Form  finde ich die Verwendung nicht wirklich praktisch, da alle "interessanten" Feiertage doch wieder händisch berechnet werden müssen. Oder habe ich etwas übersehen?

Gruß

Rainer

17

Bestehende Module / Existing Modules / Handbuch zu CALENDAR_CALC (OSCAT_BASIC_333): Eingang 'H' nicht beschrieben

« am: 03. Oktober 2013, 19:15:03 »

Hallo,

Ich sehe im Programmcode "Irgendwas mit Dämmerung", im mir vorliegenden Handbuch Im Sachstand Sonntag, 22. Januar 2012 14:40:32 der Eingang nicht erwähnt. Es wäre schön, wenn das im Handbuch erwähnt würde.

Gruß

Rainer

18

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

19

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]

20

Modulentwicklung / SPIDER_ACCESS Liest keine Daten

« am: 27. Juni 2013, 09:11:41 »

Hallo,
ich habe geplant, einige Daten für eine Phoenix ILC 155  aus einder ILC 130 (Datenquelle)  im selben Netzwerk auszulesen, beide haben umfangreiche WebVisit-Visualisierung, so dass die benötigten Daten auf der  Datenquelle verfügbar sind. Meine Programmierumfebung: WebVisit Prof. und  PC WORX Express (jeweils aktuellste öffentliche Versionen)

Lt DEMO scheint es empfehlenswert/notwendig, den Baustein zusammen mit IP_CONTROL zu betreiben,  habe ich so vorgesehen.

Ein paar Beobachtungsdetails (die Variablen rechts oberhalb der Funktionsbausteine habe ich für Beobachtungszwecke eingefügt) aus dem Debug-Modus, bei möglicherweise sehr schnellen Änderungen hinkt die Anzeige also evtl deutlich hinterher:
a) Ein Fehler passiert anscheinend nicht, jedenfalls steht die Variable auf "00000000"
b) Wenn ich im Debug-Modus etwas in  meine Variable für ausgelesene Werte SA_1_VALUE 'reinschreibe wird das wieder überschrieben.
c) SA_1_Para.C_ENABLE: Wechselt zwischen 0 und 1 (ganz grob: Sekundentakt)
d) SA_1_Para.C_IP: Zeigt meistens die IP der Datenquell-SPS, manchmal auch 00000000
d) SA_1_Para.C_MODE: Steht immer auf 0
e) SA_1_Para.C_STATE: Ich Sehe 00, 01, FF
f) SA_1_Para.ERROR: Bombenfest auf 00000000
g) SA_1_Para.FIFO, SA_1_Para.MAILBOX: wirken irgendwie "tot"
h) SA_1_Para.R_OBSERVE: Dauer-1
i) SA_1_Para.TIME_RESET Dauer-0
k) Mit SA_1_VARNAME='@GV.Allg_V_sHZBA1' bekomme ich plötzlich Massen von Fehlermeldungen  "Ausgangsstring zu kurz" von
    PC WORX EXPRESS. Das ist auf der SPS, aus der gelesen wird, ein oscat_STRING20, STRING sollte also eigentlich kein Problem sein.
    Immerhin mal eine Reaktion. Wie es scheint  kommt der Fehler grundsätzlich wenn ich (entgeben der OSCAT-Anleitung) das "GV." vor den
   Globalvariablennamen setze (auch bei INT ...)
l) Stringlängenüberprüfung mit LEN für SA_1_VALUE zeigt immer Länge=0

Meine Testumgebung:
Datenquelle: ILC 130 ETH Firmware 3.91
Datenziel mit Spider_Access:  ILC 155 ETH Firmware 3.91
Programmierumgebung: PCWORX Express 6.20.331 Hotfix 2, WebVisit  6.10.00
Lib: pcworx_network_130 Heruntergeladen von  http://www.oscat.de/community/index.php/topic,1872.0.html "Achtung Die Dateien wurden zuletzt am 27.05.2013 18:42 aufgrund von Fehlerbereinigungen aktualisiert". ;it oscat_basic_333 als Lib. eingebunden, na klar ;-)
Beobachtung: Über VPN-Verbindung zum Netzwerk mit den ILC


Mache ich etwas falsch oder gibt's ein echtes Problem mit SPIDER_ACCESS?

Gruß

Rainer

[gelöscht durch Administrator]

21

oscat.lib fuer PC WorX/MULTIPROG / OFS an CTRL_PI

« am: 24. Juni 2013, 18:15:06 »

Hallo,

nach meinen Beobachtungen arbeitet der PI-Reglung auf ILC 130 falsch.
Lt Funktionsschema sind LL und LH die abschließenden Begrenzungen des Ausgangswerts, das heißt diese Grenzen können vom Ausgang nicht überschritten werden, andererseits werden sie aber immer erreicht, wenn vom Regelungsproblem her nötig. Diese Funktion erscheint mir praxisgerecht.

Beispiel_
Tatsächlich ist es aber so, dass bei positivem OFS=20 den LH weiterhin respektiert, der "tatsächliche" unter Grenzwert aber zu LL+OFS wird. Der eingegebene LL=-100.0 wird nicht mehr erreicht, das Ausgangssignal wird unten bei -80.0 begrenzt. . Für die im Screenshot gezeigte Situation ist der "Eigentliche" unbegrenzte Ausgangswert -930.0, so dass nicht einzusehen ist, warum LL = -100 nicht erreicht wird.

Umgekehrt ist es so, dass bei OFS=-20 der LL weiterhin respektiert wird, der "tatsächliche" ober Grenzwert  aber zu LH+OFS wird.

Abgesehen davon, dass dieses Verhalten vom in der Hilfe beschriebenen abweicht, ist mir keine praktische Anwendung vorstellbar, bei der dieses Verhalten vorteilhaft wäre.

Zudem verhindert das gegenwärtige Verhalten des Bausteins eine einfache Lösung für mein Problem "Definierter Start-Arbeitspunkt für PI(D)-Regler gesucht" http://www.oscat.de/community/index.php/topic,2013.msg10508.html#msg10508. Bei Verhalten von CTRL_PI müsste ich dort beim Start der Regelung einfach einen Z
zweckmäßigen OFS wählen, der dann mein Start-Arbeitspunkt wäre.

Meines Erachtens ist das gegenwärtige Reglerverhalten ein Bug.

Grüße

Rainer

[gelöscht durch Administrator]

22

PC WorX / Falsche 'Hilfe zu FB/FU' zu CTRL_PI?

« am: 24. Juni 2013, 17:16:34 »

Hallo,

mir fiel auf, dass zumindest in der PC-WORX-Version der oscat_basic_333 Lib. das 'Kontext-Menü -> Hilfe zu FB/FU' die Hilfe zu "FT_PI" erscheint. Gewollt, weil "FT_PI" unter der Motorhaube werkelt?

Gruß

Rainer

23

Bestehende Module / Existing Modules / Definierter Start-Arbeitpunkt für PI(D)-Regler gesucht

« am: 24. Juni 2013, 17:07:46 »

Hallo,

nach der Lösung des (besser: meines) Hängenbleibe-Problems (http://www.oscat.de/community/index.php/topic,1866.msg10499.html#msg10499 scheint tatsächlich nach Wechsel auf korrekte aktuelle Lib. nicht mehr zu bestehen) Suche ich nun nach einer Möglichkeit, den Regler mit einem definierten Arbeitspunkt zu starten.

Beispiel: Zulufttemperaturregelung einer Lüftung mit Wasser-beheiztem Heizregister.

Lösungsansatz: Bei abgeschalteter Lüftung wird der Reglerausgang  per MAN=1 über MAN_I auf einen definierten wert gesetzt, der in der Regel =0.0 ist, aber per externer Auswal auch andere Werte annehmen kann, beispeilsweise über einen Zusammenhang
Außentemperatur 5°C ... -20°C ==>  MAN_I  = 0.0 ... 10.0 (um so ein Einfrieren zu verhindern, da Wärmeverlust über Alu-Klappen ausgeglichen werden muss. Das ist kein Problem. Und da bei Lüfteranlauf am nächsten Morgen der I-Anteil von heute Abend nicht mehr relevant sein wird, setzt ich den gleich mit auf 0.

Nun das Problem. Es ist absehbar, dass bei Außentemperatur -10°C wohl ein Ausgangswert von grob geschätzt 50% (für das Regelventil) erforderlich sein wird, um die gewünschte Zulufttemperatur zu erreichen, also wäre es günstig, wenn der Regler mit diesem Erfahrungswert am Ausgang starten würde, und nicht mit 0% (+ P-Anteil, natürlich). Regler für SAIA-SPS haben deshalb auch einen Parameter für "Startwert", der dann nach mit einem Witterungsgeführten Wert "gefüttert" wird und dann dafür sorgt, dass der Regler mit einem zweckmäßigen Ausgangswert startet. So erfolgt der Anlagenanlauf viel eleganter, als wenn mir beispielsweise im Winter die Temperatur erst Richtung Frostgefahr rennt, ehe über den I-Anteil allmählich ein Ausreichender Ausgangswert für das Regelventil ansteht.

Alle Trickschaltungen, die mir so einfallen, sind kompliziert (wenn Regler mit LL=-100% zugleich Kühlaufgaben übernimmt) und unzuverlässig (I-Anteil erst mal rennen lassen muss nicht unbedingt klappen, vielleicht ist wegen MAN_I  = 5.0 bei Abschaltung das Register Warm, wir haben Zulufttemperatur 28°C bei Soll 20°C, da wird der I-Anteil erst mal nicht hochlaufen. Also müsste auch noch der Sollwert für die Startphase manipuliert werden, das ist alles schlecht. Meine langjährige Erfahrung ist, dass tatsächlich ein variabler Situationsbezogener Start-Arbeitspunkt (=Start-I-Anteil) das beste Ergebnis bringt.

Die Frage nun: Gibt es einen einfachen Trick oder einen anderen OSCAT-Regler, der meinen Wunsch erfüllt?
Die Phoenix-Building-Automation-Lib. hat einen PI-Regler, der das kann, aber leider mit anderen Nachteilen behaftet ist, und die BA-Libs. werden dort m.E. etwas stiefmütterlich behandelt, so dass ich lieber einen OSCAT-Regler nehmen würde.

Grüße

Rainer

24

oscat.lib fuer PC WorX/MULTIPROG / FT_PT1: Hängt auf Phoenix ILC 155

« am: 17. Juni 2013, 19:31:42 »

Hallo,

heute konnte ich mehrfach ein Hängenbleiben des o.g. Bausteins erleben. Eine ganze Weile arbeitete er zuverlässig, aber in bestimmten Situationen bleibt der Ausgang auf seinem Wert stehen und folgt dem Eingang nicht auf 0. Alle Details im angehängten PDF. Sehr ärgerlich, da ich eigentlich hoffte, mit diesem Filter die Probleme aus "Limitierung für FILTER_I bei großen Zeitkonstanten" http://www.oscat.de/community/index.php/topic,1914.msg10043.html#msg10043 umgehen zu können

Bisher hatte ich noch keine Zeit, das Problem in einer Testumgebung auf dem Schreibtisch zu reproduzieren, problematisch ist, dass der Fehler auch an der realen Anlage nicht hundertprozentig reprodzierbar ist. Hat jemand eine Idee?

Grüße

Rainer

Nachtrag 2013-06-18: Falschen Anhang ersetzt durch  2013-06-17_Filterproblem.pdf

[gelöscht durch Administrator]

25

Modulentwicklung / Multi-Mail-Versand

« am: 08. April 2013, 15:06:14 »

Hallo,
wegen  http://www.sps-forum.de/sonstige-steuerungen/54557-ilc-150-eth-automatische-fehlermeldung.html dieses Problems  muss ich mir kurzfristig einen FB basteln, der zu grob geschätzt 100 Störmeldungen aus der Anlage, die bei einem Controller vorkommen können, die jeweils passige aus 100 E-Mails abzusetzen. Natürlich können auch mehrere (fast alle) Störungen auf einmal passieren, das muss dann schnell, aber geregelt abgearbeitet werden. Da ein solcher FB eine Ergänzung des SMTP-Client von allgemeinem Interesse sein könnte, will ich meine Überlegungen hier kurz vorstellen, evtl. können meine Experimente die Basis für einen neuen OSCAT-Baustein sein?!


Mailtext-Zuordner
Über einen SMTP_Client sollen alle (100) möglichen Störmeldungen, jeweis mit Summary und Body, abgesetzt werden. Das heißt wenn eine Störung ansteht muss dem SMTP_Client das  richtige Summary – Body – Paar per Mailzuordner angelegt werden. Die übrigen Eingänge von SMTP-Client (MailTo etc) sind für alle Störungen gleich.
Momentan würde ich einen 2. Client mit gleich aufgebautem Mailzuordner dazustellen, der auf das Service-Smartphone den Kundendienst alarmiert. Hintergrund:,  unwichtige Störungen sollen an diesen Empfänger nicht während der Nacht oder Feierabend durchgestellt werden (also gehen Sie hier an den Mailzuordner nur während einer Kernzeit, Wochenzeitschaltuhr + Feiertagsprogram)

Ins Unreine Gedacht:
Summary1 … Summary100     oscat_string 120   
Body1 … Body100                oscat_string 250
   Lokale Variablen, kann ich leicht erzeugen und Texte in PC WORX hinein kopieren
xStoerung1 … xStoerung100 BOOL    Eingänge für die jeweilige Störung
xReset       Bool   Reseteingang
xStoerAus   Bool   Ausgang Sendestörung   vom Baustein   

Zuordnungs-FB Programm Grobstruktur
...Zählt mit jedem Zyklus ein Index-SINT hoch
...Wenn zum Index Störeingang aktiv:
......Ausgabe der zugehörigen Strings an SMTP_CLIENT
......Client aktivieren (Senden)
......Warten bis „Done“ oder Fehlermeldung
......Bei Fehlermeldung Versuchezähler hochzählen und Wartezeit aktivieren
......Bei "Done" Meldungssperre, Selbsthaltung solange Fehlereingang ansteht
...Index Weiterzählen
......Wenn die Störung mit Sendefehler wieder vom Indexdurchlauf her „dran“ ist,
......erneuter Versuch, wenn Wartezeit abgelaufen
.........Im Erfolgsfall Erfolgsflag (Wiedersendungssperre Siehe oben)
.........Bei 3 Misserfolgen "Mailstörungsflag" als Stoer Boolausgang und Sperre weiterer Sendungen für diese Mail,
......  Rücksetzbar über xReset Booleingang.
...Wenn Index >100 -> Index = 1
...Endlosschleife neu ab „Zählt mit jedem Zyklus ...“
...
Besteht grundsätzliches Interesse, hier Ideen beizusteuern?

Grüße,  Rainer

26

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]

27

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]

28

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]

29

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

30

Bestehende Module / Existing Modules / Handbuch-Fehler oscat_basic333 für GEN_SIN

« am: 08. November 2012, 09:56:27 »

Hallo,

bei meinem Verusch, das Problem in "bugfix Vorschlag für FILTER_MAV_W" http://www.oscat.de/community/index.php/topic,1863.msg9851.html#msg9851 nachzuvollziehen habe ich eine Ungenauigkeit im mir vorliegenden Handbbuch bemerkt.

In der Beschreibung heißt es unter anderem:
- AM : REAL (Signal Amplitude)
- Der Eingang AM und OS legen die Amplitude ...
- einstellbarer Amplitude

Arbeit mit dem Beispielprogramm und auch der Graph im Handbuch für den Baustein-Eingang AM zeigen aber, dass der Zahlenwert vom Baustein nicht als Amplitude,  sondern als Spitze-Spitze-Wert verwendet wird; die korrekten Definitionen stehen in Wikipedia http://de.wikipedia.org/wiki/Amplitude.

Auf jeden Fall sollte das im Handbuch korrigiert werden. Für den Baustein fände ich eigentlich einen Amplitudeneingang sinnvoller, aber das ist sicher Geschmackssache, und aus Kompatibilitätsgründen ist eine Änderung wohl eher nicht empfehlenswert. Vielleicht sollte aber der Baustein- Eingang passiger benannt werden?

CU

Rainer