UNGEWOLLTE Zwangsüberschreibung extern gesetzter Output Werte

Hallo Walter und Mitleser

Folgendes Problem:

Ich greife von extern auf das Prozessabbild zu und möchte eine Output Variable sowohl von realen als auch virtuellen DIOs verändern , die als globale Variablen in LogiCad deklariert sind, (mit z. B. piTEST -w Output_10,1 oder in Node-Red mit EXEC oder Kunbus Nodes). Solange das LogiCad Programm nicht auf der SPS läuft ist das kein Problem. Läuft das Programm erzwingt es die Werte immer auf NULL zu setzen (Variablen werden sonst nirgends im Programm verwendet und auch bei der Initialisierung der Variablem, habe ich mal mit und ohne Initialisierungswert gearbeitet). Also z. B: piTEST -w Output_10,1 funktioniert (der Wert wird gesetzt), aber wenn das SPS Programm läuft, funktioniert es nicht und der Wert von Output_10 bleibt auf 0 (wie gesagt, die Variable wird sonst nirgends im Programm verwendet, wo eine Zwangsüberschreibung erfolgen könnte). Nimmt man eine Variable die nicht in den globals definiert ist ( z. B. wie Output_11), funktioniert die Beschreibung der Output_11 auch wenn das SPS Programm läuft. Also müsste das Problem irgendwie mit der Initialisierung der Globals zusammenhängen, als würde das SPS-Programm bei jedem Prozessloop die Outputwerte in jedem Fall immer auf 0 setzen. NUR DAS IST HIER NICHT GEWOLLT: Zum Hintergrund ... Bei der Erstellung eines Userinterface z. B. über Node-Red-Dashboard ist die Standardnomenklatur, das Output-Pins als INPUT verwendet werden, so auch bei den Node-Red-Dashboard Knoten die von Kunbus bereitgestellt werden oder selbst gebastelte Executable. Also ein einfacher Schalter On/Off geht über z. B. Output_10,1 oder Output_10, 0 ... die Zwangsüberschreibung wenn das SPS Programm läuft verhindert das. Ich habe in der LogiCAD Anleitung gesucht und bin dort über den Befehl Forcen gestolpert, bin aber hier nicht damit weitergekommen.

Woran könnte das liegen? Muss ich die Variablen anders initialisieren oder gibt es einen grundlegenden Befehl um die Zwangsüberschreibung zu verhindern?

Danke und viele Grüße
Marco

Hallo Marco,

ich muss das Thema mit meinen Kollegen aus der Entwicklung im Detail besprechen.
Vorweg: gerade beim Ansteuern von IOs muss "die Quelle" eindeutig sein. Hier muss eine Applikation alleine über einen physischen Ein-/Ausgang entscheiden können. Alles Andere wäre kein deterministisches Verhalten.
Kannst du Deine Anforderung nicht anders abdecken - z.B. dass der logi.RTS von den anderen Programmen über "Schnittstellen" (=Variablen, IODienste,...) Informationen bekommt und dann im SPS Programm gehandled werden kann, welchen Wert der Ausgang einnehmen soll?

Ich melde mich in Kürze nochmals mit den Vorschlägen unserer Entwicklung

lg
Walter

Hallo Marco,

ich habe mich nun mit unseren Entwicklern nochmals zum Thema ausgetauscht:

logi.CAD 3 hat ein eigenes Prozessabbild. Es enthält auch die von Dir verwendete Variable. Diese wird beim Start des SPS Programmes initialisiert. Zusätzlich wird über den IO-Task in logi.CAD 3 zyklisch (nicht eventbasiert) das Prozessabbild der Variablen in logi.CAD 3 auf das Kunbus Prozessabbild geschrieben. Dieser Vorgang ist notwendig, da sich in jedem SPS Programmzyklus der Wert der Variable ändern könnte und somit auch auf die IOs geschrieben werden muss. Das Verhalten ist für uns "works as designed".
Wenn du Einflüsse von "anderen externen Größen/Variablen/..." auf die IOs des Revolution Pi haben willst, so empfehlen wir dir folgende Strategie:
1) "externe" Größen auf virtuelle IOs zu bringen
2) diese in logi.CAD 3 einzulesen
3) im SPS Programm dann durch die Programmlogik eindeutig zu entscheiden, welcher Wert auf den physischen IO kommt.

lg
Walter

Hallo Walter

Danke für deine Antworten. Ich denke den von dir beschriebenen zweiten Weg bin ich auch gegangen. Für die exterene Kommandoebene nutze ich ein virtuelles IO. Allerdings verleibt das Problem (eventuell ein Schönheitsfehler), dass die offiziellen Kunbus-Nodes nur OUTPUT-PINs (real oder virtuell) zum aktiven beschreiben ermöglichen (INPUT-PINS gehen nicht zu beschreiben). Vom Prinzip geht es darum die KUNBUS-NODES zu verwenden. Ich habe das Problem nun so gelöst, dass ich eine Funktionsablauf erstellt habe, indem die INPUTS auch im Dahsboard als solche verwendet werden (siehe Bild). Sprich, ich schicke ein Kommando auf das virtuelle Input_pin X und das wird dann in logi.CAD auch richtig verarbeitet. Nur die offiziellen KUNBUS-NODES im Dashboard kann man hier nicht verwenden (zumindest die ich habe).

Mit wem müsst man das mal klären?

Grüße Marco

Hallo Marco,

danke für deine Erklärungen. Man könnte auch den Weg gehen, einen (weiteren) RTS-Systemdienst zu implementieren, der den Datenaustausch handled. Ich kann aber den dafür notwendigen Aufwand nicht abschätzen. Vielleicht hat ein Experte der Fa. Kunbus dazu noch eine gute Idee?

lg
Walter