TIA Daten vom Bus einlesen

[uweschwarz]

Zuviel Werbung?
-> Hier kostenlos registrieren

Upps, so einfach geht das ... jetzt funktioniert es

Vielen Dank

 

[uweschwarz]

"Rec_ADL_G100"."THIS"[0] := "Rec_G1001";

Das funktioniert ganz wunderbar. Noch schöner wäre es allerdings in etwa so:

FOR #i :=0 TO 15_ DO
    // Statement section FOR
    //
    "Rec_ADL_G100"."THIS"[#i] := "Rec_G100"&#i; //funktioniert so natürlich nicht
    ;
END_FOR;

Die Frage lautet: Kann ich mit einer Schleifenanweisung jeden PB Slave einzeln nacheinander einem Element im Array DB zuweisen? Wenn ja, wie?

 

[NBerger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Machbar wäre das schon. Arrays im EA-Abbild geht nur über den Umweg über einen Datentyp.

Die Adressen müssen dann nur korrekt hintereinander liegen...

Grundsätzlich gibt's halt immer einen kurzen ODER schnellen Weg. Beides geht nicht!

In deinem Fall würde ich die 16 Zeilen einfach ausschreiben.

 

[ducati]

Die Frage lautet: Kann ich mit einer Schleifenanweisung jeden PB Slave einzeln nacheinander einem Element im Array DB zuweisen? Wenn ja, wie?

schreib einfach die 15 Zeilen... das dauert 30 Sekunden... und man findet dann auch über Querverweise noch irgendwas...

 

[uweschwarz]

Bei 16 Zeilen stimme ich dir zu. Ich gehe davon aus, dass die grundsätzliche Vorgehensweise bei Profinet ganz ähnlich ist und da werde ich ca. 60 Analogwerte via IFM AL1100 und AS2301 einlesen müssen. Da würde sich das dann evtl. schon lohnen ... na, ja vielleicht auch nicht ...

 

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

Im Idealfall kannst du direkt mit den Daten aus dem E/A-Bereich symbolisch arbeiten und musst gar nichts in DBs umkopieren.

 

[JesperMP]

Wenn du 60 Analogkanäle hast, und von unterschiedliche Busteilnehmern, dann ist das lesen von die Analogkanäle die erste und kleinste Schritt.
Alle 60 in ein Ruck lesen (per Array oder Struktur) gibts nichts vieles.

Ein typischen Verfahren, ist ein Standard-Baustein der die benötigte Funktionen für 1 Analogkanal hat.
Z.B. Skalierung auf Engineeringwerte, Dämpfung, Alarmmeldungen, Muting von Alarmmeldungen usw..

Diese Baustein ruft man 60 mal, und pro aufruf wird der Baustein mit die benötigte Parameter befüttert. Einer von die Engangs-Paremeter ist die rohen Wert von den Analogkanal.
60 mal lautet viel, aber ist nicht. Es ist einfach zu programmieren und einfach für die Fehlersuche oder Änderungen einfügen.

 

[ducati]

Und wenn der 37. sich mal in nen anderen Typ ändert, geht das dann auch einfacher...

 

[uweschwarz]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich nehme diesen Thread einfach nochmal auf. TIA Portal V17 mit S7 1513-1-PN.
Ich habe für einen anderen Profibusteilnehmer (FU von Yaskawa) wieder je einen UDT für lesen und schreiben erstellt. Im Wesentlichen sind es 2 Worte die mich interessieren. Lesend: Zustandswort und Hauptistwert und schreibend Steuerwort und Hauptsollwert. Jetzt habe ich festgestellt, dass die Bytes auf der Peripherie vertauscht sind, d.h. Byte 0 in der Beschreibung der Profibuskarte entspricht Byte 1 meines Eingangswortes. Bei den Ausgängen genauso. Wenn ich nun symbolisch adressiere, z.B.

"S2010_write".STW.Fern := TRUE;

wird, jetzt, da ich in der Belegung im UDT die Bytes vertauscht habe, der Ausgang 1.2 gesetzt (in der Beschreibung Bit 10). Das führt aber dazu, dass mein UDT nicht mehr mit der Doku übereinstimmt. Gibt es einen besseren Weg?

Den Istwert möchte ich wie folgt "behandeln":

#HIW_roh := SWAP("S2010_read".HIW);
#HIW_skal := DINT_TO_REAL(WORD_TO_DINT(#HIW_roh));

und den Sollwert:

#HSW_roh := DINT_TO_WORD(REAL_TO_DINT(#HSW_skal));
"S2010_write".HSW := SWAP(#HSW_roh);

wäre das ok?