Beiträge

[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

Hallo Peewit

Werde ich ausprobieren. Das mit dem MODE habe ich komplett übersehen. Man sieht vor lauter Bäumen den Wald nicht mehr.

Trotzdem noch ein Frage. Wenn ich nun auf den uLux schreibe, wie kann ich mit dem IP_CONTROL auf einen uLux mit einer definierten IP-Adresse schreiben. Ich kann im IP_CONTROL nur "eine" IP_Adresse angeben. ... ODER muss ich bei jedem Versand des S_BUFFER die IP_Adresse dementsprechend im Baustein anpassen.

Mario

Hallo Peewit

uLux ist der Client
RPI ist Server

Der Original IP_CONTROL IST IM uLux enthalten.

Beachte export als V3 (gezippt sonst hats 40MB)

Danke

Mg

KONFIGURATION:

RPI: 10.0.5.120
   netstat -tulpen | grep 34988
   udp        0      0 0.0.0.0:34988           0.0.0.0:*                           0          15130      -
uLux1: 10.0.5.121 Port 34988
uLux2: 10.0.5.122 Port 34988

Eigentlich sollte das Ganze bidirektional funktionieren. (RPI zu "uLux1 oder uLux2" und "uLux1 oder uLux2" zu RPI)

zu deinem Kommentar ...
mit mehreren geräten mit unterschiedlicher ip und gleichen port zu kommunizieren ist mal kein problem
Da täte mich interessieren WIE ?

Ich bin der Meinung das müsste mit "1" IP_CONTROL gehen. Einen 2ten kann ich nicht verwenden, weil nur einer auf ein Socket gehen kann. Und je PORT gibts nur 1 Socket (oder verstehe ich da was falsch).


Mario

Hallo Peewit

Ich scheibe dich mal persönlich an (Aber vielleicht weiß da auch jemand anderes Bescheid).
Es geht um eine Anlage mit CODESYS 3. Dort verwende ich zum Auslesen eines Gerätes IP_CONFIG.
Ich weiß, daß es nicht für CODESYS 3 getestet ist, aber ich bin der Meinung, daß dieser Teil sehr gut funktioniert und ich glaube mein Problem ist ein Grundsatzproblem, das auch CODESYS 2 betrifft.

Ich habe bisher das Ganze mit einem RPI und einem sogenannten "uLux" (ist ein parametrierbares Bediengerät im Steckdosenformat). Wenn ich 1 Gerät verwende funktioniert das super (hier gab es schon Mal einen Betrag http://www.oscat.de/community/index.php/topic,2543.msg13201.html#msg13201)

Wenn ich nun 2 uLux an das RPI hänge, gehen meine bisherigen Verbindungen nicht mehr da:

a) Jedes uLux hat eine eigene IP-Adresse
b) Jedes uLux hat den selben Port und kann nur UDP. (Ich kann den Port nicht ändern und die Verbindungsart nicht ändern)

Aus b) ergibt sich, daß ich am RPI nur einen geöffneten Port für beide Gerät habe

Wenn ich nun mit IP_CONFIG verbinde muß ich eine IP-Adresse verwenden.

Frage 1:
Im einfacheren Fall bekomme ich nur Daten -> welche IP-Adresse muß ich beim IP_CONFIG einstellen.
Frage 2:
Wie mache ich das wenn ich nun den beiden uLux, Daten schicken muß. Ich kann ja nicht nur auf eine IP-Adresse die Daten schicken und im IP-CONFIG kann ich nur eine einzigste vorgeben.

Ich habe es auch schon mit 2x IP-CONFIG probiert, das läßt das System nicht zu, da ein Socket nur 1x geöffnet werden darf.

WO DENKE ICH HIER IM KREIS? WAS MACHE ICH FALSCH?

Mg

PS: Fehler am IP_CONFIG 16#02000000. (wenn ich den IP_CONFIG doppelt anlege)

Hallo Leute

Ich habe da mal eine Frage/Idee:
Wenn ich die Uhrzeit syschronisiere, wie verhalten sich die Oscat Libs.
zB: Wenn ich einen FT-PID verwende und nun erfolgt eine Uhrzeitsynchronisation und nehmen wie mal an, die Uhrzeit stimmt um einen deutlichen Betrag nicht mehr:
Wie beeinflusst das den PID bezüglich des D und des I Anteils

Ich glaube das Problem könnte viele Bausteine betreffen.

Mg

Hallo

3 Posts weiter oben ist schon WIEDER der falsche STIME im Umlauf. Bitte nicht irgendwelche fehlerhaften Bausteine neu veröffentlichen.
-> siehe posts von "PSYCHO"

Danke

Es gibt eine Version 1.6. DAS IST SEHR WICHTIG. DIE BAUSTEINE BLEIBEN SONST UNVERMITTELT STEHEN (bei der S7-300, bei der S7-1500 funktionierts auch mit der V1.4, aber ich würde das Ding so nicht verwenden!!!)

Hallo

Danke für Deine Mühe. Schau die unbedingt folgenden Beitrag an (betrifft nur die S7-300 CPU)
http://www.oscat.de/community/index.php/topic,2244.msg12400.html#msg12400

a) Ich verwende fast ausschließlich die S7-1500 (bei der 1200 siehts wahrscheinlich nochmals anders aus)
b) Aus dem OSCAT verwende folgende Bausteine:

- bekannte Fehler:
ONTIME geht nur bis 8192 h
FT_T1 bleibt stehen -> siehe Beitrag in diesem Forum
DEW_RH war sowieso falsch (... auch im Codesys, wurde vielleicht bereits geändert)
evtl. wurden noch weitere Bausteine verändert und ich kann mich nicht mehr erinnern.



[gelöscht durch Administrator]

SMI wird hauptsächlich für die Rollladensteuerung verwendet.

https://de.wikipedia.org/wiki/Standard_Motor_Interface

Leider gibt es da so einen "Verein" die alle Protokollbeschreibungen möglichst unter Verschluss halten.
Es gibt auch einen Beitrag https://www.mikrocontroller.net/topic/273846 im microcontoller.net

Hat jemand von Euch einen Zugriff auf das aktuelle Protokoll.

Danke

Mg