Beiträge

Muss ich morgen noch mal genauer drüber nachdenken. Eigentlich aber unwahrscheinlich, da ich ja das Komplette Programm für den Email-Versand aus einer anderen, älteren SPS kopiert habe. Da läuft's, und in der neueren nun nicht?

Hallo, ich benutze seit einiger Zeit die Version mit [@_ProjInfo_@] LastChange=23.03.2017  13:19:24. Funktioniert auf diversen ILC1xx einwandfrei.
Auf auch schon nicht mehr ganz taufrischer ILC 151_44 gibt es jetzt aber das Problem, dass Emails nicht versendet werden. Versand startet, Busy bis Timeout, dann Fehlermeldung!
ERROR_C = 001E0000
ERROR_T = 5
Bisweilen alternativ Endlosschleife: Busy bis Timeout, Busy verschwindet ohne neue Fehlermeldung, neuer Versuch, Busy ...
Das Log auf dem SMTP-Server zeigt keinerlei Emailversand von dieser SPS.

Gibt's eine neuere Netlib, die ich probieren könnte, und wenn Ja, wo?
Und was sollte ich mal nachforschen?

Danke für den Hinweis, probiere ich zwischen Weihnachten und Neujahr mal aus.

Schöne Feiertage und einen guten Rutsch in ein hoffentlich vieeel besseres Jahr 2021 wünscht


Rainer

Hallo,

ich benutze die netlib. "pcworx_netlib_130" und es könnte sein, dass ich für Kommunikation mit einem SMTP-Server Port 25 Verwenden muss. An welcher Stelle gebe ich wie diesen Port vor? In der Hilfe vom 16.07. fand ich nichts konkretes dazu.

Viele Grüße

Rainer

Auf <http://www.oscat.de/linksammlung-mainmenu-34/20-sps-und-sps-programmierung.html> fand ich 2 Fehler (habe nicht systematisch gesucht, sondern nur angeklickt, was mich interessierte:
SPS@home  <http://www.sps-home.de.vu/>: "Error "Network Timeout"
Magnia <http://www.magnia.de/>: Error 500 "Internal Server Error"
ElektronikForen <https://www.elektrikforen.de/gebaeudesystemtechnik/>: "Die gesuchte Seite konnte nicht gefunden werden"

Gruß


Rainer

Hier sieht man noch mal das Ergebnis im Programm und dazu den korrekten Wert in der Quell-SPS in der dazugehörigen Visualisierung:

Von den "48.3%" an der Quelle bleibt beim SPIDER_ACCESS nur die führende "4". Das ist kein toter Wert, ändert sich der Zahlenwert an der Quelle auf irgendetwas > 50%, ändert sich der SPIDER_ACCESS - Ausgang zuverlässig auf ide erwartete "5". Das ist so bei diversen Werten und Variablen, die ich durchprobierte.

[gelöscht durch Administrator]

...  mal etwas zum testen ...

Moin,

in der Hoffnung, das SPIDER_ACCESS-Problem http://www.oscat.de/community/index.php/topic,2417.msg12545.html#msg12545 damit lösen zu können, habe ich mit Phoenix ILC131 und ILC171 die Netlib 135 statt der bisher verwendeten 130er "eingebaut". Ich nutze außer SPIDER_ACCESS nur SMTP_CLIENT, das problemlos, soweit ich das bisher sehen kann; Anlagenfehler wurden anstandslos per Email gemeldet.

Nicht ganz unerwartet: kein Erfolg beim SPIDER_ACCESS-Problem.

Aber ich fand einen kleinen Fehler in der DOKU:

Bei SPIDER_ACCESS steht "Die genaue Bedeutung von ERROR ist beim Baustein HTTP_GET nachzulesen". Dort wird aber für ERROR-Erläuterungen weiter nach IP_CONTROL verwiesen, sollte dann nicht bei  SPIDER_ACCES direkt nach IP_CONTROL verwiesen werden?
Ansonsten gibt es noch verschiedene Rechtschreibfehler, Zufallstreffer:

Falsch                              Richtig
-------------------------------------------------------------------------
unterWWW.OSCAT.DE         unter WWW.OSCAT.DE
weiter.IRTRANS_RCV_1        weiter. IRTRANS_RCV_1
...type                              ...typ                                                              (recht oft)

Bei Interesse kann ich nach Absprache mal eine vollständigere Korrekturliste erstellen.

Gruß

Rainer

[a)]

Es wäre interessant was genau uebers Netzwerk kommuniziert wird. Kannst du einen wireshark mitschnitt machen ?

Moin,

von der Kommunikation zwischen den SPSsen? Keine Ahnung, wie das gehen sollte.

Da es gerade mal wieder praktisch gewesen wäre, die Funktion nutzen zu können, hab ich noch einmal etwas geforscht. Ergebnisse:
a) Das Problem ist nicht auf REAL-Werte beschränkt, ich sehe dasselbe Problem beim Lesen von INT-Werten, wahrscheinlich ist es ein grundsätzliches Problem, dass nur die führende Ziffer ausgelesen (oder angezeigt?) wird.

Die beiden folgenden Screenshots aus einer Phoenix ILC131 (pcworx_network_130) wurden kurz nacheinander erstellt, der Wert der Variabelen in der QUELL-SPS ((für den Test manipulierter) Außentenperatur-Messwert * 10) war grob bekannt.

Wie ließe sich jetzt der Verdacht erhärten, dass die Ursache des Problems ein falscher Wert (=0)  für "BODY_LEN" ist? Am praktikabelsten fände ich immer noch eine Screensharing-Sitzung, damit ein Experte mal zum Debuggen über meinen PC in die SPS  reingucken kann.

Da ich eh schon mal am Probieren bin werde ich für eine neue Version dieses Projekts eine aktuelle netlib verwenden.


[gelöscht durch Administrator]

Gerne möchte ich meine Grundfos Magna3 Solarpumpe (0-10V) anhand der maximal zur Verfügung stehende Leistung ...

Deine Wirkungsgradüberlegungen kann ich nicht nachvollziehen. So aus dem Bauch würde ich sagen, das beste Ergebnis wird erreicht, wenn das Wasser genau mit der Temperatur aus dem Kollektor kommt, die Du für deine Heizzwecke brauchst!? Höhere Temperatur verschenkt voraussichtlich Wirkungsgrad, siehe auch hier http://www.paradigma.de/vakuum-roehrenkollektor! Höhere Pumpendrehzahl wenn zu warm, niedrigere Pumpendrehzahl wenn zu kalt.

Oder kommen Deine inzwischen vielleicht vorliegenden Messungen zu einem anderen Ergebnis?

Schade. Aber: Einem geschenkten... Die Bibliotheken sind ja wirklich sehr gut und können einem sehr viel Programmierarbeit ersparen.

Ich hatte mich hier http://www.oscat.de/community/index.php/topic,2514.msg12990.html#msg12990 ja schon mal besorgt über den mangelhaften Projektfortschritt geäußert. Auf der Downloadseite findet sich hauptsächlich alter Kram, Stand 2012 ... 2015 (nicht systematisch erforscht). Das meiste davon läuft zwar gut, ich benutze OSCAT quasi täglich. Aber diese offensichtliche Vernachlässigung vermittelt nach außen den Eindruck eines sterbenden Projekts für eine abnehmende Zahl von eingefleischten Fans.  Gelegentlich finden sich irgendwo eingestreut http://www.oscat.de/community/index.php/topic,2514.msg13231.html#msg13231 aktualisierte NETLIB Versionen, die "eigentlich" seit Jahren um Klassen besser laufen als 121 auf der Downloadseite, aber leider sucht man auf der Downloadseite vergeblich. Die "frequent releases and updates" aus der OSCAT-Präsentation sehe ich nicht so recht.
Dabei wäre Abhilfe doch einfach. Die Handbücher sind wohl mehr oder weniger alle mit OOo / AOo / LibO erstellt, die haben ein Versionsmanagement. Jemand, der sich berufen fühlt (ich hatte meine hilfe schon mal angeboten), führt die notwendigen Änderungen durch â†'  einer der "Alten Hasen" kontrolliert die Updates (dank Versionsmanagement leicht im Dokument aufzufinden)  â†' fertig â†' Update im Downloadbereich â†' ganz fertig.

Ob ich für einen Verfahrenstest mal die Quelldatei haben könnte, um den Verweis nachzutragen?

Es wäre schön, wenn ein entsprechender Hinweis in das PDF-Handbuch übernommen und eine aktualisierte Fassung des Handbuchs in den Onlinebereich eingestellt werden könnte.

Rainer

Hast du rausgefunden ...

Hallo,

nein, ich war nur darüber gestolpert, weil ich das evtl. für ein Projekt gebraucht hätte, aber das hat sich dann zerschlagen.

Beim aktuellen Problem glaube ich nicht daran, dass ein wirkliches ID-Problem besteht, da die Debug-Anzeige ja passt. Interessanter wäre wahrscheinlich zu ergründen, auf welcher Basis NET_VAR_CONTROL RUN zum Ergebnis "Error = 00000001" kommt. Ich kann nur vermutne, dass es um die angezeigte ID eines NET_VAR_BOOL8 oder NET_VAR_REAL8 geht?

Ich stelle kurzfristig die Projekte online, denke allerdings nicht, dass das zu irgendetwas führt.

Irgendwie ist in der Kombination Phoenix-ILC  /  PC-WORX Express  /  OSCAT NetLib130 gerade der Wurm drin, wobei ich keinesfalls ausschließen kann, dass das Problem durch irgendeine Besonderheit hier bei mir verursacht wird.

Den Behelf aus Posting 19. April 2016, 16:02:45 versuchte ich weiter zu entwicklen, natürlich jede Neuerung in neuer Projektversion. Einfach testhalber 2 Spider_ACCES zugriffe in derselben Richtung eingefügt, funktioniert. 3. Drangehängt - Exitus, keiner funktioniert mehr, weg damit.

Alle Versuche übrigens stets nur am Slave!

Dann NET_VAR_CONTROL Variante für Verbindung ausprobiert. In dem Projekt laufen diverse solche Verbindungen problemlos. Habe gznächst als Master die Empfängerseite eingerichtet, dann Slave in der Sender-SPS. Gestartet, geht nicht, stets Error FF000000 oder FD000000 oder 00000001.
Als ich keine Lust mehr hatte habe ich die alte ursprünglich funktionierende Version wieder eingespielt, bei der dann plötzlich die ursprüngliche  NET_VAR_CONTROL auch nicht mehr funktionierte, Error 00000001 beim Slave. Hier nun aber kein ID-dreher, die Zuordnung der ID "1" und 22" war bei den Bausteinen NET_VAR_BOOL8 und NET_VAR_REAL8 passig bei Master und Slave.

Also Notfallplan mit Uraltversion in voriger PC-WORX Express Version eingespielt - Läuft auch nicht! Bis hierher also einzige halbwegs sichere Schlussfolgerungen, dass ich bisher nur eine Sammlung von Zufallsbeobachtungen habe, die alle nicht den Kern des Problems im Fokus haben.

Ich habe dann ein paar Kaltstarts am Slave durchgeführt, ohne sonst irgendetwas zhwischen den Kaltstarts an Programm oder Parametern zu ändern:

Standardablauf:
1) Kaltstart
   Â» Alle Übertragenen Werte auf 0, NET_VAR_CONTROL RUN = Error = 0
2) Nach Zeitablauf:  NET_VAR_CONTROL:ENABLE  â†' 1
   Â» Für Sekundenbruchteil RUN = 1  --  Error = 0
     Dann RUN = 0  --  Error = 00000001, alle Übertragungswerte weiterhin 0

Manchmal:
11) Kaltstart
   Â» Alle Übertragenen Werte auf 0, NET_VAR_CONTROL RUN = Error = 0
12) Nach Zeitablauf:  NET_VAR_CONTROL:ENABLE  â†' 1
   Â» Für Wenige Sekundenbruchteile bis Sekunden,  RUN = 1  --  Error = 0, Werte werden übertragen, scheinen auch "zu leben"
     Dann RUN = 0  --  Error = 00000001 (Baustein falsche ID), alle Übertragungswerte eingefroren

Dann glückliche Fügung:
21) Kaltstart
   Â» Alle Übertragenen Werte auf 0, NET_VAR_CONTROL RUN = Error = 0
22) Nach Zeitablauf:  NET_VAR_CONTROL:ENABLE  â†' 1
   Â» Dauerhaft  RUN = 1  --  Error = 0, Werte werden übertragen, "leben"
     Das bisher die ganze Nacht, wahrscheinlich auf ewig

Dass so ein Kaltstart manchmal zum korrekten Anlauf führt, meistens aber nicht ist ja doch merkwürdig, und die Fehlermeldung noch merkwürdiger, irgendeinen realen Hintergrund kann ich nicht erkennen.

Irgendeine Idee, wie man dem Effekt auf die Schliche kommen kann? die beiden Programme kann ich dir zwar schicken, aber ob sich damit ein Testaufbau realisieren lässt?
Alternativ könnte ich dir natürlich auch mal zugriff auf die Anlage Gewähren, wenn Du meinst, dass direkte BEobachtung des Effekts weiter helfen könnte.

Wie ich wohl irgendwo schon sagte will ich für Nachweiszwecke jeweils Monats-Logs per E-Mail schicken. Im Fehlerfall wird u.U. sofort eine Kopie der Datenaufzeichnung  benötigt. Mir fällt dazu bisher ein:

a) Einfach nach Knopfdruck auf dem Bedienpanel (Ich benutze SpiderControl) an den Namen am Eingang von DLOG_STORE_FILE_CSV:FILENAME temporär ändern ("Sofortsendung" per CONCAT anhängen oder ähnlich), was dann eine Sendung der bis zu Namensänderung veranlassen würde. Da der alte Baustein gelöscht wird besteht auch kein Datenüberschreibungsproblem, wenn das aber öfters hintereinander gemacht wird mcht das die Dateiablage doch recht unübersichtlich.

b) Einfach meine zusätzlich vorhandene Stöe-Email-Konstruktion benutzen.  Nach Knopfdruck auf dem Bedienpanel eine Störmeldung "Diagnosedatenübertragung" (oder so) generieren, bei dem dann die aktuelle mit Speicherdatei verschickt wird. So lange schalte ich lieber das Loggen an DLOG_STORE_FILE_CSV_ENABLE ab? Bei einer Zufallsbeobachtung schien mir die ILC an der ca 500kB großen Datei deutlich länger als 1 Minute zu rödeln. Jedenfalls hätte das den Vorteil, dass es keine Extra-Dateien gibt.

c) Oder irgendein viel besserer Trick?

Gruß

Rainer