Zum Schutz von empfindlicher Hardware haben wir seit Anfang des Jahres ein LOGO!8 Modul mit 4 Relais, um die Versorgungsspannunng automatisch abschalten zu können.

Implementiert werden soll ein "Tot-Mann-Schalter", der das Relais geschlossen hält, so lange vom Mess-PC regelmäßig ein OK Signal empfangen wird.

Dazu wurde in der LOGO!8 der Server gestartet und vom PC regelmäßig ein Client-Request geschickt, der das Bit V0.0 auf 1 setzt. V0.0 wird dann als Network-Input zur weiteren Verarbeitung benutzt. Um nicht vom LOGO!8 Cycle Timing abhängig zu sein soll das Bit V0.0 LOGO intern wieder auf 0 gesetzt werden - und nicht durch einen weiteren Client Request. Dazu wurde das AND(Edge) Logik-Gatter benutzt, das gemäß Dokumentation den Ausgang für einen Cycle auf 1 setzt und dann wieder auf 0 fällt. Über einen Network-Output wird damit V0.0 zurück gesetzt.

Im Anhang ist zu sehen, daß dies in der Simulation auch so funktioniert: Logo_AND_Edge_Sim_?.png  mit ? = 0,1,2,3 fir die Single-Step Simulations Schritte.
Nach jedem Setzen von V0.0=1 im Data-Table zählt der Zähler um 1 weiter.

Wird das Programm aber auf der LOGO!8 ausgeführt, dann klappt dies nur in ca. 30% der Fälle. In den anderen Fällen oszilliert V0.0 zwischen 0 und 1 und der Zähler läuft mit ca 2500 Hz. Logo_AND_Edge_Online_1.png zeigt einen ScreenShot eines Online-Test Zustandes, der laut Dokumentation (und Simulation)  nicht erreicht werden sollte, denn per Data-Table wird V0.0 nur auf 1 gesetzt, und nur der AND(Edge) Ausgang kann V0.0 auf 0 zurücksetzen.Außerdem dürfte der AND(Edge) Ausgang nicht 1 sein, wenn ein Eingang 0 ist.

Eine alternative Variante mit einem Edge-Triggered Wiping Relay anstelle des AND(Edge) (Logo_SingleClientRequesTrigger_vs2.png) ist über 500000 Client-Requests vom PC problemlos gelaufen, solange die Pulslänge auf 00:02 s gesetzt war. Bei 00:01 s klappte es aber auch damit nicht verläßlich.

Da ich unsere zu schützende Hardware keinem unnötigen Risiko aussetzen möchte, würde ich schon gerne verstehen, warum diese LOGO Programme nicht stabil laufen. Evtl. liegt es ja an einem internen Buffereing der Network-Inputs und -Outputs, so daß eine Abbildung auf einem Speicherbit wie V0.0 zwischen zwei LOGO Cycles nicht eindeutig ist ?

Für einen Vorschlag, wie ein Trigger mit einem einzigen Client Request von einem PC verläßlich  realisierbar ist wäre ich dankbar, ansonsten würde ich dann doch auf den internen Reset von V0.0 verzichten und dann 2 Client requests schicken - mit etwas Pause dazwischen, damit die LOGO auch den Flankenwechsel mitbekommen kann.

Software:   LOGO!Soft Comfort 8.1    Linux  64bit
Hardware: LOGO! 8.FS4 1.81.01.27.6816C

Herzlichen Dank ixo65 für diesen Vorschlag.

Er läuft fehlerlos in Simulation, Online-Test und mit PC Programm nach bisher 20000 client-requests.

Um auf diese Idee zu komment ist ja etwas mehr Information über die internen Abläufe eines Logo Cycles nötig. Wäre das in der mitgelieferten Dokumentation zu finden gewesen ?

Aber gut daß es dieses Forum dazu gibt :)

A:

Die erste Serie 0BA8 LOGO hat ein Problem mit der Netzwerkfunktion , die die LOGO laufen nach unten kann.
Die Version FS4 ist die neueste Version Logio, so sollten die Netzwerkprobleme gelöst werden

B

Der Simulationsmodus auf dem Computer mit LOGO! Soft Arbeit  langsamer als die reale Programm auf dem echte LOGO