Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: Gerätename von HW_Submodul in fb über IN des fb vorgeben

  1. #1
    Join Date
    10.01.2019
    Posts
    2
    Danke
    1
    Erhielt 0 Danke für 0 Beiträge

    Default


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo zusammen,
    ich habe in einer Anlage mehrere Codeleser (Keyence SR-2000) die über Profinet mit meiner CPU (1515-2 PN) verbunden sind. Die Verwendete Version des TIA-Portals ist V15.1.


    Zum Steuern und auslesen der Sensoren nutze ich die Hardware-Kennung. Um nicht jeden Sensor einzeln zu programmieren habe ich mir einen fb geschrieben. Dem ich die benötigten Parameter übergebe. Innerhalb des fb's werden die einzelnen HW_Submodule des Scanners eingelesen bzw. beschrieben.
    Mein Problem ist nun das ich dem Baustein den Gerätenamen des Sensors übergeben möchte um dann intern die Submodule zusammensetzen zu können.


    Bsp. Sensor 1 heißt "sr-2000" die Fehler stehen in HW_Submodul "sr-2000~Error_Status_Bits_1_1". ich Möchte dem fb nun "sr-2000" als Input "Gerätename" übergeben und dann im fb mit "#Gerätename~Error_Status_Bits_1_1" arbeiten.


    Leider habe ich hierzu noch keine Lösung gefunden. Ist es überhaupt möglich einen Teil des Submoduls Variabel zu gestalten?


    Vielen Dank im Voraus,

    Florian
    Reply With Quote Reply With Quote Answered: Gerätename von HW_Submodul in fb über IN des fb vorgeben  

  2. "Das was du machen willst sollte prinzipiell machbar sein.

    Schritt 1:
    Du legst an deinem FB einen Eingang vom Typ HW_IO an, mit dem zu quasi den "Gerätenamen" angibst. Es handet sich dabei nicht um den Gerätenamen, sondern vom eine Systemkonste, welche einem HW-Modul zugewiesen wurde.

    Schritt 2:
    Mittels der Anweisung LOG2GEO kannst du die geografische Adresse des Moduls herausfinden - darin sind alle geografischen Informationen (zentral/dzentral / dp/pn / IO-System-nr / Gerätenummer / Slot / Subslot) drinnen. Sieh dir dazu den Aufbau des Systemdatentyps GEOADDR an.

    Schritt 3:
    Bei allen Hw-Submodulen sind nun die alle Informationen mit Ausnahme von Slot / Subslot identisch. Du kannst nun alle Subslots durchiterieren und mit GEO2LOG ihre HW-ID herausfinden. Außerdem kannst mit RD_ADDR die Länge der E-/A-Daten des jeweiligen Slots/Subslots auslesen.

    Schritt 4:
    Die eigentlichen Eingangs- und Ausgangsdaten kannst du dann mittels GETIO_PART/SETIO_PART auslesen."


  3. #2
    Join Date
    08.04.2016
    Location
    4040 Linz, Österreich
    Posts
    393
    Danke
    34
    Erhielt 128 Danke für 103 Beiträge

    Default

    Das was du machen willst sollte prinzipiell machbar sein.

    Schritt 1:
    Du legst an deinem FB einen Eingang vom Typ HW_IO an, mit dem zu quasi den "Gerätenamen" angibst. Es handet sich dabei nicht um den Gerätenamen, sondern vom eine Systemkonste, welche einem HW-Modul zugewiesen wurde.

    Schritt 2:
    Mittels der Anweisung LOG2GEO kannst du die geografische Adresse des Moduls herausfinden - darin sind alle geografischen Informationen (zentral/dzentral / dp/pn / IO-System-nr / Gerätenummer / Slot / Subslot) drinnen. Sieh dir dazu den Aufbau des Systemdatentyps GEOADDR an.

    Schritt 3:
    Bei allen Hw-Submodulen sind nun die alle Informationen mit Ausnahme von Slot / Subslot identisch. Du kannst nun alle Subslots durchiterieren und mit GEO2LOG ihre HW-ID herausfinden. Außerdem kannst mit RD_ADDR die Länge der E-/A-Daten des jeweiligen Slots/Subslots auslesen.

    Schritt 4:
    Die eigentlichen Eingangs- und Ausgangsdaten kannst du dann mittels GETIO_PART/SETIO_PART auslesen.

  4. Folgender Benutzer sagt Danke zu maxder2te für den nützlichen Beitrag:

    Muellefl (11.01.2019)

  5. #3
    Join Date
    27.05.2004
    Location
    Thüringen/Berlin
    Posts
    12,855
    Danke
    626
    Erhielt 2,866 Danke für 2,076 Beiträge

    Default

    Ich hab für die SR750 ud SR1000 eine völlig andere Vorgehensweise gewählt.
    Einen Datentyp für die IN und einen Datentyp für die OUT der Scanner. Diese Datentypen enthalten alle Datenpunkte (Bool, Word, Int) in der Reihenfolge, wie Keyence sie in der Doku angibt.
    Dann lege ich in der Symboltabelle für jeden Scanner zwei Variablen an, Scanner_1_IN und Scanner_1_Out. Diese bekommen als Adresse die Startadresse der jeweiligen Adressbeteiche des Scanners, z,B. Q800.0 und I800.0.
    Diese beiden Datentypen sind auch am FB für den Scanner als IN und OUT definiert und die Variablen werden dann beim Aufruf dort angelegt. Dadurch ist es im FB (und bei Bedarf auch außerhalb) möglich, komplett symbolisch zu arbeiten.

    Deine Herangehensweise ist völlig anders, aber durchaus auch interessant.
    Mich würde dabei interessieren, was der Vorteil deiner Art der Adressierung ist, also über die Hardwaremodule. Auch da muß man ja irgendwann die Adressen nutzen und genau die Struktur der Daten kennen, also irgendwo definieren. Wie verbindet man denn in dem FB dann die herausgelesene Adresse mit der eigentlichen Datenstruktur? Geht das denn?
    Last edited by Ralle; 11.01.2019 at 08:35.
    Gruß
    Ralle

    ... there\'re 10 kinds of people ... those who understand binaries and those who don\'t …
    and the third kinds of people … those who love TIA-Portal

  6. #4
    Join Date
    08.04.2016
    Location
    4040 Linz, Österreich
    Posts
    393
    Danke
    34
    Erhielt 128 Danke für 103 Beiträge

    Default

    Quote Originally Posted by Ralle View Post
    Ich hab für die SR750 ud SR1000 eine völlig andere Vorgehensweise gewählt.
    Einen Datentyp für die IN und einen Datentyp für die OUT der Scanner. Diese Datentypen enthalten alle Datenpunkte (Bool, Word, Int) in der Reihenfolge, wie Keyence sie in der Doku angibt.
    Dann lege ich in der Symboltabelle für jeden Scanner zwei Variablen an, Scanner_1_IN und Scanner_1_Out. Diese bekommen als Adresse die Startadresse der jeweiligen Adressbeteiche des Scanners, z,B. Q800.0 und I800.0.
    Diese beiden Datentypen sind auch am FB für den Scanner als IN und OUT definiert und die Variablen werden dann beim Aufruf dort angelegt. Dadurch ist es im FB (und bei Bedarf auch außerhalb) möglich, komplett symbolisch zu arbeiten.

    Deine Herangehensweise ist völlig anders, aber durchaus auch interessant.
    Mich würde dabei interessieren, was der Vorteil deiner Art der Adressierung ist, also über die Hardwaremodule. Auch da muß man ja irgendwann die Adressen nutzen und genau die Struktur der Daten kennen, also irgendwo definieren. Wie verbindet man denn in dem FB dann die herausgelesene Adresse mit der eigentlichen Datenstruktur? Geht das denn?
    Ich finde umgekehrt auch deinen Ansatz recht interessant.

    Mein Ansatz stammt eher aus dem Bereich der Antriebstechnik. Als Beispiel nehme ich mal einen SEW-Antrieb aus der Serie MDX61B mit Profinet-Karte.
    Je nach Betriebsart müssen in der Hardware-Konfiguration 3, 4, 6 oder 10 Wörter Eingangs- und Ausgangsdaten definiert werden. Nach deiner Vorgangsweise bedeutet das für das Programmieren folgenden Aufwand:
    1. Festlegen, welche Länge ich brauche
    2. E- und A-Adressen festlegen
    3. Datentypen auf Ix.0 und Qx.0 verschalten
    4. Die E- und A-Variablen an den FB übergeben
    Es gibt damit 8 Eingriffspunkt für den Programmierer, an der Fehler passieren können, welche der FB nur bedingt feststellen kann.

    Das Übergeben der HW-ID hat den Vorteil, dass
    1. mir die E- und A-Adressen völlig egal sind (es gibt lediglich die Richtlinie, dass sie irgendwo >= 16384 sein sollen)
    2. ich ohne Kenntnis der Adressen die Eingangs- und Ausgangsdaten mit GETIO_PART und SETIO_PART lesen und schreiben kann
    3. ich mittels RD_ADDR die Länge des E-/A-Moduls herausfinden kann und ggf. im FB warnen kann wenn zu wenige Daten vorhanden sind
    4. ich mittels LOG2GEO die geografische Lage herausfinden kann und ggf. im FB warnen kann wenn diese absolut nicht plausibel ist
    5. die HW-ID ist eine symbolische Systemkonstante, welche Querverweisfähig ist

    Das Ganze hat natürlich auch einen Nachteil:
    Das Einlesen und Rausschreiben der Daten mittels GETIO_PART und SETIO_PART ist nur praktikabel mit ARRAY OF BYTE oder ARRAY OF WORD Feldern, die man dann in lesbare Datentypen umkopieren muss. Diese sind dann aber prozessoroptiomiert und ich habe einen schönen Eingriffspunkt, wenns mit der PN-Gegenstelle mal Probleme mit Intel/Motorformat-Geschichten gibt.


    Um noch weiter auszuholen das Beispiel Sinamics S120 DO Servo. Hier gibts typischer 1-3 Hardware-Module (Telegramm, Zusatzdaten, Safety-Daten). Die Angabe der HW-ID von einem der 3 HW-Module reicht, um die geografische Adresse herauszufinden (in diesem Fall der Slot). Um auf die Daten von allen 3 Modulen zuzugreifen kann man nun die HW-IDs aller 3 Subslots auslesen und zumindest lesend auf alles zugreifen, ohne dass sich der Programmierer über EA-Adressen, die Verschaltung von Datentypen usw. Gedanken machen muss.

    Das Ganze immer mit dem Hintergedanken: ich programmiere den Kern, 20-30 Kollegen setzen das an Projekten ein und sollen möglichst wenig Konfigurier-Vorschriften befolgen müssen.


    Ob diese Herangehensweise für die Keyence-Scanner die sinnvollste ist oder nicht, kann ich von der Ferne nicht beurteilen.

  7. Folgende 2 Benutzer sagen Danke zu maxder2te für den nützlichen Beitrag:

    Ralle (11.01.2019),TheLevel (11.01.2019)

  8. #5
    Join Date
    27.05.2004
    Location
    Thüringen/Berlin
    Posts
    12,855
    Danke
    626
    Erhielt 2,866 Danke für 2,076 Beiträge

    Default

    @maxder2te

    Ja, ich frage mich eben auch, was ist wann die optimale Methode,
    Beim Scanner ändert sich ja eher nicht die Schnittstelle in Abhängigkeit der Anwendung.
    Ich hatte mir mal einen Siemens-Baustein (ich glaube es war FB283) angesehen, die hatten zum Schluß sogar ihre eigenen UDT aus dem DB entfernt und dann mit Byte- Word- und Sclice-Zugriffen vollkommen "unsymbolisch" gearbeitet. Keine Ahnung, wie es dazu kam, aber der Baustein war schlußendlich grauenhaft, da man sich die Zuordnung zu den Bits immer selbst heraussuchen mußte, so sie nicht wenigstens als Kommentar oder im Siemens-Fall als auskommentierte "alte" UDT-Variable bekannt war. Zugegeben, den Baustein verwendet man, ohne in ihn hineinzusehen, aber wenn irgendetwas nicht funktioniert, sucht man dann doch mal, bzw. wenn man etwas erweitern will. Die Srukturen muß man ja auch bilden, um später symbolisch arbeiten zu können. Ich denke dein Weg ist aufwändiger, aber bei unterschiedlichen Konfigurationsmöglichkeiten zum Schluß flexibler. Immer davon abhängig, wieviel Zeit man für die Enwicklung der Bausteine zur Verfügung hat, denn ehe das läuft, hat man sicher einige Bugs auszuräumen.
    Last edited by Ralle; 11.01.2019 at 10:21.
    Gruß
    Ralle

    ... there\'re 10 kinds of people ... those who understand binaries and those who don\'t …
    and the third kinds of people … those who love TIA-Portal

  9. #6
    Muellefl is offline Neuer Benutzer
    Themenstarter
    Join Date
    10.01.2019
    Posts
    2
    Danke
    1
    Erhielt 0 Danke für 0 Beiträge

    Default

    Quote Originally Posted by maxder2te View Post
    Das was du machen willst sollte prinzipiell machbar sein.

    Schritt 1:
    Du legst an deinem FB einen Eingang vom Typ HW_IO an, mit dem zu quasi den "Gerätenamen" angibst. Es handelt sich dabei nicht um den Gerätenamen, sondern um eine Systemkonstante, welche einem HW-Modul zugewiesen wurde.

    Schritt 2:
    Mittels der Anweisung LOG2GEO kannst du die geografische Adresse des Moduls herausfinden - darin sind alle geografischen Informationen (zentral/dzentral / dp/pn / IO-System-nr / Gerätenummer / Slot / Subslot) drinnen. Sieh dir dazu den Aufbau des Systemdatentyps GEOADDR an.

    Schritt 3:
    Bei allen Hw-Submodulen sind nun die alle Informationen mit Ausnahme von Slot / Subslot identisch. Du kannst nun alle Subslots durchiterieren und mit GEO2LOG ihre HW-ID herausfinden. Außerdem kannst mit RD_ADDR die Länge der E-/A-Daten des jeweiligen Slots/Subslots auslesen.

    Schritt 4:
    Die eigentlichen Eingangs- und Ausgangsdaten kannst du dann mittels GETIO_PART/SETIO_PART auslesen.
    Danke dafür. Konnte das ganze so recht flott umsetzen.

    @ Ralle

    Deinen Ansatz finde ich auch interessant.
    Ich wollte das Ganze über die HW_ID lösen, da dieser Baustein außer von mir auch von den Kollegen meiner Abteilung genutzt wird und ich das ganze möglichst einfach in der Anwendung gestalten wollte. Durch diese Überlegung bin ich dann bei den systemkonstanten gelandet.
    So gebe ich an meinen IN des FB's die ID des ersten Submoduls und lese die Daten dann im FB aus und speichere sie dort. Danach kann ich die Daten dann wie gewohnt nutzen.

    Ich bin mir nicht sicher ob es die optimale Methode hierfür gibt, da beide Methoden ein schnelles arbeiten ermöglichen.

  10. #7
    Join Date
    06.10.2004
    Location
    Kopenhagen.
    Posts
    5,167
    Danke
    412
    Erhielt 925 Danke für 733 Beiträge

    Default

    Ich wurde nach den Verfahren mit E/A-Datentypen tendieren.
    Es ist mMn. viel einfacher und unmittelbar zu verstehen.

    Ralle hat gefragt:
    Quote Originally Posted by Ralle View Post
    Mich würde dabei interessieren, was der Vorteil deiner Art der Adressierung ist, also über die Hardwaremodule. Auch da muß man ja irgendwann die Adressen nutzen und genau die Struktur der Daten kennen, also irgendwo definieren. Wie verbindet man denn in dem FB dann die herausgelesene Adresse mit der eigentlichen Datenstruktur? Geht das denn?
    Was ist dein Antwort dazu ?
    Jesper M. Pedersen

  11. #8
    Join Date
    22.03.2007
    Location
    Detmold (im Lipperland)
    Posts
    12,223
    Danke
    411
    Erhielt 2,506 Danke für 2,084 Beiträge

    Default

    Ich habe das in der Vergangenheit im Prinzip nach dem Vorschlag von Max gelöst. Das funktioniert eigentlich sehr schön - man bildet den Aufbau der HW-Konfig in seinem Baustein nach und lädt die Daten dort hinein bzw. schreibt sie zurück.
    Soll das Ganze eine Art Standard-FB werden dann setzt das natürlich voraus, dass die HW-Konfig immer gleich angelegt wird (was ja bei Keyence u.U. dann eine Vorschrift an den Programmierer bedingt) - das würde ich allerdings nicht als ein Problem sehen, da hier die Vorteile ganz eindeutig überwiegen ...

    Das Anlegen von Schnittstellenvariablen für die diversen EA-Adressen und Bereiche würde ich (heute) nicht mehr machen ...

    Gruß
    Larry

  12. #9
    Join Date
    06.10.2004
    Location
    Kopenhagen.
    Posts
    5,167
    Danke
    412
    Erhielt 925 Danke für 733 Beiträge

    Default

    Quote Originally Posted by Larry Laffer View Post
    Das Anlegen von Schnittstellenvariablen für die diversen EA-Adressen und Bereiche würde ich (heute) nicht mehr machen ...
    Auch nicht wenn du die E/A als ganze Strukturen von vordefinierter Datentypen anlegen kann ?
    Also, alle Eingänge mittels Datentyp auf einmal definieren, und dasselbe mit die Ausgänge, und dann diese auf nur 1 FB-Eingang und 1 FB-Ausgang übergeben.
    Jesper M. Pedersen

  13. #10
    Join Date
    27.05.2004
    Location
    Thüringen/Berlin
    Posts
    12,855
    Danke
    626
    Erhielt 2,866 Danke für 2,076 Beiträge

    Default


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Quote Originally Posted by Larry Laffer View Post
    Ich habe das in der Vergangenheit im Prinzip nach dem Vorschlag von Max gelöst. Das funktioniert eigentlich sehr schön - man bildet den Aufbau der HW-Konfig in seinem Baustein nach und lädt die Daten dort hinein bzw. schreibt sie zurück.
    Soll das Ganze eine Art Standard-FB werden dann setzt das natürlich voraus, dass die HW-Konfig immer gleich angelegt wird (was ja bei Keyence u.U. dann eine Vorschrift an den Programmierer bedingt) - das würde ich allerdings nicht als ein Problem sehen, da hier die Vorteile ganz eindeutig überwiegen ...

    Das Anlegen von Schnittstellenvariablen für die diversen EA-Adressen und Bereiche würde ich (heute) nicht mehr machen ...

    Gruß
    Larry
    Im Falle von Keyence ist das je eine Struktur, in der dann Alles drin ist.

    @JesperMP

    Einfacher finde ich auch meine Lösung, die Lösung des TE ist halt dem TIA-Portal näher. Meißt hab ich gar nicht die Zeit, das soweit auszuprogrammieren, aber ich denke, wenn man mal einen Rahmen hat (siehe Larry), kann man den immer wieder neu befüllen und es wird weniger aufwändig. Im Falle von Siemens-Servos, z.Bsp. nutze ich die FB 283 etc.

    PS: Bin eben mehr im Sondermaschinenbau unterwegs, da hab ich ständig neue Geräte am Start und oft verwenden wir die nur ein oder zwei Mal. Das muß man dann den Aufwand abwägen.
    Last edited by Ralle; 11.01.2019 at 13:27.
    Gruß
    Ralle

    ... there\'re 10 kinds of people ... those who understand binaries and those who don\'t …
    and the third kinds of people … those who love TIA-Portal

Similar Threads

  1. Sinamics S120 über TTL Signal Sollwert vorgeben
    By STEP7_NEWBEE in forum Antriebstechnik
    Replies: 5
    Last Post: 02.03.2018, 01:07
  2. Step 7 Rampe über Analogwerte vorgeben
    By RON_87 in forum Simatic
    Replies: 5
    Last Post: 12.02.2015, 18:09
  3. Replies: 8
    Last Post: 29.11.2011, 17:08
  4. Pointer offset von Aussen vorgeben
    By Pascher in forum Simatic
    Replies: 2
    Last Post: 22.05.2009, 17:07
  5. Replies: 10
    Last Post: 25.02.2006, 10:59

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •