Probleme mit FC103 - CDT, Korrellierte Datentabellen

RMA

RMA

Level-1
Beiträge
400
Reaktionspunkte
24
Zuviel Werbung?
-> Hier kostenlos registrieren
Hat jemand diese FC aus dem TI - S7 Bibliothek je benutzt.

Wenn ich versuche die Pointer Adressen für IN_TBL, OUT_TBL, etc. einzugeben, bleibt das Eingabefeld nach dem zweiten RETURN leer.

Wenn ich dann in "Ansicht" zurück auf "Anzeigen mit symbolicher Darstellung" zurückschalte wird der symbolische Name für den ersten Wort angezeigt. Wenn ich dann wieder auf "Anzeigen ohne symbolischer Darstellung" umschalte kriege ich im Eingabefeld DB10.DBW0 statt der eingegebene P#DB10.DBX0.0.

Trotzdem läuft die FC ohne Fehlermeldung, nur die Werte die herauskommen sind total falsch. :?

Irgendwelche Ideen?
 
Hallo RMA,

hat der betreffende DB einen symbolischen Namen? Falls nicht, dann verpass ihn mal einen. Nach Änderungen des DB bei geöffneten Programmbaustein, den Programmbaustein erneut abspeichern! Fehlerstellen ggf. auskommentieren. Beim Umschalten auf nichtsymbolische Darstellung sollten die Pointer dennoch symbolisch angezeigt werden.

Ich bin mir nicht ganz sicher, aber die Funktion hätte trotzdem korrekt arbeiten müssen!?


Gruss, Onkel
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@Onkel Dagobert
Hätte sie eigentlich, ich hab schon ähnliche Effekte (Abgekürzte Darstellung eines Pointers inkl. Längenangabe als Symbol) erlebt, da half nur sich als Merkhilfe den Originalpointer als Kommentar mit dahinterzuschreiben. Das Baustein hat aber richtig gearbeitet.
 
Der DB hat einen symbolischen Namen, inzwischen habe ich "Symbolinformation" eingeschaltet, und das zeigt tatsächlich, statt P#DB10.DBX0.0, DB10.DBW0. Trotzdem, da Ralle sagt er hat was ähnliches gesehen, und der Baustein hat trotzdem funktioniert, bin ich nicht überzeugt, dass das Problem hier liegt. Als ich den Baustein das erste Mal parametriert habe, hab ich ein Fehler gemacht und RET_VAL hat den Fehler gemeldet, nun kriege ich ein "0" in RET_VAL.

Möglicherweise habe ich ein Problem mit meine Tabellen-DBs. Obwohl ich sie kriert habe mit den gewünschten Werte, habe ich sie nicht Online kontrolliert. Vielleicht habe ich wieder das gehasste "Anfangswert" vs. "Aktualwert" Problem. Muss ich gleich kontrollieren!

Edit: Hab ich gerade kontrolliert, die Tabellen sind OK aber indem ich ein Paar Werte geändert habe, konnte ich sehen, dass die 2 Werte (in 2 NWs), die ich als Output kriege, stammen tatsächlich von der IN_TBL Tabelle und zwar vom dritten Eintrag in NW1 und vom siebten in NW2 - egal was für ein Eingangs-Wert vorhanden ist!

Was nicht gerade hilfreich ist, ist die Tatsache, dass egal ob in AWL oder FUP, beim "Observieren" werden weder die eingeheden noch die ausgeheden Werte für FC103 angezeigt (mit Ausnahme des Konstants B#16#05 das die Tabellen-Einträge als INT definiert).
 
Weitere (nutzlose?) Infos

Nachdem ich gesehen hatte, mit "Anzeigen mit Symbolinformation" eingeschaltet, dass die Adresse als DB10.DBW0 in der Symbolinfo Anzeige erschien, habe ich den Pointer noch einmal eingegeben. Diesmal zeigte mir die Symbolinfo Anzeige *"Reuse ModuleDelay". Tabellen_Laenge*. Ich habe dann die Symbolische Darstellung ausgeschaltet (NICHT Symbolinformation) und die Anzeige wechselte in *""Reuse Module Delay".Tabellen-Laenge"*.

Nun zeigte mir NW1 immer noch den dritten Eintrag in IN_TBL und NW2 den siebten Eintrag, aber nun sind sie als hex angezeigt - selber Wert anderes Format.

Indem ich dachte, dass es mir mindestens gelungen war, die Adresse als Pointer einzugeben, habe ich das Projekt archiviert in diesem Zustand. Zurück im Büro habe ich das Projekt dearchiviert und wieder auf dem Entwicklungs PC geladen - siehe da, mein Pointer wird wieder als DB10.DBW0 angezeigt!!!
 
Problem gelöst

Falls jemand anders dasselbe Problem haben sollte, mindestens IN_TBL und OUT_TBL müssen im selben DB liegen. Wenn man so weit gegangen ist dann ist es wahrscheinlich sinnvoll alles in diesem DB zu packen, also auch IN und OUT.

Wieder ein klassisches Beispiel von der Siemens Doku - offensichtlich vom Entwicklungs-Ing. oder jemand anders geschrieben der zu viel über das ganze wußte und dem es so offensichtlich war, dass alles in einem DB gehört, dass er es nicht für notwendig hielt dies ausdrücklich zu erwähnen (wenn er überhaupt darüber nachgedacht hat!).

Mir geht es langsam auf die Nerven wie zu viele Firmen heutzutage zu geizig sind um das Geld auszugeben für ein Technischer Autor. Solche Problemen kosten Tagen Arbeit und in den meisten Fällen, wie eben in diesem kann der Hot Line auch nicht helfen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo RMA,

na das ist ja eine böse Falle! Mir war zwar in der S7-Doku aufgefallen dass in dem dargestellten Beispiel die Daten alle aus einem DB stammen, ich wäre jedoch nie auf die Idee gekommen dass es mit verschiedenen Datenquellen nicht gehen könnte. Ist ja auch S7-300/400-untypisch.

Die FC103 stammt aus dem Ordner "TI-S7 Converting Blocks". Meines Erachtens sollte man Bausteine aus den Converting-Blocks bei neu zu erstellenden Anwendungen grundsätzlich nicht verwenden. Zu den "S5-S7-Converting Blocks" hatte ich mal irgendwo einen Hinweis dazu gelesen. In den Handbüchern wird dies anscheinend leider nicht erwähnt. Nun gut, es besteht ja grundsätzlich kein Zwang, die Bausteine nicht zu verwenden. Es gibt aber offensichtlich systembedingte Eigenheiten bei diesen Bausteinen. Bei den S5-S7-Blocks sind es z.B. die Schmiermerker.

Die heutigen Siemens-Dokumentationen finde ich eigentlich sehr gut. Sicherlich gibt es immer wieder Ausnahmen, wie es ja dein Beispiel gezeigt hat.


Gruss, Onkel
 
Ich bin ein bischen sauer weil das nun der zweite Mal innerhalb von etwa vier Monaten ist, dass ich so was hatte. Der letzte Fall war mit dem FM352-5, hier muss ein Eingang mit DBx. DBB0 parametriert werden. Genau wie hier, im Beispiel abgebildet aber mit keinem Wort im Text erwähnt. Auch hier konnte die Hotline trotz mehere Stunden am Telefon und etliche e-mails MIT archiviertem Projekt über ca. zwei Wochen nicht helfen. Wenn Du Interesse hast, kannst Du die ganze Geschichte hier lesen.

Übrigens im selben Forum hat einer der S7 Gurus, der den FC103 auseinander gepflückt hat, die Meinung geäussert, dass der FC wahrscheinlich von einem ehemahligen TI-Mann geschrieben. Er fand, dass der Programmierstil nie im Leben von einem erfahrenen S7 Programmier stammen konnte. Da er einige Probleme mit dem FC gehabt hat traut er die Siemens FCs und FBs überhaupt nicht und schreibt liber seine eigene.
 
Zurück
Oben