TIA Alle Eingänge in DB transferiert

[Moritz_]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen, ich habe hier ein Programm vorliegen in dem alle Eingänge nur als IB deklariert sind und dann im ersten Netzwerk des OB1 Byte für Byte in einen EingangsDB transfertiert werden.
Jetzt wäre meine Frage, welchen Zweck hat das Ganze?
Das Einzige was mir in den Sinn kam, dass man so die Eingänge simulieren kann, ohne zu forcen.

Verwendet ihr sowas? Welche Vorteile/ Nachteile hat das?

 

[DeltaMikeAir]

Vielleicht hat das mal jemand gemacht, der den Baustein an unterschiedlichen Steuerungen und unterschiedlichen Adressbereichen öfters einsetzen wollte und hat dann immer nur die notwendigen E/A verschaltet.

Kann im Prinzip viele Gründe haben.

 

[Ludewig]

Zuviel Werbung?
-> Hier kostenlos registrieren

Manches ist auch einfach Tradition. Vielleicht aus einer Zeit, in der Zugriffe auf I langsamer waren als auf M oder DB, oder leichteres Umverdrahten bei direkter Adressierung.

 

[ducati]

Ja, wenn mann den E0.0 47 mal im Programm liest, macht es nen haufen Arbeit, das zu ändern, wenn sich bei der Inbetriebmahme rausstellt, dass der Sensor jetzt doch am E6.4 hängt.
Deshalb rangieren das manche Leute erstmal in nen DB.

Ich mach sowas schon lange nicht mehr, weil bei mir jeder DI eh nur einmal auf einen Meldebaustein geht, und im Programm für Verriegelungen, was auch immer, der DB vom Meldebaustein benutzt wird...

 

[Januar]

Ich musste das letztens auch kennen lernen. Hier wurde es für Visu-Zwecke gemacht. Die Eingänge wurden dann in DB Words kopiert, und die Visu sammelt sich dann direkt das Word ein.

Außerdem lässt sich so die Polarität leichter umstellen. Wenn du eine Lichtschranke hast und dann plötzlich feststellst, dass der Eingang doch andersrum arbeitet, dann kannst du es einfacher nachpflegen, indem du nur beim Kopier-Vorgang ansetzt.

 

[schwimmer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Außerdem lässt sich so die Polarität leichter umstellen. Wenn du eine Lichtschranke hast und dann plötzlich feststellst, dass der Eingang doch andersrum arbeitet, dann kannst du es einfacher nachpflegen, indem du nur beim Kopier-Vorgang ansetzt.

Dann musst du aber jeden Eingang einzeln an den DB anbinden, Byte oder Word kopieren geht dann auch nicht.

 

[ducati]

ja, im Endefekt gehts darum, die DIs nur einmal im Programm zu verschalten, dann brauchst auch nur einmal invertieren... Wobei das aber auch ne Frage der Standardisierung ist. Betriebsmeldungen immer Schliesser, Störmeldungen immer Öffner (drahtbruchsicher). Wenn das bei der IBN mal nicht so funktioniert, dann ist eigentlich der Elektriker/Eplaner gefragt, das zu ändern...

 

[ducati]

Dann musst du aber jeden Eingang einzeln an den DB anbinden, Byte oder Word kopieren geht dann auch nicht.

Da halt halt jemand den Hintergrund nicht verstanden und nur "nach Liste" gearbeitet. In der Arbeitsanweisung stand halt nur, "DIs über DBs rangieren".

 

[Januar]

Zuviel Werbung?
-> Hier kostenlos registrieren

Dann musst du aber jeden Eingang einzeln an den DB anbinden, Byte oder Word kopieren geht dann auch nicht.

DB_Input.IW0 := %IW0 XOR 16#b7;

 

[holgermaik]

Jetzt wäre meine Frage, welchen Zweck hat das Ganze?

so kannst du dein Programm komplett fertig stellen und testen obwohl die verwendete Hardware noch nicht feststeht bzw. lässt sich die Hardware ohne viel Probleme auch an den Markt anpassen. So bleibt der Inbetriebnehmer flexibel wenn mal ein Teil nicht lieferbar ist.
Wir haben auch mehrere Maschinen wo dies so gelöst wurde. Die "Erbauer" haben ohne den Programmierer die Hardware festgelegt. (alles Zentral.. viel dezentral..) Der Inbetriebnehmer hat anschließend die Hardware nur auf das Programm gemappt.

 

[Moritz_]

so kannst du dein Programm komplett fertig stellen und testen obwohl die verwendete Hardware noch nicht feststeht bzw. lässt sich die Hardware ohne viel Probleme auch an den Markt anpassen. So bleibt der Inbetriebnehmer flexibel wenn mal ein Teil nicht lieferbar ist.
Wir haben auch mehrere Maschinen wo dies so gelöst wurde. Die "Erbauer" haben ohne den Programmierer die Hardware festgelegt. (alles Zentral.. viel dezentral..) Der Inbetriebnehmer hat anschließend die Hardware nur auf das Programm gemappt.

Das mit dem mappen habe ich noch nicht so ganz verstanden. Da der DB genauso aufgebaut ist wie meine Eingangsadressen.
Und wenn in den verschiedenen Anlagen die Bezeichnungen andere sind, ist das vermutlich auch nicht so brauchbar oder?

 

[holgermaik]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mal ein Beispiel aus der Praxis, da wird es eventuell deutlicher
Projektiert ist eine 16xDI. Es werden also in deinem Programm 4 IB gelesen und die einzelnen Bits auf auf die DBX gemappt. Jetzt ist aber keine 16xDI verfügbar also kommt eine 32xDI rein womit sich die Adressen ändern. In deinem Fall müssen also nur die 4 IB geändert werden und es sind keine anderen Anpassungen im Programm oder HMI nötig. Grade bei Fremdprogrammen ist dies ein einfacher Weg den jeder Inbetriebnehmer durchführen kann ohne sich tiefgreifend mit der Programmstruktur zu beschäftigen.

 

[PN/DP]

Vielleicht ist das reine Kopieren der IB in DB noch nicht alles oder nur die Vorstufe eines "Standards", wo über das HMI in einem Setup-Bildschirm sämtliche Inputs manipuliert werden können: invertieren, auf 0 oder 1 "forcen", steigende/fallende Flanken-Bits erzeugen, ...

Oder auch schon erlebt: zur Inbetriebnahme wird erstmal nur jemand geschickt, der mit einem Mobiltelefon und einer Computermaus umgehen kann, und der muss dann in Setup-Dialogen mit Häkchen sämtliche Inputs an das anpassen, was vorort vorgefunden wird oder was der eigentliche Programmierer von ferne so feststellt ...

 

[Moritz_]

Vielleicht ist das reine Kopieren der IB in DB noch nicht alles oder nur die Vorstufe eines "Standards", wo über das HMI in einem Setup-Bildschirm sämtliche Inputs manipuliert werden können: invertieren, auf 0 oder 1 "forcen", steigende/fallende Flanken-Bits erzeugen, ...

Genau, das soll scheinbar gehen. Wäre auch meine Anwendungsidee, die Eingänge bei einer Vorinbetriebnahme so zu steuern.

 

[Salli1991]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also ohne jetzt großartig auf die historischen Gegebenheiten einzugehen hab ich damals im 1. Semester Informatik folgendes gelernt: "Redundanzen begünstigen Inkonsistenzen." Manchmal ist weniger mehr^^

 

[Balu_der_Bär]

Hallo,
ich habe das bei einem Projekt auchmal gemacht da es sehr viele identische digital anzusteuernde Aktoren gab.
Es gibt im DB dann doch mehr Möglichkeiten die einzelnen Variablen in Structs/Arrays zusammen zufassen vor allem wenn Ein- und Ausgänge zusammen gehören.
War damals ziemlich begeistert wie strukturiert und einfach ich das Programm dann gestallten konnte und wollte das danach häufiger benutzen. Kam aber nie dazu da es mMn schon sehr spezielle Ausgangsvoraussetzungen benötigt, dass das Sinn ergibt und am ende Zeit spart bzw. das Programm übersichtlicher macht.

grüße
Balu

 

[DCDCDC]

Hab in einem Projekt auch alle Hardware Signale über einen Datenbaustein am Laufen. Finde es so übersichtlicher.

 

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bei mir so etwas ein absolutes Nogo! Was wird denn da bitte übersichtlicher? Wenn man dann sogar noch auf diesem Wege umverdrahtet oder negiert? Das ist der blanke Horror! Und ja, auch ich muss mich kotzenderweise mit solchen Programmen herumärgern.

 

[DCDCDC]

Umverdrahten macht es einfacher, da nur alles an einer Stelle einmal auftaucht. Negieren tu ich Signale nicht, sondern Werte sie 1:1 genauso aus wie es angedacht ist, normally closed/normally open steht dann im Kommentar

 

[schwimmer]

Umverdrahten macht es einfacher, da nur alles an einer Stelle einmal auftaucht.

Bringt das nicht noch mehr Verwirrung?
Wenn ich mir vorstelle, dass du die E/As Byte oder Wordweise in den DB schreibst, dann geht umverdrahten ja auch nicht so einfach.
Und wenn dann im Bereich vom EW2 auf einmal der E100.0 verknüpft ist, da ist es schon schwer den Überblick zu behalten oder übersehe ich da etwas?