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

Muellefl

Level-1
Beiträge
2
Reaktionspunkte
0
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
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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?
 
Zuletzt bearbeitet:
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.
 
@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.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
Ich wurde nach den Verfahren mit E/A-Datentypen tendieren.
Es ist mMn. viel einfacher und unmittelbar zu verstehen.

Ralle hat gefragt:
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 ?
 
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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.
 
Zuletzt bearbeitet:
Hallo,

Ich habe ein ähnliches Problem..
an mehreren Anlagen sollen Keyence SR-1000 verbaut werden und da sind 300er CPU's verbaut..
für 300er gibt es die Funkionen wie HW_Submodule, S_Move und Chars_to_strg nicht...
Wie kann ich das am besten umsetzen? Bin auch ziemlich unerfahren was Datenverarbeitung und SPS angeht.

Bitte um hilfe.

Gruß
Bilo
 
Zurück
Oben