TIA Bit 4 in übertragenem Array of Bool ist immer FALSE

[Zombie]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi, wir übertragen einen Datensatz über die TSend Funktion von einer Steuerung auf eine andere. Darunter ist auch ein Array of Bool [1..70].

In diesem Bool Array ist Bit 4 in der empfangenen Steuerung immer False, obwohl es in dem Datensatz, aus dem der TSEND Baustein auf der sendenden Steuerung liest TRUE ist.
Von einer Baugleichen Steuerung, die den selben Datensatz sendet ist es das gleiche Phänomen.
Die Bits werden in der Empfangenen Steuerung nur gelesen, nie geschrieben.

TIAV16 Upd5

Gibt es da ne Lösung?

Danke

 

[PN/DP]

Da gibt es vermutlich Adress-Überschneidungen mit anderen schreibenden Speicherzugriffen? Beim Sender oder beim Empfänger. Oder die Zwischenpufferungs-Logik ist fehlerhaft?
Welche CPUen mit welcher Firmware sind da beteiligt?

Harald

 

[MFreiberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin Zombie,

können wir davon ausgehen, dass bei anderen Bits des Arrays schon ein "true" übertragen wurde?
Wurde jedes Bit geprüft (wie @PN/DP schon anmerkte, wird es sich um Adressüberschneidungen handeln, wenn auszuschließen ist, dass die Kommunikation nicht funktioniert)?

BTW: ein Array[1..70] of Bool ist nicht gerade elegant.
1. sollte das ArrayLänge glatt durch 16 teilbar sein (es gibt Ausnahmen, aber selten!)
2. sollte das Array mit Index 0 beginnen (es gibt Ausnahmen)

Wenn bei Dir eine Ausnahme greift, vergiss, was ich geschrieben habe. Ansonsten definiere das Array vielleicht so:
Array[0..63] of Bool
Array[0..79] of Bool

Gerade in der Kommunikation zu anderen Geräten ist es empfehlenswert, Datenbereiche auf voll Byte (besser: volle Word) aufzufüllen.

VG

MFreiberger

 

[MFreiberger]

Moin Zombie,

wenn vorher auch schon Arrays mit Länge != ganze Byte/Word deklariert sind, kann es auch daran liegen.
Dann würde ein nachfolgendes Array ggf. von Bits überschrieben, die Du nicht deklariert hast, die aber adressiert sind.

VG

MFreiberger

 

[Zombie]

Hi, einmal 1517 V2.8 und mehrmals 1214C V4.4

Inwiefern Zwischenpufferungs- Logik?

Auf Überscheidungen haben wir alles kontrolliert. Wir haben einen FC, der Sicherungen und sonstige Sachen abfragt und dann in einem DB- Array Bits setzt. Das fertige Array wird am Ende des FCs in den DB kopiert, aus welchem der TSEND Baustein seinen zu sendenden Datensatz entnimmt.

Auf der empfangenden Steuerung wird der Datensatz empfangen und ausgelesen. wir können über die Querverweise keinen schreibenden Zugriff auf den ganzen DB finden, in den der TRCV Baustein den Datensatz einträgt.

Und ja, Bits 3 und 5 werden geschrieben, sowie die anderen Bits, die wir wild getestet haben.
Warum das Array 70 lang ist, kann ich leider nicht sagen, ich hab das auch nur geerbt. (Man hätte ja 80 nehmen können, wäre auch Rund gewesen).

 

[MFreiberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Und ja, Bits 3 und 5 werden geschrieben, sowie die anderen Bits, die wir wild getestet haben.

Ruhig, Brauner! Das können wir ja nicht wissen. Aber das zeigt ja schon einmal, dass die Kommunikation funktioniert

Warum das Array 70 lang ist, kann ich leider nicht sagen, ich hab das auch nur geerbt.

Ok. Kann man das ändern?

(Man hätte ja 80 nehmen können, wäre auch Rund gewesen).

Jo, hatte ich ja auch vorgeschlagen:

Array[0..79] of Bool

VG

MFreiberger

 

[UDP]

Andere Kommunikationen dir irgendwo rein fummeln? Ich denke bei sowas immer an missbräuchlich verwendetes get.

Kannst du sonst mal das Programm von beiden Seiten zeigen? Arbeitest du mit einem Zwischenpuffer? Das heißt: Empfangene Daten werden in einem DB gespeichert und sobald TSEND sagt, dass es neue Daten gibt in den Ziel DB kopieren?

/edit: Aus Interesse: Wie ist die Zykluszeit der CPUs und wie ist die Kommunikationslast in der HW-Konfig eingestellt?

 

[Zombie]

Wir haben mal temporär auf 72 geändert und es hat sich nichts am verhalten geändert.
Da das ein Standard Produkt ist kann das leider nicht so bleiben, da das mit der nächsten Stelle inkompatibel wäre. Leider.

Get benutzen wir nicht. Und einen Zwischenpuffer haben wir nicht. Zykluszeit ist im Mittel bei 2,3ms mit Ausschlägen auf 6ms und Kommunikationslast ist bei 50%.

Die Sache mit den Größen auf volle Bytes wäre ja verständlich. Der DB in den die Daten geschrieben werden ist aber Absolut aufgebaut, d.h. der Sendebereich hat die Größe auf ganze Bytes aufgerundet, obwohl ihm ein paar Bits fehlen um wirklich voll zu sein. 140 Empfangen und 56 Senden.

Ich werd das an den Kollegen schicken der das damals gemacht hat und die Anmerkungen wegen den Arraygrößen weitergeben. Kann ja eigentlich nicht schaden den Platz den wir eh im DB brauchen auch voll zu nutzen.

Danke an euch

 

[MFreiberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wir haben mal temporär auf 72 geändert und es hat sich nichts am verhalten geändert.

Ok. Allerdings hatte ich eher an vorhergehende Deklarationen in dem Datenbereich gedacht, dich auch entsprechend unsauber sind.

Da das ein Standard Produkt ist kann das leider nicht so bleiben, da das mit der nächsten Stelle inkompatibel wäre. Leider.

Da sollte man sich dringend Gedanken machen, ob der Standard(!) so bleiben soll oder überarbeitet gehört.

Get benutzen wir nicht. Und einen Zwischenpuffer haben wir nicht. Zykluszeit ist im Mittel bei 2,3ms mit Ausschlägen auf 6ms und Kommunikationslast ist bei 50%.

Das wird auch nicht der Fehler sein, wenn es nur einzelne Bits betrifft.

Die Sache mit den Größen auf volle Bytes wäre ja verständlich. Der DB in den die Daten geschrieben werden ist aber Absolut aufgebaut, d.h. der Sendebereich hat die Größe auf ganze Bytes aufgerundet, obwohl ihm ein paar Bits fehlen um wirklich voll zu sein. 140 Empfangen und 56 Senden.

Kannst Du mal einen Screenshot von dem DB auf der Sendeseite und dem DB auf der Empfangsseite einstellen?

BTW: Zu meiner Schande muss ich gestehen, dass ich gerade ein ähnliches Problem hatte. Bei mir waren Eingangsadressen mehrfach (für mehrere Variablen) vergeben !@#$ - copy&paste!!!
Da die kopierten Variablen aber nicht verwendet wurden, da dieser Teil noch nicht programmiert ist, bin ich einfach nicht drauf gekommen.

Kurz&Gut: Die wahrscheinlichste Ursache ist, dass Daten doppelt beschrieben werden.


VG

MFreiberger

 

[UDP]

Wir haben mal temporär auf 72 geändert und es hat sich nichts am verhalten geändert.
Da das ein Standard Produkt ist kann das leider nicht so bleiben, da das mit der nächsten Stelle inkompatibel wäre. Leider.

Get benutzen wir nicht. Und einen Zwischenpuffer haben wir nicht. Zykluszeit ist im Mittel bei 2,3ms mit Ausschlägen auf 6ms und Kommunikationslast ist bei 50%.

Die Sache mit den Größen auf volle Bytes wäre ja verständlich. Der DB in den die Daten geschrieben werden ist aber Absolut aufgebaut, d.h. der Sendebereich hat die Größe auf ganze Bytes aufgerundet, obwohl ihm ein paar Bits fehlen um wirklich voll zu sein. 140 Empfangen und 56 Senden.

Ich werd das an den Kollegen schicken der das damals gemacht hat und die Anmerkungen wegen den Arraygrößen weitergeben. Kann ja eigentlich nicht schaden den Platz den wir eh im DB brauchen auch voll zu nutzen.

Danke an euch

Um die doppelte Adressierung auszuschließen, ist das gleiche Verhalten, wenn die Daten in einen Puffer-DB geschrieben werden, statt direkt ins Ziel?

 

[Zombie]

Ich durfte mir gerade eine Standpauke anhören. Legacy Code, das muss so, wird nicht angefasst und nicht hinterfragt und vor allem nicht von dir!!!!!!!!!!!! Gott, der wäre fast aus dem Telefon geklettert.

Anscheinend wird damit was maskiert das über einen Pointer??? zusammengebaut ist. Kann Tia überhaupt Pointer? Ich kann echt keinen Zugriff finden. Schlimm sowas.

Ich werde nochmal nachfragen, wenn ich wieder im Büro bin und mein Involvement mit dieser Sache überdacht ist.

Danke an euch.

 

[UDP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenns keine 1200er ist, kann man auch in 1500ern AWL nutzen und fleißig unsymbolisch pionter zur Laufzeit zusammenbasteln. Sollte man das tun? Nicht, wenn es sich vermeiden lässt, es gibt nahezu für jedes Problem eine besser lesbare und elegantere Lösung in SCL, die dann auch nebenbei noch vollsymbolisch verwendet werden kann.

Oder man bleibt halt beim AWL-Pointern und muss sich dann halt vom Kunden schlecht wartbaren Code vorwerfen lassen, weil da eben nicht mal schnell jeder Instandhalter rein schauen kann um das Problem zu finden.

/edit: Um rauszufinden ob es am Empfangsbaustein liegt oder ob es einen weiteren Pointerzugriff im restlichen Programm gibt, häng mal einen neuen Empfangs-DB an den Empfangsbaustein und schau ob der Fehler mitwandert.

 

[PN/DP]

Ich durfte mir gerade eine Standpauke anhören. Legacy Code, das muss so, wird nicht angefasst und nicht hinterfragt und vor allem nicht von dir!!!!!!!!!!!!

Leider gibt es hier kein Mitgefühl-Like, sonst würde ich Dir eines geben.
Dann kann dieser Programmierer ja den Fehler suchen oder wenigstens dabei helfen.

Um die doppelte Adressierung auszuschließen, ist das gleiche Verhalten, wenn die Daten in einen Puffer-DB geschrieben werden, statt direkt ins Ziel?

Ja, ich würde auch empfehlen, die Sendepuffer/Empfangspuffer für TSEND/TRCV einfach auf andere DB zu legen. Oder sind schon die Bausteine mit den TSEND/TRCV Eure Standardbausteine, die Du verwenden musst und nicht anfassen darfst?

Ich würde versuchen, an die Sendepuffer und Empfangspuffer heranzukommen und Kopien zu machen, bevor der Code mit TSEND/TRCV da drankommt. Um zu zeigen, daß das Bit vor dem Senden bzw. vor der Empfangsauswertung noch korrekt ist.

Harald

 

[Zombie]

Ich hab das mal schnell gemacht. Wandert nicht mit. Wird also definitiv im Baustein gemacht, nachdem das TRCV seine Arbeit vollendet hat.
Der Sinn erschließt sich mir nicht. Könnte mir denken, dass das ein Lifebit von hinten durchs Auge ist.

Wenns keine 1200er ist, kann man auch in 1500ern AWL nutzen und fleißig unsymbolisch pionter zur Laufzeit zusammenbasteln. Sollte man das tun? Nicht, wenn es sich vermeiden lässt, es gibt nahezu für jedes Problem eine besser lesbare und elegantere Lösung in SCL, die dann auch nebenbei noch vollsymbolisch verwendet werden kann.

Oder man bleibt halt beim AWL-Pointern und muss sich dann halt vom Kunden schlecht wartbaren Code vorwerfen lassen, weil da eben nicht mal schnell jeder Instandhalter rein schauen kann um das Problem zu finden.

/edit: Um rauszufinden ob es am Empfangsbaustein liegt oder ob es einen weiteren Pointerzugriff im restlichen Programm gibt, häng mal einen neuen Empfangs-DB an den Empfangsbaustein und schau ob der Fehler mitwandert.

Ich werde genau das ansprechen, sobald ich wieder im Büro bin. Sowas geht ja mal gar nicht. ÜÜÜÜberhaupt nicht.

 

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie kann man eigentlich ohne Sende- und Empfangspuffer eine Datenkonsitenz gewährleisten?

 

[Zombie]

Wie kann man eigentlich ohne Sende- und Empfangspuffer eine Datenkonsitenz gewährleisten?

In dem Fall muss man das nicht. Die Daten haben nichts miteinander zu tun.

 

[UDP]

Prinzipiell tut man sich aber schon einen Gefallen, wenn man immer mit konsistenten Daten arbeitet. So ein Puffer-DB tut nicht weh, außerdem ist dann auch schnell für andere sichtbar, wo die Daten herkommen

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie kann man eigentlich ohne Sende- und Empfangspuffer eine Datenkonsitenz gewährleisten?

In dem Fall muss man das nicht. Die Daten haben nichts miteinander zu tun.

In den Empfangspuffer vom TRCV können die Empfangsdaten-Bytes über mehrere Zyklen verteilt "eintrudeln". In den Daten-Bytes sind aber bestimmt Variablen mit Mehrbyte-Datentypen enthalten - da kann es vorkommen daß die Bytes einer Variable in verschiedenen Zyklen eintreffen. Daher darf man die Daten im Empfangspuffer nur in dem Zyklus auswerten/wegkopieren, wenn der TRCV NDR meldet.

Harald