TIA DB-Symbolisch (indirekt) aufrufen

[Kleinerwolf]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

Mittels IN/OUT soll der angegebene DB 1. gelesen 2. geschrieben werden. In der Schnittstelle wird der Datentyp als PLC-Datentyp deklariert (z.B. "LBP_typeAxisX") welcher verschiedenste Variablen enthält und somit der Baustein voll symbolisch programmiert werden kann.

Gibt es jetzt eine Möglichkeit den DB an der Schnittstelle irgendwie symbolisch variabel anzusprechen ohne "CASE-Anweisung" diesen 31mal mit den verschiedensten Version aufzurufen?

Oder hat sich Siemens mittlerweile etwas einfallen lassen einen "Symbolnamen" variabel zu gestallten so wie es sich so manch anderer schon mal gewünscht hätte ;-)

Das sich Siemens, in diesem Fall "SINUMERIK" selbst nicht an die Empfehlungen mittels Array zu arbeiten hält, fällt diese Version schon mal weg. (DB-Nr. 31-61 "LBP_Axis1-31")
DB_ANY bzw. VARIANT bzw. REF_TO geht auch nicht da hier TIA einen Fehler erkennt bzw. ich den Wald vor lauter Bäumen nicht mehr sehe .

Die Beträge wie unten angeführt kenne ich, jedoch bleibt die Hoffnung hier hat sich etwas getan.

"DB Adresse und DB Varaiblenadresse zur Laufzeit adressieren" bzw. SINUMERIK ONE "Achs-DB zur Laufzeit variabel ansprechen" ​

 

[TP-Inc]

Ein Symbol zur Laufzeit zusammenzubauen geht (Gottseidank) nicht. REF_TO und TypeOf sind eh die richtigen Ansätze. Welchen Fehler bringt TIA?

 

[Kleinerwolf]

Zuviel Werbung?
-> Hier kostenlos registrieren

Fehlermeldung bei REF_TO "LBP_typeAxisX"
233,Parameter der Funktion oder des Funktionsbausteins stimmen nicht mit den übergebenen formalen Parametern überein.

"TIA V17 Update 4"

Das "GottSeiDank" wäre jedoch in diesem Fall für mich die einfachste Version ;-)

 

[revve]

Was hast du denn vor, dass du das alles zur Laufzeit zusammenfrickeln willst/musst? Gehts um verschiedene Maschinenkonfigurationen?

Ich habs mal so in der Simulation versucht, das scheint zu funktionieren und kommt wahrscheinlich am ehesten an das was du vorhast:

 

[Oberchefe]

dann muss er aber das REF("axisx") in die CASE packen und hat nichts gewonnen?

 

[revve]

Zuviel Werbung?
-> Hier kostenlos registrieren

dann muss er aber das REF("axisx") in die CASE packen und hat nichts gewonnen?

schon, aber nicht alle FC/FB Aufrufe weil er schonmal eine "Pointervariable" für den DB übergeben kann - es las sich raus als hätte der TE hier schon Schwierigkeiten. Wir wissen ja auch gar nicht was er vorhat.


Ich denk auch besser/weniger wirds nicht, lass mich aber gerne eines besseren belehren, aber so Schweinereien wie DBs per Nummer adressieren die man sich zusammenbastelt und der nächste der dran darf findets niemehr sind halt (Gottseidank) nicht mehr en vogue.

 

[Kleinerwolf]

Was hast du denn vor, dass du das alles zur Laufzeit zusammenfrickeln willst/musst? Gehts um verschiedene Maschinenkonfigurationen?

Ich habs mal so in der Simulation versucht, das scheint zu funktionieren und kommt wahrscheinlich am ehesten an das was du vorhast:
Anhang anzeigen 64157

Ja genau es würde um verschiedene Masch. Cfg. gehen

In der guten Step7-Classic Welt war das Schlüsselwort AUF[DBNo] die Lösung um das alles schön flexibel zu halten… So konnte der Inbetriebnehmer mittels Eingabemaske die Maschine selbst konfigurieren, was somit für mich weniger Arbeit bedeutete

Werde das morgen gleich mal so probieren und bestimmt funktioniert es wie gewünscht!
Fällt eindeutig unter „den Wald vor lauter Bäumen nicht mehr gesehen“

Deklaration mit REF_TO „…“ gemacht jedoch im Code keine Zuweisung oder ungewollt gelöscht …. :-D

 

[Peter Gedöns]

Hallo ,
ich hab grade kein TIA zur Hand , denke aber mich zu erinnern das REF_To nur mit einfachen Datewntypen geht.

Es ist damals die Entscheidung getroffen worden das PLC kompatibel zur 840Dsl auszuführen , damit war ein DB mit Array of Axis raus.

Du kannst dir das ja selbst bauen , Im OB1 nach dem FC2 kopierst du die DBs in das Array , am ende vom OB 1 wieder zurück , die Performens der ONE reicht dafür.

Nur der OB40 ist da mit vorsicht zugeniesen , hast du da etwas Programmiert ?
wenn nicht keine Problem , wenn ja musst du da auch noch ins Array kopieren , wenn der OB40 aufgerufen wird , wird da auch die komplette VDI Schittstelle aktualisiert.

Auf der AMB wurde ja das Grundprogramm Plus vorgestellt , in TIA 17 mit der Toolbox up10 wird das ausgeliefert , vieleicht sagt dir das ja zu

 

[revve]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja genau es würde um verschiedene Masch. Cfg. gehen

Dann könntest sogar diese REF Geschichte mit switch-case im Achs-FB aufrufen und von außen dein Achs-DB-MD als Integer dranpacken.
Ob das mit den DB-Namen im Vorlage-FB 100% sauber ist überlasse ich dir.

In der guten Step7-Classic Welt war das Schlüsselwort AUF[DBNo] die Lösung um das alles schön flexibel zu halten… So konnte der Inbetriebnehmer mittels Eingabemaske die Maschine selbst konfigurieren, was somit für mich weniger Arbeit bedeutete

Verzeih mir, ich bin leider mit TIA groß geworden, drum halten sich meine nostalgischen Gefühle für Classic leider in Grenzen und werden eher immer wieder mal zu Kopfschmerzen, aber jedem seins..

 

[Kleinerwolf]

Hallo ,
ich hab grade kein TIA zur Hand , denke aber mich zu erinnern das REF_To nur mit einfachen Datewntypen geht.

Es ist damals die Entscheidung getroffen worden das PLC kompatibel zur 840Dsl auszuführen , damit war ein DB mit Array of Axis raus.

Du kannst dir das ja selbst bauen , Im OB1 nach dem FC2 kopierst du die DBs in das Array , am ende vom OB 1 wieder zurück , die Performens der ONE reicht dafür.

Nur der OB40 ist da mit vorsicht zugeniesen , hast du da etwas Programmiert ?
wenn nicht keine Problem , wenn ja musst du da auch noch ins Array kopieren , wenn der OB40 aufgerufen wird , wird da auch die komplette VDI Schittstelle aktualisiert.

Auf der AMB wurde ja das Grundprogramm Plus vorgestellt , in TIA 17 mit der Toolbox up10 wird das ausgeliefert , vieleicht sagt dir das ja zu

Das mit dem hin und her kopieren wäre der Notnagel gewesen, wobei dann ja auch die Kanäle usw. auch kopiert werden müssten.

Der FC19 MCP Ctrl von Sinumerik schreibt jedoch wieder direkt in die Achs-DB‘s bzw. Kanal-DB‘s was zu inkonsistenter Datenhaltung führen würde -> mit großer Vorsicht zu behandeln oder die Daten müssten wieder aktualisiert werden …

Das mit dem „Array DB“ lag bestimmt an der Tatsache dass die Migration anstatt 1000 Fehler mit 100000 Fehlern beendet worden wäre.

 

[Peter Gedöns]

Das mit dem „Array DB“ lag bestimmt an der Tatsache dass die Migration anstatt 1000 Fehler mit 100000 Fehlern beendet worden wäre.

nö es hätte keine Migration gegeben ,,
Die Migration sollte eh gesperrt werden !
ich bekomme immer wieder PLC Prgramme von der ONE , die von 840c abstammen (AR1 AR2) , die verantwortlichen dafür nennen sich "Entwickler " PLC Programmierer ist denen zu profan.

wenn Du schon den FC19 nutzt dann bau das Array halt nach dem aufruf , besser Du ersetzt den FC19 durch was ordentliches ,

 

[Kleinerwolf]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo ,
ich hab grade kein TIA zur Hand , denke aber mich zu erinnern das REF_To nur mit einfachen Datewntypen geht.

Es ist damals die Entscheidung getroffen worden das PLC kompatibel zur 840Dsl auszuführen , damit war ein DB mit Array of Axis raus.

Du kannst dir das ja selbst bauen , Im OB1 nach dem FC2 kopierst du die DBs in das Array , am ende vom OB 1 wieder zurück , die Performens der ONE reicht dafür.

Nur der OB40 ist da mit vorsicht zugeniesen , hast du da etwas Programmiert ?
wenn nicht keine Problem , wenn ja musst du da auch noch ins Array kopieren , wenn der OB40 aufgerufen wird , wird da auch die komplette VDI Schittstelle aktualisiert.

Auf der AMB wurde ja das Grundprogramm Plus vorgestellt , in TIA 17 mit der Toolbox up10 wird das ausgeliefert , vieleicht sagt dir das ja zu

Und schon sind sie wieder da, die Kopfschmerzen ;-). Du hattest im Grundgedanken recht bzgl. "REF_TO". Da der "SINUMERIK Achs-DB" ein "nicht optimierter" DB ist verweigert TIA die Verwendung :-( Dann bleibt wohl oder übel nur der Notnagel wie der auch immer aussehen wird.

Da war wohl der SINUMERIK ONE-Grundgedanke und altes Basisprogramm um 1 - 2 Jahre zu früh am Markt.

 

[revve]

Und schon sind sie wieder da, die Kopfschmerzen ;-). Du hattest im Grundgedanken recht bzgl. "REF_TO". Da der "SINUMERIK Achs-DB" ein "nicht optimierter" DB ist verweigert TIA die Verwendung :-( Dann bleibt wohl oder übel nur der Notnagel wie der auch immer aussehen wird.

Da war wohl der SINUMERIK ONE-Grundgedanke und altes Basisprogramm um 1 - 2 Jahre zu früh am Markt.

hier noch was mit Variant, scheint auch mit nicht optimierten Bausteinen zu klappen, vielleicht ja auch auf deiner ONE

 

[Peter Gedöns]

Da war wohl der SINUMERIK ONE-Grundgedanke und altes Basisprogramm um 1 - 2 Jahre zu früh am Markt.

Na ich denke da war nix zu früh am Markt , die Entscheidung wurde nicht gestern getroffen das ist schon ein paar Jahre her .

es war Pest oder Cholera , nur neues Grundprogramm und 80% der Kunden maulen da Sie ihren antiken Programmen nicht in die Steuerung bekommen,
oder kompatibel , 80% zufrieden ,10% überarbeiten das antike Programm , 10 % fordern vehement was neues .

die 10% die was neues wollen erzählen dann was sie alles brauchen .. Objekte usw ....
alles andere war ja alles alter Mist, dann gibt es was neues .
Das entsprechende Klientel beikommt das in die Finger und baut als erstes unser alte Schnittstellen nach

und ja Variant geht mit nicht optimierten DBs