ja mit dem datenverkehr wäre alles ersichtlich wie es funktioniert
und wahrscheinlich können wir dann relativ einfach einen sample baustein basteln…
Kommt gleich eine PN mit der Wireshark Datei.
In Zeile 663 steht der Befehl zum ausschalten.
Vorher habe ich noch per Smartphone Lautstärke lauter gemacht und auf einen anderen EIngangskanal gewechselt, sodass man ein wenig mehr Traffic sieht.
[gelöscht durch Administrator]
hi
danke für den mitschnitt
jetzt ist mir klar wie es aufgebaut ist bzw. funktioniert
der wesentliche faktor ist der datenheader und die datenend markierung … das fehlte bei deinen versuch komplett
und diese bytes sind auch im telnet log logischerweise nicht sichtbar
siehe anhang
im power off sample bild siehst welche bytes du in wirklichkeit versenden musst !
in der excel liste im sheet “protocol” ist dokumentiert wie so ein telegramm aufgebaut sein muss
probier mal das umzusetzen … wenn es probleme gibt dann melde dich wieder…
[gelöscht durch Administrator]
Jupp, die Infos habe ich hier bereits auch alle, helfen mir aber nicht weiter.
Die telegramme habe ich ja bereits so getestet und auch zigfach aus unterschiedlichen Foren ausprobiert, wo teils andere getestet wurden.
schön das die die meisten infos schon hattest !
warum stellst du sie dann nicht online ?
aber → der baustein den du im forum gepostest hast kann nicht funktionieren !
da gib mir doch mal dein testprogramm, damit ich nachsehen kann was falsch gemacht wurde.
hast du denn ein mit deinen testprogramm ein telegramm auch wirklich versenden können, und dieses auch im wireshark gesehen (dann kann man auch kontrollieren ob der dateninhalt exakt passt.)
Möchte ja ungern klugscheißern, aber die Excel Datei habe ich bereits auf Seite 1 als Anhang eingestellt 
Anbei das Programm. Möchte hier noch mal erwähnen, dass ich bereits zahlreiche Commandos getestet habe. Werde später aber noch mal schauen, ob und was am Receiver ankommt, wenn ich es über die Wago verschicke.
[gelöscht durch Administrator]
nachdem ich in deinem wago wireshark keinen datenverkehr entdecken konnte, mache ich mit der Theorie weiter
das verwendest du
Data := ‘ISCP\x00\x00\x00\x10\x00\x00\x00\x07\x01\x00\x00\x00!1PWR00\x0D’;
das ist die klassische bytecodierung bei hochsprachen die aber meiner meinung nach so nicht funktioniert
probiere das doch mal.
Data := ‘ISCP$00$00$00$10$00$00$00$07$01$00$00$00!1PWR00$0D’;
was wirklich los ist wird die wago wireshark aufzeichnung bringen
sollte in der aufzeichnung nichts zu finden sein, dann muss am code für den verbindungsaufbau weitergesucht werden.
das ich die xls-datei nicht gesehen habe musst du mir verzeihen, da ich das alles nebenbei mit einem auge mache und mich nicht auf ein problem ausgiebig konzentrieren kann, denn dazu ist mein leben zu kurz …
Kein Problem. Bin ja schon froh, dass sich dem Problem überhaupt jemand annimmt 
EDIT: Mit deinem Kommando geht es leider auch nicht. Das Script Sendet sogar nur “ISCP”. Alles dannach ist gar nicht im S_BUF
Am Onkyo kommt der gleiche Käse an, wie in der letzten Wireshark Datei.
Data := ‘ISCP$00$00$00$10$00$00$00$07$01$00$00$00!1PWR00$0D’;
ich glaube auch schon zu wissen warum man den ansich richtig formulierten string nicht senden kann
bei codesys bedeutet ein 0x00 Byte in einen string das es das ende eines strings ist
somit wird effektiv auch nur ‘ISCP’ versendet
das einzige was du machen kannst ist folgendes
in deinem baustein
10:
IP_C.C_PORT := 60128; (* Portnummer eintragen *)
IP_C.C_IP := IPClient_Adr; (* IP eintragen *)
IP_C.C_MODE := BYTE#0;
IP_C.C_ENABLE:= TRUE; (* Verbindungsaufbau freigeben *)
IP_C.R_OBSERVE:= TRUE; (* Datenempfang überwachen *)
IP_C.TIME_RESET:= TRUE;
S_BUF.BUFFER[00] := BYTE#16#49;
S_BUF.BUFFER[01] := BYTE#16#53;
S_BUF.BUFFER[02] := BYTE#16#43;
S_BUF.BUFFER[03] := BYTE#16#50;
S_BUF.BUFFER[04] := BYTE#16#00;
S_BUF.BUFFER[05] := BYTE#16#00;
S_BUF.BUFFER[06] := BYTE#16#00;
S_BUF.BUFFER[07] := BYTE#16#10;
S_BUF.BUFFER[08] := BYTE#16#00;
S_BUF.BUFFER[09] := BYTE#16#00;
S_BUF.BUFFER[10] := BYTE#16#00;
S_BUF.BUFFER[11] := BYTE#16#09;
S_BUF.BUFFER[12] := BYTE#16#01;
S_BUF.BUFFER[13] := BYTE#16#00;
S_BUF.BUFFER[14] := BYTE#16#00;
S_BUF.BUFFER[15] := BYTE#16#00;
S_BUF.BUFFER[16] := BYTE#16#21;
S_BUF.BUFFER[17] := BYTE#16#31;
S_BUF.BUFFER[18] := BYTE#16#50;
S_BUF.BUFFER[19] := BYTE#16#57;
S_BUF.BUFFER[20] := BYTE#16#52;
S_BUF.BUFFER[21] := BYTE#16#30;
S_BUF.BUFFER[22] := BYTE#16#30;
S_BUF.BUFFER[23] := BYTE#16#0D;
S_BUF.BUFFER[24] := BYTE#16#0A;
S_BUF.SIZE := 25; (* Sendelänge eintragen *)
state := 30;
ich hatte wohl die alte wireshark aufzeichnung angesehen und darum keine wago kommunikation gefunden
in der richtigen aufzeichnung sieht man nur 3 zeilen
das ist ein korrekter verbindungsaufbau , jedoch werden anscheinend keine daten von sps zu onkyo gesendet
wenn sich das nicht ändert muss man sich das programm nochmals genauer ansehen
das hat aber überhaupt nichts mit dem eigentlichen daten zu tun…
es wird einfach kein eizigen byte versendet…
[gelöscht durch Administrator]
habe nun deinen baustein in meiner modifizierten version ausprobiert
er funktioniert auch prinzipiell !
(siehe bild)
nach dem senden bleibt aber nun die verbindung aufgebaut, was ich aber so lösen würde…
30:
IF IP_C.ERROR <> DWORD#0 THEN (* Error ? )
ERROR := IP_C.ERROR;
IP_C.C_ENABLE := FALSE; ( Verbindung abbauen *)
state := 0;
END_IF;
IF S_BUF.SIZE =UINT#0 THEN (* warten bis alle daten gesendet sind )
DONE := TRUE;
IP_C.C_ENABLE := FALSE; ( Verbindung abbauen *)
state := 0;
END_IF;
[gelöscht durch Administrator]
Jawoll… er ist aus. (der Receiver)
Scheint also über diesen “weg” schon mal zu gehen. Kann man das jetzt noch irgendwoe schöner “verpacken”, wo wir den richtigen Weg schon mal raus haben?
schöner verpackt… und flexibel…
siehe anhang…
das kind ist geboren und es lebt…
viel spass..
[gelöscht durch Administrator]
Hui… ich sage schon mal besten Dank und werde mich da mal reinverkriechen und lernen. 8)
Habe nun so langsam Begriffen, wie du die Funktion und das Programm aufgebaut hast. Klasse Sache.
Nun würde ich gerne den Rückgabe Puffer auslesen und habe dies mit der Funktion BUFFER_TO_STRING probiert.
Leider scheine ich wieder was falsch zu machen, oder die Funktion klappt nicht. Denn dazu gabe es hier bereits schon mal ein Beitrag: OSCAT BUFFER_TO_STRING
Vielleicht magst du noch mal gucken. (Anhang) → Zeile 61
[gelöscht durch Administrator]
hi
habe mal was heruntergetippt, ist ungetestet !
baustein gibt nun den antwort parameter mit aus
neuer parameter für time_out
default wert für port und time_out
[gelöscht durch Administrator]
Vielen Dank.
Dürfte ich noch erfahren, wo mein Fehler war? Du startest mit dem Auslesen erst ab Pos 21. Ist das, damit das ganze ISCP Gedöns nicht in der Variable auftaucht?
Update: In Zeile 61 ist offensichtlich noch nen Fehler drinnen. Die Übergabevariable bei STOP muss so lauten: 21 + command_rcv_size - 9
fehler zeile 61 → kann sein
das ist die kopfrechnung die ohne ausprobieren auch schief gehen kann
richtig is es dann wenn da am baustein ausgang “00” oder “01” bei der power abfrage bekommt.
von 0 -15 ist nur der header zu finden wobei die datenlänge darin interessant ist
16 - x sind die daten selber
16 = !
17 = 1
18 = P
19 = W
20 = R
21 = 0 <---- das wollen wir
22 = 0 <---- uws… bis zum EOF
23 = EOF
24 = EOF
setzt vorraus das die verwendeten kommandos 3 zeichen haben
wenn nicht dann sags mir dann muss man nochmals nachbessern
R_BUF inhalt auch gezielt auf 0 setzt … vor dem senden
wichtig ist das man nach den senden auch auf eine antwort wartet (R_BUF.SIZE > 0)
Jupp, soweit mittlerweile das Script verstanden
Danke bis hierhin. Hat mir echt weitergeholfen, um den Einstieg zu finden.