Ruhig, Brauner! Das können wir ja nicht wissen. Aber das zeigt ja schon einmal, dass die Kommunikation funktioniertUnd ja, Bits 3 und 5 werden geschrieben, sowie die anderen Bits, die wir wild getestet haben.
Ok. Kann man das ändern?Warum das Array 70 lang ist, kann ich leider nicht sagen, ich hab das auch nur geerbt.
Jo, hatte ich ja auch vorgeschlagen:(Man hätte ja 80 nehmen können, wäre auch Rund gewesen).
Array[0..79] of Bool
Ok. Allerdings hatte ich eher an vorhergehende Deklarationen in dem Datenbereich gedacht, dich auch entsprechend unsauber sind.Wir haben mal temporär auf 72 geändert und es hat sich nichts am verhalten geändert.
Da sollte man sich dringend Gedanken machen, ob der Standard(!) so bleiben soll oder überarbeitet gehört.Da das ein Standard Produkt ist kann das leider nicht so bleiben, da das mit der nächsten Stelle inkompatibel wäre. Leider.
Das wird auch nicht der Fehler sein, wenn es nur einzelne Bits betrifft.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%.
Kannst Du mal einen Screenshot von dem DB auf der Sendeseite und dem DB auf der Empfangsseite einstellen?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.
Um die doppelte Adressierung auszuschließen, ist das gleiche Verhalten, wenn die Daten in einen Puffer-DB geschrieben werden, statt direkt ins Ziel?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
Leider gibt es hier kein Mitgefühl-Like, sonst würde ich Dir eines geben.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!!!!!!!!!!!!
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?Um die doppelte Adressierung auszuschließen, ist das gleiche Verhalten, wenn die Daten in einen Puffer-DB geschrieben werden, statt direkt ins Ziel?
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.
In dem Fall muss man das nicht. Die Daten haben nichts miteinander zu tun.Wie kann man eigentlich ohne Sende- und Empfangspuffer eine Datenkonsitenz gewährleisten?
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.In dem Fall muss man das nicht. Die Daten haben nichts miteinander zu tun.Wie kann man eigentlich ohne Sende- und Empfangspuffer eine Datenkonsitenz gewährleisten?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?