ID-Dreher bei Kommunikation über NET_VAR_CONTROL

PC WorX
1

Eine frühmorgendliche Störungs-SMS schreckte mich auf, kein Warmwasser im Block, da Temperaturanforderung an Kesselanlage im Nachbarhaus via NET_VAR_CONTROL + NET_VAR_REAL8 nach jahrelangem Betrieb nicht mehr funktionierte. Ich hatte beide Programme gestern angefasst, allerdings nicht das NET_VAR_CONTROL - Arbeitsblatt.
Weitere Ursachenforschung ergab, dass zwischen Master und Slave die ID-Nummern der Bausteine NET_VAR_REAL8 und NET_VAR_BOOL8 (für den gesamten Datenaustausch zwischenden beiden Stationen) neuerdings vertauscht waren:
Master ILC130: NET_VAR_BOOL8 ID= 01 (noch korrekt)
Slave ILC155: NET_VAR_BOOL8 ID= 02 (vertauscht)
So weit Symptom und wahrscheinlich Problemursache in einem:
Master ILC130: Error 16#0000FF00 (Timeout)
Slave ILC155: Error 16#00000002 (ID2 falsch parametriert).

Mit simplen Tricks gelang es mir nicht, das auf der Slave-ILC155 wieder in die richtige Reihenfolge zu bringen, eigentlich ist mir auch schleierhaft, wie die ID (vom NET_VAR_CONTROL?) festgelegt wird.
Um die Anlage aus dem Provisoriumsbetrieb zu bekommen habe ich für die ILC155 eine Vorgänger-Programmversion von Anfang 2014 (WORXEXPRESS-Version 6.20.331) reaktiviert, die funktionierte sowohl nach Einspielen mit WORXEXPRESS-Version 6.20.331 als auch nach Re-Build mit 6.30.1202 einwandfrei, als Nebeneffekt funktionierte auch gleich eine andere Kommunikationsverbindung über SPIDER_ACCESS wieder.
Das ist alles etwas rätselhaft, allerdings hatte ich schon bei 2 anderen PC-WORX Express - Projekten merkwürdige Effekte, die nach eingehender Untersuchung im weitesten Sinne mit der Abarbeitungsreihenfolge im Programm zusammenhingen.

Meine Fragen
a) Wie bekomme ich ganz allgemein die ID der NET_VAR_ in die Richtige Reihenfolge, falls ich an anderer Stelle noch mal über das Problem stolpere? Abarbeitungsreihenfolge der FB im Arbeitsblatt war nach meinen Versuchsergebnissen unbeteiligt,
b) Kennt ein WORX-Nutzer diese Abarbeitungsreihenfolgen-Problematik (die vielleict auch gar nichts mit dem Kommunikationsproblem hier zu tun hat)?

2

hallo

die id nummern werden nur durch die abarbeitungsreihenfolge festgelegt

wenn du grafisch programmierst und einen baustein unter den anderen setzt dann sollte dieser nach den oberen aufgerufen werden

so wie es aussieht ist die reihenfolge nicht mehr die richtige

3

Irgendwie ist in der Kombination Phoenix-ILC / PC-WORX Express / OSCAT NetLib130 gerade der Wurm drin, wobei ich keinesfalls ausschließen kann, dass das Problem durch irgendeine Besonderheit hier bei mir verursacht wird.

Den Behelf aus Posting 19. April 2016, 16:02:45 versuchte ich weiter zu entwicklen, natürlich jede Neuerung in neuer Projektversion. Einfach testhalber 2 Spider_ACCES zugriffe in derselben Richtung eingefügt, funktioniert. 3. Drangehängt - Exitus, keiner funktioniert mehr, weg damit.

Alle Versuche übrigens stets nur am Slave!

Dann NET_VAR_CONTROL Variante für Verbindung ausprobiert. In dem Projekt laufen diverse solche Verbindungen problemlos. Habe gznächst als Master die Empfängerseite eingerichtet, dann Slave in der Sender-SPS. Gestartet, geht nicht, stets Error FF000000 oder FD000000 oder 00000001.
Als ich keine Lust mehr hatte habe ich die alte ursprünglich funktionierende Version wieder eingespielt, bei der dann plötzlich die ursprüngliche NET_VAR_CONTROL auch nicht mehr funktionierte, Error 00000001 beim Slave. Hier nun aber kein ID-dreher, die Zuordnung der ID “1” und 22" war bei den Bausteinen NET_VAR_BOOL8 und NET_VAR_REAL8 passig bei Master und Slave.

Also Notfallplan mit Uraltversion in voriger PC-WORX Express Version eingespielt - Läuft auch nicht! Bis hierher also einzige halbwegs sichere Schlussfolgerungen, dass ich bisher nur eine Sammlung von Zufallsbeobachtungen habe, die alle nicht den Kern des Problems im Fokus haben.

Ich habe dann ein paar Kaltstarts am Slave durchgeführt, ohne sonst irgendetwas zhwischen den Kaltstarts an Programm oder Parametern zu ändern:

Standardablauf:

  1. Kaltstart
    » Alle Übertragenen Werte auf 0, NET_VAR_CONTROL RUN = Error = 0
  2. Nach Zeitablauf: NET_VAR_CONTROL:ENABLE → 1
    » Für Sekundenbruchteil RUN = 1 – Error = 0
    Dann RUN = 0 – Error = 00000001, alle Übertragungswerte weiterhin 0

Manchmal:
11) Kaltstart
» Alle Übertragenen Werte auf 0, NET_VAR_CONTROL RUN = Error = 0
12) Nach Zeitablauf: NET_VAR_CONTROL:ENABLE → 1
» Für Wenige Sekundenbruchteile bis Sekunden, RUN = 1 – Error = 0, Werte werden übertragen, scheinen auch “zu leben”
Dann RUN = 0 – Error = 00000001 (Baustein falsche ID), alle Übertragungswerte eingefroren

Dann glückliche Fügung:
21) Kaltstart
» Alle Übertragenen Werte auf 0, NET_VAR_CONTROL RUN = Error = 0
22) Nach Zeitablauf: NET_VAR_CONTROL:ENABLE → 1
» Dauerhaft RUN = 1 – Error = 0, Werte werden übertragen, “leben”
Das bisher die ganze Nacht, wahrscheinlich auf ewig

Dass so ein Kaltstart manchmal zum korrekten Anlauf führt, meistens aber nicht ist ja doch merkwürdig, und die Fehlermeldung noch merkwürdiger, irgendeinen realen Hintergrund kann ich nicht erkennen.

Irgendeine Idee, wie man dem Effekt auf die Schliche kommen kann? die beiden Programme kann ich dir zwar schicken, aber ob sich damit ein Testaufbau realisieren lässt?
Alternativ könnte ich dir natürlich auch mal zugriff auf die Anlage Gewähren, wenn Du meinst, dass direkte BEobachtung des Effekts weiter helfen könnte.

4

hallo

du kannst ja mal dein testprogramm online stellen

aber prinzipiell gilt
die id-nummer werden rein nach der aufrufreihenfolge vergeben

du kannst bei jeden einzelnen baustein online reinschauen und die die lokale variable der id-nummer ansehen
da kannst du mal selber nachsehen welcher baustein welche nummer bekommen hat

5

Beim aktuellen Problem glaube ich nicht daran, dass ein wirkliches ID-Problem besteht, da die Debug-Anzeige ja passt. Interessanter wäre wahrscheinlich zu ergründen, auf welcher Basis NET_VAR_CONTROL RUN zum Ergebnis “Error = 00000001” kommt. Ich kann nur vermutne, dass es um die angezeigte ID eines NET_VAR_BOOL8 oder NET_VAR_REAL8 geht?

Ich stelle kurzfristig die Projekte online, denke allerdings nicht, dass das zu irgendetwas führt.