TIA 32Bit IO-Link Input Auslesen(Integer30 und 2Bit)

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kommt drauf an, ob du in der Hilfe nach 300ér oder 1200ér schaust.
Ob man der Hilfe da so vertrauen kann? Besser selber mal ausprobieren.

Ist egal, in TIA V15.1 "SHR in SCL" steht bei beiden daß generell Nullen eingeschoben werden.

Harald

 

[Windoze]

Ist egal, in TIA V15.1 "SHR in SCL" steht bei beiden daß generell Nullen eingeschoben werden.

Harald

Jein, im Bild steht das. Aber im Text über dem Bild ist es korrekt!

SHR: Rechts schieben (S7-1200, S7-1500)
Bei Werten ohne Vorzeichen werden die beim Schieben frei werdenden Bitstellen im linken Bereich des Operanden mit Nullen aufgefüllt. Wenn der angegebene Wert ein Vorzeichen aufweist, werden die freien Bitstellen mit dem Signalzustand des Vorzeichenbits belegt.

 

[Windoze]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das Verhalten ist übrigens zwischen KOP und SCL identisch.

 

[PN/DP]

PS: die Dokumentationsfehler könnten gar nicht passieren, wenn solcher Schwachfug wie Schieben von INT gar nicht zugelassen würde. SHL mit INT ist ja noch schwachsinniger, aber trotzdem zugelassen!

Harald

 

[D_H]

Okay, demnach wäre jetzt Bit 31 und 30 nach links abzuschneiden, Bit 29 wäre das Vorzeichen?

Wenn Int Schieben schwachfug ist, wie wäre meine Aufgabe dann anders zu lösen?

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Okay, demnach wäre jetzt Bit 31 und 30 nach links abzuschneiden, Bit 29 wäre das Vorzeichen?

Wenn Int Schieben schwachfug ist, wie wäre meine Aufgabe dann anders zu lösen?

So:

Falls ich alles richtig verstanden habe könntest Du den Integer30 etwa so nach Int32 (DINT) wandeln:

#diMyDInt := DWORD_TO_DINT( SHL(IN:=#dwInt30, N:=2) ) / 4;

Harald

 

[PN/DP]

Ich vermute mal, solcher und ähnlicher Schwachfug wird von Siemens nicht als Fehler abgewiesen, weil einige "Großkunden" das so verlangen, weil deren Programmierer sooo viel mehr Arbeitszeit bräuchten wenn sie in Zukunft korrekt programmieren müssten, anstatt uralten Code zu kopieren...

Harald

 

[PN/DP]

Wenn Int Schieben schwachfug ist, wie wäre meine Aufgabe dann anders zu lösen?

So wie ich schon im Beitrag #2 geschrieben habe.
Falls Du das unbedingt in FUP/KOP haben willst, dann musst Du das sinngemäß in FUP/KOP formulieren und bei jeder Datentyp-Änderung die Zwischenergebnisse mit MOVE auf entsprechende Variablen speichern.
PS: In TIA kann man in FUP/KOP-Bausteinen auch einzelne Netzwerke in SCL einfügen.

Harald

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Umso mehr man da in der Hilfe schaut, umso mehr Varianten von SHR gibt es
Graph, KOP/FUP, AWL, SCL.....

Hier mal für die 1200/1500ér GRAPH und SCL:

 

[Windoze]

Ich vermute mal, solcher und ähnlicher Schwachfug wird von Siemens nicht als Fehler abgewiesen, weil einige "Großkunden" das so verlangen, weil deren Programmierer sooo viel mehr Arbeitszeit bräuchten wenn sie in Zukunft korrekt programmieren müssten, anstatt uralten Code zu kopieren...

Harald

Was ist denn daran "Schwachfug"? Arithmetisches Schieben gibt es schon seit Ewigkeiten auf allen bekannten Platformen.
Bei Intel x86 Assembler gibt es z.B. extra einen Befehl für Logisches Schieben (SHR) und Arithmetisches Schieben (SAR).
In vielen Hochsprachen wie z.B. C/C++/C# wird, wie bei Siemens, abhängig vom Datentyp mit Vorzeichen oder nullen aufgefüllt.

Also das ist absolut üblich, das so zu machen!

 

[PN/DP]

Was üblich ist, muß nicht unbedingt richtig sein.
Gibt es auch "Arithmetisches Links-Schieben"? SHL ist ja auch für INT/DINT zugelassen... zumindest da ist Schieben von INT/DINT unbestreitbar Schwachfug. Gibt es "Arithmetisches Links-Schieben" vielleicht in Codesys?

Als CPU Habe ich eine S7-315 und TIA V15.1.

Für S7-300 schreibt die TIA-V15.1-Dokumentation zu SHR für FUP, KOP und GRAPH übereinstimmend, daß bei Werten mit Vorzeichen mit dem Zustand des Vorzeichenbits aufgefüllt wird. Das Bild dazu zeigt jeweils das Auffüllen mit dem Zustand des "Vorzeichenbits"
(naja, "populärwissenschaftlich" erklärt, denn INT/DINT haben eigentlich gar kein Vorzeichenbit )

Für S7-300 SCL schreibt die Dokumentation zu SHR, daß nur Bitfolgen zugelassen sind und mit Nullen aufgefüllt wird.

Harald

 

[D_H]

Zuviel Werbung?
-> Hier kostenlos registrieren

Irgendwo habe ich einen Denkfehler? Es sollte eigentlich 0 Rauskommen.

Getestet auf einer 1515f mit Tia 15.1:

 

[Heinileini]

Irgendwo habe ich einen Denkfehler? Es sollte eigentlich 0 Rauskommen.

Ja, da muss ein Denkfehler vorliegen. Wo, das kann ich nicht nachvollziehen. Das Programm sieht korrekt aus und in dem gezeigten Beispiel arbeitet es auch korrekt.

 

[Thruser]

In welcher Reihenfolge werden denn die 4 Bytes im MD abgelegt?

Ist vielleicht eines der Schaltbits gesetzt?

Gruß

 

[Windoze]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja, da ist die Byte-Reihenfolge gedreht. Probier mal vorher mit "SWAP" die Bytes zurückzudrehen

 

[PN/DP]

SWAP gibt es in TIA nicht für die S7-300. (Nicht in FUP/KOP und nicht in SCL. Nur für GRAPH.)

Für die S7-300 würde ich mir einen Konvertier-FC in AWL programmieren. (In allen anderen Programmiersprachen ist das mit TIA nur äußerst uneffizient zu lösen.)

FUNCTION "FC_IOLINK_INT30_TO_DINT" : DInt
TITLE = DWORD mit Int30 von IO-Link in DINT wandeln
VERSION : 0.1
//für S7-300/400
   VAR_INPUT
      IN : DWord;   // IO-Link DWord mit Int30
   END_VAR

BEGIN
NETWORK
TITLE = Byte-Reihenfolge umdrehen und Bits 31 und 30 entfernen
//entspricht SCL: #FC_IOLINK_INT30_TO_DINT := DWORD_TO_DINT( SHL(IN:=SWAP(#IN), N:=2) ) / 4;
//Der AWL-Code verwendet absichtlich nicht SSD, damit man die SCL-Formel wiedererkennt.

      L #IN;
      TAD;      // Byte-Reihenfolge umdrehen (SWAP), nur bei Bedarf!
      SLD 2;
      L 4;
      /D;
      T #FC_IOLINK_INT30_TO_DINT;

END_FUNCTION

PS: AWL-Quelle als Datei angehängt. Zur Verwendung in TIA die Dateiendung ".txt" entfernen.

PPS: sehr wahrscheinlich muß die Byte-Reihenfolge gar nicht umgedreht werden (evtl. wird das hier im Laufe des Threads noch geklärt). Die Anweisung TAD muß dann entfernt werden.

Harald

 

[hucki]

Irgendwo habe ich einen Denkfehler? Es sollte eigentlich 0 Rauskommen.

Getestet auf einer 1515f mit Tia 15.1:
Anhang anzeigen 59946

Müssten "Schaltausgang_1" & "Schaltausgang_2" (die da geforct werden) bei gewöhnlicher Siemens-Verwendung nicht auf M0.6 und M0.7 sein?

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

"geforced": ala "Byte-Reihenfolge gedreht" durch den Tester und nicht durch IO-Link

Ich wiederhole nochmal meine Frage von Beitrag #11 an den OP: Hast Du mal eine Dokumentation Deines Gerätes, damit wir ohne Deine Fehlinterpretationen zweifelsfrei feststellen können, auf welchen Bits die Schaltsignale liegen und ob/wie die Bytes vertauscht sind?

Harald

 

[hucki]

"geforced": ala "Byte-Reihenfolge gedreht" durch den Tester und nicht durch IO-Link

Zumindest wird M3.6 auf TRUE geforct.
Und das gehört ja eigentlich zu den 30 Bits des INTs im MD0.
Und daher sicher der Beobachtungswert h#... 40 = b#... 0100 0000

 

[PN/DP]

Für S7-300 SCL schreibt die Dokumentation zu SHR, daß nur Bitfolgen zugelassen sind und mit Nullen aufgefüllt wird.

was TIA-typisch natürlich auch nicht stimmt.
Ich habe es mit TIA V15.1 für S7-300 ausprobiert und da geht SHR in SCL ebenfalls mit DINT.
In SCL "classic" war das noch ein unzulässiger Fehler.

Für die TIA-Zielgruppe (Schlechter ausgebildete/billigere Programmierer? "Weniger als 10 Minuten"-Automatisierer...) wurde das geändert und auch Integer zugelassen. Ist ein streng prüfender Compiler ein Markt-Nachteil?? In TIA muß man die IEC-Prüfung aktivieren damit die Verwendung von INT/DINT wieder als Fehler angemeckert wird.

Harald