Beiträge

Hallo Leute

... die Entwickler   :-X (eigentlich traurig)
Ich habe das nun selber probiert. Aber ich habe leider keine Station zum Probieren zu hause (muß das immer bei einer in Betrieb befindlichen SPS über VPN machen und dabei stelle ich bei einem Fehler u.U. gleich einen ganzen Betrieb ab!!!)
Trotzdem konnte ich nicht mehr länger warten und testete mal an dem ganzen Zeugs rum. Im Endeffekt habe ich das folgendermaßen gemacht ...
Die folgende Änderung sollte meiner Meinung funktionieren aber das Ganze kann ich erst nach 18 weiteren Tagen sagen (dann kommt es zum nächsten Überlauf)
So lange ist das Zeugs noch ungetestet!

Code Auswählen Erweitern

(* // START -------------------------------- DAS IST MEINER MEINUNG FALSCH (mg 5.8.2014) --------------------------------------------
(* read actual startup info *)
(* OB1_SCAN_1  BYTE  -  B#16#01: Abschluss des Neustarts (Warmstarts)
                     -  B#16#02: Abschluss des Wiederanlaufs
                     -  B#16#03: Abschluss des freien Zyklus
                     -  B#16#04: Abschluss des Kaltstarts
                     -  B#16#05: Erster OB 1-Zyklus der neuen Master-CPU nach
                                 Master-Reserve-Umschaltung und STOP des
                                 bisherigen Masters *)

#ERR := RD_SINFO (TOP_SI => #TOP_SI, START_UP_SI => #START_UP_SI);

(* read system time *)
#tx := DINT_TO_TIME(DWORD_TO_DINT("T_PLC_MS"()));

(* reset last_time on system startup *)
IF #TOP_SI.EV_NUM = 1 OR #TOP_SI.EV_NUM = 2 OR #TOP_SI.EV_NUM = 4 THEN
    #init := false;
END_IF;
 
(* initialize on startup *)
IF NOT #init THEN
    #init := TRUE;
    #last := #tx - #PT;
END_IF;
*)
// ENDE -------------------------------- DAS IST MEINER MEINUNG FALSCH (mg 5.8.2014) --------------------------------------------
// und wird ersetzt durchf die folgenden 2 Zeilen *)

"IDB_STIME"();
#tx := "IDB_STIME".tx;

(* hier muss die korrektur für step7 stattfinden
plctime muss den vollen wertebereich von time ausnutzen:
wenn bei step7 time -24tage bis plus 24 tage ist dann muss der timer auch beim überlauf auf -24tage springen
und auf keinen fall auf 0 !!!!
für siemens muss ein weiterer fb im main eingebunden werden der sicherstellt das alle 32 bits durchgezählt werden.
es kann nur ein fb sein den er muss sich das oberste (32te) bit merken.
oder etwa spring s7 bei überlauf auf -24 tage????? dann wäre keine korrektur nötig.
*)

(* generate output pulse when next_pulse is reached *)
#Q := #tx - #last >= #PT;
IF #Q THEN #last := #tx; END_IF;
 
 
(* revision hiostory

hm 25 feb 2007  rev 1.1
    rewritten code for higher performance
    pt can now be changed during runtime

hm  17. sep 2007    rev 1.2
    replaced time() with t_plc_ms() for compatibility reasons

hm  25. oct. 2008   rev 1.3
    optimized code
   
mg   5. aug. 2014   rev 1.4
    problem with the internal-time variable after the overflow
*)

Naja ich habe schon was rausgefunden.

In der STIME_V1_5 wird ein ähnliches Verfahren verwendet. Das war anscheinend ein großes Problem dort.
ABER: ... da mir die Erklärung dieses Bausteins zu sparsam ist, kann ich den CLK_PRG zwar auf das selbe System ändern, aber was dort drinnen wirklich 100%tig passiert, ist mir noch nicht bis ins letzte Detail bekannt UND solange bleibt das für mich eine Problem.

Obs funktioniert weiß ich auch nicht, ... evtl weiß jemand wie ich das am besten testen soll!

Mario

HIER WÄRE EINE HILFE VON GKOBLER ODER DALBI HILFREICH.

T_INT ist der Raumsollwert

wenn Du 22°C im Raum willst ist er halt 22°C
wenn Du lieber 28°C im Raum willst ist er 28°C

ABER: Das heißt nicht, daß Du 28°C im Raum bekommst.

Die Heizkurve berechnet aus einer Außentemperatur eine Vorlauftemperatur. Und wenn die Kurve korrekt eingestellt ist erhaltest Du mit dieser berechneten Vorlauftemperatur eine konstante Raumtemperatur und wenn Du nun T_INT um 1°C nach oben nimmst, wird deine tatsächliche Raumtemperatur um 1°C nach oben gehen.

ABER alles nur Theorie:
- keine Sonneneinstrahlung
- kein Wind
- keine Personen im Raum
- keine Küche in der gekocht wird
- keiner Lüftet
- keine Tür geht auf und zu.
uvm.

Das Ganze sollte UNGEFÄHR eine Vorlauftemperatur ergeben. Viele Parameter müssen geschätzt werden und die Einstellung braucht schon eine gewisse Erfahrung (da hilft einem auch der Installateur nicht weiter).

Viel Spass

PS: Es ist Sommer, HEAT_TEMP ... wofür???

Hallo Leute

Programmiersystem: TIA12 SCL
Controller: CPU315
Baustein im Oscat: CLK_PRG

Nach einem Änderungsdownload wurden alle (od. viele, das kann ich im nachhinein nicht mehr sagen) Baugruppen gestoppt und neu gestartet.
Danach stand der Wert für "last" auf einem niedrigen negativen Wert (3-stellig), aber der Wert für "tx" irgendwo im x-stelligen negativen Bereich (-24Tage und noch ein bischen was).

Der PWM_DC rechnet aus der Differenz der beiden eine Zeit aus die dem Taktzyklus entsprechen sollte. Das würde heißen, daß der PWM_DC dieser Wert in meinem Fall erst in 24 Tagen korrekt funktioniert.

Die Initialisierung des CLK_PRG hat offensichtlich NICHT funktioniert.

Es wäre schön, wenn man in einem der folgenden Updates auch diesen Fehler mal eliminieren könnte.

Vielen Dank

Mario

Habs nochmals bei einer CPU 315 probiert.

Hier reicht "#out=#out" nicht da braucht es die Abfrage  "#out<+3.402823e+38 AND #out>-3.402823e+38"

Ein Test mit der CPU 1513 steht noch aus.

Hallo Leute

Testbedingungen: CPU 314
Software: TIA12

a) warum der Baustein den Überlauf/Divison durch 0 oder sonst was für einen Fehler hat, kann man nach 1 Jahr Betrieb nicht mehr 100%tig rekonstruieren.
b) definitiv stürzt der Baustein bei einem solchen Fehler ab. Das bedeutet der Baustein geht bis in den Nimmerleinstag auf out 16#7FFFFFFF

Nach SEHR vielen Tests und viel Kopfzerbrechen verstehe ich wieso hierzu niemand antwortet:
Den Code "NAN" oder "16#7FFFFFFF" kann man mit herkömmlichen Mitteln nicht abfragen. Es soll zwar irgendwo ("ganz sicher") ein ENO Bit für eine fehlerhafte Berechnung gesetzt werden aber auf das wollte ich mich nicht verlassen (diese Funktion kann man evtl. sogar ein- bzw. ausschalten). Aber das ganze Zeugs mit dem (ENO-Bit, Ok-Bit, OV-Bit und VIELE Kostrukte mehr) funktioniert im TIA anders wie im STEP 7/5.5 und sowieso anders im KOP,AWL,SCL. Für die Abhandlung der Überläufe gibt es für jede Sprache,Software eigene Sonderlösungen  >:( (der Support hat mir da auch nicht wirklich helfen können). ZUMINDEST BEI MIR HAT EIN DERARTIGER FEHLER NOCH NIE ZU EINER FEHLERMELDUNG IN DER SPS GEFÜHRT - "DIAGNOSE" IST SOMIT SINNLOS (ich bin bisher nur zufällig auf diese Fehler gestoßen - aber vielleicht weiß da jemand einen Trick - WÄRE SEHR DANKBAR).

Irgendwann habe ich dann mal erkannt, daß eine IF-Anweisung bei der auf eine solche Zahl abgefragt wird IMMER in den ELSE-Zweig rennt. Und genau hier liegt das Problem des FT-T1. Die Lösung ist ganz simpel:


(* read system time *)
#tx := "T_PLC_US"();
 
(* startup initialisation *)
IF #init AND #T <> t#0s  AND #out<+3.402823e+38 AND #out>-3.402823e+38 THEN
  #x1:=DWORD_TO_DINT(#tx) - DWORD_TO_DINT(#last);
  #x2:=DINT_TO_REAL(DWORD_TO_DINT(#tx) - DWORD_TO_DINT(#last));
  #x3:=(#in * #K - #out);
  #x4:=(#in * #K - #out) * DINT_TO_REAL(DWORD_TO_DINT(#tx) - DWORD_TO_DINT(#last));
  #x5:=DINT_TO_REAL(TIME_TO_DINT(#T)) * 1.0E-3;
  #x6:=(#in * #K - #out) * DINT_TO_REAL(DWORD_TO_DINT(#tx) - DWORD_TO_DINT(#last)) / DINT_TO_REAL(TIME_TO_DINT(#T)) * 1.0E-3;
  #out := #out + (#in * #K - #out) * DINT_TO_REAL(DWORD_TO_DINT(#tx) - DWORD_TO_DINT(#last)) / DINT_TO_REAL(TIME_TO_DINT(#T)) * 1.0E-3;
  IF ABS(#out) < 1.0E-20 THEN #out := 0.0; END_IF;
ELSE
  #init := TRUE;
  #out := #K * #in;
END_IF;
#last := #tx;


(+/- 3.402823e+38ist eigentlich irrelevant. Es reicht irgendeine Abfrage statt AND #out<+3.402823e+38 AND #out>-3.402823e+38 kann man auch richtigerweise AND #out=#out verwenden ... das sieht aber dann sehr suspekt aus!)


Für mich taucht nun noch ein weiteres Problem auf. Ich will natürlich nicht alle Funktionen der SIEMENS OSCAT nach Rekursionen durchschauen. Da werde ich nimmer fertig. Kann man in einem zukünftigen Release diese Problematik bei der S7 vielleicht berücksichtigen.

Naja ich verwende einiges mehr.  ... kann sich aber je nach Projekt ändern .... folgend ein Beispiel

SCALE_R
TEMP_PT
HYST_2
ONTIME
PWM_DC
PT_PIDWL
FT_T1

Natürlich ist die Adaption uU. ein bischen tricky aber gerade der PID-Regler ist einfach perfekt.
Im Großen und Ganze habe ich keine Probleme. (ein Neuer ... siehe Eintrag ... allerdings mit FT-T1 bei einer S7-300).

Im Großen und Ganzen finde ich die S7-1500 SUPER im Gegensatz zur 300er.
Es gibt mir dort einfach zuviele Einschänkungen die ich nur mit Tricks umgehen kann.

Ich werde es auf jeden Fall weiter im Auge behalten.

Hallo Leute

Strg: S7-300
Portal: TIA12 SR4
Oscat: STEP7-TIA-V3.32

Nun habe ich einen Fehler im FT-T1 entdeckt. Der geht irgenwann oder irgendwie mal in den Überlauf:
"out" steht dann ein für allemal auf 16#7FFFFFFF.
Aber ich bin der Meinung daß dieser Fehler auf alle Funktionen zutrifft. Es wird in den Oscat-Funktionen kein Überlauf abgefragt (und schon gar nicht wie wie in der S7 mit dem Statuswort - mit abfragen und löschen) und die Siemens-Steuerung speichert die Überlaufmeldung bis sie gelöscht wird, dh.: wenn mal eine Variable in dem Überlauf rauscht wird die nie mehr berechnet. (im AWL mit der Funktion SPS im SCL bin ich noch am studieren wie ich das bestens lösen soll).
Dieses Problem hatte ich in der einen oder anderen Art schon bei meinem Code nun aber auch im original OSCAT Code

Vielen Dank

Mg

Hallo Gkobler

Erst mal Danke (ich habe zwar die V13 noch nicht und bin mir nicht sicher ob ich nicht gleich in einem Schwung auf die V14 gehen soll)

Warum glaubst Du daß die BIB nicht bei der 1500 gehen soll. Ich habe derzeit nur Probleme mit den Timern. Aber das läßt sich in verhältnismäßig kurzer Zeit korrigieren. Gibts sonst noch Probleme?

Danke Mario

Hallo Leute

Ich habe mal vor ca. 1 Jahr versprochen ich werde mal die migirierte Version von GKOBLER laufen lassen und eine Rückmeldung geben.
Nun hier mein Resume:
a) Die Einbindung der Oscat ist mir verhältnismäßig großem Aufwand verbunden, da das Ganze nur als Programm (nicht als Library) eingebunden werden kann.
  Es bedarf schon etwas Zeit um die Abhängigkeiten der Bausteine und der Datentypen usw. herauszufinden. Das ist eine Art "try-and-error"-Hürdenlauf.
b) Ich habe einige Regel-FB's (PID-Regler - das Ding ist einfach SUPER!!!) und auch diverse math. FB's verwendet. Im Großen und Ganzen funktionieren die (BEACHTE UNBEDINGT DIE HINWEISE zu "S5-TIME" ohne das funktioniert das System nur ca. 1-2 Wochen)
c) Ich habe keine Textbausteine und Kalenderfunktionen verwendet (da gibt es immer noch viele Warnmeldungen, aber dafür hatte ich auch keine Verwendung)
d) Ich habe die Anzahl der verwendeten Bausteine gering gehalten (ca. 30-40Stk.), bei einigen habe ich die Funktion angezweifelt, einige habe ich untersucht und da waren auch in der Codesys-Version Fehler drinnen (insbesondere in der building.lib - siehe auch meine anderen Kommentare)

Ich habe 4 größere Anlagen (je Anlage >200DP) in Arbeit, 2 laufen seit 1/2 Jahr einwandfrei. 2 stehen noch zur IB aus.
Die FB's und FC's funktionieren so weit ich das ausprobiert habe gleich gut wie im Codesys.
Natürlich wird Oscat hauptsächlich für Codesys verwendet. Ich war aber SEHR froh über die Hilfe die mir GKOBLER gegeben hat und werde OSCAT in Zusammenhang mit S7-TIA sicher weiter verfolgen.

VIELEN DANK

Mg

Und noch was in eigener Sache (bitte das nicht kommentieren - sind meine eigenen Erfahrungen und müssen sich nicht mit anderen Erfahrungen decken): Trotzdem wäre es schön, wenn in Zukunft mehr auf S7-TIA eingegangen wird. Für mich ist das einfach die Zukunft. Das alte STEP7 ist eigentlich tot, auch wenn es viele nicht wahr haben wollen. Ich bin inbesondere mit der S7-1500 sehr zufrieden. Das Gerät bieten gravierende Vorteile (AUCH IN DER PROGRAMMIERBARKEIT) gegenüber der alten S7-300. Ich habe faktisch in der ersten Minute umgestellt und leider auch ein paar Kinderkrankheiten mitgemacht. Summa sumarum wundert es mich trotzdem schon ein bischen, daß viele User so auf dem Uralt-System (S7-300) beharren wollen.

Hallo Pewid

habe nun alle Punkte mal durchprobiert ... ohne Erfolg:

1. wenn mehrere email empfänger vorhanden sind -> nur einen zu probieren
habe auch mal mich selbst ausprobiert (ging auch nicht)

2. andere adressen ausprobieren
siehe oben

3. smtp_mailfrom: STRING :='Tianjin.EMess@xlxlx.com;EMessg_Tianjin';
  lass mal den zusätzlichen namen hinten weg
... ist weg ... kein Unterscheid

  ich habe mal vor monaten hier einen fehler korrigiert
   (in der network lib 1.30 sollte dieser behoben sein)
auch das funktionierte nicht.

Ich werde mal in ca. 1 Monat dort rüberfliegen und mit wireshark mitschauen was da passiert.

Mario

PS: von der V1.30 kursieren mehrere Versionen im Forum. Welche sollte verwendet werden?

Hallo Peewid

Das wäre kein Problem. Das habe ich bereits auch schon gemacht. ABER ich kann den lokalen Mail-Server nicht simulieren. Ich kann es nur mit dem GMX-Server testen und da ging es!

Deswegen würde es mir unheimlich helfen, wenn ich wüßte was im Schritt 95 genau passieren sollte.

Danke

Mg

PS: Ich werde mal einen Test mir der V1.3 bei mir zu Hause machen und das dann da rüber senden.

Hallo peewit

Nein es hat noch gar nie funktioniert. Hatte monatelang Probleme mit der firmeninternen IT. Ich glaube ich habs nun auf der Reihe (hoffentlich)

Ich hatte vor langer-langer-langer Zeit das Ganze mit Eurem GMX Accout getestet und da ging es.

Controller: Wago 750-880
Network-Lib: 1.21
Oscat-Lib: 3.33

Das nächste Problem ist, daß ich nur von ca. 3°° morgens bis 7°° morgens einen ausreichenden schnellen Zugriff auf die Steuerung habe (sonst ist die Verbindung so miserabel, daß jeder Test sinnlos ist), somit braucht jeder Test einen Tag. Das sollte aber kein Problem mit dem EMail-Server sein, da der ja lokal sitzt.

Für mich wäre wichtig was beim Schritt 95 ganz genau ausgeführt wird. Ich habe schon mal die Lib angeschaut aber so richtig schlau bin ich nicht daraus geworden. Ich nehme mal an, daß die "501" vom email-server kommen, somit muß die Verbindung ja stehen. Lt. wikipedia soll 501 ja bedeuten, daß die EMail-adresse falsch ist:
   smtp_server: STRING := 'xnxix-xmxp.xlxlx.net'; (*Passwort gibt es keines*)
   smtp_mailfrom: STRING :='Tianjin.EMess@xlxlx.com;EMessg_Tianjin';
   smtp_mailto: STRING(STRING_LENGTH) :='xtxfxn.xexzxex@xlxlx.com';
(wurde leicht verändert wegen SPAM)



Danke für Deine Hilfe

Mg

PS: Normalerweise wird das Ganze nur 1x pro Monat angestoßen, somit kann es sein, wenn ich das Ganze testweise laufen lasse, daß kein Text oder keine Dateien übertragen werden (hier ist der Text nicht eingetragen) aber das sollte ja keine Rolle spielen.

[gelöscht durch Administrator]

Hallo Leute

Ich habe einen SMTP-Baustein mit folgenden Fehlermeldungen

ERROR-C:5
ERROR-T: 5F01F5

Das sollten ja die Fehler vom IP-CONTROL sein. (... Korrektur: diese Aussgae ist falsch / von mir)
Somit bedeutet das:
> step=95
> rcv_state=501


Der Controller (Wago 750-880) hängt irgendwo in China. Ich habe einen miserablen Zugriff über VPN darauf. Lt. Kunde sollte sein EMail jetzt funktionieren.

Wie soll ich weiter verfahren?

Mario

... ein ganz später Kommentar vielleicht hilfs dennoch.

Also ich mache das so:

Der Regler startet immer bei 0!
0 muß aber nicht wirklich der Nullpunkt sein.
Wenn man den Regler nun von low=-0.5 auf high=0.5 regeln läßt sitzt dieser Punkt in der Mitte.
Danach kann ich die Werte wieder umrechnen zB -0.5 ist 0 und +0.5 ist 1.
Dann startet der Ausgang zB in der Mitte bei 0.5

Vielleicht hilfts