Serieller LOGO-Bus mit Hausmitteln (Version 2)

Hallo,

von Robert (monochromatic) wurde hier ein sog. "serieller Bus" für LOGO!-Module ab der Serie 0BA4 vorgestellt (Datei: "DEMO_Serieller_Bus_Original_monochromatic.lsc").

Auch wenn ich die Übertragung eines (AD-gewandelten) Analogwertes zwischen SPS-Modulen nicht für effizient und auch für fehleranfällig halte, habe ich mir auf Basis der o. g. Schaltung Gedanken zu einer effiziente(re)n Lösung gemacht und will euch meine Schaltungsentwürfe hier vorstellen. Die einzelnen Funktionen der Gesamtsteuerung sollten in jedem Fall so auf die einzelnen SPS-Module aufgeteilt werden (wenn denn nun schon mehrere zwingend erforderlich sind!), dass nur eine mininale Kommunikation (= Kommandos) bzw. ein minimaler Datenaustausch erforderlich ist (z. B. Alarme, Trigger und Statusinfos...). D. h. insbesondere sollte die Verarbeitung/Auswertung von Analogsignalen innerhalb eines der SPS-Module bleiben und nur daraus abgeleitete Digitalsignale an eine (oder mehrere) andere Module übertragen werden, wenn diese Signale zwingend für deren Funktion erforderlich sind. Natürlich hängt dies von der jeweiligen Anwendung ganz erheblich ab...

Vorab:
a) Sämtliche digitalen Signale zwischen verschiedenen SPS-Modulen sollten m. E. LOGO!-seitig mit Transistorausgängen (z. B. Zusatzmodul DM8 24) realisiert werden, ansonsten ist keine adäquate Übertragungsrate zu erreichen und außerdem wäre die Lebensdauer der Relais deutlich eingeschränkt!

b) Sämtliche Lösungsvorschläge sind weiterhin ab der LOGO!-Serie 0BA4 anwendbar.

c) Grundsätzlich können mit allen Entwürfen auch bidirektionele Verbindungen realisiert werden, doch der Blockbedarf dafür ist doch recht erheblich.

d) Ggf. können dann allerdings auch durch Anforderung eines (Slave-)Modules (über entsprechende Eingangssignale) mehrere "Datensätze" über die selben Transistorausgänge "angefordert" werden. Insgesamt müssen dann andererseits weniger Bits (je Sendung) übertragen werden, wodurch sich ggf. vorteile ergeben.

meine Lösungskonzepte:
1. Durch konzeptionelle Modifikation der Senderschaltung lassen sich (ohne sonstige Änderungen der Originalschaltung) bereits einige Blöcke einsparen (vgl.
Datei: "DEMO_Serieller_Bus_Blockanzahl_reduziert_V1.lsc").

2. Durch Eliminieren der Addressierung von jeweils 8 Daten-Bit lassen sich in der Sender- und der Empfänger-Schaltung weitere Blöcke einsparen. Außerdem habe ich auf die Verwendung des Schieberegisters verzichtet und ein neues (einheitliches) Konzept zur Auswertung der empfangenen Bits im Empfänger erstellt, das eine einfache Anpassung an die Bit-Anzahl n ermöglicht. (vgl. Datei "DEMO_Serieller_Bus_Alternative_V1.lsc"). Daraus ist schließlich der Schaltungsentwurf entstanden, der das Gesamtkonzept eines seriellen Busses am Beispiel der Übertragung von 16 Bit verdeutlicht (Datei "DEMO_Serieller_Bus_Alternative_V2a.lsc").

Vorteile: insgesamt weniger Blöcke erforderlich und flexiblere Adressierung der Bits, so dass 1..x LOGO!s als Empfänger eingesetzt werden können. Die Addressierung der Bits erfolgt hier alleine durch die Parameter der Zähler; Jeder EMPFÄNGER sucht sich quasi die entsprechenden Bits heraus, die ausgewertet werden sollen. Die Bitanzahl n ist flexibel über die Anzahl der Zähler im SENDER zu definieren. Die Empfänger müssen dann nur die jeweils erforderliche Anzahl an Zählern (mit den entsprechenden Parametern) für die Bits beinhalten, die jeweils genutzt werden sollen. Die Schaltungsversion 2a ermöglicht so eine " endlose Datenübertragung ohne Synchronisation zwischen SENDER und EMPFÄNGER" über nur ZWEI Signalleitungen!

3. Um nun die Übertragungssicherheit zu erhöhen habe ich nun noch eine Synchronisation zwischen SENDER und EMPFÄNGER entwickelt. Die Schaltungsversion ..2b ermöglicht so eine " endlose Datenübertragung MIT Synchronisation zwischen SENDER und EMPFÄNGER" über nur DREI Signalleitungen! Die Vorteile einer leichten Anpassung der Anzahl an zu übertragenen Bits und der Wegfall einer Begrenzung von Empfängern bleibt dabei bestehen. Darüber hinaus verbleibt noch immer ein Transistorausgang (eines Basis bzw. Zusatz-Modules) frei für andere Aufgaben.

4. M. E. ist eine STÄNDIGE, ununterbrochene Übertragung der Bits häufig nicht erforderlich und kann andererseits auch zu EMV-Störungen führen. Deshalb habe ich einerseits eine moderate Übertragungsrate (per Impulsgenerator) vorgegeben und andererseits zwei Schaltungsvarianten mit getriggerter Datenübertragung entwickelt. In der Variante ..2c ist eine getriggerte Datenübertragung (1-mal) MIT Synchronisation zwischen SENDER und EMPFÄNGER realisiert, die je Trigger(-Impuls) genau 1 x n Bits überträgt. In der Variante ..2d ist dann schließlich eine getriggerte Datenübertragung (k-mal) MIT Synchronisation zwischen SENDER und EMPFÄNGER realisiert, die je Trigger(-Impuls) k x n Bits überträgt (mit Übertragungswiederholung k = 1 bis 9). Dabei ist aber leider zu beachten, dass k nicht per Verweis definiert und leider auch nicht im Parametriermodus der LOGO! editiert werden kann. Soll dieser Wert k also geändert werden, dann muss die LOGO! vom RUN- in den STOP-Modus geschaltet werden (was u. a. den Verlust von Aktualwerten verschiedener Blöcke zur Folge hat!).

5. Folgendes zu den Möglichkeiten einer AD- und DA-Wandlung mit der LOGO!, um bei Bedarf auch Werte, Ziffern bzw. Zahlen mit dem o. g. seriellen Buss übertragen zu können:

5a. Zwar sind in der Schaltungssammlung zur AD-Wandlung zwei (nicht von mir stammende) Schaltungen enthalten (und auf den entsprechenden Foren-Beitrag verwiesen), doch sind diese, wie die folgenden Ausführungen verdeutlichen, für eine Anwendung hier nicht wirklich von grossem Nutzen, insbesondere weil zu viele Blöcke erforderlich sind. Die Schaltung "4-Bit AD-Wandler.lsc" ist praktisch die Umsetzung eines 16-nach-4-Encoders, wie er in der Datei "16-zu-4-Encoder.pdf" (der Schaltungssammlung) beschrieben ist. Die 16 Blöcke "Schwellwertschalter" dienen dabei der eigentlichen "Digitalisierung" (= Analyse) des jeweiligen Analogwertes und deren Digitalausgänge sind praktisch die in der Tabelle angegebenen Eingabesbits x0 bis x15. Die 12 Blöcke "ODER" dienen dann entsprechend den unter der Tabelle angegebenen Logikgleichungen für die Bildung der Signale y0 bis y3 als 4-Bit-Ergebnis der AD-Wandlung.

5b. Betrachtet man übrigens den Tabellenteil mit den yi, dann bietet sich noch eine andere Lösungsvariante an, die nur 20 anstelle der 28 Blöcke der o. g. Lösung erfordert. y3 kann mit nur einem Block Schwellwertschalter (ON = 50% und OFF =100% des zu wandelnden Analogbereiches) definiert werden. y2 kann mit 2 Schwellwertschaltern (ON_1 = 25%; OFF_1 = 50% und ON_2 = 75%; OFF_2 = 100%) und einem Block ODER zur Verknüpfung der beiden Ausgangssignale gebildet werden. Entsprechend verfährt man mit den Signalen für y1 und y0...

5c. Die 2. Schaltung "7Bit AD-Wandler Digitaler_Zähler.lsc" der Schaltungssammlung kann dann für eine AD-Wandlung nützlich sein, wenn höhere Auflösungen (hier 7 Bits) des Analogwertes gefordert werden, denn dazu werden dann insgesamt weniger Blöcke benötigt. Aber von Nachteil ist der Umstand, dass die Schaltung jeweils die Ausgangsbits nur nach einem Triggereimpuls und (dann) mit Zeitverzögerung bereitstellt - schliesslich sind die Digitalausgänge des Wandlers erst nach vollständiger (sequentieller) Analyse des Eingangswertes korrekt.

5d. Eine 3. Variante zur AD-Wandlung wäre die Umsetzung des Analogwertes in ein PWM-Signal, so dass dann die jeweilige "ON-Zeit" den tatsächlichen Analogwert (linear zwischen den Grenzen "0" und "1000") repräsentiert. Dies kann mittels des Blocks "PWM" der 0BA6 oder mit den in der Schaltungssammlung enthaltenen Schaltungen erfolgen.

5e. Eine 4. Variante zur AD-Wandlung wäre die Ausgabe eines Analogwertes mit einem Zusatzmodul AM2 AQ.

5f. Die m. E. beste Variante einer AD-Wandlung mit der LOGO! wurde im engl. Forenteil von Carlos Calderón Córdova vorgestellt, mit "decimal_to_4_bit_binary_Converter.lsc". Diese Lösungsvariante ist ab der LOGO!-Serie 0BA5 möglich. Für n Bit(s) Analogwertauflösung OHNE Vorzeichen werden dazu (n * 3) + 1 LOGO!-Blöcke benötigt (wenn der Analogwert per Verweis aus einem Block der übrigen Schaltung "entnommen" werden kann. Bei einem Wertebereich von 0..1000 (= LOGO!-Analogein- und -ausgänge) wären dass dann 31 und bei einem Wertebereich von 0..32767 46 Blöcke. Enthält der Wertebereich darüber hinaus auch negative Werte, dann kommt noch ein Block "Analoger Schwellwertschalter" zur Vorzeichenerkennung und ein (Analogverstärker) oder zwei (Multiplexer + Analogverstärker) Blöcke zur Bildung des Wertbetrages (stets positiv!) hinzu. Der Auffwand ist also noch immer recht beträchtlich, jedoch insgesammt geringer als bei den o. g. anwendbaren Varianten!

6. Nun noch folgendes zu den Möglichkeiten einer DA-Wandlung mit der LOGO!. Diese Aufgabe läßt sich vergleichsweise effizient mit einer LOGO! durchführen. Demonstriert wird dies für eine LOGO!-0BA5 in der Datei "4-Bit DA-Converter_V2_0BA5.lsc" und für eine LOGO!-0BA6 in der Datei "DEMO_8-Bit DA-Converter_V4_0BA6.lsc". Durch geschickte Anwendung von Multiplexer- und Komparator-Blöcken mit geeigneten Blockparametern kann eine DA-Wandlung effizient erfolgen. In der 0BA6 lassen sich die Blöcke "Analoge Arithmetik" zur einfachen Ergebniswertberechnung (bei Bedarf inkl. Vorzeichen) verwenden.

7a. Trotz der inzwischen entwickelten Schaltung(en) "DEMO_Serieller_Bus_Alternative_V2(x).lsc" halte ich die Übertragung eines wie oben angegeben transformierten Analogwertes zwischen SPS-Modulen leztendlich nicht für effizient und auch für fehleranfällig (insbesondere bezyglich der Übertragung). Die Schaltungsteile enthalten keinerlei Fehlererkennung. Auch die vorhandene Synchronisation ist nicht in allen Situationen "fehlerresistent".

7b. Besser sollten die einzelnen Funktionen der Gesamtsteuerung so auf die einzelnen SPS-Module aufgeteilt werden (wenn denn nun schon mehrere zwingend erforderlich sind!), dass nur eine mininale Kommunikation bzw. ein minimaler Datenaustausch erforderlich sind (z. B. Alarme, Trigger und Statusinfos...). D. H. insbesondere sollte die Verarbeitung/Auswertung von Analogsignalen innerhalb eines der SPS-Module bleiben und nur daraus abgeleitete Digitalsignale an eine (oder mehrere) andere Module übertragen werden, wenn diese Signale zwingend für deren Funktion erforderlich sind!!! Natürlich hängt dies von der jeweiligen Anwendung ganz erheblich ab...

MfG
Betel