Beiträge

//entfällt bei S7-1200: "IDB_STIME"();
#T_PLC_MS := "System_Time_DB".ms_dw;
(* 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.
*)
IF "debug" THEN
    #T_PLC_MS := DINT_TO_DWORD((DWORD_TO_DINT(SHL(IN:=#T_PLC_MS,N:="N") OR SHL(IN:=DWORD#1,N:="N"))-1) + DWORD_TO_DINT("offset_1"));
END_IF;
 
 
(* revision history
hm  14.9.2007   rev 1.0
    original version

hm  12. nov 2007    rev 1.1
    added temporaray variable tx because some compilers could not handle time() as an argument

hm  16. nov. 2008   rev 1.2
    initialized constants with 0 for compatibility reasons
*)





//entfällt bei S7-1200: "IDB_STIME"();
#T_PLC_US := "System_Time_DB".us_dw;
(* 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.
*)
IF "debug" THEN
    #T_PLC_US := DINT_TO_DWORD((DWORD_TO_DINT(SHL(IN:=#T_PLC_US,N:="N") OR SHL(IN:=DWORD#1,N:="N"))-1) + DWORD_TO_DINT("offset_1"));
END_IF;
 
 
(* revision history
hm  14.9.2007   rev 1.0
    original version

hm  12. nov 2007    rev 1.1
    added temporaray variable tx because some compilers could not handle time() as an argument

hm  16. nov. 2008   rev 1.2
    initialized constants with 0 for compatibility reasons

*)

(* initialize at power_up *)
IF NOT #init OR #RST  THEN
    #init := TRUE;
    #in_last := #IN;
    #t_last := "T_PLC_US"();
    #i := 0.0;
    #tc := 0.0;
ELSE
    (* read last cycle time in Microseconds *)
    #tx := "System_Time_DB".us_dw;
    #tc := 1000.0/1024.0*DINT_TO_REAL(DWORD_TO_DINT(#tx) - DWORD_TO_DINT(#t_last));
    #t_last := #tx;

    (* calculate proportional part *)
    #p := #KP * #IN;

    (* run integrator *)
    #i := (#IN + #in_last) * 5.0E-7 * #KI * #tc + #i;
    #in_last := #IN;

    (* calculate output Y *)
    #Y := #p + #i;

    (* check output for limits *)
    IF #Y >= #LIM_H THEN
        #Y := #LIM_H;
        IF #KI <> 0.0 THEN 
            #i := #LIM_H - #p;
        ELSE
            #i := 0.0;
        END_IF;
        #LIM := TRUE;
    ELSIF #Y <= #LIM_L THEN
        #Y := #LIM_L;
        IF #KI <> 0.0 THEN
            #i := #LIM_L - #p;
        ELSE
            #i := 0.0;
        END_IF;
        #LIM := TRUE;
    ELSE
        #LIM := FALSE;
    END_IF;
END_IF;


(* revision history
hm 13. jun. 2008    rev 1.0
    original version

hm  27. oct. 2008   rev 1.1
    integrator will not be adjusted when ki = 0

hm  25. jan 2009    rev 1.2
    module will also work with negative K

hm  11. mar. 2009   rev 1.3
    real constants updated to new systax using dot
*)

Da geisterte ca. 2020 eine KORREKT übersetzte Oscat für die S7-1200 rum.
Ich habe sie verwendet. Die ist aber dermaßen falsch, dass ich mich zu diesem Kommentar gezwungen sehe.
Ich veröffentliche hier die Reglerbausteine im Klartext. (anders geht es nicht mehr, UND BITTE TESTEN vor dem Verwenden)
(Für meine Anwendungsfall ging es perfekt)

Verwendet wurde eine S7-1212 (FW 3.1 ist schon ziemlich alt sollte für alle neueren funktionieren)
Die Reglerbausteine (siehe folgende Blogs) wurden im meinem Fall nicht unter dem MAIN-Task verwendet sondern unter CYL (333ms).
Wenns jemand für MAIN verwenden will bitte auch vorher testen.

Dazu wurde erst mal die System_Time aus der besagten nicht funktionierende LIB verändert (im Orig.Oscat gib es dafür die T_PLC_us und die T_PLC_ms)
Systembdingt gibt es T_PLC_us, T_PLC_ms immer noch ABER VERÄNDERT siehe weitere BLOGs
Die SYSTEM_TIME sollte unter dem MAIN Task eingebunden werden


System_Time
Input                               
                                   
Output                               
                                   
InOut                               
                                   
Static                               
    Systemzeit_    DTL    DTL#1970-01-01-00:00:00    True    True    True    True       
    Systemzeit_Err_i    Int    0    True    True    True    False       
    old_systemzeit_    DTL    DTL#1970-01-01-00:00:00    True    True    True    False       
    fast_time_t    Time    T#0ms    True    True    True    False       
    ms_dw    DWord    16#0    True    True    True    False       
    us_dw    DWord    16#0    True    True    True    False       
    old_Systemzeit_MINUTE    UDInt    0    False    False    False    False       
    Minutes_    UDInt    0    False    False    False    False       
    check1_    DTL    DTL#1970-01-01-00:00:00    True    True    True    False       
    check2_    DTL    DTL#1970-01-01-00:00:00    True    True    True    False       
    check3_    Time    T#0ms    True    True    True    False       
    check4_    DWord    16#0    True    True    True    False       
    check5_    Int    0    True    True    True    False       
Temp                               
    T_DIFF_ENO_x    Bool                           
Constant                               
                                   

#Systemzeit_Err_i:=RD_SYS_T(OUT=>#"Systemzeit_");
// ************* MILLISEKUNDEN *****************
IF #"old_systemzeit_"=DTL#1970-01-01-00:00:00 THEN
    #"old_systemzeit_":=#"Systemzeit_";
END_IF;
#fast_time_t:=T_DIFF(IN1:=#"Systemzeit_", IN2:=#"old_systemzeit_", ENO=>#T_DIFF_ENO_x);
IF NOT #T_DIFF_ENO_x THEN
    #"old_systemzeit_":=T_SUB(IN1:=#"old_systemzeit_", IN2:=T#-24d_20h_31m_23s_648ms);
    #"check1_":=#"old_systemzeit_";
    #"old_systemzeit_":=T_ADD(IN1:=#"old_systemzeit_", IN2:=T#24d_20h_31m_23s_647ms);
    #"check2_":=#"old_systemzeit_";
    #"check3_":=T_DIFF(IN1:=#"Systemzeit_", IN2:=#"old_systemzeit_");
    #"check4_":=TIME_TO_DWORD(#fast_time_t);
    #"check5_":=#"check5_"+1;
    #T_DIFF_ENO_x:=TRUE;
END_IF;
#ms_dw:=TIME_TO_DWORD(#fast_time_t);
#us_dw:=SHL(IN:=#ms_dw,N:=10);      // entspricht einer DIV durch 1000, stimmt nicht ganz genau weil das ist [ms]*1024 sollte aber ausreichend sein

I have the same time-problem. I will write you a private Message with my email. If you like maybe we can do something but I think it is NOT easy. ... maybe next year when the economy works like the last 12 months ...
Hint: I have done a lot of work for the SIEMENS oscat already (in the beginning we had a good forum, now it is not interested to report a fault) ... only for around 30-oscat functions of the SIEMENS / BASIC OSCAT I needed years to make it really 100% working.

* AND here we discuss about the OSCAT NETWORK (much more complcated)

Mg

... about technical issues ...

You are right. The old libs with *23 on the end are the biggest problem. I use the BASIC in SIEMENS S7 too and I adapted it in the same way like you plan to do (dirty, but my parts I use work perfect for me).
For codesys I use the official one. There the big problem is for sure the NETWORK lib. 
I am working in a super small company too and I have no time to make real good engineered corrections on the lib. I can just report some bugs when I find one.

Regards

Mg

Hello Anton

I am happy that at least you do some investigations about 64-bit OSCAT. I am very interested. I wrote it in other posts of the forum too.
I am a frequent user of this library and I am very interested about your news.
About OSCAT ...
a) First most users are germans (me too soso, at least I am a native german speaker). So for me it is unusual to discuss technical problems in english
b) The original inviters of OSCAT they are maybe a little bit older (maybe retiered, I do not know, I hope I do not blame some ones). At least 5 years ago this library had a very active communitiy now it is a blame. But the lib is still good and I use it NEARLY ALL DAY.
c) In this moment I check the forum all 3 months around.
d) It is not possible to send some codes with OSCAT-forum. The attachments have been disabled (due to too much SPAM from ... -- NO NAMES. I understand that, but it has ruined the forum).

Mg

PS: I hope Peewit or Hugo is still interested to do this work maybe somewhen.

... die "Portierung" ... betrifft das nun die 64bit Version.
Ich kann nichts finden.

... leider gibt es die Network derzeit das nur für die 32 Bit Controller. Für 64 Bit dzt anscheinend nicht funktionsfähig. Vielleicht reicht es wenn man nur die syslibfile32 gegen die syslibfile ersetzt und die syslibsocket32 gegen die syslibsocket. Aber das weiß ich nicht. Wäre schön wenn Pewit oder Hugo Mal was dazu sagen. (zB
Wago PFC 200 geht, Wago PFC 300 geht nicht.)

[Simulation]

Nun weiß ich mehr.
In der Simulation geht es nicht mehr.
Ohne Simulation funktioniert es weiterhin "NOCH". (zumindest bei der SL und wahrscheinlich auch bei der SL MC)
Aber das Ganze muss unbedingt mit den neuen 64-bit Libs überarbeitet werden.

Ein Bild von dem Problem kann leider nicht eingefügt werden (so sinnvoll das auch wäre)

diese Meldungen gab es schon 2022. Seitdem keine Reaktion. ...

[JEDER]

Hallo Leute

Ich habe nun 2 Tage damit verbracht die OSCAT NETWORK lauffähig hinzubekommen.
Die Version im Codesys Store verwendet
SysRTC23
SysSocket23
Das hakt mit der neuen Version. Lt. Codesys ist keine 32-bit Lib mehr zulässig.
Nachdem ich x Versuche unternommen habe, habe ich die letzte Codesys Version NICHT mehr verwendet.  (bei den Oscat-Libs bin ich auf meine eigenen gegangen und habe die vom Store nicht verwendet) --- Zumindest scheint es nun zu funktionieren.  --- Korrekt ist es sicht nicht!!!

TROTZDEM: Die NETWORK-Lib MUSS professionell auf die letzt gültigen Lib's vom Codesys gespeichert werden. (64-bit)
Ich bin mir ganz sicher dass JEDER extrem viel Zeit verwendet um diese Version zum Laufen zu bringen.
Leider kann man das Ganze nicht mehr über Ihr Forum diskutieren (wenn man keine Files mehr drauf legen kann, ist es unverwendbar)
... und das Forum vom Codesys ist dafür sicher die flasche Adresse.

ICH BITTE DRINGEND UM KORREKTUR !!!

Danke

Mario

Das geht mir auch gewaltig gegen den Strich.
Ich habe noch im Jänner OSCAT_BASIC_332_TIA_V15_SP4_20190107_1107 für S7-1200 runtergeladen.
Evtl schreibst Du mir eine private Nachricht mit Deiner EMail, dann schicke ich dir das über WETRANSFER.
Aber die für die 1500er ist futsch. (habe einige Softwarebeispiele auch auf dem OSCAT-Server abgelegt ... und nun suche bin ich halt bei mir am Suchen)

Mg

Hallo Peewit

Entschuldige die späte Antwort, aber ich bin im Moment etwas am strudeln.

Der Einfachheit halber habe ich die Kommunikation mit meinem PC simuliert (am RPI läuft es ident, aber mit dem IP_CONTROL)
Mein PC hat die Adresse 10.0.0.2
Mein uLux hat die Adresse 10.0.0.122 (hier mal nur EIN Gerät, im Endeffekt sind es 2)

Die ersten 5 Pakete sind die Dinge die das uLux an das RPI sendet.
Die folgenden 9 Pakete sind die Dinge die das RPI an das uLux senden sollte.

Das mit dem UDP-Empfangen ist mir klar. (das ist bereits fertig implementiert)
Aber beim Senden muß ich eine IP-Adresse angeben (zumindest bin ich der Meinung, daß das so laufen sollte - hier fehlt bei MIR noch die korrekte Implementierung)
Port ist immer 34988

Mario

Ich kann dir auch mal einen Auszug aus dem WIRESHARK schicken.  :'( Aber ich bin im Stress.
Hab seit heute weitere uLux switche erhalten und kann das Ganze mal im Büro aufbauen und mitsniffen. (
ZEITPUNKT DAFÜR IST NOCH NICHT KLAR / heute geht es nicht)

Mario

... das Senden habe ich im Moment eh noch nicht so ganz im Griff.
Aber im Endeffekt will ich eine Störmeldung und ein paar Rückmeldungen zurückschicken.

Aber das würde bedeuten, daß das FRAGE(uLux) -> ANWORT(RPi) Spiel nicht funktioniert, da nicht immer eine Frage erst fom uLux kommt und darauf folgend eine Antwort erfolgt. Es kann auch sein daß der RPI unaufgefordert an das uLux Daten senden muss (und ich bin zumindest der Meinung dazu brauche ich die IP-Adresse des uLux)

Die Protokollbeschreibung ist im Anhang.-> siehe insbesondere Seite 7/71 "Treibergestaltung"

Mairo