TIA-Portal > Negative Systemeigenschaften > Wunsch- / Verbesserungsliste

Zuviel Werbung?
-> Hier kostenlos registrieren
ich kann ja verstehen, dass man seinen Code möglichst schnell eintippen will. Aber ist das Codieren nicht nur ein sehr kleiner Teil unserer Arbeit?
Die meisten Zeit geht meines Erachtens für Strukturierung, Konzeptionierung, Pflege, Test und Fehlersuche drauf.

und um mehr zeit für den sekundären scheiß wie "Strukturierung, Konzeptionierung, Pflege, Test und Fehlersuche" zu haben muss der primäre scheiß schnell und komfortabel von der hand gehen können...
 
Das hoffe ich nicht - sonst dauert das programmieren in AWL bald noch länger als in FUP oder KOP... Ich kann zwar nur für mich sprechen, aber es tippt sich schneller ein DB10.DBD48 als "DB_SYSTEM".CONVERT.Offset[1]

Bitte korrigiert mich wenn ich damit falsch liege.
....

Nur wenn das System immernoch kein Autovervollständigen beherrscht ....
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nur wenn das System immernoch kein Autovervollständigen beherrscht ....

Selbst WENN es das Autovervollständigen super schnell funktioniert ist die direkte Eingabe immer noch schneller.

Standardbeispiel (zuminmdest in meinen Anwendungsfällen):
vereinfacht dargestelltes existierendes Mengengerüst in Step 7 - Prozessleitsystem:
FBs 1001 - 1064 für Schrittkettenaufrufe
FC 1001 - 1999 Schrittfunktionen 1-999
ab DB10.DBX0.0 beliebige DB-Strukturen
ab DB10.DBX80.0 ein Array of Bool von 1-999
folgende Symbolik für das Array: "DB_GOP".Step[x]

In jedem FC von 1001 - 1999 wird das entsprechende Bit im "DB_GOP" zugewiesen.

Ich befinde mich nun also in irgendeinem Baustein und möchte wissen ob der Schritt 499 aktiv ist.

Vorgehensweise bei absoluter Adressierung:
Ich schreibe "U db10.dbx80.0" - verlasse dann einmal die Programmzeile mit Pfeil oben, dann wieder Pfeil runter und ersetzt den Wert [1] durch [499]

Vorgehensweise bei symbolische Adressierung:
Ich schreibe "U "DB_G..." Wähle den entsprechenden Baustein, drücke "." woraufhin alle Symboliken angezeigt werden, dann tippe ich "Step"
(vorausgesetzt der Kunde ist englischer Herkunft, sonst heißt es "Schritt") und bin dann am Beginn des Arrays - jetzt stellt sich die Frage:
"Scrollen bis 499 oder auch hier einen beliebigen Array-Wert nehmen und dann durch den korrekten ersetzen?"

Das Beispiel hat hoffentlich nochmal verdeutlicht worauf ich hinaus will.
Wie gesagt, das war ein einziges und ich denke gut erklärbares Praxisbeispiel was sich aber auf beliebig viele Arten umstrukturieren lässt.

P.S.: Die Aufrufe der FBs und FC erfolgen indirekt und nach Nummerierung.
Was würde daraus wenn die absolute Programmierung wegfällt?

Gruß
Matthias
 
Hallo Matthias,

ich kann ja verstehen, dass man seinen Code möglichst schnell eintippen will. Aber ist das Codieren nicht nur ein sehr kleiner Teil unserer Arbeit?
Die meisten Zeit geht meines Erachtens für Strukturierung, Konzeptionierung, Pflege, Test und Fehlersuche drauf.

Gerade die letzten von mir genannten Punkte können bei absoluter Adressierung wirklich nervig werden, wenn die Symbolik nicht gepflegt wird oder in der Schnelle einfach vergessen wurde.

Gruß

dummy

Hallo Dummy,

da ich leider nicht weiß wie groß die Projekte sind die du mit Step 7 bearbeitest und für welchen Industriezweig sie sind, mag das schon sein.
Kannst du da vielleicht ein kleines Beispiel zu geben? Dann kann ich deine Sichtweise vielleicht besser verstehen!

Ich versuche mal ein Beispielprojekt in die Stunden aufzugliedern:
80 Std Prozessbilder zeichnen
24 Std E/A-Listen anlegen
16 Std HW-Konfig (bei TIA V11 wohl eher 40 Std) ;)
800 Std Programmierung
80 Std Test im Büro
300 Std IBN

Gruß
Matthias
 
Hallo Dummy,

da ich leider nicht weiß wie groß die Projekte sind die du mit Step 7 bearbeitest und für welchen Industriezweig sie sind, mag das schon sein.
Kannst du da vielleicht ein kleines Beispiel zu geben? Dann kann ich deine Sichtweise vielleicht besser verstehen!

Ich versuche mal ein Beispielprojekt in die Stunden aufzugliedern:
80 Std Prozessbilder zeichnen
24 Std E/A-Listen anlegen
16 Std HW-Konfig (bei TIA V11 wohl eher 40 Std) ;)
800 Std Programmierung
80 Std Test im Büro
300 Std IBN

Gruß
Matthias

Hallo Matthias,

ich denke die Größe der Anlage/Maschine ist bei dieser Betrachtung zweitrangig. Wobei ein sauberes Arbeiten gerade bei größeren Projekten zwingend notwendig ist.

Ich kann Deine Argumentation im Übrigen verstehen. Es ist nichts verkehrt daran. Wer seine Hausaufgaben macht hat auch keine Probleme mit absoluter Adressierung. Ich habe nur häufiger schon Step7 Projekte gesehen die nicht gut gepflegt waren. Also falsche oder gar nicht gepflegt Symbolik, Schmiermeker und soweiter. Wenn Du so willst alles was die Schmuddelkist hergibt. Die Pflege und Erweiterung solcher Projekte macht keinen Spaß. Da hat sich der Zeitvorteil ganz schnell wieder aufgefressen.

Vielleicht können wir uns darauf einigen, dass die absolute Adressierung schneller geht aber zu unsauberen Arbeitern verleitet.

Ausserdem arbeite ich zurzeit auch nicht mehr mit Step7 sondern mit CoDeSys und für mich habe ich die absolute Adressierung dort bisher nicht vermisst. Wir sollten diese Diskussion hier auch nicht weiter vertiefen, da wir damit den Thread etwas zerlabern.

Gruß

dummy
 
Zuviel Werbung?
-> Hier kostenlos registrieren
...nach dem ganzen S...... vergleichen mal wieder eine reale Negative Systemeigenschaft in WinCC V11:


Ausgangspunkt:

PLC-Variable wurde erstmals im HMI-Projekt als verbundene Variable angelegt:
(zu diesem Zeitpunkt sind der Name der angebundenen PLC-Variable noch identisch zum HMI-Variablennamen)

Aktion: Veränderung des Namens in der SPS, z.B. in einem Datenbaustein.

WIRD ein im Panel angebundene Variable nachher in der PLC umbennannt so wie der PLC-Name im HMI-Projekt im Feld PLC-Variable korrekt nachgeführt.

Leider gibt es keine direkte Möglichkeit diesen Name auf die HMI-Variabel zu übernehmen (so wie in FLexilbe).
Neu Verbinden hat keine Auswahlmöglichkeiten hierzu und passt den Namen nicht automatisch an.

Das wird hoffentlich beizeiten nachgebessert.

Frank
 
MINIFENSTER --> Variable umbenennen <-- ZU KLEIN

Das MINIFENSTER --> Variable umbenennen <-- läßt sich nicht vergrößern. Das ist schwachsinnig :rolleyes:

Variblenbeispiel: M_B02_Sedimentation_Füllstand_analog

Wenn man so eine Variable komplett sehen will, verschwinden alle anderen Spalten.
 
Wenn man ein Projekt mit der 10.5 erstellt hat in dem IEC-Timer verwendet werden, kann diese Projekt mit der V11 nicht mehr geöffnet werden.
Grund: Die Struktur des IEC Timers wurde verändert :-D

Momentane Abhilfe: Timer löschen, migrieren, Timer wieder einbauen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn man ein Projekt mit der 10.5 erstellt hat in dem IEC-Timer verwendet werden, kann diese Projekt mit der V11 nicht mehr geöffnet werden.
Grund: Die Struktur des IEC Timers wurde verändert :-D

Momentane Abhilfe: Timer löschen, migrieren, Timer wieder einbauen.

nah dann viel Spass ... bei 5 - 10 Timer mag das ja noch gehen,
aber spätestens wenn man viele Timer als Multi-Instanzen in einem
oder mehreren FBs hat ... dann gute Nacht.

Frank
 
Hallo Kollegen, hallo Siemens-Mitleser

( VORBEMERKUNG)
Ich kenne das TIA-Portal noch nicht, möchte aber im Vorfeld auf einige Sachen hinweisen.
Der leichteren Diskutierbarkeit halber werde ich die Vorschläge einzeln einhängen.
Einige davon waren bereits in 2000 Vorschläge an Siemens, leider ohne Erfolg.

Mit der Entstehung einer neuen Programmiersoftware und einer neuen CPU-Generation könnten nun auch einige Design-Fehler behoben werden, die nach einer gewissen Zeit (nachvollziehbar) zur Systemeigenschaft mutiert sind, und dadurch unabänderbar wurden.


VORSCHLAG:

Es fehlen (in S7) folgende Möglichkeiten:
1. Trotz Zeitstempelkonflikt bzw. unterschiedlichen Formatinformationen muss Beobachten möglich sein.
2. Trotz Zeitstempelkonflikt bzw. unterschiedlichen Formatinformationen muss "Laden ins PG" möglich sein, ohne die im PG vorhandenen Variablennamen und Komentare zu überschreiben/ zerstören.
3. Es muss möglich sein, das Format von Datenbereichen (offline) in DBs zu ändern ohne deren Inhalt zu zerstören.
4. Es muss möglich sein, eine neue Format-Definition ins AG zu übertragen ohne die Aktualwerte dabei zu ändern.

( Es sollte also der operative Stand der S5 wieder erreicht werden)


GRUND:
Dies betrifft prinzipiell alle Anlagen, an denen während der Produktion gearbeitet werden muss/kann.
Insbesondere bei grossen Anlagen kann diese Phase der IBN recht lange dauern.

Die Fähigkeit, an laufender Anlage zu arbeiten, unterscheidet SPSen von Microprozessorsteuerungen.

Ich habe in Kraftwerken zusammengenommen über ein Jahr an S5-Anlagen während der Produktion gearbeitet, das Ändern und Nutzen von freigehaltenen Reserve-Bereichen in DBs war während des Betriebs unproblematisch.

Bei S7 ist das nicht möglich.

( Ständiges Anhalten von Kraftwerken wegen einer Formatänderung macht einen schlechten Eindruck :)

Gruss

Werner
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Kollegen, hallo Siemens-Mitleser

( VORBEMERKUNG)
Ich kenne das TIA-Portal noch nicht, möchte aber im Vorfeld auf einige Sachen hinweisen.
Der leichteren Diskutierbarkeit halber werde ich die Vorschläge einzeln einhängen.
Einige davon waren bereits in 1998 Vorschläge an Siemens, leider ohne Erfolg.

Mit der Entstehung einer neuen Programmiersoftware und einer neuen CPU-Generation könnten nun auch einige Design-Fehler behoben werden, die nach einer gewissen Zeit (nachvollziehbar) zur Systemeigenschaft mutiert sind, und dadurch unabänderbar wurden.


VORSCHLAG:

Das Netzwerk-Handling sollte gegenüber S7 verbessert werden:

1. Sprung auf Netzwerk (z.B. 5) also : Step7 : <CTL E> -> 5 sollte auf Netzwerk 5 landen, nicht auf Netzwerk 4,5
Also: Beginn des Ziel-Netzwerks oben, nicht in der Mitte.

2. Falls ein Sprung auf ein Netzwerk eine Netzwerk-Nummer enthält, die es im Baustein nicht gibt, sollte auf das letzte Netzwerk gesprungen werden. Eine Fehlermeldung schadet nichts, aber der Sprung wäre sinnvoll.

3. die <PAGE UP> <PAGE DOWN> - Tasten sollten netzwerk-orientiert blättern, d.h. ein Netzwerk vorwärts / rückwärts mit Netzwerk-Beginn oben.


GRUND:
( zu 1) Der zufällige Auftauch-Ort der Netzwerk-Überschrift und -Struktur erfordert ein ständiges Neu-Orientieren, wenn die Stelle gleich bleibt, ist die "Verarbeitungsgeschwindigkeit" des Programmierers schneller.
Der nur in Step7 trainierte Programmierer muss sich nicht umgewöhnen, ihm wird lediglich auffallen, dass das Netzwerk "zufällig" immer oben anfängt.
Zum "Zwischen-die-Netzwerke"-Positionieren:
Zur Zeit der Step7-definition gab's noch keine Mäuse mit Rädern, daher war eine anderes Handling vielleicht noch erklärbar, heute macht es keinen Sinn mehr.

( zu 2) Viele Programmierer haben die Struktur ihres Progamms grob im Kopf, nicht allerdings die konkreten Netzwerkadressen.
Wenn ich jetzt weiss: "es irgendwo ganz hinten" springe ich nach hinten und suche von dortaus rückwärts.

( zu 3) gleich wie ( zu 1)


Es kann also diesbezüglich der operative Stand der S5 wieder erreicht und überholt werden:

Bei Kommandos mit Netzwerk-Bezug ( <CTL E>,<PAGE UP> <PAGE DOWN> ) Sprung mit Ergebnis Zielnetzwerk Start oben, bei formatfreier Positionierung ( mit Maus, Rollbalken) bie bisher.



Gruss

Werner
 
Hallo Kollegen, hallo Siemens-Mitleser

Mit der Entstehung einer neuen Programmiersoftware und einer neuen CPU-Generation könnten nun auch einige Design-Fehler behoben werden, die nach einer gewissen Zeit (nachvollziehbar) zur Systemeigenschaft mutiert sind, und dadurch unabänderbar wurden.


VORSCHLAG:
Da ich dahinter ein grundsätzliches Design-Problem in der S7-Linie vermute, wird es eigentlich nur die neuen X-CPUs betreffen:

Das Statusanzeige sollte gegenüber bestehenden S7 - CPUs dringend verbessert werden:


1. Die Anzahl der beobachtbaren Elemente ( Zeilen , Parameter ) ist zu klein.
2. Bei Befehlen, die nur sporadisch durchlaufen werden, (s.u.) soll der letzte Zustand angezeigt werden.


GRUND:
( zu 1) Die CPUs werden immer leistungsfähiger, in vielen Programmen steigt die Anzahl der an FBs / FCs übergebenen Parameter.
Viele Netzwerke wachsen während der IBN, das Beobachten im Zusammenhang ist nicht mehr möglich.

( zu 2) Beispiel:
M 2.5 sei ein Impuls, der in jeder Sekunde für einen Zyklus auf 1 sitzt. ( also z.B. eine Flankenauswertung aus dem entsprechenden Bit des Takt-Merkerbytes.)

' un M 2.5
' spb nabb
' l db20.dbw60 <<<<<<<<CURSOR
' l 1
' +i
' t db20.dbw60
nabb: nop 0

zeigt den Inhalt von db20.dbw60 nur sporadisch an.
In der S5 wird noch ein sauberes Hochzählen angezeigt, in der S7 erscheint eine Änderung nur sporadisch.
Je schneller der CPU-Zyklus, desto seltener die Status-Aktualisierung.
Es scheint: aktualisiert wird nur, wenn sich CPU-Zyklus und Status-Zyklus zufällig treffen.
Das ist nicht gut, besonders, weil's vor 30 Jahren schon mal besser war.

Es sollte also diesbezüglich der operative Stand der S5 wieder erreicht werden.



Gruss

Werner
 
Hallo Kollegen, hallo Siemens-Mitleser

( VORBEMERKUNG)
Ich kenne das TIA-Portal noch nicht, möchte aber im Vorfeld auf einige Sachen hinweisen.

Mit der Entstehung einer neuen Programmiersoftware und einer neuen CPU-Generation könnten nun auch einige Design-Fehler behoben werden, die nach einer gewissen Zeit (nachvollziehbar) zur Systemeigenschaft mutiert sind, und dadurch unabänderbar wurden.


Es ist gut zu hören / lesen, dass die Länge der Labelnamen endlich verlängert wurde, aber es bleibt, denke ich, noch ein Problem:


VORSCHLAG:
Es sollte zwischen Netzwerk-lokalen und Baustein-globalen Labeln unterschieden werden können.

GRUND:
( Ich kopiere hier einfach mal, modifiziert, einen Vorschlag ein, den ich 2000 schon mal gemacht habe. Die Sache mit den Labelnamen ist geklärt, der Rest gilt aber immer noch.)

( Man erinnere sich in diesem Zusammenhang an die Glaubensdiskussionen der Hochsprachler in den 70/80er Jahre:
"Sind Labels in Hochsprachen schlechter Stil?"
Die Step5-Entwickler hatten dieser Diskussion damals mit lokalen Labels Rechnung getragen und die damals angeführten Argumente gelten fuer uns Halb-Assembler-Programmier nach wie vor. )


In der S5 waren die Labels Netzwerk-Lokal.
Dies hatte auch verschiedene Vorteile:

Bei Änderung musste nur eine umgrenzter Bereich (max 256 Befehle, also maximal das Netzwerk ) auf die Auswirkung der Änderung untersucht werden.
Eines der Hauptargumente der GOTO-Gegner war "Spagetti-Code".
Durch die jetzt ( Step7) bausteinweiten Labels in 64kb-Bausteinen hat sich die "Spagetti-Code"-Gefahr deutlich verschärft.

Ausserdem führen Netzwerk-Kopierfunktionen schnell zu fehlerhaften Sprüngen.


In dem TIA-Portal sollten deshalb folgende Verbesserungen eingebaut werden:

  • Label sind Lokal, wenn nicht als mit einem Präfix gekennzeichnet. Dies erleichertert die Übersichtlichkeit (s.o)

  • Es sollten in verschiedenen Netzwerken gleiche Labelnamen möglich sein, solange sie lokal sind. Dies ermöglicht im Netzwerk-Zusammenhang ausagefähige Namen ohne langen Info-Overhead. ("HSK30AP001_nabb" oder "HSK30AP001_Auto" liest sich schlechter als "nabb" oder "Auto", vom Eintippen mal ganz abgesehen. )

  • Sprünge, die ausserhalb des Netzwerks springen, werden ebenfalls mit einem Präfix versehen, es koennen nur Globale labels von ausserhalb des Netzwrks angesprungen werden.

( Dies hat im Uebrigen keinen Einfluss auf die SPSen. Ich weiss nicht,
ob S7-Programme mittlerweile abwaertskompatibel sind, aber auch dies
koennte realisiert werden, wenn die Praefixes nicht mit abgespeichert
werden und nur zur Editierzeit existieren. )


z.B:

------- Netzwerk n ------------------
spb nabb // lokaler Sprung
....
spa G#ende // globaler Sprung

nabb: NOP 0 // lokales Label
------- Netzwerk n + 1 --------------
spb nabb

nabb: NOP
------- Netzwerk n + m --------------

G#ende: nop 0 // Globales Label

Es sollte also diesbezüglich der operative Stand der S5 (lokale Labels) und der S7 (bastein-weite Labels ) erreicht und übertroffen werden.



Gruss

Werner
 
Labels (Sprungmarken)

Es ist gut zu hören / lesen, dass die Länge der Labelnamen endlich verlängert wurde, aber es bleibt, denke ich, noch ein Problem:

VORSCHLAG:
Es sollte zwischen Netzwerk-lokalen und Baustein-globalen Labeln unterschieden werden können.

Finde ich ebenfalls eine gute Idee.

Hat, wie du schon schreibst, auch nichts mit der SPS (Hardware) zu tun. Dies ist eine reine Compiler-Sache.

Wie der Paule schon schreibt (oder zumindest meint mit was er schreibt :cool: (denke ich :rolleyes:)) sollte dies aber nicht dazu führen, dass wir dadurch die bausteinweite Sprünge verlieren. Beides soll möglich sein.

Als (verbindlichen) Prefix für einen globalen Sprung würde mich persönlich übrigens einen "#" reichen. "G#" ist mir zu umständlich und "verschmutzt" IMHO zu viel das Lesebild. Man könnte auch einen "." nehmen, oder was Anderes, hauptsache es gibt eine klare Unterscheidung (wer die Programmierumgebung kennt sieht sofort was gemeint ist), aber es fällt nicht zu viel auf bzw. drängt nicht zu viel in den Vordergund.

Schoenen Gruss,
Und Happy Hacking,
Jan
 
Aber auch Nachteile.
Das Sprungverhalten von S5 auf S7 war schon eine Umstellung, aber finde es jetzt gut wie es ist.
Wichtig war der längere Labelname und das wurde ja erfüllt.

genau, so wie es in TIA jetzt ist, sollte es bleiben, das ist Perfekt :s7:
um es als Globelen Sprung zu Kenzeichnen, kann mann sich ja selber dieses gewünschte
Kenzeichen machen. Ohne Netzwerkübergreifende Sprungziele, macht z.b. der Sprungverteiler
nicht viel Sinn.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
genau, so wie es in TIA jetzt ist, sollte es bleiben, das ist Perfekt :s7:

Da ich (leider) immer noch kein Zugang zum TIA Portal habe, weiss ich leider nicht genau wie das da dann gelöst ist.


um es als Globelen Sprung zu Kenzeichnen, kann mann sich ja selber dieses gewünschte
Kenzeichen machen.

Das hilft aber nicht weiter, wenn man das Verhalten alla Step5 mit dem Verhalten alla Step7 kombinieren möchte. Dann muss der Compiler es lösen und helfen "eigene" Vorzeichen nicht wirklich weiter (die kann man dann auch gleich ganz weglassen).

Der Sinn des Step5 Verhaltens ist ja, dass ich mehrere Netzwerke mit den gleichen Labels haben kann/darf. Wenn ich Schleifen Programmiere hätte ich am liebesten überall als Label "LOOP" oder "loop", bei mehrere Schleifen in dem gleichen Baustein geht das bei Step5 sehr wohl, bei Step7 aber gar nicht. Bei Step7 muss ich dann unsinnigerweise wieder anfangen was aus dem Daumen zu saugen, bei Step5 kann ich ohne weiteres Nachdenken die Netzwerke kopieren, oder das gleiche Label wiederum einsetzen.


Ohne Netzwerkübergreifende Sprungziele, macht z.b. der Sprungverteiler
nicht viel Sinn.

Kann, muss nicht. Hängt zum Beispiel von der Länge vom Sprungverteiler ab.

Gruss,
und Happy Hacking,
Jan
 
lokale labels

Hallo Kollegen,

zur Klarstellung: natürlich will ich die baustein-globalen Labels nicht abschaffen! ( dadurch würde Ihre Kennzeichnung natürlich obsolet !)

Es geht vorrangig um 2 Sachen:

  1. (automatische ?) Kennzeichnung der global benutzten labels, um bei entstehendem Spagetti-Code einen Warnhinweis zu erhalten. Stichwort: Glaubenskrieg
  2. gleiche Labelnamen in verschiedenen Netzwerken.
Hintergrund:
Zu S5-Zeiten sah z.B. meine Schrittkette ( falls es komplizierter wurde)
so aus:

NETZWERK " Schritt1"
' L KY 1,0
' L DW 0 // Schrittnummer
' <>F
' SPB NABB

// Aktion



// Weiterschalt-Kriterium zu Schritt 2
' UN "sprung_S_2"
' spb CHK2
' L KY 2,0 // Weiter Schritt 2
' T DW 0
' SPA NABB

// Weiterschalt-Kriterium zu Schritt 10
CHK2: UN "sprung_S_10"
' spb NABB
' L KY 10,0 // Weiter Schritt 10
' T DW 0
' SPA NABB

NABB : BLD 255 // NABB ist pfälzisch, heisst "hinunter", für mich das STD-Label für Netzwerk-Ende


Es waren also kurze, "normierte" Labelnamen, die beim Kopieren des Netzwerks keiner Änderung bedurften, da Netzwerk-Lokal.

Es geht um
- weniger Tipparbeit
- geringere Fehlerwahrscheinlichkeit
- Weniger Nachbearbeitung

Heute : Netzwerk kopieren erzwingt neue Labelnamen mit der Fehlerwarscheinlichkeit, dass ich, wenn ich bei einem Sprung die Änderung vergesse, im falschen Netzwerk lande. Wie wir alle wissen halten besonders diese dusseligen Fehler besonders lange auf.

Wie die Kennzeichnung dann tatsächlich aussieht, ist mir erstmal Wurscht,
die Sache mit G# war meinerseits bereits ein Zugeständnis an die Step7-Entwickler, die uns an wichtigerer Stelle schliesslich auch zu unsinnigen Präfixes zwingen.

Dazu später ein neuer Verbessungsvorschlag.

Gruss

Werner
 
Da ich (leider) immer noch kein Zugang zum TIA Portal habe, weiss ich leider nicht genau wie das da dann gelöst ist.




Das hilft aber nicht weiter, wenn man das Verhalten alla Step5 mit dem Verhalten alla Step7 kombinieren möchte. Dann muss der Compiler es lösen und helfen "eigene" Vorzeichen nicht wirklich weiter (die kann man dann auch gleich ganz weglassen).

Der Sinn des Step5 Verhaltens ist ja, dass ich mehrere Netzwerke mit den gleichen Labels haben kann/darf. Wenn ich Schleifen Programmiere hätte ich am liebesten überall als Label "LOOP" oder "loop", bei mehrere Schleifen in dem gleichen Baustein geht das bei Step5 sehr wohl, bei Step7 aber gar nicht. Bei Step7 muss ich dann unsinnigerweise wieder anfangen was aus dem Daumen zu saugen, bei Step5 kann ich ohne weiteres Nachdenken die Netzwerke kopieren, oder das gleiche Label wiederum einsetzen.




Kann, muss nicht. Hängt zum Beispiel von der Länge vom Sprungverteiler ab.

Gruss,
und Happy Hacking,
Jan

Hallo Jan,
für deine Loop schleifen könntest du ja jetzt einfach ein Index hinterhängen,
Loop_1; Loop_2; usw. das finde ich wieder übersichtlicher. Außerdem
sollte mann sich mal langsam vom Step 5 lösen, wir sind im Jahre 2011.
 
Zurück
Oben