Beiträge

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

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