TIA V17: Wie konfiguriere ich die Signalsäule (8WD4613-5HH47) am IO-Link Master (6ES7148-6JG00-0BB0) GELÖST

Ist vielleicht wichtig. Die LED unten am Fuß der Säule blinkt grün. Ist das so in Ordnung oder muss die dauerhaft leuchten?
Nachtrag: Beim Übertragen des Programms kommt die Meldung "Datensatz 209 nicht verfügbar"
 
Mir geht gerade ein Licht auf.
Könnte hier irgendwo die Lösung liegen?
1740402677473.png
Oh Mann, ernsthaft? Im Handbuch steht Byte 0 und Byte 1 drin, aber das das für die Adresse 148 gilt steht da nirgends. Habe die Werte gerade im S7-PCT gesehen und meine Variablentabelle entsprechend angepasst, jetzt funktioniert es.
Nochmals vielen Dank an alle, die hier mitgeholfen haben.
 
Oh Mann, ernsthaft? Im Handbuch steht Byte 0 und Byte 1 drin, aber das das für die Adresse 148 gilt steht da nirgends.
Äh, jein.
Dein StartBYTE ist 147 also ist:
Byte 147 + Byte 0 = Byte 147 und
Byte 147 + Byte 1 = Byte 148.

Der Wald und die Bäume und so?
😜


PS:
Bei manchen Geräten muss man dann noch auf BigEndian achten.
Je nachdem, wie die Daten im IOL-Gerät konfiguriert sind.
 
Zuletzt bearbeitet:
Äh, jein.
Dein StartBYTE ist 147 also ist:
Byte 147 + Byte 0 = Byte 147 und
Byte 147 + Byte 1 = Byte 148.

Der Wald und die Bäume und so?
😜


PS:
Bei machen Geräten muss man dann noch auf BigEndian achten.
Je nachdem, wie die Daten im IOL-Gerät konfiguriert sind.
Hm, vielleicht sehe ich die Bäume nicht, aber ich verstehe das Handbuch so, dass Bit 0 - 4 von Byte 0 für die Segmente zuständig sind un bei einer Startadresse von 147 wäre das %Q147.0 bis %Q147.4 für mich und nicht %Q148
 
Hm, vielleicht sehe ich die Bäume nicht, aber ich verstehe das Handbuch so, dass Bit 0 - 4 von Byte 0 für die Segmente zuständig sind un bei einer Startadresse von 147 wäre das %Q147.0 bis %Q147.4 für mich und nicht %Q148
Da die beiden Bytes im Manual (IMHO Siemens-typisch etwas kompliziert zu lesen) immer zusammen und nicht einzeln dargestellt werden, werden sie wohl als WORD und nicht als BYTEs übertragen (deswegen vermutlich auch 4 Bytes Konfig, von denen nur 3 genutzt werden) und dann gilt dies hier:
PS:
Bei manchen Geräten muss man dann noch auf BigEndian achten.
Je nachdem, wie die Daten im IOL-Gerät konfiguriert sind.
 
Zuletzt bearbeitet:
Theoretisch kann S7-PCT Dir den udt erzeugen (da gibt's irgendwo 'nen Button für), ...
Hab' das gerade mal interessehalber gemacht.
Der Button ist hier:
1740420021498.png

das Ergebnis:
Code:
TYPE "PII - 8WD46 IO-Link 9 Segmente"
VERSION : 0.1
     STRUCT
        "Port Qualifier"                            : Byte;
     END_STRUCT
END_TYPE


TYPE "PIQ - 8WD46 IO-Link 9 Segmente"
VERSION : 0.1
     STRUCT
        "Prozessdaten Output - Optik (Signalmodus)" : Word;
     END_STRUCT
END_TYPE
... praktisch sind diese automatischen udts jedoch nicht immer brauchbar.
sehr praktisch 🫣
aber wenigstens bestätigt es noch einmal diese Vermutung:
Da die beiden Bytes im Manual (IMHO Siemens-typisch etwas kompliziert zu lesen) immer zusammen und nicht einzeln dargestellt werden, werden sie wohl als WORD und nicht als BYTEs übertragen.
... muss man dann noch auf BigEndian achten.
☝️
 
Zuletzt bearbeitet:
Reicht es normalerweise nicht aus die ein-/ausgangsdaten über dprd / dpwr zu senden bzw. zu empfangen?
:unsure:
Wozu dprd / dpwr?
Das sind stinknormale Hardware-Ein-/Ausgänge, als wäre es ein Anreih-Modul der SPS.

PS:
es macht halt nur Sinn, die Daten nicht nur einfach als Bit/Bytes/Word/Dword zu verarbeiten, sondern in der Struktur, wie sie das Gerät einspeist.
Z.B. die Struktur eines Leitwertsensors, den wir verwenden:
1740426454951.png
 
Zuletzt bearbeitet:
:unsure:
Wozu dprd / dpwr?
Das sind stinknormale Hardware-Ein-/Ausgänge, als wäre es ein Anreih-Modul der SPS.

PS:
es macht halt nur Sinn, die Daten nicht npur einfach als Bit/Bytes/Word/Dword zu verarbeiten, sondern in der Struktur, wie sie das Gerät einspeist.*
Z.B. die Struktur eines Leitwertsensors, den wir verwenden:
Anhang anzeigen 85608
Das kommt dann im nächsten Schritt. Ich wollte es erstmal schaffen, dass ich die Säule konfiguriert bekomme und sie leuchtet und das habe ich dank Euch erreicht.
@hucki : Den Hinweis, dass das RTFM nicht auf Dich bezogen war hast Du gesehen?
 
:unsure:
Wozu dprd / dpwr?
Das sind stinknormale Hardware-Ein-/Ausgänge, als wäre es ein Anreih-Modul der SPS.

PS:
es macht halt nur Sinn, die Daten nicht nur einfach als Bit/Bytes/Word/Dword zu verarbeiten, sondern in der Struktur, wie sie das Gerät einspeist.
Z.B. die Struktur eines Leitwertsensors, den wir verwenden:
Anhang anzeigen 85608

Hallo @hucki, ja du hast vollkommen recht. Das reicht vollkommen.
Ich habe bisher mit den ifm al1402 Baugruppen gearbeitet. Da konfiguriert man Port in der GSD über die Ports. Das schreiben und lesen der Prozessdaten habe ich damals über dprd / dpwr gemacht. Da ich über die HW_Submodul Nummer auf die Ein-/Ausgangsdaten zugegriffen habe, musste ich das nicht über eine Variablentabelle lösen
Ich denke ich habe da meine Erfahrung mit der beschriebenen Situation von @oliver.tonn bisschen durcheinander geworfen. Nichts für ungut, ich wollte keine Verwirrung stiften.
 
Zurück
Oben