Step 7 Digitalen Eingang über gesamtes Programm negieren

[d-fan02]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Community,

besteht die Möglichkeit über das gesamte Programm einen booleschen Eingang, z.B.: E 0.1 zu negieren ohne dessen Aufrufe im gesamten Programm zu ändern? Kann man dies über die Hardwarekonfiguration machen oder gibt es eine bessere Lösung? Es handelt sich um eine CPU 315 mit einer normalen DI Baugruppe. Der Grund ist, ein Mitarbeiter hat den falschen Sensor eingebaut.

Vielen Dank

 

[Wincctia]

Hallo Dfan2,

wenns es Qick and Durty sein darf und du in deinen Programm den Eingang niergends per PEW oder PED abfragst kannst du im OB1 ganz als erstes NW einfach

UN E0.1
= E0.1


MFG TIA

 

[Betriebselektriker28]

Zuviel Werbung?
-> Hier kostenlos registrieren

Sensor tauschen wäre keine Alternative?

Das mit dem E0.1 im OB1 direkt invertieren ist aber interessant. Auf die Idee wäre ich nicht gekommen. Werd ich mir merken.

 

[Boxy]

Was passiert wenn der Sensor kaputt geht? Was kommt dann wieder rein?
Diese Frage sollte man zuerst beantworten und dann entscheiden was oder wie es gemacht werden soll.

Wird der Sensor auch im HW Plan getauscht, dann sollte man eher das Programm anpassen und es richtig machen.
Natürlich funktioniert dies im OB1, viele sehen dies aber meist als IB Krücke an, weil z.B. der Sensor fehlt.

Andernfalls Sensor auf den richtigen tauschen und die Sache richtig machen und sich auch die Frage stellen, was passiert wenn dieser Sensor defekt geht? Welches Signal liegt dann an und was kann passieren im Programm?

 

[Paul]

Hallo Dfan2,

wenns es Qick and Dirty sein darf .........
UN E0.1
= E0.1


MFG TIA

Quick and Dirty kann man schon mal machen, wenn´s wirklich Quick gehen muss und man es nachher wieder raus macht.
Aber bekanntlich hält ja nichts länger als ein Provisorium.

Meine Meinung: Leute die so einen MIST reinprogrammieren, die gehören sich GRÜN UND BLAU GESHLAGEN !!!
Läuft vielleicht nicht unter "Grob Fahrlässig" aber zumindest unter "Grober Unfug"

PS: Sag dem Hirni, der den falschen Sensor eingebaut hat, er muss ein Koppelrelais mit Öffner dazwischen hängen.

 

[vollmi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Was wäre denn an im gesamten Programm ändern so schlimm.
worst case das Programm ist absolut programmiert.
Konsistenzprüfung machen.
Umstellen auf Operandenvorrang Symbolisch.
Symbol für E0.1 erstellen.
Konsistenzprüfung machen
Symbol umverdrahten z.B. auf Merker
Konsistenzprüfung machen
Irgendwo zuweisung auf Merker UN E0.1 = "Merker"
Download aller geänderten Programmteile (ausser DBs)

Es gibt übrigens einen Grund warum die meisten Anlagenbauer ein IO Mapping machen und somit die Peripherie nur ein einziges Mal im Programm anfassen.

mfG René

 

[Larry Laffer]

Ich bleib da mal bei Paul und erkläre seinen Unmut :
Du erhältst durch die von Wincctia vorgeschlagene Negation (die natürlich funktionieren würde) folgenden Effekt :
- diese Negation wirkt nur ab da im Programm, wo sie gemacht wurde (davor im Zyklus ist die Zustand wie er wirklich ist) - das kann zu "netten" Verirrungen führen
- der Zustand, den du an der Eingangskarte siehst, stimmt nicht mehr mit dem Zustand im Programm überein. Das ist ganz sicher etwas, über das früher oder später jemand stolpern wird und dessen Sinn nicht wird nachvollziehen können bzw. vielleicht sogar vermutet, dass die Eingangskarte oder deren Verschaltung einen Defekt hat.

Fazit :
Mach es so, wie von Vollmi beschrieben ...! (es ist nämlich gar nicht so schlimm, etwas richtig zu machen - im Gegenteil )

Gruß
Larry

 

[weißnix_]

Um spätere Verwirrungen zu vermeiden, sollte natürlich die Dokumentation angepasst werden sowie die Ersatzteilhaltung.
Ein netter Rattenschwanz.

Grundsätzlich halte ich aus leidvoller Eigenerfahrung wenig davon, so auf solche durchaus normalen Irrtümer zu reagieren. Ich wäre eher dafür, den vorgesehenen Sensor einzubauen. Morgen ändert wieder jemand aus Versehen die Hardware und Du musst wieder das Programm ändern. Wo führt das hin...

 

[Boxy]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Frage bei solchen Dinge ist halt auch, wie wird das Signal im PLC Programm abgefragt und wie würde dies sich bei einem Defekt dieses Sensors und dieser Invertierung auswirken?

Was passiert im weiteren Ablauf, wenn Statisch eine 1 anliegt? Meist gehen Sensoren ja so kaputt und melden kein Signal mehr, durch die Invertierung kommt aber permanent „1“ an …

Es gibt z.B. auch von Balluf für M12 Inverter, die werden einfach auf den M12 Anschluß geschraubt und machen dies dann ohne PLC Änderung.
Hier müsste man nur vermerken, das wennwieder auf den Original Sensor gewechselt wird, daß dieser Inverter auch raus muß ...

 

[testuser]

man kann doch den sensor auf seinen zustand abfragen. in jedem produktionszyklus wird einmal auf true und einmal auf false. bei unseren maschinen kommt dann eine fehlermeldung, dass der sensor xy einen falschen bzw. nicht den erwarteten zustand liefert.

trotzdem würde ich auch den sensor tauschen lassen oder das programm anpassen.

 

[d-fan02]

Die Variante von Wincctia ist mir zu heiß. Ich habe erst mal ein Finder Relais zwischengeschaltet. Morgen sollte der richtige Sensor (NO) da sein. Nochmals Danke

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

wichtig in dem Zusammenhang sicherlich auch die Drahtbruchsicherheit des Sensors... Ich vermute, die wäre bei dem falschen Sensor sicherlich auch nicht mehr gegeben.

Gruß.

 

[Nico1977]

Mein Vorgehen bei analogen/digitalen Ein-/Ausgängen ist immer, diese in einen DB zu übertragen.
Ist am Anfang viel Arbeit, bietet mir aber einige Vorteile. So kann ich eine Negierung, wie in diesem Fall, schnell anpassen.
Ebenso kann ich den Transfer-FC nicht aufrufen, um einfach die EAs zu testen.

 

[Boxy]

Es gibt viele Wege nach Rom und viele Vorgehensweisen ...
Im Endeffekt ist aber das Ergebnis (ob PAE oder DB invertiert wird) das selbe

 

[Paul]

Zuviel Werbung?
-> Hier kostenlos registrieren

....Ich habe erst mal ein Finder Relais zwischengeschaltet.....

Sag ich doch

 

[PN/DP]

Es gibt viele Wege nach Rom und viele Vorgehensweisen ...
Im Endeffekt ist aber das Ergebnis (ob PAE oder DB invertiert wird) das selbe

Ganz "das selbe" ist es leider nicht. Man muß das Problem multitasking-mäßig betrachten.

Bei negiert oder nicht negiert Kopieren in einen Rangier-DB (IO Mapping) hat die Variable im DB im gesamten Programmzyklus immer den selben Zustand, weil es nur genau eine Zuweisung im Zyklus gibt.

Beim quick'n'dirty Negieren und wieder Zuweisen auf das selbe Bit im PAE (E0.1) ändert sich der Wert des Bits im Programmverlauf (zwei gegensätzliche Zuweisungen), und welchen Wert man erhält hängt davon ab, wann man den Wert liest. Wenn man das Bit mit einer Variablentabelle beobachtet, mit der Standardeinstellung Trigger bei Zyklusbeginn, dann sieht man nicht den Wert, mit dem das Programm arbeitet - das wird zumindest für Verwirrung sorgen. Interessanter wird es, wenn da auch noch eine HMI das Eingangsbit beobachtet, wo der Programmierer aus üblicher Faulheit/"Genialität" ohne Koppel-DB direkt das E0.1 projektiert hat: wenn die HMI im Zykluskontrollpunkt den Wert liest, dann wird die HMI immer den falschen unnegierten Wert anzeigen. Wenn die HMI jederzeit den Wert lesen kann ("priorisierte BuB"), dann wird der Wert in der HMI unmotiviert flackern. Das selbe passiert, wenn das Bit in einem Alarm-OB gelesen wird - da wird der Wert ebenfalls flackern.

Meine Meinung: die quick'n'dirty Lösung ist nur für Inbetriebnahmen akzeptabel, im richtigen produktiven Programm hat sowas nichts zu suchen.

Harald

 

[Boxy]

Meine Meinung: die quick'n'dirty Lösung ist nur für Inbetriebnahmen akzeptabel, im richtigen produktiven Programm hat sowas nichts zu suchen.

Harald

Da sind wir uns einig, solange auf das selbe PAE Abbild in dem selben Zyklus im Programm zugegriffen wird, ist es Wurst ...
Wird aber über andere Kanäle (z.B. Variabel beobachten (Trigger Punkt), HMI usw.) ebenfalls drauf zugegriffen, kann es hier zu Differenzen kommen. Dies sollte dann der Programmierer bedenken (daher ist diese Methode bei Siemens nix für den Produktiven Einsatz).

Aber innerhalb des PLC Programms (selben Zyklus) wäre es erst einmal egal ...

Wir könnten das Thema auch vertiefen und dann noch andere Pakete wie Grap7 oder High-Graph berücksichtigen und dann kommen weitere Probleme auf, da dort teils direkt auf das PAE wieder zugegriffen wird und somit diese Manipulation nicht überall greift ...
Daher wie gesagt muss man es immer speziell bedenken, wie und was man macht!

Auch manche Hinweise wie "ich mache es immer und übertrage es in einen DB", sind auch nicht immer Zielführend.
Einmal besteht das Programm nun einmal und es wird kaum kpl. geändert. Zum anderen können Kunden es teils nicht aussuchen wie die Programme z.B. bei Standard Maschinen programmiert sind und die Instandhaltungen dadurch das annehmen müssen was sie bekommen!