Firmen-Norm

Zuviel Werbung?
-> Hier kostenlos registrieren
PS: ich sehe Classic noch lange nicht tot... und ob TIA sich durchsetzen wird, wäre noch abzuwarten. Von daher: kommt eben drauf an.

Wen man bei Siemens bleibt, wird sich TIA durchsetzen, es sei den man möchte seine
Anlage in Zukunft mit gebrauchten Steuerungskomponenten bauen. Das wird nicht mehr
lange dauern, dann geht es den Classic CPUs an den Kragen.

Ich einer der aller größten Kritiker von TIA werde kein neues Projekt mehr mit der Classic
Welt anpacken. So ein bischen habe ich auch meinen Frieden mit TIA geschlossen.

Zur Endwicklung der Firmen-Norm, warum nicht das was in beide Welten passt, nicht
schon sofort anpacken, so hat man doch einen sanften Umstieg und es kommt nicht
alles geballt. Es ist ja sowieso kein Prozess der innerhalb 3 Wochen abgeschlossen ist,
das wird schon mehrer Jahre dauern.
 
Methode 1 nutze ich immer wenn ich die Software Programmiere. Dann brauche ich auch keine Querverweise bzw. ich nutze gehe zur lokalen Verwendungsstelle (Shift+STRG+ B oder F).

Bei Methode 2 befinden sich die Daten in einem DB wieso sollten da die Querverweise nicht funktionieren ?

Für wen schreibst du deine Programme? Für dich oder den Kunden?
Wir haben Anlagen x-Herstellern und jeder hat seinen eigenen Stil ...

Wenn ich an einen FB eine komplette Struktur übergebe, was bekomme ich dann im Querverweis?

Gruß
Dieter
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich schreibe die Programme für unsere Kunden. Ich arbeite bei einem Maschinen und Anlagenbauer der die Software für seine Anlagen selber macht.

Wenn ich einen Querverweis auf einen UDT machen bekomme ich sämtliche Referenzen in der Software angezeigt sofern ich den Hacken setze "Überlappender ...".
 

Anhänge

  • Referenzen.jpg
    Referenzen.jpg
    155,7 KB · Aufrufe: 64
Zuletzt bearbeitet:
Wenn ich einen Querverweis auf einen UDT machen bekomme ich sämtliche Referenzen in der Software angezeigt sofern ich den Hacken setze "Überlappender ...".
Du bekommst lediglich einen Querverweis, daß die Struktur an irgendwas übergeben wird, aber keine Querverweise auf die Zugriffe auf die Member der Struktur.
Außerdem wird die angezeigte Art des Zugriffs (R/W) nur davon abgeleitet, ob die Struktur-Adresse an IN/OUT/IN_OUT übergeben wird. Unabhängig davon was wirklich mit der Struktur veranstaltet wird.

Harald
 
Dazu kann ich nur sagen bei mir werden immer alle Elemente der Struktur nutze. Ich habe keine Reserven. Deshalb weiß ich das die Daten genutzt werden.

Also ich kann in meiner Liste sehr wohl sehen auf welches Element lesend und Schreibend zugegriffen wird.
Innerhalb des FB oder des FC kann ich dann über die lokale Verwendungsstelle Querverweise bilden.

Was es Querverweise angeht bin ich ganz einfach der Meinung umso mehr ich die Querverweisliste nutzen muss umso schlechter ist die Software strukturiert bzw. aufgebaut.

Bei einer guten Struktur und einer Symbolik die so aufgebaut ist das die Referenzen klar erkennbar sind komme ich fast vollkommen ohne Querverweise aus.

Ich verstehe aber worauf Blockmove hinaus will, er muss viele Maschinen mit unterschiedlicher Software betreuen und ist daher auf Hilfsmittel wie Querverweise angewiesen.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Was mich an beiden Lösungen stört ist, dass bei keiner ein Querverweiss richtig möglich ist.
Man muss sich unter Umständen bei der Fehlersuche durch x-Aufrufschnittstellen hangeln.
Unsere Instandhalter (und ich denke auch viele andere) fluchen bei sowas kräftig.


Gruß
Dieter

Vielleicht solltet ihr mal andere Maßnahmen ergreifen. Einer meiner Ansprüche an einen Standard ist z.B. das die Instandhalter erst gar nicht zum PG greifen müssen um Störungen zu analysieren.

Wegen einem defekten Sensor oder Aktor sollte man z.B. nicht zum PG greifen müssen. Kommunikation zu Subsystemen oder zur Leittechnik sind zu visualisieren.

Diese "unsere Instandhalter" Aussage geht mir schon seit Jahren auf den Nerv. Ich kenne auch einige Instandhalter und die meisten derer die sich mit einem PG an die Machinen und Anlagen begeben können damit auch gut umgehen und kommen damit klar. Die anderen können ganz gut mit einem Telefon umgehen und sich Unterstützung anfordern. Die Jungs sind doch nicht dumm.

Hinter der Aussage vermute ich eher eine Ausrede die bewirken soll den eigenen Stil zu rechtfertigen.
 
Vielleicht solltet ihr mal andere Maßnahmen ergreifen. Einer meiner Ansprüche an einen Standard ist z.B. das die Instandhalter erst gar nicht zum PG greifen müssen um Störungen zu analysieren.

Wegen einem defekten Sensor oder Aktor sollte man z.B. nicht zum PG greifen müssen. Kommunikation zu Subsystemen oder zur Leittechnik sind zu visualisieren.

Diese "unsere Instandhalter" Aussage geht mir schon seit Jahren auf den Nerv. Ich kenne auch einige Instandhalter und die meisten derer die sich mit einem PG an die Machinen und Anlagen begeben können damit auch gut umgehen und kommen damit klar. Die anderen können ganz gut mit einem Telefon umgehen und sich Unterstützung anfordern. Die Jungs sind doch nicht dumm.

Hinter der Aussage vermute ich eher eine Ausrede die bewirken soll den eigenen Stil zu rechtfertigen.

Wir haben all die Massnahmen bei unseren eigenen Anlagen umgesetzt.
Es gibt komplette Diagnose von Bewegungen / Schrittketten / Antrieben /Schnittstellen usw.
In dieser Hinsicht teile ich komplett deinen Anspruch, dass ein Instandhalter gar nicht erst zum Notebook greifen muß.

Ich sehe allerdings auch viele Anlagen von anderen Herstellern, bei denen darauf kein großer Wert gelegt wird.
Schliesslich steckt hinter einer vernünftigen Visualisierung eben auch ein erheblicher Zeitaufwand.
Verfahren wie UDT-Übergabe oder Instanz-Zugriffe sparen beim Programmieren extrem viel Zeit, spart man noch zusätzlich an Visualisierung und Diagnose, so ist ein Programm schnell erstellt.
In diesem Fall dienen diese Verfahren dem reinen Selbstzweck. Der Kunde profitiert nicht davon.
Wenn an einer Anlage ein innovativer Programmierer alle Aktoren durch einen einzigen FB über ein Array von UDTs in dem sogar die Hardware-Adressen hinterlegt sind, anspricht, dann wird die Fehlersuche "interessant".

Gruß
Dieter
 
Ich schreibe die Programme für unsere Kunden. Ich arbeite bei einem Maschinen und Anlagenbauer der die Software für seine Anlagen selber macht.

Wenn ich einen Querverweis auf einen UDT machen bekomme ich sämtliche Referenzen in der Software angezeigt sofern ich den Hacken setze "Überlappender ...".

Du übergibst in deinem Beispiel keine UDT, sondern gehst z.B. mit den UDT-Elementen von "Plant_Line"._7600_VMX_PU auf die Parameter deines FB "ST Motor".
So mache ich das auch, weil da eben der Querverweis geht.
Du könntest aber auch ganz einfach die komplette UDT an den FB übergeben und so viel Tipparbeit sparen.

Gruß
Dieter
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Vielleicht solltet ihr mal andere Maßnahmen ergreifen. Einer meiner Ansprüche an einen Standard ist z.B. das die Instandhalter erst gar nicht zum PG greifen müssen um Störungen zu analysieren.

Wegen einem defekten Sensor oder Aktor sollte man z.B. nicht zum PG greifen müssen. Kommunikation zu Subsystemen oder zur Leittechnik sind zu visualisieren.

Diese "unsere Instandhalter" Aussage geht mir schon seit Jahren auf den Nerv. Ich kenne auch einige Instandhalter und die meisten derer die sich mit einem PG an die Machinen und Anlagen begeben können damit auch gut umgehen und kommen damit klar. Die anderen können ganz gut mit einem Telefon umgehen und sich Unterstützung anfordern. Die Jungs sind doch nicht dumm.

Hinter der Aussage vermute ich eher eine Ausrede die bewirken soll den eigenen Stil zu rechtfertigen.

Denkst du wirklich, auch nur ein Entwickler schreibt seine Programme so, dass ein Programmiergerät angeschlossen muss?
Wenn du die Möglichkeit hast, alle theoretisch und praktisch möglichen Fehler zu analysieren und entsprechenden Meldung auszuprogrammieren und auch alles austesten, dann gehörst du zu den Glücklichen.
Wir können das leider nicht und mich würde interessieren, wer diese Zeit und Gelegenheit hat.

Und es stimmt Instandhalter sind meist nicht dumm und wir können froh sein, dass es viele gute Techniker unter diesen Leuten gibt.


bike
 
....
Wenn du die Möglichkeit hast, alle theoretisch und praktisch möglichen Fehler zu analysieren und entsprechenden Meldung auszuprogrammieren und auch alles austesten, dann gehörst du zu den Glücklichen.
...

Eben genau dafür braucht es einen guten Standard. Die Meldungen werden eben nicht von Hand zu Fuß programmiert sondern durch den Standard generiert und augegeben. Die Ansteuerung von Bewegungen sorgt eigenständig für eine Laufzeitüberwachung und Paarüberwachung. Geräte wie Servoregler usw. geben auch häufig ihre Fehlermeldungen ganz bereitwillig an die SPS weiter diese kann man im klartext anzeigen. Schittketten lassen sich je nach eingesetztem Verfahren auch recht gut visualisieren. usw. usw

Mit Merkerschrittketten und S5Timern dauert das alles sicher ewig und genau deshalb setzen wir die nicht gerne ein.
 
Wenn du die Möglichkeit hast, alle theoretisch und praktisch möglichen Fehler zu analysieren und entsprechenden Meldung auszuprogrammieren und auch alles austesten, dann gehörst du zu den Glücklichen.
Wir können das leider nicht und mich würde interessieren, wer diese Zeit und Gelegenheit hat.

Wenn du eine Maschine/Anlage das Allererste Mal in der vorliegenden Form baust dann mag das bedingt zutreffen - dennoch gibt es aber schon mal ein paar grundsätzliche Dinge, die man berücksichtigen kann (Endlagen, Timeouts, Meldungen etc.).
Die Meißten bauen allerdings ihre Maschinen/Anlagen in ähnlicher Form immer wieder - da sollte man dann so nach und nach schon Erfahrungen gesammelt haben, was alles außer dem genannten noch so vorkommen kann und es mit berücksichtigt haben.
Das hat allerdings mit Standard nur bedingt etwas zu tun ... das gehört nach meiner Meinung so oder so dazu ...

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Du hast bedingt recht.
Wenn es um eine schwarz / weiß Bewegung geht.
Da kann man problemlos die entsprechenden Meldungen und Alarme anzeigen.
Aber z.B. bei einer Achse, die etwas positionieren oder fügen soll.
Die Endposition wird nicht erreicht.
Wie soll die Steuerung wissen, warum die Mechanik oder der Regler Mist bauen oder warum sonst die Position nicht erreicht wird?
Wenn es Probleme mit dem Datenaustausch mit intelligenten Komponenten gibt, was soll angezeigt werden?

Daher ist es ab und an notwendig, ein Programmiergerät anzuschließen.
Denn besser keine, als eine falsche Meldung anzeigen.


bike
 
Wenn du unbedingt Gründe gegen einen Standard suchst, man kann es auch falsch machen.
Ich habe schon "Standards" gesehen, da wäre es wirklich schneller gewesen den Code einfach stumpf runter zu tippen.

Da sind schlecht durchdachte System die gewachsen sind, inzwischen muss man das Signal halt hier und da und dort auch noch verschalten und zur Übergabe an einen anderen Teil noch mit einer bestimmten Logik versehen.
Dann muss man die REAL Istwerte aber mit dem einen Teil als DINT verrechnen und das Ergebnis für die Übergabe an 5 verschiedene Übergeordnete Systeme auf 5 verschiedene Arten aufbereiten...

Es ist alles mehr oder weniger schlecht so dokumentiert, und alle müssen es so machen weil es Standard ist, aber eine Erleichterung ist das auf keinen Fall.

Solche Beispiele sprechen aber letzten Endes nicht gegen einen Standard an sich, sie zeigen nur auf das man in nicht von jedem Idioten entwickeln bzw. pflegen lassen darf...
 
...
Aber z.B. bei einer Achse, die etwas positionieren oder fügen soll.
...
Positionierungstimeout, Überstrom, Schleppfehler, was auch immer mir der Regler verrät. Da kommt man mit der SPS Software auch nicht weiter. Auch wenn es an der Mechanik hängt kann man das schlecht aus dem SPS Code rauslesen.


...
Denn besser keine, als eine falsche Meldung anzeigen.
...
Gar keine Meldung ist oberkacke. Eine Maschine die ohne Meldung einfach den Dienst verweigert ist peinlich. Sie sollte wenigsten einen Hinweis liefern auf was sie wartet oder was den Ablauf stört.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn du unbedingt Gründe gegen einen Standard suchst, man kann es auch falsch machen.
Ich habe schon "Standards" gesehen, da wäre es wirklich schneller gewesen den Code einfach stumpf runter zu tippen..

Jetzt habe ich mich entweder falsch ausgedrückt oder wurde falsch verstanden.
Ich bin für Standards.
Bei uns sind alle Standardfunktionen mit Meldungen und Anbindung an ein Programm in Bibliotheken.
Da ist HMI, Netzanbindung und Protokolle auch dabei.

Die Aussage wegen Alarmen und Meldungen war wegen den Aussagen, dass man jeden Fehler ohne Programmiergerät findet.
Wer garantiert, dass alle Quereinflüsse richtig decodiert und angezeigt werden?
Man kann viele Meldungen und Überwachungen ausprogrammieren, doch alles geht meist aus verschiedenen Gründen nicht.

Darum ging / geht es mir.


bike
 
@bike
das war an den treadstarter gerichtet - er hat sich ja eher Gegenargumente gewünscht
 
Hilf mir mal auf die Sprünge und zeig mir die Stelle wo ich folgendes behauptet habe:
...
Die Aussage wegen Alarmen und Meldungen war wegen den Aussagen, dass man jeden Fehler ohne Programmiergerät findet.
...


...
Wer garantiert, dass alle Quereinflüsse richtig decodiert und angezeigt werden?
...
Niemand. Wenn man sich bemüht und die Einsätze vom PG zur Fehlersuche bis auf ein Minimum reduziert, ist an den Grenzfällen eh meist der Programmierer gefordert der die Scheiße verbockt hat.
IMHO sollte die Instandhaltung sich mit Fehlern beschäftigen die durch Ablaufstörungen wie defekte Bauteile (Sensoren, Aktoren, Mechanik und Co.) beschäftigen wenn Du noch Bugs in Deinen Programmen hast sollte das nicht die Instandhaltung ausbügeln.

...
Man kann viele Meldungen und Überwachungen ausprogrammieren, doch alles geht meist aus verschiedenen Gründen nicht.
...
Nun habe ich das Glück fast ausschließlich Maschinen und Anlagen zu programmieren die Ablaufgesteuert sind und man kann die IO-Abläufe, NIO-Abläufe, Grundstellungsfahrt mit Schrittketten abbilden. Hier kann man zwar nicht zu 100% sagen warum die Maschine zum Stillstand gekommen ist, wenn etwas von der Mechanik zu Bruch geht weis das die Steuerung halt nicht aber sie kann visualisieren worauf die Maschine wartet und das auch anzeigen.

Wenn aber irgend ein Stift abbricht und deswegen die Kiste nicht läuft nutzt Dir auch kein PG weiter.


Wenn man sein System aber dementsprechend aufbauen möchte kommt man schnell an den Punkt wo ein unerfahrener Programmierer oder Instandhalter den Quellcode halt nicht mehr versteht. Im Fall des Instandhalters ist es nicht schlimm da die Kiste ihm in der Regel die nötigen Hinweise vermittelt. Jetzt hinzugehen und die gesamte Kiste mit Merkern und S5 Timern unter Verzicht auf SCL zusammen zuschustern nur für den Fall das der Instandhalter doch mal mit dem PG dran muss, macht die Umsetzung eines ordentlichen Fehlermanagment sehr aufwendig und teuer.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@zotos:
Kann es sein, dass wir an einander vorbei schreiben?

Es ist schön wenn du deine Abläufe so aufbauen kannst, dass alle Störungen angezeigt werden und nach IB kein PG mehr gebraucht wird.

Bei uns sind die Maschinen und Anlagen eben komplexer, da geht es nicht und das stört auch bisher keinen, nicht einmal die Kunden.
Wie soll der Programmierer mal eben nach Chile oder sonst wo hin, um einen Fehler zu beheben?
Nicht alle Maschinen stehen mal eben um die Ecke.

Die Aussage wegen Merkern und Timern passt nicht wirklich.
Standard sind gekapselte Einzelfunktionen, so weit möglich.
Aber auch du darfst zugeben, dass einfacher ist bei der IB S5t und Merker zu verwenden und nicht immer wieder IDB und Global DB zu übertragen.
Denn beim Übertragen werden leider auch die aktuellen Werte überschrieben, was nicht immer gewollt ist.


bike
 
Gerade bei komplexen Anlagen hilft doch ein gut strukturierter und dokumentierter Standard.

Auch wenn die Anlage nicht gerade um die Ecke steht, sollte der Maschinen- / Anlagenbauer seine Fehler selbst beheben und dies nicht dem Kunden überantworten. Auch wenn man dafür anreisen muss. Bei sooo.. komplexen Anlagen wie die die Ihr baut lohnt sich da schnell eine ordentliche Fernwartung.
 
... dass einfacher ist bei der IB S5t und Merker zu verwenden und nicht immer wieder IDB und Global DB zu übertragen.
Denn beim Übertragen werden leider auch die aktuellen Werte überschrieben, was nicht immer gewollt ist.

Da hast du bestimmt Recht - auf der anderen Seite erzeugt genau das eben keine wiederverwertbaren Bausteine und falls man einen dieser Bausteine dann noch ein zweites Mal instanziert hat schon gewonnen ... 8). Im Grunde sind solche Mischbausteine sogar für den Ersteller irgendwann einmal ein Problem ...

Ich habe auch das Problem, dass sich meine FB's so mit der Zeit (bei der IBN und in der Folge) in der Instanz vergrößern - ich habe dann aber auch immer die Möglichkeit, so etwas wie Parameter etc. in die neue Instanz wieder hinein zu bekommen.

Gruß
Larry
 
Zurück
Oben