Tipps zur Standardisierung der Programmierung

SPS-Guru69

Level-1
Beiträge
1
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hey Leute,

ich befinde mich gerade im Praxissemester und meine Aufgabe ist es Standards für die Programmierung zu finden, um diese zu optimieren (Zeit sparen, effizienter, wartbarer). Bei den Programmierumgebungen handelt es sich zum einen um das TIA-Portal V13 und zum anderen um das e!Cockpit. Bisher habe ich Festlegungen bei der Namensgebung getroffen und allgemeine Projektabläufe definiert. Zusätzlich habe ich für das TIA-Portal eine Excel Tabelle mit Makros erstellt, die das Bearbeiten und Einlesen von PLC-Variablen erleichtert.

Allerdings sind meine Ideen jetzt am Ende, daher die Frage, welche weiteren Möglichkeiten und Mittel bestehen , um die Programmierung zu erleichtern?

Danke im Voraus
Grüße Michael
 
Das versuchen wir auch schon seit Jahren.
Das kann nicht funktionieren, denn es ist doch so:
Wer bezahlt schafft an.
Es wurde mit Transline2000 eine Richtung für die Autobastler zu entwickeln und das ging böse in die Hose.
(Es gab aber Higraph :ROFLMAO: )

Denkst du deine Symbolik oder deine Beschreibungen der Abläufe können universell den Kunden aufgedrückt werden?
Was willst du machen, wenn deine Vorgaben nicht gekauft werden?
Dann hast du eine schöne Beschreibung und ein schönes? Programm, doch kein Geld in der Kasse.

Wir geben unseren Studis auch immer wieder solch eine Aufgabe.
Weniger wegen der Lösung, sondern um zu sehen, wie die sich dem Problem annähert und entsprechende Lösungsansätze erarbeiten.


bike
 
Sorry,
bin mal klein-laut aber...

es scheitert nicht an Ideen sondern am Ego der Personen.

Frage 5 programierer und du hast 6 Wege, nach Wochen vileicht nur noch 3, aber auf einen Einigen ??????????
 
Zuviel Werbung?
-> Hier kostenlos registrieren
In unserer Firma programmieren Anlagen für Maschinenhersteller und arbeiten somit als Subunternehmer. Vor 4 Jahren begann ich mit einem Kollegen eine Standardisierung unserer Programmierung.
Verwenden wir unseren Standard und sind wir viel schneller mit der Programmierung fertig, wovon auch der Kunden profitiert, da der Projektierungsaufwand geringer ist und jeder unserer Programmierer, ohne die Maschine zu kennen,
Erweiterungen schnell und einfach implementieren kann.

Detailliert will ich nicht auf den Standard eingehen, aber wichtig ist, dass man SPS-Bausteine in Gruppen nach Ihrer Funktionalität aufteilt. Somit gibt es schon die einfache Gliederung nach Aktorik, Sensorik, usw.
Diese Bausteine erhalten eine Schnittstelle zu dem HMI, womit Bildbausteinen das jeweilige Objekt visualisiert wird. Durch diese Aufteilung ist man schon mal in de Lage jede Anlage, den mechanischen Aufbau einer Anlage nach dem Baukastenprinzip durchzuführen. Dieses Prinzip lässt sich mit allen Komponenten einer Anlage durchführen.

Angelehnt ist diese Konzept an die Objektorientierte Programmierung aus der Hochsprachenprogrammierung nur halt ohne Klassen und Vererbung.

Für deine Konzeptbeschreibung solltest du einen ähnlichen Weg einschlagen, da dieses Konzept erfolgreich in unserem Unternehmen und bei meinem vorherigen Arbeitgeber Aumann funktioniert.

EDIT: Oh...hab gerade bemerkt, dass der Thread schon etwas älter ist, hoffe aber er ist noch relevant.
 
Warum die Standardisierung immer Praktikanten machen und nicht die alten Hasen, welche die notwendigen Erfahrungen besitzen, und wissen, was in dem jeweiligen Unternehmen Sinn macht, wird mir vermutlich auch fuer immer ein Rätsel bleiben...
Am Besten noch Praktikanten, die nie zuvor eine SPS gesehen haben... Nichts fuer ungut.
 
Für mich selber Arbeite ich auch so,
Anfang - Gruppen einteilung .....
innerhalb einer Firma ist das auch mehr als sinnvoll (aleine die Fehlersuche bei Kolegen)
aber darüber hinaus sieht man schon wielange es dauert z.b. USB oder HDMI.... oder DOS, MAC oder doch WIN.
und selbst dan kan man nur hoffen keine nichen entwicklung hervorgebracht zu haben.
Wie bei Linux und ihren ganzen Ablegern.

Warum es nicht die Alten Hasen machen ist auch klar, den die wissen wie schwierig es ist und Anfänger sind doch voller Elan und Tatendrang ;)

Aber ein gewisser Programier standard wäre für ein Forum wie hier sinvoll und ein Anfang, zumal Fehleranalyse und Tips schneller umsetzbar wären.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ist es vielmehr nicht so, dass die Kunden verschiedene Spezifikationen haben und diese auch geliefert bekommen wollen?
Wenn zum Beispiel zu den Autobastlern geliefert wird, dann ist jedes Werk anders.
80 Maschinen, selber Konzern aber 5 verschiedene Programme und Hardwarepläne.
Solange dies so ist, hilft Standardisierung bei den Liefertanten wenig, wer bezahlt schafft an, das ist leider? die Realität.

Früher dachte ich, als TL2000 kam es wird leichter.
Erare humanum est.


bike
 
Warum die Standardisierung immer Praktikanten machen und nicht die alten Hasen, welche die notwendigen Erfahrungen besitzen, und wissen, was in dem jeweiligen Unternehmen Sinn macht, wird mir vermutlich auch fuer immer ein Rätsel bleiben...
Am Besten noch Praktikanten, die nie zuvor eine SPS gesehen haben... Nichts fuer ungut.

Weil alte Hasen gerne mal sagen...

- ich kenne alle Merker die ich brauche und habe da ein System
- das funktioniert
- ich kenne alle Timer die ich brauche
- das funktioniert
- ich mache das schon immer so
- das muss in AWL sein
- ich brauch keine Strukturen!
- das funktioniert
- ich brauche keine Doku und keine Engineering Richtlinie die anderen machen das genau wie ich
- Du hast doch keine Ahnung
- das funktioniert

Und damit auch gerne mal für die Ausgangslage gesorgt haben das Standardisiert werden muss/soll/wird/kann/darf usw.

Trotzdem gebe ich dir recht das Praktikanten für den Job genauso falsch sind.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Weil alte Hasen gerne mal sagen...

- das muss in AWL sein

Ja, das sehe ich aktuell bei mir im Umfeld passieren


Trotzdem gebe ich dir recht das Praktikanten für den Job genauso falsch sind.

mann soll ruhig die Praktikanten ein standart machen lassen.
Dann lernen die auch
mann soll sie aber bloss nicht verwenden.

und sonnst ist für mich ein Standard Baustein eine die herstellerübergreifend ein zu setzen ist.
Und in die ganze Siemens Familie.
dann ist man wieder beim SCL.

Bram
 
Zuletzt bearbeitet:
und sonnst ist für mich ein Standard Baustein eine die herstellerübergreifend ein zu setzen ist.
Und in die ganze Siemens Familie.
dann ist man wieder beim SCL.
Mit Verwendung von SCL verliert man aber einen Vorteil der Siemens-Steuerungen, daß man notfalls ohne Originalprojekt das Online-Programm unkompliziert ins Projekt zurückladen und bearbeiten kann. Baustein-Detailvergleich geht bei SCL meines Wissens auch nicht.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Mit Verwendung von SCL verliert man aber einen Vorteil der Siemens-Steuerungen, daß man notfalls ohne Originalprojekt das Online-Programm unkompliziert ins Projekt zurückladen und bearbeiten kann. Baustein-Detailvergleich geht bei SCL meines Wissens auch nicht.

Harald

Kommt auf der Steuerung an, in der neuen Welt 1200/1500 geht es.
 
Mit der Verwendung von AWL verliert man aber bei den 1500er Steuerungen die Möglichkeit lange Datentypen zu nutzen.

Konkret bedeutet das man sich einen Betriebsstundenzähler basierend auf Time + TONR bauen kann, der entweder 24 Tage und ein paar zerquetschte anzeigen kann oder basierend auf LTime + TONR 106751 Tage (> 300Jahre) anzeigen kann.
Auch bei der Verwendung von VARIANT gibt es Einschränkungen im Zusammenhang mit AWL.

Bei neuen Standards sollten auch solche Punkte im Auge behalten werden.
 
Also ich hätte bisher noch nie ein Problem, nen Betriebsstundenzaehler zu bauen, der mehr als 24 Tage zaehlen konnte. Auch in AWL nicht. Aber nagut. Auch wenn ich lieber SCL machen wuerde und aktuell aber AWL programmieren muss, gibt es gute Gründe fuer und gegen SCL und AWL... Haelt sich ungefähr die Waage denke ich...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Genau da liegt mein Problem, ich will mir nichts bauen müssen nur weil ich auf eine Sprache gesetzt habe die das System nicht vollständig nutzen kann.
Wenn ich mir was bauen muss bedeutet das immer (viel) mehr Code und eine individuelle Lösung.

Setze ich hingegen auf das System und nutze es geschickt, bin ich in zwei Zeilen Code fertig plus eine 3. Zeile für das mapping in die UserInterface Struktur.

OOC.png

3 Zeilen mit der Sicherheit einer Systemfunktion gegen eine selber programmierte Lösung, da fällt mir die Entscheidung nicht schwer.
 
Setze ich hingegen auf das System und nutze es geschickt, bin ich in zwei Zeilen Code fertig plus eine 3. Zeile für das mapping in die UserInterface Struktur.

Und hast einen Betriebsstundenzähler sich bei Warmstart der SPS auf Null setzt!

Leider ist das Anlaufverhalten der Timer weder in der Online-Hilfe nicht im Systemhandbuch dokumentiert. Man muss es also testen, das Verhalten feststellen und hoffen, dass sich auch alle anderen Steuerungen so verhalten, und sich dann auch noch darauf verlassen, dass Siemens dieses Verhalten nie mehr ändert. Was ja theoretisch möglich wäre, denn es war ja noch nie irgendwo festgeschrieben.
 
In dem Beispiel fehlt lediglich der Haken bei Remanenz.
Und natürlich ist das Dokumentiert sogar für die einzelnen Controller.


Warmstart.jpg
 
Zuletzt bearbeitet:
Zurück
Oben