Übertragungsabbruch, z. T. nach Stunden

Hier werden Themen zur Elektronik und Abgleich des Port-Motherboards ADA-IO und seiner Tochterplatinen IO8-32, Optoschaltstufe, AD16-8 und DA12-8 diskutiert.
Niclas
kann c't-Lab-Bausätze bestellen
kann c't-Lab-Bausätze bestellen
Beiträge: 10
Registriert: 25.10.2017, 11:04

Übertragungsabbruch, z. T. nach Stunden

Beitrag von Niclas »

Hallo,
ich betreibe ein c't-Lab, bestehend aus IFP, ADA-C mit IO8-32+AD10+AD16+DA12 und 2x DCG in genannter Reihenfolge am Opto-Bus in einem Prüfstand. Eine zyklische Datenabfrage der IOs und aller Kanäle des AD16 im 100 ms Intervall funktioniert an sich problemlos. Jedoch kommt es, manchmal äußerst selten und erst nach Stunden, manchmal aber auch mehrfach pro Stunde zu sporadischen Abstürzen des c't-Lab in der Form, dass eine Übertragungseinheit im Format #x:y=z vor 'NewLine' stehen bleibt. Manchmal kommen noch in größeren Abständen einige weitere Zeichen hinterher, wie aus einem verstopften Kanal. Dies konnte ich durch Mithören der RS-232-Ein- und -Ausgänge mittels Terminal auf einem weiteren Rechner sicher feststellen.
Zu irgendwelchen EMV-Störern in der Umgebung konnte kein Zusammenhang gefunden werden. Auch die Erd- und Masseführung ist überall korrekt und ohne Schleifen, das Ganze in einem 19"-Gehäuse. Beim Oszilloskopieren der RS-232-Signale finden sich kräftige und störfreie Impulse von ca. +/- 10 V.
Die Firmware ist jeweils auf dem letzten veröffentlichten Stand.
Die Software am PC lässt sich mit Time-Out u. dgl. abfangen, einen Neustart der Controller des c't-Lab bekommt man aber über die Schnittstelle leider nicht initiiert - schade. Mir bleibt derzeit nur, das Gerät für einige Sekunden auszuschalten und neu zu starten. Dadurch ist die angefangene (z. T. länger) laufende Messserie aber unbrauchbar.
Meine Fragen an die Gemeinde:
- Hat jemand ähnliche Erfahrungen gemacht und möglicherweise eine Lösung gefunden?
- Gibt es vielleicht doch einen mir unbekannten Weg, die Controller vom PC aus zurückzusetzen und neu zu starten?
Ich bin für jeden Hinweis dankbar.
Niclas
dg1vs
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 138
Registriert: 20.12.2009, 22:26

Re: Übertragungsabbruch, z. T. nach Stunden

Beitrag von dg1vs »

Hallo Niclas,

ein zwei kurze Fragen zum Thema:
- Pascal oder C-Firmware?
- Tritt das Probme beim ADA-C oder DCG auf?

Gruß Karsten
Niclas
kann c't-Lab-Bausätze bestellen
kann c't-Lab-Bausätze bestellen
Beiträge: 10
Registriert: 25.10.2017, 11:04

Re: Übertragungsabbruch, z. T. nach Stunden

Beitrag von Niclas »

Hallo Karsten,
ich verwende direkt den Hexcode, der gemeinsam mit Pascal-Quellcode im zip-File steht, also
- ADA-C.zip vom 07.03.2008 mit ADA-C.hex (28.11.2007) und ADA-C.eep (17.09.2007), zeigt V. 1.742 an,
- DCG.zip vom 07.03.2008 mit DCG.hex (18.10.2007) und DCG_12.eep (18.10.2007), zeigt V. 2.92 an.
Vermutlich ist das also Pascal-Quellcode, selbst compiliert hatte ich aber nicht.
Vorher waren es übrigens die Versionen 1.732 und 2.821, die aber bereits das gleiche Problem zeigten.
Das beschriebene Problem tritt bei der zyklischen Datenerfassung vom ADA-IO auf, wobei in ständig wiederkehrender Folge (100 ms) ein Paket aus den PIO-Ports und dem ADC mit mehreren Kanälen abgefragt und eingelesen wird. Es sind auch genügend Zeitreserven vorhanden, die Abfrage und Übertragung eines Pakets aus allen Messwerten benötigt inkl. Wartezeiten ca. 45 ms.
Die beiden DCG werden auch sporadisch in größeren Abständen mit veränderten Einstellwerten beschrieben, hier besteht aber eindeutig kein Zusammenhang zu den Abstürzen.
Auch in einem anderen Exemplar, wo nur ADA-IO ohne ADC-16 und keine DCG enthalten sind, beobachte ich im Dauerlauf ähnliche Abstürze, manchmal ein-zwei-malig am Tag, manchmal gar nicht.
Eigentlich sieht es "gefühlsmäßig" nach EMV-Störimpulsen aus, habe aber bereits viele Versuche mit vorsätzlichen Schalt- und Hochspannungsimpulsen unternommen, ohne dass ein Zusammenhang zu finden war.
Am besten wäre das Problem wohl durch Abfangen der Fehlerzustände, Neustart der Hardware und kontrolliertes Fortsetzen der unterbrochenen Prozesse zu lösen, wenn es bspw. ein Rücksetzkommando über die Schnittstelle gäbe, das im Fehlerfall auch noch ausgewertet wird...
Gruß Niclas
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 942
Registriert: 25.01.2008, 23:34

Re: Übertragungsabbruch, z. T. nach Stunden

Beitrag von psclab38 »

Hallo Niclas,

die Original.Pascal Firmware verlangt keine Adresse, damit fällt eine grundsätzlich Formatprüfung weg. Wenn da mal ein Zeichen verloren geht, könnte sie sich verschlucken.
Hast Du den Checksummen-Modus verwendet? Also $ und XOR-Checksumme angehängt?

Wenn das auch nix hilt, dann probiere die C-Firmware aus, da wird zusätzlich die Adresse verlangt.

Gruß
Paul
Niclas
kann c't-Lab-Bausätze bestellen
kann c't-Lab-Bausätze bestellen
Beiträge: 10
Registriert: 25.10.2017, 11:04

Re: Übertragungsabbruch, z. T. nach Stunden

Beitrag von Niclas »

Hallo Paul,
nein, den Checksummenmodus verwende ich bisher nicht, um Übertragungskanal und Controller zu entlasten. Wie gesagt, die Schnittstelle selbst scheint (!) doch sehr sicher und stabil zu laufen. Aber wer weiß das genau?
Die von Dir vermutete Kausalität wäre für mich nur so vorstellbar, dass ein Abfragestring in Richtung c't-Lab fehlerhaft ankommt und der Controller hierdurch festfährt, wonach ein gerade vom c't-Lab gesendeter String angehalten wird. Erscheint mir nicht sehr wahrscheinlich, aber ich werde auf jeden Fall einmal den Prüfsummenmodus versuchen, die zeitlichen Reserven sollten dafür reichen.
Nicht verstanden habe ich den Adressencheck in der C-Software. Wird nicht auch in meiner Version von jedem Modul die Adresse der Strings geprüft, bevor er sich "angesprochen fühlt'? Die bei mir verwendete Syntax lautet für jeden Abfragestring
<MainChan>:<SubChan>?
wobei beide Adressen stets als numerisches Ergebnis, also nicht über Mnemonik und Argument, ausgegeben werden und stets vollständig, also nicht verkürzt ohne MainChan, gesendet werden.
Kannst Du bitte noch mal kurz den Unterschied zur C-Software und den Einfluss auf die Übertragungssicherheit erläutern, bzw. mitteilen, wo ich das nachlesen kann?
Vielen Dank
Niclas
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 942
Registriert: 25.01.2008, 23:34

Re: Übertragungsabbruch, z. T. nach Stunden

Beitrag von psclab38 »

Hallo Niclas,

die C-Firmwaren erwarten <MainCh>: vor jedem Kommando, sonst verwerfen sie es bis zum nächsten CrLf.

Bei der Pascal-Variante ist das optional. Ich hatte seinerzeit auch Zuverlässigkeitsprobleme damit, drum habe ich das bei der C-Firmware geändert. Ich kann mich aber nicht mehr an alle Details erinnern, da müßte ich selbst nachschauen.

Gruß
Paul
Niclas
kann c't-Lab-Bausätze bestellen
kann c't-Lab-Bausätze bestellen
Beiträge: 10
Registriert: 25.10.2017, 11:04

Re: Übertragungsabbruch, z. T. nach Stunden

Beitrag von Niclas »

Hallo Paul, Hallo Karsten,
vielen Dank für Eure Hinweise. Ich habe jetzt erstmal zwei Optionen, die ich nacheinander ausprobieren werde. Anschließend werde ich dann an dieser Stelle über meine Erfahrungen berichten.
Bis dahin
Niclas
Benutzeravatar
Bart
kann c't-Lab-Bausätze löten
kann c't-Lab-Bausätze löten
Beiträge: 45
Registriert: 11.01.2014, 10:44

Re: Übertragungsabbruch, z. T. nach Stunden

Beitrag von Bart »

Damit die Übertragung fehlerfrei funktioniert, müssen ja alle Busteilnehmer mitmachen.
Hast Du mal geschaut, ob die Einzelgeräte im Fehlerfall noch funktionieren (über das Bedienpanel)?

Desweiteren würde ich mir zur Fehlersuche einen Zwischenstecker für den Optobus bauen und den der Reihe nach zwischen die Baugruppen hängen um mit dem Oszi zu sehen an welcher Stelle die Kommunikation hängt.

Bart
Niclas
kann c't-Lab-Bausätze bestellen
kann c't-Lab-Bausätze bestellen
Beiträge: 10
Registriert: 25.10.2017, 11:04

Re: Übertragungsabbruch, z. T. nach Stunden

Beitrag von Niclas »

Hallo Bart,
meine Geräte haben kein Bedienpanel, weil es für die vorgesehenen Zwecke eigentlich nicht erforderlich ist. Im Fehlerfall wäre das natürlich hilfreich.
Eine systematische Fehlersuche am Optobus ist hier deshalb so kompliziert, weil der Fehler immer nur sporadisch und mitunter sehr selten auftritt. Allerdings hatte ich vor längerer Zeit schon einmal die übrigen Baugruppen abgeklemmt und nur noch ADA-IO am Bus - Ausfälle traten damit auch auf.
Ich habe mittlerweile 5 Geräte in verschiedenen Konfigurationen und an unterschiedlichsten Rechnern und manchmal tagelang im Einsatz, überall tritt das Problem irgendwann auf, manchmal läuft es aber auch mehrere Tage ohne Ausfall. Die ADA-IO ist dabei immer anwesend. Ich denke deshalb, dass es nichts exemplarisches ist und doch irgendwo noch ein Bug drinsteckt, der nur beim seltenen Zusammenspiel bestimmter Ereignisse wirksam wird.
Ich werde jetzt zunächst die o. g. Maßnahmen versuchen und dann wieder berichten.
Danke
Niclas
Niclas
kann c't-Lab-Bausätze bestellen
kann c't-Lab-Bausätze bestellen
Beiträge: 10
Registriert: 25.10.2017, 11:04

Re: Übertragungsabbruch, z. T. nach Stunden

Beitrag von Niclas »

Hallo Paul,
die implementierte Prüfsummenbehandlung brachte keine Verbesserung.

Es gibt aber neue Erkenntnisse, die den Verdacht auf einen Firmware-Bug erhärten:
Sobald das geschilderte Problem einmal auftritt, ist eine "Verzögerungsleitung" von ca. 219..225 Zeichen (also etwas unter 256 Byte) wirksam, die folgendes bewirkt:
- Werden vom Host die Zyklen der Wertanforderungen unterbrochen, so bleibt die Ausgabe bei einer weiter zurückliegenden Antwort (z. B. 20 Zeilen vorher) stehen. Gibt man jetzt verschiedene Setzbefehle aus (egal an welche Moduladresse), so kommen die fehlenden Antwortzeilen stückweise zum Vorschein, bis schließlich der vermeintliche Puffer leer ist. Dann gibt es keine Antwort mehr auf Setzbefehle (ohne '!').
- Werden jetzt wieder Wertanforderungen gesendet, so braucht die erste Antwort zunächst wieder ca. 20 Zeilen bis etwas zu sehen ist, also das Verhalten eines vorher geleerten FIFOs.
- Das geschilderte Verhalten bleibt sogar bestehen, wenn eine andere Anwendung gestartet wird und verschwindet erst nach einem Neustart von c't-Lab.

Ohne je in den Quellcode gesehen zu haben habe ich den Verdacht, dass hier ein nicht korrekt behandelter Überlauf der Zeigeradresse bei 256 Byte auftritt und es hierdurch zu einem fehlerhaften festen Abstand zwischen Schreib- und Lesezeiger kommt (evtl. Formatfehler?), der erst bei einem Neustart wieder beseitigt wird. Nach wie vor unklar ist aber, wodurch das ausgelöst wird - vielleicht eine unsaubere Interruptbehandlung?

Nun habe ich ja gesehen, dass Du den Quellcode auf C portiert hattest, und sehe die Chance, dass der vermeintliche Fehler nicht mit übernommen wurde. Da hätte ich nun großes Interesse, diese Version alternativ zu versuchen. Kannst Du sie mir bitte versuchsweise - am einfachsten im HEX-Code - zur Verfügung stellen?
Vielen Dank
Niclas
dg1vs
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 138
Registriert: 20.12.2009, 22:26

Re: Übertragungsabbruch, z. T. nach Stunden

Beitrag von dg1vs »

Hallo Niclas,

bin auf dem Sprung --> nur kurze Antwort.

Schau unter
http://dcg-firmware.cvs.sourceforge.net/
http://dcg-firmware.cvs.sourceforge.net ... -firmware/
bzw im git
https://sourceforge.net/p/dcg-firmware/ ... -firmware/

da hast Du alles. Auch die Quellen um im Zweifelsfall zusätzliche Debug-Infos einzubauen. Das geht bei der Pascal-Firmware leider nur mit finanziellen Aufwand

Grüße und viel Glück

Karsten
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 942
Registriert: 25.01.2008, 23:34

Re: Übertragungsabbruch, z. T. nach Stunden

Beitrag von psclab38 »

Hallo Niclas,

ich habe gestern in ein paar alten Threads hier im Forum gestöbert und da sind mir alte Klagen zur Original-ADA-Firmware aufgefallen. Ich hab aber leider die Links nicht notiert, da scheint aber was nicht ganz hasenrein zu sein.

Die Pascal-FW wurde mit einem kommerziellen Compiler entwickelt, den hier keiner hat. Also wird's bei Änderungen schwierig.

Die ADA-C-Firmware habe ich mal aus Spielerei portiert, aber nie ersthaft eingesetzt. Wenn's Probleme gibt, dann bitte melden. Meine ADA-Hardware ist zwar grade in einem Umzugskarton, aber ich würde schon die FW-Pflege unterstützen.

Mit dem "ParamBackupRestore.vi" von der alten FW die Parameter abziehen, dann den Controller löschen (Flash+EEPROM), das C-Hexfile einspielen und die Parameter wieder mit dem "ParamBackupRestore.vi" zurückspielen. So geht die Kalibrierung nicht verloren, zumindest ist das die Idee.

Die Links für das C-Repository hat Dir ja Karsten schon genannt.

Grüße
Paul
Niclas
kann c't-Lab-Bausätze bestellen
kann c't-Lab-Bausätze bestellen
Beiträge: 10
Registriert: 25.10.2017, 11:04

Re: Übertragungsabbruch, z. T. nach Stunden

Beitrag von Niclas »

Hallo Karsten, Hallo Paul,
danke für Eure Hinweise. Die HEX-Files habe ich geladen, die C-Quellen konnte ich allerdings nicht finden.
Werde nun erst einmal testen und in den nächsten Tagen berichten.
Viele Grüße
Niclas
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 942
Registriert: 25.01.2008, 23:34

Re: Übertragungsabbruch, z. T. nach Stunden

Beitrag von psclab38 »

Hi Niclas
Niclas hat geschrieben:... die C-Quellen konnte ich allerdings nicht finden.
Eigentlich ganz einfach
http://dcg-firmware.cvs.sourceforge.net/
bzw.
https://sourceforge.net/p/dcg-firmware/ ... ster/tree/
da hat dann jede Firmware ihr Verzeichnis für die C-Quellen, z. B. ada:
https://sourceforge.net/p/dcg-firmware/ ... /tree/ada/

Grüße
Paul
Zuletzt geändert von psclab38 am 29.10.2017, 14:14, insgesamt 1-mal geändert.
Niclas
kann c't-Lab-Bausätze bestellen
kann c't-Lab-Bausätze bestellen
Beiträge: 10
Registriert: 25.10.2017, 11:04

Re: Übertragungsabbruch, z. T. nach Stunden

Beitrag von Niclas »

Eigentlich ganz einfach - ja, wenn man's weiß. Mir war die Struktur nicht klar, aber jetzt ist es einfach.
Danke!
Niclas
Antworten