LOGO Vergleich STEP7-AWL zu LOGO!-FDB

Zuviel Werbung?
-> Hier kostenlos registrieren
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.

Es gibt insgesamt 3 "Stecker"-Typen.

Digitale Verbindungen: Dünne Verbindungslinie.
Analoge Verbindungen: Dicke Verbindungslinie.
Referenzverbindungen: Bei zugeklappen Parameterfeldern erscheinen sie als gestrichelte Linien.

Diese Verbindungen sind untereinander nicht kompatibel.
 

Anhänge

  • Inkompatible Stecker.jpg
    Inkompatible Stecker.jpg
    65,3 KB · Aufrufe: 3
1. Diese Logik als Hardware würde nie funktionieren, wenn das VKE von B025 direkt auf B013 zurück gekoppelt würde.
2. ... wenn selbst beim Siemens-Support zugegeben wird, das es Schaltungen gibt, die in der Simulation funktionieren, dagegen auf der Hardware nicht ...
3. ... und vice versa.
1. Das ist der Unterschied zwischen Hardware einerseits und Software andererseits - ganz generell, nicht zwischen LOGO! und anderen SPS.
Das "zu-Fuss-StromstossSchalter-Beispiel" aus #5 kann in Hardware so nicht funktionieren, weil die "ordnenden" Zyklen fehlen. Darum hat man in HardwareSchaltungen die Taktung eingeführt.
2. Meines Wissens geben sie zu Recht zu, dass Ausgänge von Blöcken abgeschlossen werden müssen, wenn die Schaltung nicht nur in der Simulation funktionieren soll. Nicht mehr und nicht weniger.
Das Phänomen bzw. die Bereitstellung der "offenen Klemmen" war anfangs auch für mich ein Rätsel.
3. zu dem Umkehrschluss fällt mir so gar nichts ein. Hast Du ein Beispiel dafür?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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 dicken Linien sind Verbindungen zwischen Analog-Baustein-Ein- und Ausgängen (am gelben Bausteinblock), die gestrichelten Linien sind Parameterverweise (am weißen auf- und zuklappbaren Parameterblock).
Baustein- und Parameteranschlüsse können nicht miteinander verbunden werden. Bis zur 0BA7 waren und sind die Parameterverweise reine Textangaben, also noch ohne die gestrichelten Linien.


PS: Oh, da hab' ich aber ziemlich lange zum Tippen gebraucht.
:ROFLMAO:


Die überall fälligen Skalierungen
Die sind nicht überall fällig.
Jeder neu eingefügte Analogblock hat Gain=1 und Offset=0 als Standardeinstellung und damit bleibt der Wert erst einmal von Ein- zu Ausgang bzw. Verwendung unskaliert.
In den überwiegenden Anwendungen reicht es aus, den Analogwert einmal zu Beginn direkt nach dem AI z.B. per Analog-Verstärker auf den gewünschten Wertebereich zu skalieren und die folgenden Blöcke kann man dann in der Beziehung meist "unberührt" lassen.
 
Zuletzt bearbeitet:
Es gibt insgesamt 3 "Stecker"-Typen.

Digitale Verbindungen: Dünne Verbindungslinie.
Analoge Verbindungen: Dicke Verbindungslinie.
Referenzverbindungen: Bei zugeklappen Parameterfeldern erscheinen sie als gestrichelte Linien.

Diese Verbindungen sind untereinander nicht kompatibel.
Die digitalen Verbindungen hatte ich bei den analogen nicht mitgezählt.
Ich hatte an die 2 Typen gedacht, die Du anschliessend anführst.
Gibt es denn dazu irgendwo eine verbindliche und verständliche Aussage, woran die Kompatibilität scheitert?
Die ReferenzVerbindungen bedürfen (für meinen Geschmack) keiner weiteren Erläuterung.
Aber die analogen Ein- und Ausgänge an den BlockSymbolen (nicht den ParameterListen) transportieren anscheinend mehr Informationen (und zwar bidirektional!?) als nur einen AnalogWert (in einer Richtung) und sind deshalb nicht kompatibel zu den ReferenzVerbindungen.
Sinn und Zweck dieser ZusatzInfos erschliesst sich mir nicht und die "SchnittstellenDefinition" ist für mich ein böhmisches Dorf mit sieben VerständnisRiegeln und die Auswirkungen finde ich eher katastrophal als hilfreich. Irgendwie habe ich das Gefühl, dass man hier eine intuitive Bedienung realisieren wollte, die zu meiner Intuition leider absolut inkompatibel ist. ;)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Aber die analogen Ein- und Ausgänge an den BlockSymbolen (nicht den ParameterListen) transportieren anscheinend mehr Informationen (und zwar bidirektional!?) als nur einen AnalogWert (in einer Richtung) und sind deshalb nicht kompatibel zu den ReferenzVerbindungen.
Sinn und Zweck dieser ZusatzInfos erschliesst sich mir nicht
Keine Zusatzinfos, sondern historisch gewachsen:
Bis zur 0BA7 waren und sind die Referenzverweise reine Textangaben, also noch ohne die gestrichelten Linien zum Ziehen.
Wie wolltest Du da eine Linie vom Ausgang mit dem Text vom Parametereingang verbinden können?
 
Die überall fälligen Skalierungen mit ihren Wirkungen und Rückwirkungen auf "benachbarte" Blöcke sind mir ein Greul.
Meinst Du vielleicht die "Rückwirkungen" des ersten Analogblocks nach einem Analogeingang (AI)? Die haben mich am Anfang auch fast wahnsinnig gemacht. Ich habe jetzt gerade leider kein LogoSoft zur Verfügung, um das nochmal nachzustellen, doch das war irgendwie so (LogoSoft V7 ?), daß in der Simulation (nur da!) die Simulationswerte des Analogeingangs völlig unlogische Werte haben müssen... Um den Analogeingang so steuern/simulieren zu können wie er sich am realen LOGO-Gerät tatsächlich verhält, habe ich immer nur für die Simulation einen Analogblock (Analogverstärker?) (quasi als "Trennverstärker" ;)) direkt nach dem Analogeingang eingefügt.

Harald
 
Hallo PN/DP,

meinst du die beiden Werte, die in der Simulation unterhalb des AI angezeigt werden?
Der obere Wert ist der Wert nach Analogverstärker, der untere der Wert des AI.

In Anhang ein Beispiel.

Es soll eine Temperaturmessung mittel PT100/1000 dargestellt werden.
Der eingestellte Wert ist 100, was durch das Einstellen einer Nachkommastelle 10,0 entspricht.

Wert vom AI = 240
Gain im Verstärker = 2,5
Offset = -500

240 * 2,5 = 600
600 + -500 = 100
 

Anhänge

  • Unbenannt.png
    Unbenannt.png
    23,2 KB · Aufrufe: 3
Zuviel Werbung?
-> Hier kostenlos registrieren
Danke GUNSAMS, doch was ich noch unscharf im Gedächtnis habe, da ging es vermutlich um einen 0-10V-Eingang, und in der Simulation gibt es doch solche Schieberegler (oder Eingabefelder?) für den Wert, den der simulierte AI liefern soll, und da mußte ich im nächsten Analogblock irgendwie unlogisch Gain/Offset einstellen, damit der Wert am Einsteller und der Wert am AI-Block mir wieder realistisch vorkam... ich bekomme das jetzt leider nicht mehr exakt wieder raus, wie das genau war.

Harald
 
Zuletzt bearbeitet:
Ja, der Schieberegler passte sich dem Wert des eigestellten Bereichs im nachgeschalteten Analogverstärker an.

Lässt du ihn in den Defaulteinstellungen, zeigt der Schieberregler einen Bereich von 0-1000.
In meinem Beispiel mit der Parametrierung als PT100/1000 mit einer Verstärkung von 2,5 und einem Offset von -500 würde er dann -500 bis 2000 anzeigen (mit einer angewählten Kommastelle wird im Display -50,0 bis 200,0 °C angezeigt).
 
Dank an euch beide, Harald und GUNSAMS!
Ja, das muss das Phänomen gewesen sein, was mich mal vom LOGO!-Glauben hat abfallen lassen.
Ich kann mich auch nur vage erinnern (immerhin!;)), da es schon länger her ist und seither von mir "weiträumig umfahren" wurde, wie es in Verkehrshinweisen immer so schön heisst.
Mehr als die Simulation kenne ich von der LOGO! nicht - mag sein, dass dies (hoffentlich) nur in der Simulation so verwirrend gelöst ist. Mit Rückwirkungen dieser (Un-)Art hatte ich bei "richtigen" SPS nie zu kämpfen - da war die Welt für mich noch in Ordnung!
 
Für mich ist aber keine Rückwirkung.

Der Analogeingang wird davon doch gar nicht betroffen. Es ist doch nur eine Anzeige des Ausgangswert des nachgeschalteten Verstärkers zusätzlich unter dem AI. Und der Schieberegler nimmt den Bereich des verstärkten Signal an.

Der AI bleibt wie erst: Es sind die Einheiten 0-1000 bzw. 200-1000 bei 4-20mA als eingestellter Sensortyp im Verstärker.

Es ist wie so oft im Leben: Wenn man es weiß, ist es doch okay.
 
1. Das ist der Unterschied zwischen Hardware einerseits und Software andererseits - ganz generell, nicht zwischen LOGO! und anderen SPS.

Nöö, nicht nur, sondern auch von SPS zu SPS. Das Problem liegt in der Struktur des Merkers. Das das Beispiel in Hardware so nicht funktioniert, muss man erst gar nicht diskutieren.
zu 2. +3., das war eine Einlassung vom Siemens-Support. Ich selbst verfüge noch nicht über entsprechende Erfahrungen. Das soll auch hoffentlich so bleiben. Aber die Meldungen über Ungereimtheiten der Simulation werden auch hier im Forum deutlich artikuliert.

Ich bin gestern über eine ich nicht vorhandene offene Klemme "gestolpert" - aber nicht in der Simulation, sondern beim Ladenversuch eines Programmfetzens, der mit einer sagenhaften=nichtssagenden Meldung quittiert wurde, einzig der Hinweis, zusätzliche Informationen in einem Infofenster erhalten zu können, wäre schon mal lobenswert gewesen, wenn man denn eine Ahnung davon haben könnte, wo dieses Fenster sich befinden könnte. Aber nada! Das erinnert mich an die Wut auf die Entwickler sehr früher C-Compiler, die dir mit einer Meldung mitgeteilt haben, dass die Übersetzung wegen eines Fehlers abgebrochen wurde. Ich habe diese Leute bis auf's Blut gehasst, sie wussten um die fehlerhafte Stelle, nur ich nicht. OK, eine offene Klemme hat gefehlt, das habe ich mir dann zusammen gereimt.

Batucada
 
Nöö, nicht nur, sondern auch von SPS zu SPS. Das Problem liegt in der Struktur des Merkers.
Merker oder BitSpeicherlätze anderen Namens sind bei LOGO!-FBD nicht nötig, um ZwischenErgebnisse bis zur nächsten Verwendung im selben Zyklus zu parken, jedenfalls nicht an der Oberfläche sichtbar und dementsprechend nicht vom Anwender zu verwalten. Merker tauchen also ausschliesslich dann auf, wenn es darum geht, Zustände in den nächsten Zyklus hinüberzuretten.
Ungewöhnlich ist bei LOGO!-FBD-Darstellung eigentlich nur, dass die "MerkerBlöcke" (gilt auch für die Ausgänge) links einen Eingang und rechts einen Ausgang haben und der Ausgang des Blocks dem Eingang immer um einen Zyklus hinterherhinkt. Das ist für Programmierer anderer SPS das Gewöhnungsbedürftige an der Geschichte.
Dieser Unterschied beschränkt sich auf die Darstellung im "Schaltbild". Das bedeutet aber nicht, dass die LOGO! anders arbeitet - insbesondere nicht, dass sie ein Programm nicht genauso zyklisch abarbeitet. Den von Dir vermuteten, vermeintlichen Unterschied zwischen verschiedenen SPS gibt es m.E. nicht.
 
Zuletzt bearbeitet:
Zurück
Oben