TIA Eingang vs. Merker

[Credofire]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich habe es jetz bei einigen gesehen, dass sie sich die Eingänge einmal als Merker in einem DB ablegen und dann nur auf den Merker zurückgreifen.
Gibt es dafür einen Grund? Ist der zugriff auf den Merker vielleicht schneller als auf den Eingang?
Beispielsweise wurde ein Endlagensensor in einem DB als remanenter Merker hinterlegt

 

[RONIN]

Hatten wir schön öfters....

Siehe Thema hier:
http://www.sps-forum.de/simatic/75621-haltet-ihr-von-input-output-mapping.html?highlight=Mapping

Grundsätzlich geht es dabei nicht etwa um Geschwindigkeiten oder ähnliches.
Man kann so z.B. auf den DB-Datenpunkt bei der nächsten Anlage eine andere E-Nummer drauflegen ohne den Code zu ändern.
Oder man kann den Datenpunkt den Eingang eventuell mit ein paar Codezeilen simulieren wenn z.b. der Sensor optional ist und nicht aufgebaut wurde...

So'n Zeug halt.

EDIT: Ich nutze sowas ebenfalls, allerdings in dem ein Sensor als ganzer Datensatz im einem DB abgelegt wird. Das Programm greift dann auch nur mehr auf den Datensatz zu.

 

[Gnaldariel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mögliches Beispiel, ist ein ASi-Bussystem. Viele Eingänge haben unterschiedliche Funktionsprinzipien. Manche sind False wenn sie belegt sind (Lichtschranke) oder eben True wenn sie belegt sind (Lichttaster).

So kann ich einmal in einem Baustein alles runterschreiben und entsprechend negieren und nutze dann diese Sensoren alle so, als ob sie True wären, wenn sie belegt sind. Kann je nach Größe und Bedarf den Programmieraufwand verringern. Als ein möglicher Grund dafür

 

[Ivan91]

Wenn ihr immer ähnliche Anlagen konstruiert und sich im E-Plan lediglich die Eingänge verschieben musst du später lediglich in einem FC etwas umschreiben.
Dies wäre dann nur die Eingänge in das richtige Bit des Datenbausteins schreiben.
Der Rest des Programms bleibt unberührt

 

[Christmaspoo]

bitte löschen

 

[RONIN]

Zuviel Werbung?
-> Hier kostenlos registrieren

Der Rest des Programms bleibt unberührt

Obwohl man zwar die Eingänge bei symbolischer Programmierung (in TIA sowieso) auch über die Symbol/Variablentabelle wechseln kann, hat man dort immer noch den Nachteil dass der Code (mit den neuen Eingangsnummern) neu kompiliert werden muss.

Dann hat man beim Codevergleich mit einer anderen Anlage wieder Probleme mit Zeitstempeln und Code-Unterschieden.

Im Endeffekt stellt diese Vorgehensweise eine Kapselung deines Programmes gegenüber der I/O-Ebene dar.
Wenn du einen Funktionsbaustein aufrufst und ihm einen Eingang per Schnittstelle gibst machst du auch nichts anderes als den Code innerhalb des FBs von den Eingangsparametern abzukapseln.

 

[Credofire]

Vielen Dank,
auch für den Link. Wenn ich geahnt hätte das man sowas I/O Mapping nennt, hätte ich es sicher gefunden.
Man lernt eben nie aus.

 

[PN/DP]

Beispielsweise wurde ein Endlagensensor in einem DB als remanenter Merker hinterlegt

Sowas macht eigentlich nur Sinn, wenn es den Sensor in der Anlage nicht gibt und deshalb kein Eingang auf das DB-Bit kopiert wird. Ich würde da aber trotzdem in jedem Zyklus statt dem Eingangsbit ein TRUE oder FALSE zuweisen mit entsprechendem Kommentar, statt auf Remanenz zu hoffen.

Harald

 

[abe01]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das hatten wir frueher gemacht um beispielsweise im Falle eines Hardwarefehlers - defekt an eingangskarte nicht das gesamte Programm auf die betroffenen Eingaenge durchsuchen zu muessen. Remanenz ist nicht in dem fall, da zyklisch eingelesen undbei jedem zyklus der DB aktualisiert wurde. Da wurde schonmal ne 8 bit Eingangskarte an die SPS drangehaengt weil keine 16bit oder 32bit Karten zur Verfuegung standen. Auch waren die HMI nicht Stand der heutigen Technik und man hatte nur DB zugriffe vom und zum HMI. Das gleiche wurde auch mit den Ausgaegen gemacht. Diese vorgehensweise wurde auch von einigen Kunden gefordert.

Das waren noch Zeiten gewesen als man im weissen Kittel und Schlips rumrannte und als Halbgott angesehen wurde