Processdaten von smarten Devices in TwinCAT

Torch

New member
Beiträge
3
Punkte Reaktionen
0
Zuviel Werbung?
->Hier kostenlos registrieren
Hallo Leute,

Ich bin neu hier im Forum und auch in der Programmierung mit TwinCAT. Ich habe ein Projekt wobei ich smarte Sensoren von ifm über einen IFM Master AL1332 mit einer Beckhoff CX8190 kommunizieren lassen möchte.

Bei meinen Devices handelt es sich um:

- DV2500 5 Segment-Signalampel
- KT6100 Kapazitiver Leuchttaster

IFM liefert im Downloadbereich eine IO-Link Schnitstellenbeschreibung. Dort ist bei der DV2500 zumindest im RGB-Mode schön aufgeschlüsselt, welche Bits vorhanden sind, damit an zumindest mal ein Segment triggern kann, damit dieser auch leuchtet.

Und jetzt kommt mein großes Problem. Die Eingänge und Aufgänge des IFM Masters muss man entsprechend der Prozessdatenlänge die Anzahl der Bytes für Input und Output zuordnen. Soweit habe ich das auch verstanden. Schaue ich in den Unterlagen, so liegen die Bits auf Words. Das beduetet für mich, dass ich ein Word aus jeweils 2 Bytes zusammensetzten müssen. Soweit wäre das logisch für mich.

Ich brauche doch irgendeine Funktion, damit ich 2 Bytes zu einem Word zusammenfügen kann, oder sehe ich das falsch?

Bei ifm kann man sich eine ZIP Dabei runterladen für den IO-Link Master mit einem Beispielprogramm darin enthalten. Hier werden 2 Bytes jeweils zu einem WORD konvertiert. Für mich sieht es aber nicht aus, dass diese Bytes zu einem Word zusammengefügt werden.

Ich habe wirklich keinen Schimmer, was die von IFM dort machen. Ich verstehe, dass mit dem Rol- Funktion (Input 1 von Byte auf Word konvertier) um 8 stellen nach links verschoben wird. Würde der Input 1 :=1 sein, dann wäre der 8 Bit getriggert und es würde 256 rauskommen.

Ich verstehe auch, dass die Funktion SHR sagt, dass ein Offset beim Lesen der Bytes des Wortes vorhanden ist, sodass die ersten 4 Bits nicht gelesen werden. Und erst ab den Bit 4 bis Bit 15 meine Prozessdaten vorhanden sind, also nur eine Bit-Breite von 12 zur Verfügung steht.

Ich hoffe hier findet sich jemand, der Ahnung davon hat, oder sich selber mal in das Thema getaucht ist.

Grüße Torch
 

Anhänge

  • Beispiel.JPG
    Beispiel.JPG
    219,8 KB · Aufrufe: 20

asci25

Well-known member
Beiträge
612
Punkte Reaktionen
81
Das "OR" fügt doch nur die 16 bits zusammen. Das das zweite Byte die Bits 8-15 representiert, müssen diese zuerst auf die richtige Position geschoben werden. Das erledigt die Funktion ROL mit dem 16-Bit-Wert am Eingang.

Für mich ist das jedoch schon eine ganz üble FUP-Anfängerlösung. Das Ganze noch als PROGRAM und mit Schnittstelle, Ey, wer macht denn sowas?

Eleganter geht das in ST und als instanziierbaren Funktionsbaustein, gleich mit der passenden HW-Anbindung:

Code:
FUNCTION_BLOCK FB_O5D
VAR_OUTPUT
    onDistance:        INT;
END VAR
VAR
    byI_In1:    AT%I*    BYTE;
    byI_In2:    AT%I*    BYTE;
END VAR
------------------------------------------------------
onDistance := WORD_TO_INT(SHR(byI_In1 + byI_In2 * 16#100,4));

Macht das Gleiche, spart Arbeit und ist mehrfach verwendbar. Ich würde den Baustein gleich für den Rest des Sensors mit aufbohren.

Übrigens, dass nur die Bits 4-15 den Prozesswert enthalten, ist in der Automatisierungstechnik kein unbekanntes Verfahren. Die Bits 0-3 enthalten oft Diagnosefehler, wie Messwertbereichsunter- oder -überschreitung.
 
Zuletzt bearbeitet:
OP
T

Torch

New member
Beiträge
3
Punkte Reaktionen
0
Zuviel Werbung?
->Hier kostenlos registrieren
Vielen Dank für deine zügige Antwort auf meine Frage.

Ich habe deine Lösung mal auf meinen Fall angewendet. Ich habe aus den 6 Bytes aus jeweils 2 Bytes ein Word zusammengesetzt. Jetzt möchte ich mit einem IF-Anweisung, wenn ein Taster ( BOOL) getriggert ist, dass sich das dritte Bit von 0 auf 1 gesetzt wird, damit entsprechend das erste Segment leuchtet. Kann es so mit dem Funktionsbaustein gehen ?

Ich bin wirklich grün hinter den Ohren und habe nicht wirklich viel Ahnung und so wirklich helfen kann mir auch keiner in meinem Betrieb, weshalb ich mich auch hier angemeldet habe. Ich bin fast verzweifelt als ich nach Gleichgesinnten gesucht habe im Thema TwinCAT und Beckhoff.
 

Anhänge

  • Bitmapping.JPG
    Bitmapping.JPG
    89,5 KB · Aufrufe: 11
  • Dekleration.JPG
    Dekleration.JPG
    86,4 KB · Aufrufe: 11
  • Belegung Bits.JPG
    Belegung Bits.JPG
    148 KB · Aufrufe: 11

asci25

Well-known member
Beiträge
612
Punkte Reaktionen
81
Wenn, dann so:

Code:
IF bTaster Then
    wPLCoutWord.4 := True;
END_IF

Allerdings macht das im restlichen Kontext keinen Sinn, weil im nächsten Zyklus das Bit 4 aus dem Ergebnis der Addistion aus byQ_Out6 + byQ_Out5 überschrieben wird, außer bTaster ist kein "Taster" sondern ein "Schalter".

Übrigen, Bedingungen zwischen IF und Then werden als Boolean abgefragt. Man mus also einen Boolean nicht noch umständlich durch einen Vergleich in einen Boolean umwandeln:

Richtig:
Code:
IF bTaster THEN
...

IF NOT bTaster Then
...

Umständlich:
Code:
IF bTaster = TRUE THEN
...

IF bTaster = FALSE Then
...
 
OP
T

Torch

New member
Beiträge
3
Punkte Reaktionen
0
Danke für die zügige Antwort. Ich morgen zumindest etwas ans Laufen kriege. Ich arbeite mit einer CX8190. Bei der Steuerung hatte ich schon Probleme beim direkten Routing über den PC. Bei dem Ethernet Schnittstelle handelt es sich um einen Intel i219 LM dort habe ich auch das TwinCAT Ethenet Protokoll aktiviert.

Morgen versuche ich mal das ganze an einem Switch mit dem PC zu verbinden. Beim direkten Routing hat er zwar die Steuerung erkannt und ich konnte auch auf das System zugreifen, sowie beim first Scan auch meinen IO Link Master erkennen und in die verschiednen Modi zugreifen wie INI, PreOP und OP. Beim Neustart jedoch hat er den IO-Link Master über die Ethercat Schnittstelle nicht mehr erkannt.
 

Heinileini

Well-known member
Beiträge
4.909
Punkte Reaktionen
1.037
Zuviel Werbung?
->Hier kostenlos registrieren
Ich habe wirklich keinen Schimmer, was die von IFM dort machen. Ich verstehe, dass mit dem Rol- Funktion (Input 1 von Byte auf Word konvertier) um 8 stellen nach links verschoben wird. Würde der Input 1 :=1 sein, dann wäre der 8 Bit getriggert und es würde 256 rauskommen.

Ich verstehe auch, dass die Funktion SHR sagt, dass ein Offset beim Lesen der Bytes des Wortes vorhanden ist, sodass die ersten 4 Bits nicht gelesen werden. Und erst ab den Bit 4 bis Bit 15 meine Prozessdaten vorhanden sind, also nur eine Bit-Breite von 12 zur Verfügung steht.
Ich verstehe jetzt leider nicht, was Du nicht verstanden hast und erklärt haben möchtest.

In Deinem DeklarationsBild in Beitrag #3 sehe ich z.B. wPLCoutWord4 := BYTE_TO_WORD(byQ_Out6 + byQ_Out5) ;.
Damit werden die beiden Bytes nur addiert, aber nicht zuvor nebeneinander im Wort abgelegt.
Eins der beiden Bytes müsste nach links um 8 BitPositionen geschoben werden.
Durch
- Schieben nach links oder
- Rotieren nach links (oder rechts) oder
- Multiplikation mit 256.
Erst danach "vereint" man die Bytes durch OR oder durch Addition, je nach DatenTyp (OR bei WORD, + bei INT).
Wenn die beiden Bytes an ihrer "SollPosition" stehen, überschneiden sie sich nicht und dann liefern OR und Addition dasselbe Ergebnis.
onDistance := WORD_TO_INT(SHR(byI_In1 + byI_In2 * 16#100,4));[/CODE]
... ist ein Beispiel für das Schieben von 'byI_In2' um 8 BitPositionen nach links mittels Multiplikation mit 256 bzw. 16#100.

Das anschliessende Schieben nach rechts um 4 BitPositionen kann ich Dir nicht erklären.
Es dürfte wohl so sein, dass der 12-Bit-Wert linksbündig im Wort steht und deshalb in die rechtsbündige Position geschoben werden muss(?).
Übrigens, dass nur die Bits 4-15 den Prozesswert enthalten, ist in der Automatisierungstechnik kein unbekanntes Verfahren. Die Bits 0-3 enthalten oft Diagnosefehler, wie Messwertbereichsunter- oder -überschreitung.
Das kenne ich auch, allerdings fast ausschliesslich bei A/D-Wandlern bzw. D/A-Wandlern.
Dort wird es so gemacht, damit man eine einheitliche Darstellung als INT-Zahl hat, egal ob der Wandler z.B. 10 Bit, 12 Bit oder 16Bit "erzeugt" bzw. verarbeitet.
Dann wirkt es sich nur auf die "Granularität" aus, d.h. der Unterschied liegt dann nur darin, wie fein abgestuft die Zahlen darstellbar sind und die maximal und minimal darstellbaren Zahlen sind immer 32767 und -32768. Diese Behauptung darf man nicht zu wörtlich nehmen, denn, wenn die niederwertigsten Bits 0 sind, kann natürlich der maximale Wert von 32767 nicht ganz erreicht werden.
 
Oben