LOGO Vergleich STEP7-AWL zu LOGO!-FDB

Batucada

Level-1
Beiträge
36
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Vergleich STEP7-AWL zu LOGO!-FBD

Hallo LOGO!-Fans,

ich möchte mal die Meinung von anderen Usern zu meinen Gedankengängen hören.

Nach dem ich jetzt ein wenig mit dem "Verdrahten" eines FBDs gespielt habe, fällt mir auf, dass z. B. STEP7 in der SIMATIC und die "Verdrahtung" in der LOGO! gar nichts miteinander gemeinsam haben. Es gibt zwar in beiden Bereichen den Begriff des Merkers, aber der Gebrauch eines solchen ist doch sehr unterschiedlich.

Wenn also bei einer in STEP7-AWL geschriebenen Operation das (letzte) VKE sofort verloren geht, wenn eine neue Operation gestartet wird und man das vorherige VKE später aber noch einmal benötigt, kommt man um den Gebrauch eines (Schmier)-Merkers nicht umhin. Was bei umfangreichen Programmen schon mal zu Engpässen führen kann, wenn Merker ausschließlich statisch vergeben werden.

Bei der LOGO! scheinen die Blöcke ein Gedächtnis zu haben, so dass der hemmungslose Gebrauch von Merkern eigentlich nicht notwendig ist.

Ist meine gerade gemachte Erfahrung zutreffend?

LG Batucada

EDIT: hab versucht den Titel zu korrigieren
 
Zuletzt bearbeitet:
Die Logo hat nur ein "Netzwerk", daher geht das VKE in diesem auch nicht verloren.

In erster Linie unterbrechen Merker (neben Ausgängen) Rekursionen, indem sie das Signal vom Eingang für den nächsten Zyklus am Ausgang zur Verfügung stellen.
 
Die Logo hat nur ein "Netzwerk", daher geht das VKE in diesem auch nicht verloren.
Moin hucki,

der Begriff Netzwerk, noch uralten Zeiten stammend, hatte auf die eigentliche Be- bzw. Abarbeitung der inhaltlichen Logik keine Bedeutung, von ganz geringen Ausnahmen abgesehen. Aber der Begriff VKE steht IMHO gar nicht in einer Verwandschaftsbeziehung zu einem "Netzwerk", sondern kann innerhalb eines solchen mehrere Sequenzen haben. Und mit jeder Sequenz startet die Bildung des VKE wieder neu, weshalb das davor liegende VKE "verloren" geht.

Ja, gut. Beide Welten kann man nicht miteinander vergleichen. Weshalb eine Diskussion darüber schon müßig zu sein scheint. Für einen Neuling wie mich, der sich zunächst an Althergebrachtes klammert, sind solche Vergleiche erst einmal sehr naheliegend. Als ich gestern in Deiner Antwort Deinen Hinweis auf Rekursionen las, konnte ich damit zunächst nichts anfangen :confused: Weil sich mein Verständnis für eine Rekursion auf einen gänzlich anderen Vorgang bezieht, dem ich sicher nicht in einer Anwender-Programmierung für eine LOGO! jemals begegnen werde. Erst später als sich in LSC der Mauscursor in ein Verbotsschild verwandelte und der Tooltiptext explizit auf eine angebliche "Rekursion" hingewiesen hatte, konnte ich Deinem Beitrag folgen. OK, damit war ich gezwungen 2 Merker zu verwenden, ich hätte auch Verodern können und wäre dann mit einem Merker ausgekommen. Aber da dies die beiden einzigen verwendeten Merker sind, war mir der Einspareffekt schlicht egal.

Was mir absolut nicht egal ist und das wäre, sofern ich mit LOGO! mein Geld verdienen müsste, ein Hinderungsgrund, überhaupt eine LOGO! einzusetzen, da LSC explizit keine Möglichkeit bietet, die Reihung der Blöcke zu korrigieren, implizit geht's, ist aber mit einem Riesenaufwand verbunden. Bei einer Korrektur eines logischen Ablaufs werden beim Hinzufügen von Blöcken diese nicht mehr in der logischen Sequenz bearbeitet, sondern auf verschiedene Zyklen verteilt, was je nach Logik zu einem Ergebnis führt, das nicht mehr konsistent ist. Das ist eine absolute Bärenka**e :sb7:

Wer Lust hat kann sich mein erstes "Machwerk" ansehen und wenn die Lust vorhanden ist, auch bemeckern. Wahrscheinlich gibt's da noch ein paar Ecken, die den Insidern von LOGO! auffallen, ich hab' mal was von "offenen" Klemmen gelesen, vielleicht muss ich was in meinem Plan ergänzen.

Batucada
 

Anhänge

  • BSP - LOGO Steuerung.zip
    27,5 KB · Aufrufe: 3
Zuviel Werbung?
-> Hier kostenlos registrieren
Was mir absolut nicht egal ist und das wäre, sofern ich mit LOGO! mein Geld verdienen müsste, ein Hinderungsgrund, überhaupt eine LOGO! einzusetzen, da LSC explizit keine Möglichkeit bietet, die Reihung der Blöcke zu korrigieren, implizit geht's, ist aber mit einem Riesenaufwand verbunden. Bei einer Korrektur eines logischen Ablaufs werden beim Hinzufügen von Blöcken diese nicht mehr in der logischen Sequenz bearbeitet, sondern auf verschiedene Zyklen verteilt, was je nach Logik zu einem Ergebnis führt, das nicht mehr konsistent ist. Das ist eine absolute Bärenka**e :sb7:
Meinst Du damit, dass die Reihenfolge der Numerierung von Blöcken automatisch festgelegt wird und nachträglich nicht nach eigenen Wünschen "aufgeräumt" werden kann? Und wie geht's dann "implizit"? Durch Löschen der Blöcke mit den "blockierten" WunschNummern samt aller diese Blöcke betreffenden Verbindungen und Neuanlegen der Blöcke samt ihren Verbindungen? Das finde ich viel schlimmer als nur BeschäftigungsTherapie.
Bei Eingängen, Ausgängen und Merkern kann man die Numerierung nachträglich ändern. Das ist schon mühsam genug, aber immerhin möglich.
Dafür, dass "Bei einer Korrektur eines logischen Ablaufs beim Hinzufügen von Blöcken diese nicht mehr in der logischen Sequenz bearbeitet werden, sondern auf verschiedene Zyklen verteilt, was je nach Logik zu einem Ergebnis führt, das nicht mehr konsistent ist.", habe ich noch nie irgendeinen Hinweis feststellen können.

PS:
An der LOGO! stört mich hauptsächlich, dass man vergeblich nach ganz simplen Möglichkeiten sucht. Wenn man Glück hat, findet man einen FunktionsBlock, den man missbrauchen kann.
Das generelle Runden beim ArithmetikBlock stört mich z.B. wahnsinnig - wenn es doch wenigstens per "HäkchenUmknippsen" abschaltbar wäre ...
 
Zuletzt bearbeitet:
Es geht doch gar nicht darum, um eine Wunschnummerierung nach einem besonderen Belieben einzuhalten, sondern um die Vermeidung von Seiteneffekten, die in dieser Umgebung oftmals nicht zu vermeiden sind. Einer der Seiteneffekte, den man u.U. noch schmerzlich akzeptieren kann, ist die Verzögerung der Sprungantwort um 2 oder mehr Zyklen. Wesentlich hässlicher sind solche Seiteneffekte, die dynamisch die Unterdrückung einer Sprungantwort bewirken.

Dafür, dass "Bei einer Korrektur eines logischen Ablaufs beim Hinzufügen von Blöcken diese nicht mehr in der logischen Sequenz bearbeitet werden, sondern auf verschiedene Zyklen verteilt, was je nach Logik zu einem Ergebnis führt, das nicht mehr konsistent ist.", habe ich noch nie irgendeinen Hinweis feststellen können.
Dann hast Du bisher Glück gehabt. Ich denke auch, dass bei einer Pumpensteuerung oder zum Einschalten des Garagenlichtes solche Probleme nicht zum Tragen kommen. Ich habe allerdings in meinem Berufsleben Steuerungen kennen gelernt, deren Hersteller sich dieser Problematik bewusst waren und entsprechende Korrekturmöglichkeiten entweder automatisch oder manuell vorgesehen haben.

Batucada
 
Dann hast Du bisher Glück gehabt. ... Ich habe allerdings in meinem Berufsleben Steuerungen kennen gelernt, deren Hersteller sich dieser Problematik bewusst waren und entsprechende Korrekturmöglichkeiten entweder automatisch oder manuell vorgesehen haben.
Die LOGO! habe ich nur in der Simulation ein Bisschen kennengelernt. Andere, "vergleichbare" Steuerung gar nicht.
Zugegeben, gerechnet habe ich bei der LOGO! auch mit solch undurchsichtigen Effekten, aber beobachten konnte ich sie noch nicht.
Vielleicht ist sie in dieser Beziehung tatsächlich anderen, ähnlichen Steuerungen überlegen?

Zu Deinem BeleuchtungsEinAusSchaltUDF unbekannten Inhalts hier zwei Alternativen:
StromstossSchalter.jpg
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Vielleicht ist sie in dieser Beziehung tatsächlich anderen, ähnlichen Steuerungen überlegen?
Nöö, ist sie nicht. Auf eine entsprechende Anfrage hin, wurde dies vom Siemens-Support eingeräumt. Allerdings dürfte wegen der "Kleinheit" der Programme, die von der LOGO überhaupt ausgeführt werden können, die Gefahr, dass es zu unüberschaubaren Seiteneffekten kommt, gut kalkulierbar sein. Wenn man den Fehler früh genug erkennt, muss man nur ganz wenig umräumen.

Das UDF-Schmuckstück habe ich mal zum Kennenlernen "gebastelt". Für mich ist es schließlich auch die erste LOGO, bei der ich selbst aktiv geworden bin. Früher hab' ich verächtlich drauf herabgesehen. Aber ich denke, man kann schon interessante Sachen damit machen und für meinen Fall dürfte eine S7 gleichbedeutend sein, mit Kanonen auf Spatzen...

Einen Nachteil habe ich noch entdeckt, dass der modulare Zubau von digitalen Eingängen nur in festen Raten bei gleichzeitigem Zuwachs der digitalen Ausgänge möglich ist. Man schießt mit der Anzahl der digitalen Ausgänge "leicht" übers Ziel hinaus, wenn die Anzahl der digitalen Eingänge knapp wird. Ich hab' mich jetzt darauf eingelassen, eine bestimmte Anzahl der digitalen Eingänge in zwei Gruppen zu multiplexen. Aus dieser Sicht war mir natürlich klar geworden, dass die Verschleppung einer Sprungantwort über mehrer Zyklen, entstanden durch Reihungsfehler, so nicht akzeptabel ist. Die Steuerung bewältigt somit bei Einsatz eines DM16-Erweiterungsmoduls 22 frei verfügbare digitale Eingangssignale, 10 digitale Ausgangssignale, 4 analoge Eingangssignale. Das Verhältnis der digitalen Eingangssignale zu den digitalen Ausgangssignalen sieht somit für mich wieder "gesund" aus.

Batucada
 
Die Reihenfolge der Abarbeitung der Funktionsblöcke hängt nicht von ihrer Blocknummer sondern nur von ihrer Verdrahtung zu vorangehenden und nachfolgenden Blöcken ab.
Auch nachträglich eingefügte Blöcke werden an der richtigen Position und nicht am Ende abgearbeitet.

Das kann man gut sehen, wenn man die Simulation in der Fußleiste pausiert und dann jeweils nur im 1 Zyklus-Modus per Hand weiterschaltet.



Vielleicht solltest Du besser "vergessen", was Du über S5/S7 weißt, wenn Du mit der LOGO arbeitest, damit Du nicht ständig Äpfel mit Birnen vergleichst.
:p
 
Die Blocknummern haben nichts mit der Abarbeitungsreihenfolge zu tun. Die sind der Name/die ID/die Instanz des Blocks, um auf den Block verweisen zu können. Das ist historisch so, weil die ersten LOGO wurden noch oft mit den Tasten und Display direkt am Gerät programmiert, und da sieht man immer nur einen Block und die Verbindungslinien sind Verweise auf Blocknummern. Siemens hat es noch nie für nötig befunden, die Nummerierung der Blöcke im nachhinein ändern zu können. Das ist aber eigentlich nur ein "kosmetisches" Problem. Überhaupt sind viele der "Unverständlichkeiten" historisch bedingt. Die ersten LOGO konnten nur logische Grundfunktionen (UND, ODER, ...) und TON, TOF, Stromstoßschalter, Selbsthalterelais, Zeitschaltuhr... - halt nur das, was ein Haus/Hof/Wiesen/Licht-Elektriker vorher aus einzelnen Relais zusammenbasteln konnte und mußte. Mit der Zeit kamen dann mächtigere Funktionen und Analogverarbeitung dazu, die mußten dann aber in das einmal festgelegte Konzept passen.

Wenn Du die Abarbeitungsreihenfolge sehen willst, dann wandle den FBD in LAD um. (Wobei ich nicht sicher bin, ob das wirklich eine 1:1-Umstellung ist oder eine Konvertierung nach eigenen Regeln.) Man kann eine LOGO auch komplett in LAD (wie KOP) programmieren, vielleicht gefällt Dir das mehr. Hinweis: Ausgänge, Merker und Timer kann man erst verknüpfen, nachdem es eine Zeile mit einer Zuweisung/Spule an den Ausgang, Merker oder Timer gibt. Die ersten LOGO-Generationen konnten nur FBD. (Moeller easy wurde von Anfang an mit KOP/LAD programmiert)

Ich mache selten LOGO, doch ich meine, der FBD wird "ungefähr" so abgearbeitet, daß zuerst der Verknüpfungsweg zu einem Ausgang abgearbeitet wird. Danach wird die Verknüpfung zu verknüpften Ausgängen, Merkern und Timern abgearbeitet, so daß dadurch der erste Ausgang erst einen Zyklus später schaltet. Beispiel:
Code:
   +---+    +----+    +----+
I1-| & |    |    |    |    |
  -|   |----| M2 |----| Q3 |
  -|   |    |    |    |    |
  -|   |    +----+    +----+
   +---+
Sowas wird nach meiner Erfahrung meistens so abgearbeitet:
Code:
    M2       Q3
----| |------( )

    I1       M2
----| |------( )
Dadurch schaltet Q3 erst einen Zyklus nach I1. Es kann auch vorkommen, daß es wie folgt abgearbeitet wird. Wie man das beeinflußt weiß ich jetzt aber nicht, Siemens dokumentiert dazu nichts:
Code:
    I1       M2
----| |------( )

    M2       Q3
----| |------( )
Wenn Du Programme erstellen willst, wo die Abarbeitungsreihenfolge eine Rolle spielt, dann könntest Du zunächst Test/Fang-Schaltungen erstellen, um zu sehen was früher schaltet.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Vielleicht solltest Du besser "vergessen", was Du über S5/S7 weißt, wenn Du mit der LOGO arbeitest, damit Du nicht ständig Äpfel mit Birnen vergleichst.

Ach hucki, Äpfel mit Birnen, soso , für was stehen Äpfel? oder die Birnen?

OK, das steht Im Widerspruch zu der Auskunft vom Siemens-Support. Das Problem der Effekte durch falsche Reihung von Blöcken ist schließlich kein typisches Siemens-Problem. Aber wenn wir schon mal in Richtung S5/S7 schielen, dann verweise ich darauf, den Blick ganz besonders in Richtung CFC-Programmierung, Ausführungen hierzu erspar ich mir. Wer will kann im CFC-Handbuch nachlesen, dort wird sehr ausführlich über das Eingemachte berichtet.

Die Blocknummern haben nichts mit der Abarbeitungsreihenfolge zu tun.

Hallo Harald,
ich lass' das mal so stehen. Natürlich habe ich es jetzt versucht, Deinem Ratschlag zu folgen und meinen Plan automatisch in eine LADDER-Logic-Darstellung zu überführen. Aber bei mir finde ich in LSC keinen Menüpunkt, den ich dafür ansprechen kann. Umgekehrt aber auch nicht. Seltsamerweise werden die FBD-Pläne mit der Endung ".lsc" gespeichert, während der LADDDER-Plan an der Endung ".lld" erkannt werden kann.

Deine Ausführungen habe ich zunächst mit Interesse gelesen, auch wenn sie im Augenblick den Widerspruch nicht aufzulösen vermögen. Unabhängig davon, wer von uns (ihr das draußen und ich hier vor meinem Erstlingswerk) mit seiner Betrachtung richtig liegt, halte ich es für opportun, auch den nächsten FBD in einer sauberen Reihenfolge zu erstellen. Das schon alleine deswegen, weil ich IOs multiplexen will und da möchte ich keine böse Überraschung erleben.

Batucada
 
Also ich muss schon etwas schmunzeln, dass hier S5 S7 CFC und dann die Logo verglichen werden. Bitte steinigt mich jetzt nicht dafür.
 
Aber bei mir finde ich in LSC keinen Menüpunkt, den ich dafür ansprechen kann. Umgekehrt aber auch nicht.
Icon-Leiste im Diagramm-Editor, 6. Icon von rechts.
Aber schön ist was anderes als diese Konvertierungsergebnisse.
:twisted:


PS:
Das Icon für mehr Seiten (max. 100) ist direkt links daneben "versteckt".
 
Zuviel Werbung?
-> Hier kostenlos registrieren
halte ich es für opportun, auch den nächsten FBD in einer sauberen Reihenfolge zu erstellen.
Falls Du damit meinst, daß Du am Ende eine "schöne" Blocknummern-Verteilung hast die wie eine Reihenfolge aussieht, dann viel Spaß. Dann darfst Du den FBD-Plan zweimal eingeben: einmal entwickeln und testen und weitere Blöcke einfügen und wieder testen... Und wenn dann alles zur Zufriedenheit funktioniert, dann nochmal alles komplett neu eingeben in der Reihenfolge wie Du die Blocknummern dastehen sehen willst, und nochmal alles ausführlich testen...

Schau Dir mal das Bild von diesem LOGO-Programm (von Heinileini in Beitrag #25) an - denkst Du dann immer noch, daß die Blocknummern die Reihenfolge beeinflussen? ;)

Harald
 
Ich hab' mich jetzt darauf eingelassen, eine bestimmte Anzahl der digitalen Eingänge in zwei Gruppen zu multiplexen. Aus dieser Sicht war mir natürlich klar geworden, dass die Verschleppung einer Sprungantwort über mehrer Zyklen, entstanden durch Reihungsfehler, so nicht akzeptabel ist.
Wie multiplext Du denn die Eingänge? Mit Klappertechnik? Vielleicht besser mit OptoKopplern, bei denen man die BetriebsSpannung der LEDs umschaltet? Kann es sein, dass Dein SprungAntwortenProblem (was immer das sein mag) daher kommt? Der Begriff SprungAntwort sagt mir nur etwas in Zusammenhang mit Reglern, aber dann ginge es ja um AnalogEingänge?
Die LOGO! wird immer so als SPS-EinsteigerModell gepriesen. Das habe ich nie verstanden, weil die "Zyklische Denkweise" dem Anfänger gar nicht so klar und eindeutig präsentiert wird.
Auch der Begriff "analog" wird ganz selbstverständlich völlig falsch und irreführend ge- bzw. missbraucht. Was mir auch unverändert Probleme bereitet, sind die zwei Arten von "Steckern" bei den AnalogWerten. Die LOGO! meldet gerne, dass die Stecker nicht kompatibel sind, aber ich habe noch nichts darüber gefunden, worin sie sich die vermutlich 2 Typen eigentlich unterscheiden.
Die überall fälligen Skalierungen mit ihren Wirkungen und Rückwirkungen auf "benachbarte" Blöcke sind mir ein Greul. Man kann sich einen Wolf herumexperimentieren, bis man zufällig eine Lösung findet ... oder auch keine Lösung. Die Logik der LOGO! erschliesst sich mir in diesem Punkt bisher noch keinesfalls. Bin heilfroh, dass für mich die LOGO! nicht als Einstieg in die SPS gedient hat ... das hätte ich ihr nie verziehen. :ROFLMAO:
 
Schau Dir mal das Bild von diesem LOGO-Programm (von Heinileini in Beitrag #25) an - denkst Du dann immer noch, daß die Blocknummern die Reihenfolge beeinflussen?

Hallo Harald,

soll mich das beeindrucken? Nöö, eigentlich nicht wirklich, wenn man davon absieht, dass es eine sehr schöne Arbeit von Heinileini ist. Und so im groben Überblick erscheint es sehr sauber angelegt, was meinen Maßstäben entspricht! Bemerkenswert sind die Merker M1, M2, M3 und M4. Schau ich mir exemplarisch den Merker M1 an, der das VKE von B025 zum B013 zurück koppelt, so habe ich mittlerweile begriffen, was in diesem Umfeld unter "Rekursion" zu verstehen ist. In einer Simulation habe ich bemerkt, dass z.B. bei einem Merker der Ausgang immer erst um 1 Zyklus später den Status des Eingangs annimmt. Diese Logik als Hardware würde nie funktionieren, wenn das VKE von B025 direkt auf B013 zurück gekoppelt würde.

Weil kurz zuvor jemand ins Schmunzeln geraten ist, dass ich CFC ins Gespräch gebracht habe, möchte ich dazu bemerken, dass es gerade bei CFC einen Ablaufeditor mit fulminanten Möglichkeiten gibt. Und nein, ich bin immer noch nicht davon überzeugt, dass die Reihenfolge der Blocknummern keinen Einfluss auf die Logik in einem LOGO-FBD haben sollen.

In der kommenden Woche werde mal wieder mein Oszilloskop entstauben und mich mal an einen Test unter realen Bedingungen machen. Das geschieht dann, wenn mir das entsprechende Erweiterungsmodul zur Verfügung steht. Simulationen in LSC betrachte ich mit gemischten Gefühlen, wenn selbst beim Siemens-Support zugegeben wird, das es Schaltungen gibt, die in der Simulation funktionieren, dagegen auf der Hardware nicht und vice versa.

Batucada
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Schau Dir mal das Bild von diesem LOGO-Programm (von Heinileini in Beitrag #25) an - denkst Du dann immer noch, daß die Blocknummern die Reihenfolge beeinflussen? ;)
Du weisst ja, Harald: niemand ist überflüssig - er kann zumindest als abschreckendes Beispiel dienen!!!
Warum ich eine eigene Numerierung möchte, die immer ganz anders aussehen würde, als sie von der LOGO! dank "sprunghafter" KreuzUndQuerEingabe produziert wird, hat nichts mit einer vermeintlichen Reihenfolge der Abarbeitung zu tun. Die kriegt die LOGO! sehr gut geregelt, weil sie sich nicht um diese NumerierungsReihenfolge kümmert.
Da meine LOGO!-Experimente eigentlich immer "geordnet" anfangen, sich aber sehr schnell zum KreuzUndQuerKuddelMuddel entwickeln und ich trotzdem auch mal von getrennten Verbindungen Gebrauch machen möchte, habe ich ganz andere Vorstellungen über die Numerierung als die LOGO! Es ist einfach frustrierend, wenn man einen Verweis auf Block xy findet, aber den Block xy erst nach verzweifelter, zeitraubender Suche.

PS:
Das ist so, als müsste man eine TelefonNr in einem TelefonBuch suchen, in dem die Namen nicht alphabetisch sortiert sind.
 
Zuletzt bearbeitet:
Wie multiplext Du denn die Eingänge? Mit Klappertechnik? Vielleicht besser mit OptoKopplern, bei denen man die BetriebsSpannung der LEDs umschaltet?

Klappertechnik :ROFLMAO: schön, den Begriff gibt's also immer noch. Nöö, keine Optokoppler, ich nehm' jeweils einen Ausgang des DM16-Moduls, der kann maximal 300 mA treiben, bei 12 Eingängen kommen rein rechnerisch 24 mA zusammen, das sollte gehen. Was ich beobachten will, wie sich die Eingangsfrequenz von maximal 4 Hz bemerkbar macht. Zur Zeit hab' ich den Multiplexer auf 4 Zyklen verteilt, notfalls muss ich nochmals untersetzen.

Kann es sein, dass Dein SprungAntwortenProblem (was immer das sein mag) daher kommt?
Nöö, ganz sicher nicht, ich bin nur für das Erkennen solcher Probleme seit mehr als 30 Jahren gut sensibilisiert.

Der Begriff SprungAntwort sagt mir nur etwas in Zusammenhang mit Reglern, aber dann ginge es ja um AnalogEingänge?
Die Entlehnung kommt eigentlich aus der Regelungstechnik. Die Anwendung im aktuellen Zusammenhang ist vielleicht fachlich nicht ganz korrekt, aber bildlich gesehen, gefällt mir der Ausdruck :D

Die LOGO! wird immer so als SPS-EinsteigerModell gepriesen. Das habe ich nie verstanden, weil die "Zyklische Denkweise" dem Anfänger gar nicht so klar und eindeutig präsentiert wird.
Auch der Begriff "analog" wird ganz selbstverständlich völlig falsch und irreführend ge- bzw. missbraucht. Was mir auch unverändert Probleme bereitet, sind die zwei Arten von "Steckern" bei den AnalogWerten. Die LOGO! meldet gerne, dass die Stecker nicht kompatibel sind, aber ich habe noch nichts darüber gefunden, worin sie sich die vermutlich 2 Typen eigentlich unterscheiden.
Die überall fälligen Skalierungen mit ihren Wirkungen und Rückwirkungen auf "benachbarte" Blöcke sind mir ein Greuel. Man kann sich einen Wolf herum experimentieren, bis man zufällig eine Lösung findet ... oder auch keine Lösung. Die Logik der LOGO! erschliesst sich mir in diesem Punkt bisher noch keinesfalls. Bin heilfroh, dass für mich die LOGO! nicht als Einstieg in die SPS gedient hat ... das hätte ich ihr nie verziehen.
Ich sag' ja, wenn ich heute damit mein Geld verdienen müsste, würde ich beim Arbeitsamt um eine Umschulung nachsuchen.

Batucada
 
Es ist einfach frustrierend, wenn man einen Verweis auf Block xy findet, aber den Block xy erst nach verzweifelter, zeitraubender Suche.

PS:
Das ist so, als müsste man eine TelefonNr in einem TelefonBuch suchen, in dem die Namen nicht alphabetisch sortiert sind.
Dafür gibt's den Menüpunkt "Bearbeiten -> Gehe zu Block" bzw. den Shortcut Strg+G.
;)
 
Zurück
Oben