TIA Alle Eingänge in DB transferiert

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

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

Mal ein Beispiel aus den Programmen meines "Peinigers". Es werden sämtliche Eingänge, physikalische und Bus, wortweise in Schleifen in einen DB kopiert. In einem weiteren DB werden zu jedem dieser Signale Parameter abgelegt. Bei einem digitalen Eingang wäre das lediglich ein Bit zum Negieren. Dieses Negieren wird selbstverständlich indirekt adressiert in Schleifen durchgeführt.
Jetzt führt man eine ganz simple Fehlersuche durch und sucht zum Beispiel nach dem Eingang E2.4 und findet ihn natürlich nicht. Ok, man erinnert sich an den Käse und sucht nach dem Bit DB49.DBX2.4 und man wird 35 mal fündig. Jetzt ist dieses Bit FALSE. Ist das jetzt aber richtig FALSE oder negiert FALSE? Jetzt sieht man noch im DB50.DBX2.4 nach dem Parameterbit. Und dann kommt noch jemand und verdrahtet einzelne Bits um. Spätestens jetzt habe ich vergessen, wonach ich eigentlich gesucht habe. Mit den Ausgängen wird konsequenterweise genau so sinnlos verfahren.

Letzte Woche wollte ein Kunde auf einer Busschnittstelle ein Bit mit einer neuen Meldung verodert haben. Das selbe Drama.

Bei euch wird es sicherlich nicht so weit getrieben. Aber übersichtlicher oder einfacher wird es bestimmt nicht. Und das Umverdrahten ist heute auch kein Argument mehr, jedenfalls nicht bei moderenen Systemen.

 

[ducati]

Mal ein Beispiel aus den Programmen meines "Peinigers". Es werden sämtliche Eingänge, physikalische und Bus, wortweise in Schleifen in einen DB kopiert. In einem weiteren DB werden zu jedem dieser Signale Parameter abgelegt. Bei einem digitalen Eingang wäre das lediglich ein Bit zum Negieren. Dieses Negieren wird selbstverständlich indirekt adressiert in Schleifen durchgeführt.
Jetzt führt man eine ganz simple Fehlersuche durch und sucht zum Beispiel nach dem Eingang E2.4 und findet ihn natürlich nicht. Ok, man erinnert sich an den Käse und sucht nach dem Bit DB49.DBX2.4 und man wird 35 mal fündig. Jetzt ist dieses Bit FALSE. Ist das jetzt aber richtig FALSE oder negiert FALSE? Jetzt sieht man noch im DB50.DBX2.4 nach dem Parameterbit. Und dann kommt noch jemand und verdrahtet einzelne Bits um. Spätestens jetzt habe ich vergessen, wonach ich eigentlich gesucht habe. Mit den Ausgängen wird konsequenterweise genau so sinnlos verfahren.

Letzte Woche wollte ein Kunde auf einer Busschnittstelle ein Bit mit einer neuen Meldung verodert haben. Das selbe Drama.

Bei euch wird es sicherlich nicht so weit getrieben. Aber übersichtlicher oder einfacher wird es bestimmt nicht. Und das Umverdrahten ist heute auch kein Argument mehr, jedenfalls nicht bei moderenen Systemen.

Richtig lustig wirds, wenn an der SPS jetzt jemand nachträglich rumändert, der das Ursprungskonzept nicht verstanden hat und jetzt parallel dazu seinen eigenen Programmierstil dazubastelt
Aber trotzdem, Du hast mein Beileid

Ich finds persönlich nicht so toll, den E2.4 35mal mehrfach im Programm abzufragen... Aber wenn man schon ne Zwischenschicht einführt, dann wenigstens vollsymbolisch und nicht Codezeilenoptimiert...

Aber jeder hat so seinen Programmierstilstandard, warum auch immer..
Ich kenne nur sehr wenige wirklich einfach überschaubare Programmierstandards, und selbst die werden nach Jahren verhunzt...

 

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

... dann wenigstens vollsymbolisch und nicht Codezeilenoptimiert...

Ja, es ist schon vollsymbolisch. Nur tippe ich in Step7 bei "Gehe zu Verwendungsstelle" nicht das Symbol ein.

 

[Salli1991]

Ich find die Lösung die PCS7 da bietet eigentlich recht angenehm. Da gibts für jedes Eingangs und Ausgangssignal direkt miterzeugte Hardwaretreiber. Und da das Systembausteine sind, programmiert die eigentlich jeder gleich.

 

[DCDCDC]

Mal ein Beispiel aus den Programmen meines "Peinigers". Es werden sämtliche Eingänge, physikalische und Bus, wortweise in Schleifen in einen DB kopiert. In einem weiteren DB werden zu jedem dieser Signale Parameter abgelegt. Bei einem digitalen Eingang wäre das lediglich ein Bit zum Negieren. Dieses Negieren wird selbstverständlich indirekt adressiert in Schleifen durchgeführt.
Jetzt führt man eine ganz simple Fehlersuche durch und sucht zum Beispiel nach dem Eingang E2.4 und findet ihn natürlich nicht. Ok, man erinnert sich an den Käse und sucht nach dem Bit DB49.DBX2.4 und man wird 35 mal fündig. Jetzt ist dieses Bit FALSE. Ist das jetzt aber richtig FALSE oder negiert FALSE? Jetzt sieht man noch im DB50.DBX2.4 nach dem Parameterbit. Und dann kommt noch jemand und verdrahtet einzelne Bits um. Spätestens jetzt habe ich vergessen, wonach ich eigentlich gesucht habe. Mit den Ausgängen wird konsequenterweise genau so sinnlos verfahren.

Letzte Woche wollte ein Kunde auf einer Busschnittstelle ein Bit mit einer neuen Meldung verodert haben. Das selbe Drama.

Bei euch wird es sicherlich nicht so weit getrieben. Aber übersichtlicher oder einfacher wird es bestimmt nicht. Und das Umverdrahten ist heute auch kein Argument mehr, jedenfalls nicht bei moderenen Systemen.

Soweit treibe ich das nicht.

Meine Projekte lassen es zu, dass ich jeden E/A sauber einzeln über einen Baustein auf eine boolsche Variable legen kann, da würdest dich wirklich schnell zurecht finden.

 

[DCDCDC]

Zuviel Werbung?
-> Hier kostenlos registrieren

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?

Ich darf es mir anhand der Übersichtlichkeit erlauben, jedes Signal einzeln übergeben zu dürfen Da muss ich zum Glück keine Worte und Bytes beachten

 

[winnman]

Schaut bei mir auch so aus:
DI gibt einen (oder wenn sinnvoll mehrere) FC die die Eingänge Bit für Bit in den entsprechenden DB kopieren, hat dan Vorteil das man hier super Negieren kann, intern wird dann nur mehr mit dem DB gearbeitet.

DO genauso, es wird dann nur am Ende einmal alles auf die DO geschrieben

AI hier gibt es auch wieder einen (oder wenn sinnvoll mehrere) FC in denen das Signal Normiert wird (ich mag Prozesswerte die in der Anlage auch nachgemesser werden können und keine % sachen), hier erfolgt auch die Auswertung ob plausibel, Drahtbruch, . . . das kommt dann auch in einen DB

AO hir wird aus dem DB dann denormiert und auf die AO geschrieben.

Die DB sind je nach Anlage so aufgebaut das alle Variablen einer Funktionsgruppe in einem DB liegen oder es gibt einen DB für DI, deinen für Analogeingänge, . . .

Das hängt davon ab was bei der jeweiligen Anlage übersichtlicher ist. Bei mehreren Antrieben, . . . gibt es je einen DB mit allem was zum jeweiligen Antrieb gehört.

Ist das Teil eher zur Überwachung vieler Signale da, dann ist es meist Sinnvoller einfach einen DB für DI und einen Für Analogwerte zu benutzen.

Auf alle Fälle wird da nichts "vogelwield" rumkopiert was dann nicht in den Querverweisen ordentlich auftaucht.

Ist viellericht etwas mehr Tipparbeit, hilft aber ungemein bei der Inbetriebnahmen und Fehlersuche.

 

[Marty2000]

Jede unnötige Umkopiererei bringt Verwirrung und zusätzliche Fehlerquellen.
Wenn ein Eingangsbyte als Byte deklariert wurde, können dennoch zusätzlich auch die Eingangsbits deklariert und verwendet werden, das beißt sich nicht.
Wenn ein Eingang mehrfach benutzt wurde, kann man dennoch ganz einfach diesen Eingang in der Tag-Table auf einen anderen Eingang umverdrahten und S7 korrigiert das (by Symbolische Adressierung) überall.
Die Eingänge sollten eindeutig (zumindest im Kommentar) beschriftet werden, auch bezüglich der High/Low-Zuweisung, und wenn eine Negierung notwendig ist (das kommt immer mal vor), sollte man die Bezeichnung des Eingangs auch UMBENNEN. Dann kann man auch genau so schnell an jeder Verwendungsstelle ganz schnell den Eingang negieren (Strg+Shift+4). Dadurch sieht man am Baustein selbst vollumfänglich, was los ist, wenn etwas nicht stimmt.
Und zum Thema simulieren ... man kann auch ganz einfach mit einem "Simulationscode" am Anfang von OB1 Eingänge beschreiben (forcen nicht notwendig), ohne dass der Rest vom Code etwas davon mitbekommt.

 

[Peter Wahlen]

Zuviel Werbung?
-> Hier kostenlos registrieren

Jede unnötige Umkopiererei bringt Verwirrung und zusätzliche Fehlerquellen.

genau meine Meinung, so was mache ich manchmal bei Produktabfragesensoren wo das Signal (1 oder 0) noch nicht feststeht, dann kopiere ich mir die entsprechen E auf Datenbits mit einer festen Bezeichnung (Teil da, Teil richtigrum,... ) und diese Datenbits werden dann im Programm abgefragt, d.h. ich muss bei einer evtl. Drehung des Signals nur an einer Stelle das Programm und auf keinen Fall die Visu ändern.

Wenn ein Eingangsbyte als Byte deklariert wurde, können dennoch zusätzlich auch die Eingangsbits deklariert und verwendet werden, das beißt sich nicht.

Auch bei Ausgängen und Merker. Wenn auch M nicht mehr (außer Taktmerker, Systemmerker) nicht mehr verwenden werden sollten (was ich auch nicht mehr mache,) war das einfacher als mit den verschieden heutigen Möglichkeiten (Überlagerung, scatter, gather, ....), z.B. Wortinfo eines FUs, wo jedes Bit eine andere Bedeutung hat. Man kann halt sowohl das Wort als auch die Bits ohne Zusatzaufwand bezeichnen.

Wenn ein Eingang mehrfach benutzt wurde, kann man dennoch ganz einfach diesen Eingang in der Tag-Table auf einen anderen Eingang umverdrahten und S7 korrigiert das (by Symbolische Adressierung) überall.

Das funktioniert bei TIA sogar noch besser als bei Classic.

Die Eingänge sollten eindeutig (zumindest im Kommentar) beschriftet werden, auch bezüglich der High/Low-Zuweisung, und wenn eine Negierung notwendig ist (das kommt immer mal vor), sollte man die Bezeichnung des Eingangs auch UMBENNEN. Dann kann man auch genau so schnell an jeder Verwendungsstelle ganz schnell den Eingang negieren (Strg+Shift+4). Dadurch sieht man am Baustein selbst vollumfänglich, was los ist, wenn etwas nicht stimmt.

Signale (E, A) werden bei mir im aktiven Zustand bezeichnet, also z.B. "Schalter betätigt", "Tisch oben",... falls ein Sensor was anders anzeigt, wird das in der Bezeichnung klargestellt, z.B. "Tisch nicht oben".

Und zum Thema simulieren ... man kann auch ganz einfach mit einem "Simulationscode" am Anfang von OB1 Eingänge beschreiben (forcen nicht notwendig), ohne dass der Rest vom Code etwas davon mitbekommt.

So was mache ich oft, wenn Zeit zur Verfügung und Anlage / Steuerung noch nicht aufgebaut ist.

 

[Januar]

Wenn auch M nicht mehr (außer Taktmerker, Systemmerker) nicht mehr verwenden werden sollten

Wenn du auf die Empfehlung von Siemens anspielst, die sich um Hardware-unabhängiges Programmieren und Performance dreht, dann solltest du konsequenterweise auch Takt- und Systemmerker vermeiden.

 

[Peter Wahlen]

Wenn du auf die Empfehlung von Siemens anspielst, die sich um Hardware-unabhängiges Programmieren und Performance dreht, dann solltest du konsequenterweise auch Takt- und Systemmerker vermeiden.

Bei dem Hardware unabhängiges programmieren gebe ich dir recht, aber Performance möchte ich dann bezweifeln. Ich muss ja zusätzlichen Aufwand treiben, um die Takte / System-Signale zu generieren und diese Programmroutinen kosten auch (wenn auch sehr geringen) für die CPU Speicherplatz und Rechenzeit.